連載
» 2009年08月03日 00時00分 公開

報告、それは脆弱性検査の「序章」セキュリティ対策の「ある視点」(15)(2/3 ページ)

[辻 伸弘(ソフトバンク・テクノロジー株式会社),@IT]

報告書で伝えるべきこと

 このサイクルを踏まえ、報告書・報告会といった、検査のアウトプットにあたる「報告」の部分についてフォーカスを当てたいと思う。

 世の中にはさまざまな検査を行う企業があり、そのアウトプットもさまざまだ。検査の報告を一度でも受けたことのある方であれば、報告書がどのようなものかはある程度イメージが湧くかもしれないだろう。今回は検査の報告を受けたことのない方のために、おおよその報告書の構成とその内容を説明しよう。

●1.検査内容

 検査内容では、いつ、どのような目的で、どのような検査を、どのような経路から、どの対象に行ったのかの概要が記述されている。また検査の概要として、検査範囲のスコープはどういったものであるのかいったことも記述されている。報告会では、報告内容に関する意識の再すり合わせとして用いる。

●2.検査結果報告

 検査結果報告は、報告書の主となる部分である。ここでは、どのような基準で検査対象を評価しているのか、検査全体を通してどのような傾向があったのかといったサマリを記している。そして検査対象それぞれがどのような状態であったのかといった個別の評価、それを導き出すに至った根拠となる、各検査対象で検出された指摘事項ごとの解説も記載している。

図2 検査結果報告書の例 図2 検査結果報告書の例

●3.侵入証跡

 検査では、さまざまな脆弱性を利用することで侵入を行うこと、または、個人情報のような機密情報が取得可能である場合は珍しくない。そういった場合、どのような手順を踏むことで貫通することが可能であったのかということを報告する。

 これこそ、ペネトレーションテストの醍醐味(だいごみ)ともいえる、生の情報をレポートする部分である。お客様の中には技術的興味が非常に高い方もおり、そのような方には侵入証跡のレポート部分が最も喜ばれる。

図3 脆弱性を利用した侵入証跡レポートの例 図3 脆弱性を利用した侵入証跡レポートの例

●4.付録

 検査中に取得したログが主となっている。ポートスキャンの結果など、報告書の本文中に掲載にするには煩雑になると判断したものを、付録として掲載する。

検査範囲のスコープ

 さて、ペネトレーションテストの報告書についておおよそのイメージはわいただろうか。

 報告会では、この報告書をもとに進めていくのだが、報告の前に筆者が必ずする話がある。それは「検査範囲のスコープ」についてである。

 ペネトレーションテストは、筆者がそれを始めたころからすると、比べものにならないくらいに認知度が向上したと感じている。しかし、お客様との折衝を行う上で、正しい理解がなされていないと感じることの1つがこのスコープである。

 セキュリティ上の問題点は、開発であれ、運用であれ、人によって引き起こされる場合が大分部分を占めている(天災による事業継続性はここでは触れない)。つまりは、セキュリティに対する意識の欠如が問題の発生要因であるといえる。そのセキュリティに対する意識の欠如は、以下のような3つの問題を発生させる。

  • アプリケーションの欠陥
  • 設定の不備
  • 運用の不備

 それぞれを簡単に解説しよう。

●アプリケーションの欠陥

 「アプリケーションの欠陥」は、広義のソフトウェア上に存在する、バッファオーバーフローに代表されるような脆弱性のことを指す。Webアプリケーションでは、パラメータのチェック不足により発生するクロスサイトスクリプティング(XSS)やSQLインジェクションなどの脆弱性のことを指す。

●設定の不備

 「設定の不備」は、利用しているソフトウェアに欠陥はないが、推測可能なパスワードや不要なサービスの稼働、不要な情報の露出のようなコンピュータの設定に起因する脆弱性のことを指す。

●運用の不備

 「運用の不備」はセキュリティポリシーが存在しない、各種のマニュアルの未整備など、管理上の不備を指す。

 検査では、欠陥を抱えたアプリケーションを利用していること、好ましくない設定に起因するセキュリティ上の問題点(脆弱性、セキュリティホール)を検査範囲のスコープとしている。つまり、運用に関する部分に関してはスコープには含まない。

 従って、検査報告の中には、お客様にとってどうしても対応できないような問題が記載されている場合がある。代表的なものは、以下のような理由によるものである。

  • 月に1回リリースされる修正プログラムを適用するにあたり、十分な検証が必要なため適用サイクルを3カ月に一度にしているため、常に最新の状態ではない。
  • ほかのアプリケーションとの連携があるのでバージョンを上げることができない。

 検査者は、以上のようなことを想定はするが、そのような事情を評価に反映させない。つまり、なんらかの理由があって、対策を行うことが現実的ではないため評価を上げる(セキュリティレベルを高い方に倒す)といったことや、指摘そのものを報告書から削除しない。

 運用上の理由とはいえ、対策できないものを指摘するということは、一見不条理にも思えるだろう。筆者もこのことで指摘したほうがよいのか、許容とするべきなのかということを悩んだ時期がある。そこで、健康診断の結果を例に考えてみてほしい。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。