組織のセキュリティリスクの測定に欠けている可能性のある 3 つの重要なステップ
なぜ、「リスク」は情報セキュリティでそれほど重要な概念なのでしょうか。リスクは情報セキュリティチームがエンジニアリングチームやビジネスチームのような情報セキュリティ以外のパートナーとコミュニケーションできるよう、共通の言語を提供します。リスク管理により、セキュリティ、エンジニアリング、ビジネスのニーズ間でコストとメリットが決まります。成熟したセキュリティリスク管理能力がなければ、情報セキュリティチームは他の領域で確かな能力があったとしても、成功することは難しいでしょう。
成熟したセキュリティリスク管理能力を構築するための 1 つの要件は、リスク測定の能力です。残念ながら、リスクを測定することは困難です。リスクの測定方法についてはさまざまな視点がありますが、広く認められている方法や全体的な指針は存在しません。NIST SP 800-55 Rev. 1、『Performance Measurement Guide for Information Security』は、出発点を提供していますが、リスクよりパフォーマンスの測定に焦点を当てています。
私も包括的なソリューションやプロセスを持っているわけではありません。しかし、自身の経験から、3 つの重要なステップが高い投資対効果をもたらし、リスク測定能力を高めることがわかっています。
ステップ 1: 脆弱性の深刻度スコアを組織に合わせてカスタマイズする
「リスクを計算していないのであれば、計算済みのリスクとは言えない」 - Naved Abdali、『INVESTING - Hopes, Hypes, & Heartbreaks』
セキュリティチームはサードパーティの静的な脆弱性の深刻度スコアを使用することだけに力を入れ、自社環境における独自の脆弱性の影響を考慮しない場合があります。このような行動は当然でしょう。多くの場合、組織には脆弱性が多数存在し、既存のスコアを使用するほうが便利だからです。しかし、サードパーティの脆弱性の深刻度スコアのみを使用した場合、セキュリティ対策の優先順位付けが正しく行われず、組織が危険にさらされる可能性があります。
たとえば、多くのセキュリティチームは、CVE (共通脆弱性識別子) レコードを公開されている脆弱性の情報源として使用します。CVE には共通脆弱性評価システム (CVSS) によって生成された脆弱性の深刻度スコアが設けられています。CVE の CVSS スコアには深刻度の評価が含まれていることが多く、この評価はソフトウェアベンダーや対象分野の専門家が脆弱性の一般的な性質に基づいて提供しています。中には、このスコアのみを使用して脆弱性に優先順位を付けるセキュリティチームもありますが、このアプローチでは、脆弱性の深刻度の進化する性質や組織の環境に特有の影響が除外されてしまいます。
CVSS ユーザーによっては、基本指標のみを考慮して脆弱性のリスクスコアリングを行う場合がありますが、より包括的なリスクスコアを組織に提供するには 3 つのグループすべての指標が必要です。これらの課題やリスクスコアリングの構成要素は、CVSS に限らず他の多くの手法でも類似しています。
推奨方法
Salesforce では、情報セキュリティチームは複数の手法を使用することで、深刻度スコアを適用するのみの方法から、全面的にリスクを評価する方法へと移行しています。例として次のような方法があります。
- 脅威インテリジェンスプラットフォームと脆弱性管理ツールによる脆弱性リスクスコアリングに時間的指標を取り入れる。
- 可用性の要件、データ機密性のレベル、顧客に対する脅威など、脆弱な資産の環境特性を評価する。
- リスクスコアリングのアプローチは簡単なものから始め、リスク要因のデータが徐々に増えてきたら、動的に調整する。
ステップ 2: 重要リスク指標を使用してリスクを監視する
「私たちが何者であるかを決める基準は、私たちが持っているもので何をするかである」 - Vince Lombardi、『The Lombardi Rules』
重要リスク指標 (KRI) は、組織が設定した目標やしきい値を用いたリスクの測定値と定義できます。組織のリーダーは多くの場合、目標やしきい値を定義してリスクが許容できないレベルを示します。KRI は組織のトップレベルからリスク管理のセキュリティリーダーまで広く使用されており、リスクを積極的に監視できます。
さて、ここまではよいのですが、肝心のリスク指標はどのように作成するのでしょう。
最初に、測定基準はリスクに関連している必要があります。リスク測定では、有害なセキュリティ事象の可能性や影響を大きくするおそれのある出来事を特定します。たとえば、研究者がシステムのソフトウェアで危険度の高い新しい脆弱性を発見した場合、リスクの可能性が高まるおそれがあります。システムに保存される機密データが増えると、リスクの影響が大きくなる可能性があります。
第 2 に、測定基準には関連するしきい値が必要です。組織は通常、リスク選好度と許容度に基づいてリスク指標のしきい値を定義します。FAIR Institute が定義するリスク選好度とは、「事業の目的とリソースを前提として、組織が許容できるとみなす損失リスクの目標レベル」であり、リスク許容度とは「組織が許容できるリスク選好度との差異の度合い」です。たとえば、ある組織は、リスクの高い環境で「重大」な深刻度の脆弱性を許容できないと判断しています。そのため、KRI の「リスクの高い環境での『重大』な脆弱性の数」のしきい値は 0 になります。
第 3 に、何をもって指標を「重要」とするかです。チームは多くのリスク指標を作成しますが、「重要」リスク指標は、組織全体のリーダーにとって重要であるという理由から選ばれたリスク指標のサブセットです。たとえば、エンジニアリングや IT に関連する KRI もあれば、製品や業務に関連する KRI もあります。KRI は通常、情報セキュリティチーム以外でも共有され、監視されます。
推奨方法
重要リスク指標の策定には、さまざまなアプローチがあります。Salesforce では次のような方法を使用しています。
- リスク指標を組織のフレームワークと整合させる (セキュリティ制御、セキュリティ成熟度、組織のリーダーへの説明に使用する最も重要なリスクや脅威など)。
- 少数の KRI から試験的に開始し、フィードバックや対象者にとっての価値に基づいて拡張する。
- 重要リスク指標の策定には、対象者の代表者、対象分野の技術専門家、エンジニアおよびビジネスの関係者など、複数の関係者を参加させる。
ステップ 3: 「既知の未知」について考える
「最も大きな被害をもたらすセキュリティインシデントは、自身が予想していなかったインシデントである」 - 古いボクシングの格言より一部変更
第 3 のステップである「『既知の未知』について考える」は、3 つのステップの中で最も単純であり、組織によっては最も重要である可能性があります。多くの組織では環境に既知の未知が存在します。これには、数年間セキュリティレビューを受けていないレガシーアプリケーション、脅威の発展によりリスクが高まったセキュリティ負債、通常のセキュリティ評価範囲外の資産を含む特殊プロジェクト、セキュリティチームが十分に時間をかけてレビューできていないコードなどが該当します。
このような既知の未知は、長年水面下に潜み、組織で暗黙のうちに容認されていることがあります。しかし残念ながら、これが最大のリスクをもたらす可能性があります。正しい方向に歩み始めるための最善の方法は、少なくとも未知を既知にして、暗黙の容認のサイクルから脱却することです。
推奨方法
Salesforce では、さまざまなアプローチを使用して既知の未知を管理しています。他の組織でも役立つ可能性のあるアプローチを次に紹介します。
- 専用のプロジェクトを立ち上げて既知の未知を特定し、定期的なセキュリティ評価の範囲に含めることを検討する。
- 既知の未知をリスク測定のフレームワークに組み込み、「既知の既知」と共に改善策に優先順位を付ける。
- ポリシー、基準、ガイダンスを更新して既知の未知の発生要因に対処し、今後の発生を予防する。
リスク測定は必ずしも簡単ではありませんが、セキュリティはマラソンのようなもので、短距離走ではありません。では、次に何を行えばよいでしょうか。各ステップの推奨方法を確認し (または自分で作成し)、リスク測定を改善するために今日できることを明確にしましょう。良い方法が見つかった場合は、ぜひ共有してください。このマラソンでは、私たちは誰もが助けを得ることができるのです。