Help Net Securityのインタビューにおいて、OnspringのCISOであるNichole Windholz氏が、GRC自動化システムおよび継続的コントロール監視の限界について語りました。色分けダッシュボードがいかに重要な文脈を覆い隠すか、ツールに供給されるデータをどのように検証するか、そして内部者の行動やベンダー集中リスクなど計測しにくいリスクにどう向き合うかを解説しています。
継続的コントロール監視ツールが生成する「緑・黄・赤」のモザイク表示は、本来の複雑さを単純化してしまいがちです。CISOがその表示を持って取締役会に臨む際、テレメトリーと議論の間で何が失われるのでしょうか？
緑・黄・赤のビューは、多くの場合において優れた、そして不可欠な出発点です。ただし、それだけでは十分ではありません。問題は、文脈が伴わない場合、色分けされたダッシュボードが本来きわめて複雑な問題を等価に見せてしまう点にあります。
赤い指標が示すのは、コントロール自体が完全に欠如しているケースだけではありません。証跡が古くなっている、業務責任者がアテステーションを見逃した、システムが変更されたにもかかわらず対応する更新がなされていない、あるいは影響度の低い資産でしきい値を超えてしまった、といったケースも含まれます。これらはすべて異なるリスクであり、求められる対応も同じではありません。
ニュアンスが平坦化されると、CISOは防御的な立場に追い込まれます。「何が重要で、どのような対処が必要か」を説明する代わりに、「なぜ赤なのか」「ダッシュボードは良い状態なのか悪い状態なのか」という議論に終始してしまいます。セキュリティリーダーにとって消耗するだけでなく、取締役にとっても何ら有益ではありません。
より有意義な取締役会での議論は、「何が変わったか」「何が重要か」「経営陣はどのような意思決定を求められているか」という3点から始まるべきです。コントロールのテレメトリーはその議論を支援するものであり、議論そのものに取って代わるものではありません。CISOは「今四半期に注目すべきリスクの変化はこれです。その根拠となる証跡、ビジネスへのエクスポージャー、そして経営幹部のサポートが必要な領域はここです」と語れる状態にある必要があります。
GRC自動化システムが価値を発揮するのは、コントロールの活動からビジネスへの影響までのトレーサビリティを保持している場合です。ヒートマップを生成するだけでは、その価値は大きく損なわれます。取締役会が必要とするのは、文脈、トレンドライン、オーナーシップ、そして「どのリスクが受容済みか」「どれが対処中か」「どれが悪化しているか」を明確に示すビューです。
GRC自動化ツールが誤設定されたソースからデータを取り込んだ場合、出力は権威あるものに見えても実際には誤りです。「監査者を監査する」にはどうすればよいでしょうか？
これは、自動化に過度に依存する前に組織が必ず問いかけるべき、最も重要な問いのひとつです。洗練された出力は、その基盤となるデータの正しさを保証しません。ソースシステムが誤設定されていたり、情報が不完全だったり、マッピングが誤っていたりすれば、自動化によって誤った仮定が速く伝播し、より信頼できるものに見えてしまいます。
「監査者を監査する」第一歩は、データリネージュの把握です。セキュリティおよびリスクのリーダーは、データの出所、ソースのオーナー、更新頻度、使用されているフィールドマッピング、そして前回レビュー以降の変更点を把握しておく必要があります。そのトレーサビリティを説明できない組織は、出力を権威あるものとして扱うべきではありません。
次に取り組むべきはコントロールの検証です。GRC自動化は「設定して放置する」システムであってはなりません。ソースシステムに対する定期的なテスト、証跡のスポットチェック、システムオブレコード間の突合、そして連携が失敗した際やデータの更新が止まった際の明確なアラートが必要です。また、何を自動化できて、何には依然として人間の判断が必要かを組織として定義しておくべきです。
目的は自動化を信頼しないことではなく、根拠のない過信を避けることです。ダッシュボードが予期しない改善を示したとき、セキュリティリーダーは悪化を示したときと同じくらい「なぜか」を問うべきです。コントロールが実際に改善されたのか、それともデータフィードが変わっただけなのか。業務部門が問題を是正したのか、それとも資産がスコープ外になったのか。こうした問いかけを怠ると、自動化によって不正確なデータが取締役会向けの説明資料に変わってしまいます。
テレメトリーで捉えにくいリスクのカテゴリが存在します。内部者の行動、ベンダー集中、地政学的エクスポージャー、コントロールレビューをスキップする経営幹部の意思決定などがその例です。GRC自動化システムは「見えない部分」をどう扱い、その盲点を取締役会にどのように伝えるべきでしょうか？
GRC自動化システムにはすべて、視野の範囲があります。責任ある問いかけとは、「その視野はどこで終わるのか」を問うことです。
一部のリスクは自然とデータを生み出します。パッチ適用状況、アクセスレビュー、コントロールの証跡、ベンダーアテステーション、そしてインシデント対応活動は、追跡・監視が可能です。一方で、クリーンかつ自動化された方法では測定が難しいリスクも多く存在します。内部者の行動、地政学的エクスポージャー、ビジネス依存関係、経営幹部の意思決定、ベンダー集中リスクなどは、定性的な評価・判断・シナリオプランニングを組み合わせて対応する必要があります。
こうしたリスクに対しても、GRC自動化システムは一定の役割を果たせます。しかし、システムが何を捉えているかをリーダーが明確に理解していることが前提です。優れたシステムは、前提条件を文書化し、ベンダーを重要プロセスに紐付け、高価値ビジネス機能にまたがる集中リスクにフラグを立て、レビュー・例外・リスク受容が期限どおりに実施されたかを追跡できます。こうした記録へのアクセスは非常に重要です。これらの意思決定の多くは、メール、スプレッドシート、非公式な会話の中に埋もれており、状況が変化した際に振り返ることが困難だからです。
ただし、盲点をなくすことはできません。いかなるプラットフォームも、意図を完璧に読み解いたり、あらゆる地政学的変化を予測したり、プレッシャーに直面した経営幹部がコントロールを覆すかどうかを判断したりすることはできません。
取締役会はこの現実を理解する必要があります。成熟したCISOは、取締役会の場に臨む際、すべてのリスクにセンサーが付いているかのように振る舞うべきではありません。むしろ正しいメッセージは「一部のリスクは継続的に監視できますが、他のリスクは人間によるレビューと判断が必要です。私たちの評価の前提条件、それをどのように検証しているか、そしてビジネスとしてエクスポージャーを受容することを選択した領域はここです」というものです。
この透明性によって、取締役会はあらゆるリスクが等しく計測可能であるという誤解を抱くことなく、データの限界を正しく理解できるようになります。またCISOが単独でリスクの翻訳者になり続けることも防ぎます。セキュリティリスクはビジネスリスクであり、取締役会は「何が計測されているか」「何が推定値か」「何が経営判断を必要とするか」を理解する必要があります。
過去3年間に公表されたインシデントから一つ選んでください。被害組織が最高水準のGRC自動化プラットフォームを運用していた場合、何が変わり、何は変わらなかったでしょうか？
2024年のChange Healthcareへのランサムウェア攻撃は、その影響が一企業にとどまらなかったという点で有益な事例です。医療保険の請求処理、薬局業務、決済処理がシステム全体にわたって混乱しました。公表情報や議会での議論でも、多くの組織が抱える課題が浮き彫りになりました。レガシー技術、アクセスコントロール、多要素認証、事業継続性、そしてサードパーティへの依存がその代表例です。
最高水準のGRC自動化プラットフォームがあれば、攻撃前に特定のギャップを明らかにできた可能性があります。特に重要なアクセスポイントに多要素認証がなかった点は、検出できたでしょう。また、そのギャップをビジネスインパクトに結びつけることも可能だったはずです。具体的には、影響を受けたシステムに依存するプロセス、顧客、下流のパートナーを可視化することで、経営幹部が単なる技術的コントロールの欠如としてではなく、事業のレジリエンスに対するリスクとして認識できるよう支援できたでしょう。
このようなGRCシステムは、各コントロールの記録の品質も向上させたはずです。コントロールが「実装済み」と記録されていた場合、古いアテステーションに頼るのではなく、ソースからの最新の証跡を要求する仕組みがあるべきです。例外が存在していた場合は、誰が承認し、いつ期限が切れ、どのような補完コントロールが存在するかを示すべきです。
変わらなかった点も同様に重要です。GRC自動化だけではランサムウェアを単独で阻止することはできず、ID セキュリティ、セグメンテーション、エンドポイント保護、バックアップの整備、インシデント対応の実行力の代替にはなりません。その価値はより現実的なものです。脆弱なシグナルを早期に発見し、技術的な発見をビジネス上の影響に結びつけ、インシデントが広範な混乱に発展する前に説明責任を明確にすることにあります。
5年後を見据えたとき、このカテゴリにおいて過剰投資されている領域と、投資が不足している領域はどこだと思いますか？
このカテゴリは「プレゼンテーション」に過剰投資されており、「信頼性の担保」への投資が不足しています。
多くの企業が、ダッシュボードの見栄えを改善することに投資する一方で、その背後にある運用モデルの改善を怠っています。ダッシュボードがいかに洗練されていて常時更新されていても、データが不完全で、オーナーシップが不明確で、裏付けとなる記録が脆弱であれば、根拠のない過信を生み出すだけです。リスク報告の本当の試金石は、取締役会が「何が変わったか」「ビジネスはどこにエクスポージャーを抱えているか」「どの意思決定が必要か」を真に理解できるかどうかです。
また、壊れたプロセスの自動化に過度な重点が置かれていることも問題です。コントロールのオーナーシップが不明確で、標準が一貫しておらず、システムが連携できていない組織では、自動化はそれらの問題を解決しません。むしろ問題を増幅させる可能性があります。強い組織とは、どのワークフローが自動化に値するか、どの意思決定には経験豊富なリスクオーナーが必要か、どのシグナルが最も重要かを把握している組織です。
GRCの背後にある信頼性のレイヤーには、もっと注目が集まるべきです。セキュリティリーダーに必要なのは、リスクシグナルのステータスだけでなく、そのリスクに至る経緯を記録するシステムです。具体的には、データが最新かどうか、適切なオーナーがレビューしたかどうか、取締役会に提示される意思決定が信頼できる記録に基づいているかどうかを示すことが求められます。
CISOはまた、技術的な発見、コントロールの証跡、経営幹部の期待、取締役会レベルの説明責任という複数の要素を橋渡しする「翻訳者」としての負担を単独で背負いすぎています。GRC自動化はリスクに関する意思決定の共有記録を構築することでその負担を軽減し、散在するシグナルをビジネスの文脈に変換する責任をセキュリティリーダーだけが担わなくて済む状態を実現すべきです。
翻訳元: https://www.helpnetsecurity.com/2026/06/15/nichole-windholz-onspring-automated-grc-systems/
