サイト内の現在位置

「発生してほしくない事象」を基点としたセキュリティ対策手法の紹介 ~Consequence-Driven Cyber-informed Engineering(CCE) ~

NECセキュリティブログ

2022年11月18日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの長浜です。米国アイダホ国立研究所が開発したセキュリティ対策検討手法の一つであるConsequence-driven Cyber-informed Engineering(以降CCEとします。)を紹介いたします。
CCEは、結果事象からセキュリティ対策を検討していく手法です。「民間宇宙システムにおけるサイバーセキュリティ対策ガイドラインnew window[1] 」でも利用されています。上記ガイドラインでは、民間宇宙システムの構成図を対象にCCEで攻撃シナリオの検討を行っています。攻撃シナリオを防ぐために対策を検討し、最終的にガイドラインとして落とし込み公開されています。実際の利用方法が気になった方は、new window[1] のガイドラインを閲覧いただけますと利用方法がわかりやすいと思います。

CCEとは

CCEは、米国アイダホ国立研究所(INL)が2016年に公開した制御システム向けセキュリティ対策検討手法の一つですnew window[2]。「発生してほしくない事象」を基点として制御システム向けのセキュリティ対策を検討します。
CCEの特徴は以下の3点です。

  • リスク値の計算が不要
  • 4ステップで検討が可能
  • 制御システムの関係者の連携が必要

リスク値の計算が不要

CCEでは、リスク値の算出を行いません。「発生してほしくない事象」からセキュリティ対策を考えることで、重大インシデントから優先的に防げるようなフレームワークとなっています。
制御システムでは、もともと重要インシデントを防ぐようにシステムを構築されています。これらのシステムは、セキュリティ要件ではなく故障によるインシデントを防ぐために構築されています。セキュリティ対策を組み込むためには、リスク値の計算で対策を進めるよりも、既存の設計志向に沿った形でセキュリティ対策を進めることで、OTエンジニアの協力が得られやすくなりスピーディに対策を進めることが可能です。

4ステップで検討が可能

図1 CCEの検討プロセスnew window[2]

CCEの検討には図1の流れで行います。各ステップについては紹介いたします。

1st Quad. 発生事象の優先度順位付け(Consequence Prioritization)

組織のミッションを達成するために重要な機能とサービスを列挙します。その際、重大な影響を及ぼす可能性のある事象を抽出します。『経営層』の合意のもとCCEで検討を実施する事象を決定します。

2nd Quad. システム間の関連構造の洗い出し(System of Systems Breakdown)

1st Quadで決定した事象につながるシステムや機器の特定を行います。このプロセスは、プラント内のエンジニアリング分析のアプローチと考えることができます。本プロセスは、『ITエンジニア』だけではなく、『OTエンジニア』と協力しながらシステム分析することが重要です。

3rd Quad. 発生事象を引き起こす方法のマッピング(Consequence-based Targeting)

2nd Quadで洗い出したシステム構成を対象にICS Cyber Kill Chainnew window[3]を用いて攻撃のマッピングを行います。ここでは、『ITエンジニア』を中心として検討してきます。この際、人による不正操作も一緒に考える必要があるため、『OTエンジニア』も一緒に攻撃経路を検討できると幅広く検討が可能となります。

4th Quad. 軽減対策の検討・決定(Mitigations and Protections)

最後のステップは、3rd Quadで検討した攻撃の流れを封じるためのセキュリティ対策の検討、決定を行います。セキュリティ対策の検討は『ITエンジニア』で行い、『経営層』が対策執行の承認を行うことでCCEの一連のプロセスが終了となります。

制御システムの関係者の連携が必要

本記事内では、4ステップの中の登場人物に『』を付けていました。ステップ内での役割を見ていくと、制御システムにかかわる人材がCCEの一連のプロセスの中で登場していることがわかります。このようにすべての人材が関わりながら対策を検討することで、納得感を得ながら短時間でセキュリティ対策を検討することが可能になります。

課題

CCEは、想定ができた事象に対して効果的にその対策を実施することはできます。しかし、想定外の被害は防げません。例えば、プロセスの中で検討の対象外とした「プラント施設への不正侵入」があった場合、本事象はCCEでは対策検討をしていないため対策できません。そもそも、発生事象の列挙から漏れた事象があった場合は、想定外の被害というのは発生する恐れがあります。そういった意味では万全な対策とは言いにくいです。
そのため、各種業界ガイドラインや規制によって多層的なセキュリティ対策を実施しつつ、そのうえでCCEを用いて発生してほしくない事象の対策を進めるという流れで利用する必要がありそうです。

ITセキュリティへの応用

CCEは制御システムをターゲットとして作成されたセキュリティ対策手法ですが、少し視野を広げ考えてみると、昨今のITセキュリティへの対策にも応用が可能な考え方だと思われます。ここでは、2つの例について紹介したいと思います。

  • 従業員訓練・教育への応用
    昨今金融業界にて、TLPT(Threat-Led Penetration Testing)といわれる脅威ベースのペネトレーションテストへの注目が高まっています。TLPTでは、対象組織への「脅威シナリオ」を作成し、シナリオベースに実際の攻撃を行います。運用中のシステムに対し実際に攻撃を行うことで、現在のセキュリティ対策の効果やインシデント対応チームのスキル向上につなげていきます。
    一方CCEは、実システムに対して攻撃は実施いたしませんが、各組織が考える発生してほしくない事象の攻撃経路を検討し、対策を実施していくことになります。そのため、TLPTを実施する前に、自組織で「発生してほしくない脅威」を基点として対策状況の確認に利用できるのではないでしょうか。
  • セキュリティ対策状況の検討範囲を拡大するために利用
    多くの組織でこれまでガイドラインや業界の規制に従いセキュリティ対策を多層的また、網羅的に実施されてきているかと思います。そうした対策に加えCCEの考え方を取り入れることで、「発生してほしくないセキュリティインシデント」を防ぐことが可能になるかと思います。
    例えば、「サーバのランサムウェア被害」を発生してほしくないセキュリティインシデントとして考えて、CCEの残りのステップを検討することでランサムウェアの対策の検討が進められる可能性があります。ただ、CCEは対策をメインとしたホワイトペーパーであるため、インシデント対応や復旧という観点は検討されていません。そのため、別途検討する必要があります。

まとめ

本記事では、INLが開発したCCEについてご紹介しました。「発生してほしくない事象」を基点としてセキュリティ対策を検討するという考え方は、制御システムだけではなくITシステム向けのセキュリティでも通ずる考え方かと思いますのでご参考になりますと幸いです。
なお、本執筆にあたりICSCoEでの講義の内容を参考にいたしました。

参考資料

執筆者プロフィール

長浜 佑介(ながはま ゆうすけ)
セキュリティ技術センター リスクハンティング・アナリシスグループ

主にペネトレーションテスト、脆弱性診断などを担当しNECグループのセキュア開発・運用を推進。
2020年6月にIPA 産業サイバーセキュリティセンター中核人材育成プログラムを修了。
CISSP、GIAC(GXPN)、情報処理安全確保支援士(RISS)を保持。

執筆者の他の記事を読む

アクセスランキング