ウェブアプリケーションを運用する企業にとって、脆弱性診断の実施はもはや不可避となっています。
一方で、今まで脆弱性診断を実施したことが無い場合、何から始めたらよいかわからないという声も良く聞きます。
そこで脆弱性診断サービス/脆弱性診断ツールのサポートの双方を提供しているテクマトリックスから、外部診断を依頼する、または内部診断を実施する際のフローをご案内いたします。

※この項目では主に動的診断を実施する際のフローを説明いたします。
　実際の診断方法やテクニックについては解説いたしませんのでご注意ください。

※本コラム「脆弱性診断ことはじめイントロダクション」の後半はこちらから。

＜目次＞

脆弱性診断の調査

ウェブアプリケーションに対して動的診断を行うとき、診断実施者は診断対象の画面を全て巡回する必要があります。
実際にはクローラーと呼ばれる自動巡回ツールを併用するため、実際に全部の画面を表示するわけではありませんが、クローラーは単純な画面しか巡回できない為、トップページからリンクがつながっていない画面や、入力が必要な画面は人力で巡回するのが最も確実です。
そのため正確に診断を実施するにはウェブアプリケーションの規模や仕様を正確に把握している必要があります。

調査1. 診断範囲を定義する

診断を実施する画面とアクションの一覧を作成します。
「画面一覧」や「URL一覧」とすることもありますが、1画面に複数のアクションがあった場合に乖離が発生するため、「アクション一覧」で作成することを推奨します。
エクセルなどの表に画面一覧と、その画面で操作できることを網羅していくと良いでしょう。

この作業を怠ると...
✖ 診断に必要な工数や期間に乖離が発生します。
✖ テスト漏れが発生します。

調査2. 画面仕様

画面によってはURLを入力しただけでは正しく表示することができません。
特定のデータが存在することが必要だったり、一連の手順として操作を行う必要があるためです。
場合によってはログインするアカウントを切り替えながら「この操作を行えば、この処理を実行できる」というところまで確認しておく必要があります。
アクション一覧を作るときに同時に進めます。

確認内容

• アカウントの確認
• 画面の遷移方法
• 処理に必要なテストデータ

この作業を怠ると...
✖ 診断開始後に問い合わせや確認が発生します。

調査3. 外部への影響

動的診断の特徴は実際に機能を動かして確認することです。
確認のために仕様上正しいデータ、境界ギリギリのデータ、仕様から大きく外れたデータなど様々なテストパターンを実施いたします。
その過程で大量のテストデータが発生するため、以下の例にご注意ください。

1. バックオフィスに大量の通知や注文が発生する
2. 正常/異常なアクセスが大量に発生し、アクセスログや監視ログが大量に増える
3. 連携しているサービスに大量の正常/異常な処理要求が発生する

それぞれ対策として下記が挙げられます。

1. バックオフィスに事前に了解を取る
2. 監視システムを停止、または静観依頼
3. 連携サービスを一時的に停止

この作業を怠ると...
✖ 診断開始後にクレーム発生する恐れがあります。
✖ 監視に引っかかりアクセス断となり、テストが中断します。

効率的に調査する方法
最もベーシックなものとしては画面一覧や画面遷移図です。
ただし上記では画面の表示条件等がわからないこともあるため、画面遷移図を見ながら実際に操作してみるのが一番確実です。
その他、受入テスト/総合テストのテスト計画書も非常に参考になります。

診断計画

診断チームの調整

前項で述べた通り正確に診断を実施するにはウェブアプリケーションの規模や仕様を正確に把握している必要があります。
診断対象の調査で調べた内容を診断チームに共有し、見積もりや診断準備を進めます。

サービス企業の選定/契約(外部診断の場合)

脆弱性診断サービスを行っている企業に見積を依頼します。
サービス企業によっては、事前に診断環境に事前アクセスして見積を行うこともあります。
資料が少なかったり、事前アクセスができない場合調査費用やリスクバッファを上乗せした結果、診断費用が割高になることがあります。
逆に見積りに必要な資料が少なかったり、価格が極端に安い場合は機能の実行までを確認対象としていない場合があります。

この時は金額面も重要ですが、サービス企業が正しく仕様の理解をしているか注意してください。

日程の調整

診断チームと日程の調整を行います。
診断チームより着手開始可能日と診断に必要な日数が提示されるので診断環境の準備を進めておきます。

診断に必要な日数
診断に必要な日数はウェブアプリケーションの仕様とサーバーの応答速度で決まります。

• ウェブアプリケーションの仕様
  下記の要素が増えたり、複雑になる事で「テストケース数」が多くなります。

1. アクション数
2. パラメーターの数
3. 画面遷移の仕様

• サーバーの応答速度
  動的診断は一回の診断で1URLに対し数百～数千のテストパターンを実施します。
  診断全体では数万リクエストから数10万リクエストに上ります。
  仮に10万リクエストに対して平均応答速度が1秒だった場合は約28時間平均応答速度が2秒だった場合には倍の約56時間が必要になる計算です。

今回は診断を実施する際の準備段階をご紹介いたしました。
次回はいよいよ診断を実施する際の流れを解説します。
テクマトリックスでは脆弱性診断サービス/脆弱性診断ツールのサポートの両方を行っていることから外部診断、内部診断を行いたいお客様のニーズに沿ったサービスをご提供しております。
詳しくはこちら【お問い合わせ】よりお気軽にお問合せください。

脆弱性コラム「サイト脆弱性をチェックしよう！」についてはこちらからご確認ください。