報告、それは脆弱性検査の「序章」：セキュリティ対策の「ある視点」（15）（1/3 ページ）
ペネトレーションテストにおける最後のフェイズ、「報告」。しかしセキュリティの確保という命題において、報告は始まりにすぎないのだ。
第14回「ASV検査、ペネトレテスターの思考を追う」では、ASV（Approved Scanning Vendors）という認定試験で遭遇した脆弱性の実例から、ペネトレーションテストとは一体どういうものなのか、そしてペネトレーションテストで用いられる、脆弱性スキャナの「うそと沈黙」について解説させていただいた。
検査者、つまり「人間」は考えることにより、機械や道具には見つけることのできない穴??小さくとも価値があり、千里の堤を崩しかねない一穴??を発見することができるということをご理解していただけたと思う。
2007年7月に公開した第1回「たった2行でできるWebサーバ防御の『心理戦』」から、1年半以上の期間で14回という回数にわたり書かせていただいた。筆者自身、この連載すべてを通して、伝えたいこと、伝えるべきことをすべて出し切ったという感想は持っていない。すべてを出し切るに越したことはないだろう。だが、そのすべてを記すにはあまりにも時間が足りない。
よって今回は、ペネトレーションテスト最後の見せ場である「報告」の部分について、3回に分け語ることにしよう。
ペネトレーションテストの流れ
卒業アルバムでも見るような感じで、過去の記事を一気読みして気付いたのだが、いままでの記事の中で、ペネトレーションテストがどのような流れで進んでいくのかということを紹介したことがなかった。よい機会なので、「報告」について解説する前に、その流れについて紹介しておこう。
ペネトレーションテストの流れといっても、検査自体の流れではなく、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）を定期的に実施し、その都度、脆弱性を排除していくようサイクルを回すことが望ましい。しかしながら、費用面などの理由から、このサイクルを回せていないシステムが多いというのが、日々検査を行っている筆者が受ける印象である。
Copyright © ITmedia, Inc. All Rights Reserved.