
第15回 報告、それは脆弱性検査の「序章」
辻 伸弘
NTTデータ先端技術株式会社
2009/8/3
第14回「ASV検査、ペネトレテスターの思考を追う」では、ASV(Approved Scanning Vendors)という認定試験で遭遇した脆弱性の実例から、ペネトレーションテストとは一体どういうものなのか、そしてペネトレーションテストで用いられる、脆弱性スキャナの「うそと沈黙」について解説させていただいた。
検査者、つまり「人間」は考えることにより、機械や道具には見つけることのできない穴――小さくとも価値があり、千里の堤を崩しかねない一穴――を発見することができるということをご理解していただけたと思う。
2007年7月に公開した第1回「たった2行でできるWebサーバ防御の『心理戦』」から、1年半以上の期間で14回という回数にわたり書かせていただいた。筆者自身、この連載すべてを通して、伝えたいこと、伝えるべきことをすべて出し切ったという感想は持っていない。すべてを出し切るに越したことはないだろう。だが、そのすべてを記すにはあまりにも時間が足りない。
よって今回は、ペネトレーションテスト最後の見せ場である「報告」の部分について、3回に分け語ることにしよう。
ペネトレーションテストの流れ
卒業アルバムでも見るような感じで、過去の記事を一気読みして気付いたのだが、いままでの記事の中で、ペネトレーションテストがどのような流れで進んでいくのかということを紹介したことがなかった。よい機会なので、「報告」について解説する前に、その流れについて紹介しておこう。
ペネトレーションテストの流れといっても、検査自体の流れではなく、1つのペネトレーションテストが案件としてどう始まり、どう終わるのかという流れを紹介する。
大まかには、ペネトレーションテストは下図のような流れで行われる。
![]() |
| 図1 ペネトレーションテストの流れ |
| 【筆者注】 このフロー図はNTTデータ・セキュリティでの流れをもとに作成している |
それでは順を追って簡単に説明していこう。
●(1)提案
ペネトレーションテストの問い合わせをいただき、お客様先で
- どのような脅威を危惧(きぐ)しているのか
- どのようなネットワーク構成となっているのか
などをヒアリングし、「どのような検査をどのような経路でどの対象に行うべきなのか」といった、お客様に合った検査パターンの提案を行う。もちろん、費用面に関する話もこの段階で行われる。
●(2)説明会
検査対象(IPアドレスなども含む)、経路、検査パターン、スケジュールなど、事前にいただいた情報と検査への意識について、相違がないかの確認する。また検査における体制、注意事項、お願い事項などを伝え、質疑応答を行う場を設ける。
注意事項やお願い事項として、検査用に割り当てるIPアドレスなども事前通知し、IDSやIPSなどで検知し、攻撃と判断しない処置を行っていただくことを説明する。ここでは当日の担当者の立ち会い、連絡体制などについても確認する。
●(3)検査
これについては、本記事の読者には説明不要であろう。
脆弱性スキャンなどの自動化されたツール、そして検査者の手と思考、経験をフルに活用し、検査対象上の脆弱性となりうる部分の列挙、実証を行う。詳しい内容は、筆者の過去の記事を参照いただければ幸いである。
●(4)報告書作成
検査の結果を踏まえて、検出、実証された脆弱性についての危険度、説明、対策を記載し、検査対象別の評価や検査全体を通したサマリなどの文書化を行う。検査対象数やその内容にもよるのだが、ペネトレーションテスターとして最も時間を必要とするフェイズである。
●(5)報告会
(4)で作成した報告書をもとに、原則として検査を行ったメンバー自身が報告を行う。
報告会の規模はさまざまだ。筆者が経験したものでは、担当者の方との1対1のような小規模のものもあれば、大きな会議室でプロジェクタを使い、60名程度の関係者を相手に行うものまであった。報告会に要する時間は、検査したシステムの規模や検査結果によって変化するが、ほとんどの場合が60分から90分程度である。
●(6)是正計画立案
検出された脆弱性は、報告会・報告書にて是正方法も併せて報告する。
しかし、報告したもののなかには、運用上是正困難なものや、ほかのソリューションや運用でカバーしているというようなものもある。その内容について、対策する/しないを判断し、対策を行わない理由、状況を踏まえ、是正計画の立案のお手伝いをさせていただく場合がある。
●(7)再検査
(6)の是正計画において、修正、処置を行ったものについて、それが正しく行われているのかを中心に再検査する。基本的には(3)で行った検査の結果をもとにするため、この時点で新たな脆弱性がシステムに内在している可能性はあるが、そちらについては別のものとして扱う。
お客様の中にはこの時点でも初回と同じレベルの検査を要求される場合もあり、その際には別途対応する場合もある。
●(8)是正結果報告
(7)の結果について報告を行う。実際の結果報告では、修正を行ったとしても、検査をしてみると適切に行われていないことが発覚する場合もある。そういった場合には、正しく修正できるようサポートさせていただく場合もある。
また、正しく修正されていなかったものについては再修正後、別途再検査を行う場合もある。
| 【注】 (6)〜(8)についてはすべての検査で行われるとは限らず、お客様が望んだ場合にのみ対応させていただいている。 |
理想的には(1)〜(8)を定期的に実施し、その都度、脆弱性を排除していくようサイクルを回すことが望ましい。しかしながら、費用面などの理由から、このサイクルを回せていないシステムが多いというのが、日々検査を行っている筆者が受ける印象である。
1/3 |
| Index | |
| 報告、それは脆弱性検査の「序章」 | |
| Page1 ペネトレーションテストの流れ |
|
| Page2 報告書で伝えるべきこと 検査範囲のスコープ |
|
| Page3 健康診断結果があなたに指摘すること 脆弱性と向き合い続けるために |
|
セキュリティ対策の「ある視点」 バックナンバー
- 第1回 たった2行でできるWebサーバ防御の「心理戦」
- 第2回 ディレクトリ非表示の意味をもう一度見つめ直す
- 第3回 「Forbidden」「サンプル」をセキュリティ的に翻訳せよ
- 第4回 メールサーバ防御でも忘れてはならない「アリの一穴」
- 第5回 DNS、管理者として見るか? 攻撃者として見るか?
- 第6回 己を知り、敵を知る――Nmapで見つめ直す自分の姿
- 第7回 魂まで支配されかねない「名前を知られる」という事件
- 第8回 魂、奪われた後――弱いパスワードの罪と罰
- 第9回 人の造りしもの――“パスワード”の破られ方と守り方
- 第10回 SNMPコミュニティ名、そのデフォルトの価値は
- 第11回 ハニーポットによるウイルス捕獲から見えてくるもの
- 第12回 プレイバックPart.I:ウイルスのかたち、脅威のかたち
- 第13回 プレイバックPart.II:シフトした脅威の中で
- 第14回 ASV検査、ペネトレテスターの思考を追う
- 第15回 報告、それは脆弱性検査の「序章」
- 第16回 たった1つの脆弱性がもたらすシステムの“破れ”
- 最終回 Q.E.D.――セキュリティ問題を解決するのは「人」
| セキュリティ対策の「ある視点」 連載インデックス |
TechTargetジャパン
- Facebook タイムライン利用時の「鉄則」 (2012/2/9)
ユーザーインターフェイスの変更措置に伴い浮上した、Facebookの「過剰な情報提供」のリスクと対策とは - 無料サービスなら通信内容を記録してもいいの? (2012/1/13)
無料の公衆無線LANサービスが、ユーザーに無断で通信履歴を記録していたことが判明し、話題に - 攻撃はまるでレーザービーム (2011/12/26)
2011年に話題となった標的型攻撃は「人」という弱点ををねらい打ちにしました。では、人に教育さえしておけば防げるものなのでしょうか? - 見せたくないなら「持たせない」が鉄則! (2011/12/15)
逆コンパイル対策で難読化したのに、大事なデータが解析されちゃった? Androidアプリのセキュリティの道は深い
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -

