セキュリティ負債からの脱却——エクスポージャー問題への取り組み

オピニオン

セキュリティチームは、自分たちが抱える脆弱性の数が多すぎることをすでに把握しています。しかし、そのリスクがどれほど長期にわたって露出し続けているかについては、往々にして過小評価されています。

現在、82%の組織がセキュリティ負債を抱えています。これは、1年以上放置されたままの脆弱性を指します。同時に、深刻度が高く悪用される可能性の高い欠陥も増加しています。

この二つの要因が重なることで、積み残しの課題が現実のリスクへと変わります。脆弱性は発見されるだけでなく、攻撃者に見つけられ悪用されるほど長い期間、本番システムに残存し続けているのです。

多くのチームは、すべての脆弱性を修正することが不可能だと以前から認識しています。それは今に始まった話ではありません。変わったのは、露出が実害につながるまでの速度です。攻撃者の動きは速くなり、悪用手法へのアクセスは容易になり、発見から攻撃までのウィンドウはますます縮小しています。

いまだにセキュリティ負債を積み残し案件の管理問題として捉えているなら、それはリスクではなく活動量を測定しているにすぎません。

今、本当に問われるべき問いはシンプルです。どの脆弱性が露出しており、それがどれほどの期間続いているのか、という点です。

重要なものから始める

最初のステップは、対象範囲を絞り込むことです。

どの組織にも、リスクの大部分を占める少数のアプリケーションが存在します。これらは収益、機密データ、または外部アクセスに直結するシステム、いわゆる組織の「クラウンジュエル」です。攻撃者が最も狙いやすいのも、こうしたシステムです。

バックログ全体に力を分散させるのではなく、まずこれらの重要なアプリケーションに集中してください。そのうえで、さらに一段階深く掘り下げます。悪用される可能性が高い、または非常に高い欠陥のうち、深刻度の高いものを特定してください。当社の調査では、欠陥の11.3%がこの高リスク領域に集中していることが明らかになっています。

このアプローチで、バックログが一夜にして解消されるわけではありません。しかし、現実のリスクを確実に低減できます。

優先順位付けの見直し

深刻度スコアは依然として重要ですが、それだけでは不十分です。

攻撃者は深刻度ランキングで動きません。アクセスしやすく、悪用が容易で、価値あるものへとつながるものを探しています。公開されているアプリケーションに存在する中程度の深刻度の脆弱性は、内部システムの高深刻度の問題よりも、より即座のリスクをもたらすことがあります。

また、高リスクカテゴリに分類される脆弱性が増加しています。これらは高い深刻度と高い悪用可能性を兼ね備えた欠陥であり、実際の攻撃で使用される可能性が最も高く、全検出件数に占める割合も増え続けています。

効果的な優先順位付けには、こうした現実を反映させる必要があります。チームはいくつかの重要な問いを自らに投げかけるべきです。その脆弱性は本番環境から到達可能か。対象のアプリケーションは外部公開されているか、または業務上重要なシステムか。既知のエクスプロイトやアクティブな攻撃パターンは存在するか。調査によれば、開発者は任せておくと、このような観点で優先順位を付けない傾向があることが分かっています。

優先順位付けモデル全体を作り直す必要はありません。ただし、自社に対して使われる可能性が最も高い脆弱性を確実に最初に対処できるようにしてください。

修復をキャパシティの問題として捉える

修復対応力は、今日のアプリケーションリスク管理における最大の制約の一つです。

ほとんどの組織では、脆弱性の発見速度が修復速度を上回っています。このギャップこそが、セキュリティ負債を着実に増加させている要因です。

修復作業が「開発者に余裕があるときに行うもの」として扱われている限り、常に遅れを取り続けることになります。

成果を上げているチームは、修復をリソースを割り当てるべき機能として位置づけています。セキュリティ作業に専用のエンジニアリング時間を確保し、高リスクな脆弱性をどれほど迅速に対処すべきかの基準を定め、新たに発見された問題が修復能力を上回っていないかを追跡しています。また、継続的な修復プロセスの一環として、修正作業をSDLCに組み込んでいます。

場合によっては、トレードオフの判断が求められます。露出リスクを低減するためにフィーチャー開発を一時停止することは容易な決断ではありませんが、リスクをコントロール下に戻すためには往々にして必要な措置です。

サードパーティリスクの管理

サードパーティコードにおけるセキュリティ負債の66%はクリティカルであり、長期的な露出の最も根強い原因の一つとなっています。

クリティカルなセキュリティ負債のかなりの部分は依存関係に起因しており、修復に長い時間を要する傾向があります。当社の調査では、サードパーティの欠陥における修復半減期は358日であることが分かっています。

その理由はよく知られています。推移的依存関係は複雑であり、アップグレードによって機能が壊れるリスクがあり、責任の所在も不明確なことが多いのです。結果として、こうした問題は長期間放置され、露出のウィンドウを広げ続けます。

このリスクを低減するには規律が必要です。特に高リスクなアプリケーションにおいて依存関係を最新の状態に保ち、脆弱なコンポーネントがどこで使用されているかの可視性を維持し、バージョン番号や深刻度スコアだけでなく到達可能性と影響度に基づいて修正の優先順位を決定してください。

このレイヤーを積極的に管理していなければ、気づかないうちにリスクの大部分をこの層に支配されることになります。

バックログだけでなく、露出を測定する

多くのセキュリティプログラムは、実際のリスクを反映しない指標に依存したままです。

脆弱性の件数を数えても、自社が安全になっているかどうかは分かりません。一定期間にクローズした問題の数を追跡しても、その問いには答えられません。これらはあくまでも活動量の指標です。

より有用な指標は露出時間です。これは、クリティカルかつ悪用可能な脆弱性が修正または緩和されるまでに存在し続ける期間を指します。

これこそが攻撃者が活動するウィンドウです。このウィンドウが開いている時間が長ければ長いほど、悪用される可能性は高まります。

このウィンドウを測定・管理することで、自社のプログラムがリスクを本当に低減しているかどうか、はるかに明確な視点を得ることができます。

ウィンドウを縮小することに集中する

セキュリティ負債がなくなることはありません。修正可能な数を超える脆弱性が常に存在してきましたし、今後もそれは変わりません。変えられるのは、最も危険な脆弱性が露出し続ける期間です。これこそ、セキュリティリーダーが取り組むべき転換点です。バックログの解消を目指すのではなく、クリティカルな脆弱性が攻撃者に利用可能な状態にある時間を縮めることに集中してください。侵害が発生するのは、危険な脆弱性が長すぎる時間にわたって露出していたからに他なりません。