オピニオン
大量の脆弱性に埋もれている企業の多くは、検出に問題を抱えているわけではありません。実際には、検出の問題という衣をまとった説明責任の問題なのです。
それは支出の傾向に表れています。滞留案件が経営陣の耳に届くほど膨らむと、企業はまずスキャンの強化に投資しようとします。カバレッジの拡大、サイクルの高速化、より豊富な脅威インテリジェンス、一元的な管理画面といった具合です。ところが1年後に手元に残るのは、さらに膨らんだ滞留案件を完璧に可視化できる状態です。
これはツールの失敗ではなく、診断の誤りです。スキャン能力と修正能力は互いに独立した変数であり、発注書1枚で拡張できるのは前者だけです。
最新のスキャナーを十分に管理されていない環境に向ければ、検出件数は資産数とチェックの深さだけを上限として増え続けます。一方、修正能力を左右するのは、エンジニアの工数、変更作業の時間枠、アプリケーションの互換性、ベンダーのパッチの提供状況、そして事業側が許容できるダウンタイムの長さです。ライセンスをアップグレードしても、これらは何一つ動きません。
筆者は、サーバー群に対する認証付きスキャンの導入によって、検出件数が1四半期で3倍に増えた事例を目の当たりにしました。安全性が低下したわけではありません。ただ、知らないふりを続けられなくなっただけです。
ここに歪んだインセンティブが生まれます。未解決の検出件数で評価されるプログラムでは、カバレッジを広げるほど成績が悪く見えてしまいます。そのように評価されるチームは、あえて見ないことを学習します。
滞留案件が本当に示すもの
滞留案件が示すのは、技術的負債の大きさではなく、解消されていない責任の所在です。
1件の検出を完了させるために、何が成立している必要があるかを考えてみてください。まず、その資産の存在を誰かが把握していること。次に、誰かが責任を負っていること。その人物に変更を加える権限があること。変更する時間があること。そして、他の業務に優先してそれを実行する動機があることです。
スキャンで得られるのは、このうち最初の1つだけです。残る4つはガバナンスの領域です。
だからこそ、ツールも環境も検出件数もまったく同じ2社の間で、修正の速さに10倍もの差がつくことがあります。起こりうる状況には、次のようなものがあります。
-
所有者がいない。資産が誰にも紐づけられていません。これは最も多く、かつ最悪の失敗です。所有者のいない検出は、エスカレーションする相手がいないため、上位に引き上げることができません。しかも、環境内で所有者不在の部分は、たいてい最も古く、最も攻撃にさらされやすい部分でもあります。
-
所有者に権限がない。チームは責任を負っているものの、動くことができません。パッチはベンダーが握っています。プラットフォームは別のチームの管轄です。アプリケーションは契約上、変更が凍結されています。その結果、サービスレベルアグリーメント（SLA）を明らかに達成できないキューが生まれますが、担当者は「自分には何もできなかった」と正当に主張できます。
-
所有者に余力がない。責任も権限もありますが、修正作業は同じバックログ内で機能開発と競合し、その優先順位を決めるのは、賞与の評価項目にセキュリティが含まれていないプロダクトオーナーです。ツール上では見えません。チケットは割り当て済みで対応中のように見えるからです。
-
所有者に結果責任がない。体制はすべて整っているのに何も起きません。修正SLAを守れなくても、誰も何も失わないからです。セキュリティ報告の宛先が、所有者の上司ではなくセキュリティチームになっているなら、これが御社のデフォルトの状態でしょう。
エスカレーションを強化しても、解決するのはこのうち1つだけです。
まず資産の所有者を明確にする
企業の脆弱性管理プログラムで最も効果の高い施策は、スキャンのアップグレードではありません。資産と所有者の対応づけを正確に作り、維持し続けることです。
地味な作業です。構成管理データベース（CMDB）をスキャナーの実際の検出結果と突き合わせ、抜けを追いかけ、誰も引き受けたがらない資産も含めて、すべての資産に具体的な所有者を割り当てます。セキュリティエンジニアリングというより監査に近い作業であり、まさにそれが、セキュリティチームがこの領域への投資を怠りがちな理由です。
守るべきルールは3つあります。所有者は個人または常設チームとし、部門にしてはいけません。「インフラ部門」を呼び出すことも、SLAの責任を負わせることもできないからです。対応づけは一度作って終わりではなく、維持し続けるものです。組織変更のたびに、その有効性は失われます。そして、誰も引き受けない資産は、そこに存在する脆弱性とは切り離して、それ自体をガバナンス上の指摘事項としてエスカレーションします。この方法は、どれだけ脆弱性を報告するよりも早く所有者を生み出します。
未解決の検出件数は、最もよく報告される脆弱性指標でありながら、最も役に立たない指標の1つです。検出カバレッジと修正の成果が混ざり合い、どちらとも無関係な理由で増減し、特定の誰かに帰属させることもできません。
代わりに、次の指標を試してみてください。
-
所有チーム別に区分した平均修正時間。セキュリティの指標が、マネジメントの指標に変わります。
-
完了率ではなくSLA遵守率。完了率は、簡単なものを片付けるだけで高くなってしまうためです。
-
そして、所有者が確認済みの資産の割合。これは他のすべての指標に先行する指標です。90%を下回ると、他の数字はほとんど意味を持ちません。
あるプログラムでは、6カ月かけて修正までの期間が45日から10日に、SLA遵守率が30%から95%に改善しました。ツールの改善も寄与しましたが、決め手はツールではありません。検出結果が、所有チームへ自動的に振り分けられるようになりました。SLA違反は、セキュリティ部門ではなくエンジニアリングの幹部に報告されるようになりました。例外には、実効性のある承認経路が設けられました。そして、所有者のいない資産はガバナンス上の指摘事項として扱われるようになりました。
同じ期間に、開発のスループットも向上しました。
これは直感に反する結果であり、じっくり考える価値があります。修正作業の所有者が決まり、優先順位がつき、範囲が区切られていれば、修正は予定外の割り込み作業ではなく、計画に組み込める作業になります。問題は修正そのものにあったのではありません。誰が何をいつまでに直すのかが曖昧だったことが、摩擦の原因でした。
スキャナーに問題はありません。まずは、自社のサーバーを誰が所有しているのかを突き止めてください。
翻訳元: https://www.darkreading.com/cybersecurity-operations/vulnerability-backlogs-ownership-problem
