新たな脆弱性が報告されると、関係者の間では時間との闘いが始まる。ソフトウェア側から見ると、脆弱性のあるアプリの開発者は、障害の修正のために必要なセキュリティパッチを作成し、対応するアップデートを公開することに努めなければならない。

一方、攻撃者からすると、どこに弱点があるのかがはっきりするので、この弱点を悪用して不正コードのエクスプロイトの開発を始めることになる。

他方で、ユーザーとITセキュリティ管理者は、こうして提供されたアップデータをインストールしなければならない。そして、もしもアップデータがない場合には、脅威を阻止する代替的な安全対策を用意し、決定的な解決策が開発され実装できるようになるまでの間、自力で防ぎ切らなければならない。

このことを念頭に置くと、まさしく「時は金なり」という標語が思い浮かぶ。利益を得ようとするサイバー犯罪者の標的になる恐れのある企業組織が適切に脆弱性に対処するためには、時間こそが潜在的な攻撃にさらされる可能性を減らす重要な鍵となる。

そして、時間が決して止まることがない一方で、完璧なセキュリティという理想状態も永遠に訪れることはない。現実問題としては、常に脆弱性の評価を続けること、これこそが何よりも推奨されるだろう。

脆弱性評価の限界と課題

セキュリティの状態を継続的に評価することは、言うほど簡単ではない。実際に行ってみると、さまざまな要因によって非常に複雑になる。第一に、ITセキュリティ管理者は絶えず、ソフトウェアアップデートのデータはもちろん、新しいセキュリティパッチ、新しい脆弱性もしくはセキュリティアラートに関する情報を更新しなければならない。

これらを実現させるためには、そのためのツールとソフトウェアが必要である。そして、それらを使いこなすスキル、知識、経験を持ったスタッフが必要である。また、これらのために費やす時間や予算といったリソースも考慮しなければならない。さらには、確認された脆弱性の優先度を決める基準や物差しも必要である。なぜならば、脆弱性にもさまざまなレベルがあり、場合によってはビジネス全体を左右する恐れがあるような、極めて重要性の高いものもあるからである。しかし、脆弱性を継続的に評価することこそ、現在のセキュリティ対策の動向としては、最も重要な活動である。

継続的な脆弱性の評価と関連する考慮点の実装

継続的な脆弱性評価を実施するための簡単な方法がある。それは、それぞれの企業組織における重要性に基づいて、過去に重要であると分類された一連の標的に対しては、スキャンの自動化を行うことである。自動ではなく、手動のテストでも構わない。大事なのは過去のデータを踏まえるということである。

これと並行して、システムの更新記録あるいはログへのアクセスも、以下の二つの理由から非常に有用である。

１）テストの結果、問題のある脆弱性をシステムが感知した場合、システムはこの異常な挙動を記録しているはずである。

２）その情報によって、検出された攻撃が前回の脆弱性のスキャンとリンクするのかどうかを示し得る。そして、そのため、エクスプロイトが脆弱な標的に対して使用されたのかどうかを検証し得る。SIEM（セキュリティ情報とイベント管理）は、このタスクにとって有効である。

また、スキャンに使用されているツールが最新であり、実行時に最も関連のある脆弱性を検知しているか確認することも重要である。旧式のソリューションを使用すると、セキュリティの状況に関して最も重要な情報が提供されない可能性があるからだ。

修正のためには、OSや他のソフトウェアのパッチおよびアップデートの管理ツールが適用可能である。ただし生産システムのように重要な箇所に対しては、直接適用させる前に、対応するテスト環境のチェックを行うべきであろう。なぜならば、そうすることで、アップデートの適用が操作に危険を及ぼすことを回避できるからである。

すでに述べたように、必要なアップデートがない状態で対応を迫られている場合、決定的な解決法が開発されるまでの間、脅威を阻止する他の安全対策を実装する必要がある。この場合、リスク回避やリスク感受性に基づいて、正しいと思われる判断を行うことになるだろう。同様に、保護される資産よりもソリューションの方が高額になってしまう場合にも、この適用を実行しなくても構わない。

目指すのは理想的な安全状態に向けて努力すること

評価に必要な期間は、それぞれの組織のニーズ、特徴、リソース、ならびに重要なシステムの対応や数によって異なってくる。しかし、継続的に適切な点検が行われるべきであるという事実に変わりはない。見直しや改善の期間が短くなれば、攻撃者や脅威にさらされる時間も短くなる。より重要な脆弱性の対応を優先させることは、言うまでもない。

具体的にどういった枠組みに基づいて対策を行えばいいのか、はっきりとした指標がないのであれば、例えば、最初に適用されるべきものの一つとして、「CSC」（Critical Security Controls）が挙げられる。これは、優先順位の高い20のサイバー攻撃のための対応措置（評価と改善を含む）をまとめたものである。

「CSC」は2008年に米国防長官の要請に対してサイバーセキュリティ協議会が作成したのが最初で、その後、多くの企業や専門家が参加して改良を重ね、各組織や団体における実効力の高いセキュリティ対策の構築に役立てられている。

「CSC」の目的は、それぞれの企業組織がサイバー攻撃を見つけ出し、防御を行い、対応または軽減するための効果的な手段を持つことにある。実現するためには、脆弱性の評価に関するさまざまな点についても検証しなければならない。例えば、サービスを委託にするのか、それとも独自のチームで開発するのか、実行するために期間はどのくらい必要なのか、セキュリティパッチをどのように適用させるのか、などである。また同様に、システムや人々の脆弱性の悪用など、人間の心理的な隙を狙って攻撃を行うソーシャル・エンジニアリングまで考慮することになる。すなわち、一言で「攻撃」と言っても、全てが技術的なものとは限らないのである。

加えて、継続的に脆弱性を評価することは、複雑で面倒なタスクであるとはいえ、一般的な攻撃や脅威を一通り軽減することができることから、さまざまなセキュリティ統制の枠組みによって主要な取り組みとして推奨されている。

最後に、情報セキュリティが継続的なプロセスであるということを念頭に置いて、この活動は行われるべきである。現実的には全てのリスクを回避することはできないが、理想的なセキュリティの状態を達成するために、日々努力することこそが重要なのである。