セキュリティコンサルタントの日誌から

セキュリティに関するエッセイなど

「リスク分析・管理」再考(その3)

前回(その2)は、リスク分析について深くご紹介しました。

www.scientia-security.org

大きく、6種類のステップでやることをご紹介します。

  • Step 1 : 資産の特定
  • Step 2 : 脅威の特定
  • Step 3 : 脆弱性の特定
  • Step 4 : 残存リスクの特定
  • Step 5 : 発生確率・影響度の決定
  • Step 6 : アウトプット作成

上記のプロセスは、上記のプロセスは、NIST SP800-30 "Managing Information Security Risk"におけるリスクマネジメントプロセスにおいて、「Assess」フェーズに該当します。今回は、残りの二つのプロセス「Respond」と「Monitor」をご紹介します。

f:id:security_consultant:20191214174550p:plain

リスク管理プロセス:Respondフェーズ

リスク分析を経てリスクを特定した後は、リスクへの対応を行います。リスク対応戦略は大きく4種類存在します。一般的には、リスク低減 → リスク受容をすることが一般的な戦略となります。

  • リスク低減(Risk Mitigation)
    • セキュリティコントロールの導入などにより、リスクを低減することを意味します。
  • リスク受容(Risk Acceptance)
    • 経営層の判断に基づき、残存リスクを受容することを意味します。
  • リスク転移(Risk Transfer)
    • リスクを第三者(3rd Party)に転移することを意味します。例えば、サイバー保険の活用や、サードパーティ製品・サービスの活用を意味します。*1
  • リスク回避(Risk Avoidance)
    • リスク、もしくはリスクの原因を取り除くことを意味します。例えば、ご送信のリスクを避けるために、メールでの顧客とのやり取りを禁止するなどが挙げられます。

5種類のセキュリティコントロール

リスク低減(Risk Mitigation)において、セキュリティコントロールを実装することが一般的です。分類は様々ですが、セキュリティコントロールは複数のカテゴリーに分類されます*2

  • 指揮的コントロール(Directive・Deterrent)
    • 望ましい行動を促進したり、望ましくない行動を抑制するように指定・指示コントロール
    • 例)ルール・啓発研修
  • 予防的コントロール(Preventive)
    • 特定の悪意のある行動を禁止・制限・抑止するコントロール
    • 例)FW・アクセスコントロール
  • 発見的コントロール(Detective)
    • 悪意のある行動を検知するコントロール
    • 例)IDS・EDR
  • 訂正的コントロール(Corrective・Recovery)
    • 発見的コントロールで検知された事象を修正・是正するコントロール
    • 例)バックアップ
  • 代替コントロール(Compensating)
    • あるコントロールが正当な理由で取れない場合、リスクを低減するために取る代替策のこと

ここでのポイントは、多層防御(Defense-In-Depth)の観点から、複数種類のコントロールを組み合わせていくことが重要だとされています。例えば、アクセスコントロールによる予防的コントロールを実装した後、ログ監視による発見的コントロールを入れるなど組み合わせていくことが重要です。

リスク管理プロセス:Monitorフェーズ

さて、リスクマネジメントプロセスにおける最後のフェーズはモニタリングです。これは、以下の観点から、リスクと対応を監視し、何か変化があればリスク分析・リスク対応をやり直していくというプロセスです。

  • 「リスク対応戦略が適切か?」
  • 「セキュリティコントロールの実効性はあるか?」
  • 「新しいリスクが登場していないか?」

リスク管理プロセスに関するまとめ

さて、上記の結果から、リスクマネジメントとは、リスク分析 → リスク対応 → リスクモニタリングを行っていくことだと言えます。そのため、リスク管理とはこの地道なプロセスを繰り返してく、PDCAサイクルにほかなりません。

さて、リスク分析・管理について少し補足しておきましょう。

補論1:リスク分析の簡略化について

第1回では、リスクとは、「脅威 × 脆弱性 × 資産」と紹介しました。しかし、一部のリスク分析では、「脅威 × 脆弱性」だけでリスク分析をする、さらにはCSCなどのフレームワークを使い、実質的に脆弱性だけでリスク評価をする場合もあります。

このように、リスク分析は簡略化をすることができます。

例えば、「資産は複数種類存在しない」、「いずれの資産も情報漏洩すればビジネス上大きな影響がある」など資産分析の種類によって分析結果がぶれない場合、省略することは可能です。

また、脅威についても、省略することが可能です。例えば、「脅威として特定のシナリオを想定している」、あるいは「いずれの脅威に対しても全力で対応する必要がある」などの場合、脅威をいくら考えても仕方ない場合があります。そうした場合、省略をすることが可能です。

特に、資産・脅威という二つのパラメータは、防御側でコントロールが難しいパラメータです。(一応、資産は防御側で管理できるパラメータなのですが、「これは非常にリスクが高い資産なので破棄しましょう」と主張したところでビジネス側は絶対に受け入れないでしょう)。そのため、当該2つのパラメータについては整理さえできれば簡略化することができます。

補論2:チェックリストアプローチ vs. シナリオベースアプローチ

上記のように、リスク分析を簡略化し、CSCによる「脆弱性」評価だけによるリスク分析をよくチェックリストアプローチと呼ぶことがあります。ようするに、CSCなどのチェックリストを用意し、YES/NO、あるいは5段階評価などで成熟度を測っていく方法です。このアプローチ自体は、簡単にでき、なにをやらなければいけないか明確にできるアプローチであるためとっかかりとしては非常に良いでしょう。下記記事で紹介した、CIS CSATは典型的なチェックリストアプローチのツールです。

www.scientia-security.org 

しかし、これだけに頼ることは推奨しません。むしろ、CSCなどの棚卸をネットワーク図に当てはめ、攻撃シナリオを意識しながら分析していく、シナリオベースアプローチを利用することをを推奨します。そうしないと、落とし穴が生まれてしまう可能性があるためです。

例を挙げて説明します。例えば、ある企業Xは重要な業務システム・業務データをすべてクラウドに依存しているとしましょう。一方、チェックリストアプローチでチェックすると、(社内OA環境については)全て完璧に対策をできていました。この場合、正しいリスク分析はできているといえるでしょうか。

答えはNOです。上記の場合、一つの攻撃シナリオとしては、クラウドへの攻撃を考えるべきです。しかし、チェックリストに集中してしまい、「どんなネットワークか?」、「実際の攻撃シナリオは何か?」という点をおろそかにすると、本質を見失います。そのため、チェックリストアプローチは重要なアプローチですが、きちんと本質を見失いように攻撃シナリオを意識しながら分析していくことが必要になります。

まとめ

さて、今回は「リスク分析・管理」の最終回ということで、リスクマネジメントプロセスの残りのフェーズについてご紹介しました。また、シナリオベースアプローチの重要性についてもお話をしました。

このように、リスク分析・リスク管理はセキュリティ施策の基礎となる方法ですが、こうした考えがあまり明確に書かれている資料がないため、ご参考になれば幸いです。

*1:但し、最近はサードパーティを活用する場合でも、委託元責任が問われるなどサードパーティ管理という新しいリスクが生まれる可能性があり、リスク転移は部分的にしかできない可能性があるといわれています。

*2:CISSPなどにこうしたカテゴリーは出てきますが、MECEでなかったり、数が教科書によって異なるため、適宜好みの分類を利用してください

「リスク分析・管理」再考(その2)

前回は、リスクの定義、リスクマネジメントプロセスについて紹介しました。

www.scientia-security.org

前回のポイントは、リスクの定義です。改めて復習しておきましょう。

リスク = 発生確率 × 影響度 = 脅威 × 脆弱性 × 資産

今回は、リスクマネジメントプロセスの「ASSESS」フェーズについて具体的に紹介していきたいと思います。 

リスク分析とは、大きく3つの特徴があるといえます。

  • 3要素(脅威・脆弱性・資産)の3要素を特定する。
  • 残存リスク(Residual Risk)を理解する。
  • ROSI(Return on Security Investment)が高い対策を特定する。

リスク分析手法

NIST SP800-30によれば、脅威ベース、脆弱性ベース、資産ベースの3種類のアプローチが紹介されています。但し、結局全要素を分析する必要があるので、どこから手を付けるのか、というだけの話だと考えられます。

例えば、一つのアプローチとして、以下の方法で分析する方法があります。

  • Step 1 : 資産の特定
  • Step 2 : 脅威の特定
  • Step 3 : 脆弱性の特定
  • Step 4 : 残存リスクの特定
  • Step 5 : 発生確率・影響度の決定
  • Step 6 : アウトプット作成

それでは、各ステップごとに検討を進めていきたいと思います。

Step 1 : 資産の特定

資産の特定とは、文字通り自社の資産(システム・データ)を特定することです。そのためには、大きく3種類を特定します。

  1. ネットワーク図の特定
  2. データ資産リストの特定
  3. ビジネスプロセスの特定

第一に、ネットワーク図の策定です。具体的に、自社環境がどんなシステムを持っているか、どんな構成をしているか正確に理解するために、ネットワーク図を作ります。

第二に、データ資産リストとは、どんなデータを保持しており、性質、重要度、考えられる影響などを整理します。これを整理することで、影響度(Impact)が分析できるようになります。

f:id:security_consultant:20200330230013p:plain

第三に、ビジネスプロセスの特定で、具体的にどんな業務プロセスを持っているか整理を行います。この目的は、次で説明する通り、上記で整理したデータがビジネスプロセス上どのように流れていくか、そのデータフローを理解するために行います。

上記3種類の情報を集めたら、最後にマッピングを行います。マッピングとは、特定したデータ資産をネットワーク図、ビジネスプロセスにマッピングしていく作業で、ビジネスプロセス上のデータフロー、ネットワーク図上のデータフローなどを把握することが可能となります。

f:id:security_consultant:20200330215106p:plain

Step 2 : 脅威の特定

次に、脅威の特定を行います。脅威の特定とは、具体的な想定される脅威について、敵対的意図(Intent) × 能力(Capability)分析し、具体的な攻撃シナリオを整理することです。

敵対的意図(Intent)とは、攻撃者のモチベーションです。例えば、Canadian Centre for Cyber Securityが挙げるCyber Threat Actorsの分類では、以下のように分類されます。このモチベーションを果たすために、何をするのか考えることができます。具体的なアクションとして、情報セキュリティのCIA(Confidentiality・Integrity・Availability)の何を侵害するのか、あるいはSTRIDEフレームワークで具体的な脅威を整理しても良いでしょう。

一方、能力(Capability)とは、実際の攻撃手法(TTPs)です。これは、例えば事前に定義された攻撃シナリオを使う方法です。例えば、金融庁は演習などを通じて、攻撃シナリオを提供しています(リンク)。

また、APT・Oraganized Cyber Crimeを想定する場合、Threat Actors(攻撃グループ)を研究することで、攻撃者の意図と能力を同時に分析することができます。例えば、FireEye社のレポートによれば、APT41は知的財産の窃取を目的にしており、医療分野などを攻撃対象とし、次のような攻撃手法で知られています。

attack.mitre.org

www.fireeye.jp

このように攻撃グループを分析することで、脅威(Intent × Capability)を分析することも可能です。脅威グループについては、次のリソースなどを活用することができます。

さて、ここで重要なことは2点です。

第一に、攻撃者の意図(Intent)と、既に特定した「資産」と合致している必要があります。先ほど例に挙げたAPT41の場合、知的財産を狙うため、資産としては知的財産がある必要があります。

第二に、ここで特定した攻撃手法は、ネットワーク図やビジネスプロセスにマッピングしてあげる必要があります。以下に、その例を挙げています。

f:id:security_consultant:20200330222458p:plain

Step 3 : 脆弱性の特定

「脆弱性の特定」とは、自社の脆弱性を特定することです。

では、脆弱性とは何でしょうか?様々な定義があると思いますが、ここでは以下の定義を採用しておきましょう。

脆弱性  = (理想のセキュリティ状態)ー(現在の状態)

 脆弱性とは、あるべきセキュリティの状態(To-Be)と現在のセキュリティ状態(As-Is)のギャップという定義です。例えば、MS17-010脆弱性が脆弱性と認識される理由は以下の通りです。

  • To-Be:本来リモートから任意のコードを実行できてはいけない
  • As-Is:EternalBlueなどの攻撃ツールにより、任意のコードを実行可能

但し、リスク分析では特定の脆弱性について分析するわけではありません。むしろ、システム全体の脆弱性を洗い出していきます。

さて、これをシステム全体の脆弱性を分析する場合、セキュリティフレームワークを利用する方法が一般的です。セキュリティフレームワークは一般に、セキュリティのあるべき姿を示しているため、そのフレームワークを使って現状を分析することでシステム全体の脆弱性を明らかにすることができます。

個人的には、CIS ControlsがCIS CSATという無償分析ツールなども公開をしており使いやすいと思います。CISコントロールの詳細についてはこちらを参照してください。

www.scientia-security.org

Step 4 : 残存リスクの特定

このフェーズは、資産・脅威・脆弱性を利用して、残存リスク(Residual Risk)を特定します。

具体的なフェーズは、以下の通りです(既に実施済内容も含みます)。

タスク1:資産を分析し、影響範囲を特定する。(Step 1で実施済み)

例えば、以下のように資産を特定します。

<顧客データ:重要度(High ~ Very High)>

  • リスク(CIA):機密性(Confidentiality)
  • 資産価値:HIGH(補償・顧客ロイヤリティの喪失)
  • 暗号化なし。データ保存ポリシーがないため、非アクティブな顧客情報も含む
タスク2:資産・攻撃シナリオをNW図へマッピング(Step 2 & 3で実施済み)

資産と攻撃シナリオをネットワーク図にマッピングし、ネットワーク図上の攻撃シナリオを特定します。

タスク3:攻撃シナリオを、脆弱性の分析結果を組み合わせる

特定した攻撃シナリオと現在のセキュリティ対策・不足しているセキュリティ対策を組み合わせて、どの脆弱性(不足したセキュリティ対策)が単一障害点(SPF:Single Point of Failure)になるか、どの脆弱性(不足したセキュリティ対策)が実装されれば攻撃シナリオを止められるか、分析を行います。

その結果を、ネットワーク図にマッピングしていきます。

f:id:security_consultant:20200330222851p:plain

タスク4:残存リスクの特定

その後、上記の結果から、残存リスクをまとめていきます。

残存リスクシナリオ(Threat × Vulnrability :High ~ Very High

攻撃者がカスタマイズされたマルウェアを利用した場合、Office 365とエンドポイントのウイルス対策を回避された場合内部に侵入されます。しかし、侵入後、EDRが存在せず、SOCの能力も低いため、マルウェアを検知することが難しい。また、C&C通信は、Webフィルタリングのアップデートが適切になされていないため、検知できない可能性があります。

Step 5 : 発生確率・影響度の決定

次に、発生確率影響度を導き出します。既に示した通り、それぞれの定義は以下の通りです。

  • 発生確率(定義1)= 脅威 × 脆弱性(定義2)
  • 影響度(定義1)= 資産(定義2)

ここから、R-Map(リスクマップ)へマッピングを行います。既に述べた通り、特にNon-ITの経営層にとってこの図は良いコミュニケーションツールであり、意思決定ツールになります。

ãrisk mapãã®ç»åæ¤ç´¢çµæ

Step 6 : アウトプット作成

次に、上記の結果を踏まえて、アウトプットを作成します。具体的には、上記のようなR-Mapに加え、優先度付きの対策一覧を出すことで具体的なアクションに結び付けていくことができます。

まとめ

今回は、リスク分析の具体的手法について説明してきました。このやり方は全てではありませんが、一つのやり方としてとらえていただければと思います。この評価では、ネットワーク図とビジネスプロセスへのマッピングへ帰着させることを強く意識しています。

その理由としては、ネットワーク図やビジネスプロセスを無視すると、本質的な脅威を見落とす可能性があるためです。たとえば、重要資産がクラウド環境に依存している環境において、いくらオンプレのセキュリティを語っても意味がありません。むしろ、きちんと実態に即した分析をする意味で、実際のビジネスプロセスとネットワーク図に帰着させることが重要だと思います。

次回は、NIST SP800-30 "Managing Information Security Risk"のリスクマネジメントプロセスの残り二つ(Respond・Monitor)とリスク分析の補足議論について行いたいと思います。

www.scientia-security.org

 

CIS Controlsと自己評価ツールCIS CSAT

CIS Controlsとは、CIS(Center for Internet Security)が管理しているサイバーセキュリティのフレームワークで、CSC(Critical Security Control)とも呼ばれます。

通常、セキュリティを担当するように言われた際、自分だけで考えていくと多くの考慮漏れが発生します。フレームワークはそういった考慮漏れがないよう、多くの専門家が検討に参加し、網羅性を担保した考え方です。

ちなみに、サイバーセキュリティのフレームワークはこれだけでなく、様々な種類があります(一部、法制度なども含まれます)。

先ほど「網羅性」という単語を使いましたが、多くのフレームワークは特徴を持っており、CIS Controlsはサイバー攻撃に対する技術的対策をメインとするフレームワークです。

CIS Controlsの歴史

CIS Controlsの歴史は、2008 年にさかのぼります。国防総省(DoD)のセキュリティ支出に対して優先度をつける為、国防長官府(Office of the Secretary of Defense)がNSAに対して、「無数あるセキュリティ対策の優先度をつけるプロジェクト支援」を依頼をしたのが始まりとされています。

NSAに協力要請が届いた理由は、以下だといわれています。

  • NSAは、当時もっともサイバー攻撃に精通していたこと*1
  • 2000 年代初頭から、ホワイトハウスからの指導により強化された軍部からの要請に基づいて、既知の攻撃を阻止するために最も効果的なセキュリティ対策リストを作成していたこと

もともと政府利用前提とされていた内容ですが、NSAが持つ官民連携の枠組みを活用し、CIS・SANS Institute、様々な有識者を巻き込んで2009年度頃に公開され、現在ではVer.7.1までに進化しています。SANSが以前が全面的に協力していたこともあり、SANS Top 20 とか、SANS Critical Security Controlと呼ばれていた時代もあります。

こうした経緯から、CIS Controlは、サイバー攻撃の技術的対策に特化したフレームワークだと知られています。

より詳しい歴史を知りたい方は、こちらを参照してください。

www.sans.org

CIS Controlsを読み解くポイント

CIS Controls自体は、以下に公開されていますので実際に読んでみることを推奨していますが、読み解く上でのポイントをいくつか紹介したいと思います。(ダウンロード

5つの原則

CIS Controlsは、大きく5種類の原則があります。

  • 攻撃から防御を学ぶ
  • 優先順位をつける
  • 測定とメトリクス
  • 継続的な診断とリスク低減
  • 自動化

特に注目すべきは、「測定とメトリクス」と「自動化」というポイントだと思います。まず、「想定とメトリクス」とは、日々の取り組みを定量化していくという点です。これは、日々のセキュリティプログラムの意義を経営層に説明する上で非常に重要な取り組みです。

www.cisecurity.org

また、CIS Controlsは「自動化」を推奨しています。これは、米国のセキュリティ人材市場が流動的で、人に依存したプロセスが組みづらく、また人間はミスをしやすいのでその可能性を排除したいという考えから、こうしたことに言及しています。

www.scientia-security.org

こうした「測定とメトリクス」や「自動化」などの取り組みを全面に押し出すガイドラインは珍しいといえます。

20種類のコントロール

さて、CIS Controlsは20種類のコントロールで成立しています。元々、サイバー攻撃対策の優先度を決めるフレームワークだけあり、技術的、NISTフレームワークの5カテゴリー(特定・予防・検知・対応・復旧)をバランス良く入っています。

  • CIS Control 01:ハードウェア資産のインベントリとコントロール
  • CIS Control 02:ソフトウェア資産のインベントリとコントロール
  • CIS Control 03:継続的な脆弱性管理
  • CIS Control 04:管理権限のコントロールされた使用
  • CIS Control 05:ハードウェアおよびソフトウェアのセキュアな設定
  • CIS Control 06:監査ログの保守、監視および分析
  • CIS Control 07:電子メールと Web ブラウザの保護
  • CIS Control 08:マルウェア対策
  • CIS Control 09:ネットワークポート・プロトコル・サービスの制限とコントロール
  • CIS Control 10:データ復旧能力
  • CIS Control 11:ファイアウォール・ルータ・スイッチなどのネットワーク機器のセキュアな設定
  • CIS Control 12:境界防御
  • CIS Control 13:データ保護
  • CIS Control 14:Need‐to‐Know に基づいたアクセスコントロール
  • CIS Control 15:無線アクセスコントロール
  • CIS Control 16:アカウントの監視およびコントロール
  • CIS Control 17:セキュリティ意識向上トレーニングプログラムを実施する
  • CIS Control 18:アプリケーションソフトウェアセキュリティ
  • CIS Control 19:インシデントレスポンスと管理
  • CIS Control 20:ペネトレーションテストおよびレッドチームの訓練

 

3つのカテゴリー

CIS Controlsは、Basic・Foundational・Organizational の3種類に分類されます。

Basicに分類されるCIS Control 1 ~ 6までは必要不可欠であり、最初にやるべきCyber Hygiene(サイバー公衆衛生)として知られています。そのため、Cyber Hygieneについて聞かれた場合は、この6つのコントロールを提示すればよいことになります。

f:id:security_consultant:20200324230050p:plain

 4つの項目

各CIS Controlsは、以下の4項目が必ず書かれています。

  • 当該コントロールの重要性
  • サブコントロール
  • 手順とツール
  • システムエンティティ図

その重要性と各コントロールを実現するためのサブコントロールが表現されています。また、先ほどキーワードで挙げた通り、自動化に向けた「手順・ツール」と実装例としての「システムエンティティ図」なども紹介しています。

CIS Controlsの利点

CIS Controlsの利点は、様々なリソースが公開されている点が挙げられます。

例えば、CIS Controlsに伴って対策を実装するのであれば、当然次の疑問は、「何がソリューションになるか?」でしょう。昔は、SANSが認定製品リストのようなものを作っていたのですが、現在は中立性を優先してか、そういった情報は出なくなっています。以下に、古いバージョンも含めてリンクを張っておきます。

また、Windows 10とCSCについては以下で整理されています。

www.cisecurity.org

CIS Controlsによる自己評価(CIS CSAT)

CSCを活用する方法として、自社のセキュリティ態勢を評価することができる点です。

実際に、CSCは成熟度を評価するツール(CIS CSAT : CIS CSC Self-Assessment Tools)を提供しています。

www.cisecurity.org

もともと、こうした自己評価ツールとして、AuditScript社のExcel評価ツールを推奨していましたが、CSCの管理元であるCSC CSATというツールを出したため、これを使うのが良いと考えています(実際、このフレームワーク自体もAuditScript社の内容を参照しているようです)。私も登録して使ってみましたが、Evidenceを登録させたり、承認機能があり、同業他社との比較をしたり、報告用PPTを自動作成してくれたりと、無償でも非常によくできているツールだと思います。

f:id:security_consultant:20200329202931p:plain

もちろん、セキュリティ企業に依頼すれば、独自フレームワーク等を使い、インタビューやエビデンスを分析してもらい、第三者的観点での評価を得ることができます。しかし、こうした評価は多くの予算と労力を必要としますので、自社でCSCで評価できる人材がいる、予算が少ない企業はこうした無償ツールを使うことも一つの手段だとできます。

補足:他のフレームワークとの関係性

他のフレームワークとの関係性については、上記のCIS CSATがマッピングを整理していますし、また資料もいくつか存在します。

補足:オープンフレームワーク vs. 独自フレームワーク

こうしたフレームワークに基づく評価として、オープンフレームワークとコンサルティング会社が提供する独自フレームワークのどちらを使うべきかという議論があります。個人的にはオープンなフレームワークの利用を推奨していますが、メリット・デメリットを踏まえて判断すべき内容だと考えています。

オープンなフレームワークは、多数の専門家による知見が結集されている一方、使い方に成熟する必要があったり、コンセプトによっては期待する網羅性が担保されていない可能性があります(例えば、CSCのは技術的対策を中心としているため、内部不正やプロセスという面では弱い可能性があります)。

一方、コンサルティング会社の独自フレームワークは、様々なフレームワークを組み合わせているケースが大半のため、より多くの網羅性がカバーされていたり、個社の性質によってはよりマッチしている可能性があります。一方、ロックインの要因になる、他社比較が難しい、グループ内・業界内の共通言語になりづらい、評価に偏りがでる可能性がある、サービス提供停止になる可能性があるなど、デメリットもあります。

個人的には、こうした評価は、一過性ではなく継続的に実施すべき内容ですので、できるだけオープンフレームワークを使うことが望ましいと考えていますが、それぞれのメリット・デメリットを判断しながら決定するのが望ましいといえます。

まとめ

 今回は簡単にCSCの概要と自己評価ツールについて整理しました。こうしたフレームワークによる点検は継続的に見直していくべき内容ですので、ツールを使いながら整理していくと良いかと思います。

*1:実際、TAO(Tailered Access Operation)と呼ばれる攻撃チームを持っています。

「リスク分析・管理」再考(その1)

セキュリティの世界にいると、「リスク分析」や「リスクベースアプローチ」という単語を非常によく耳にします。「リスク」という概念は、セキュリティに限らず様々な局面において登場しますが、意外とその定義は難しく、明確なイメージを持っている人は少ないと思います。

今回は、様々な学術的知見や各種標準をみながら、「リスク」への理解を深めたいと思います。

リスクの定義

まず、リスクの定義について探ってみましょう。ISO/IEC 27005 Information Security RIsk Managementによれば、Information Security Riskによると、以下のように定義されています。

The potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization. It is measured in terms of a combination of the probability of occurrence of an event and its consequence.


(著者翻訳)
想定される脅威が資産の持つ脆弱性を悪用した結果、組織に対して悪影響を与える潜在的可能性。これは、イベントの発生確率ともたらされる結果の組み合わせで評価される。

この定義は大きく2種類の定義が含まれています。ひとつづつ分析していきましょう。

定義1:発生確率 × 影響度

まず、「イベントの発生確率ともたらされる結果の組み合わせで評価される」という部分に焦点を当ててみます。この定義は、リスクの標準的な定義として採用されており、現在では以下のように表現します。

リスク = 発生確率(Likelihood) ×影響度(Impact)

まず、発生確率(Likelihood)とは、「セキュリティイベントが実際に発生する確率」を意味します。一方、影響度(Impact)とは、「セキュリティイベントが発生したことにより発生する損失の大きさ」を意味します。この二つの要素がわかれば、セキュリティリスクを決定できるという考え方です。

リスク分析の結果は、R-Map(リスクマップ)と呼ばれる発生確率と影響度のマトリックスで可視化していきます。この表現が好まれる理由は、2軸で非常にシンプルであること、発生頻度と影響度というセキュリティの専門家でなくても理解できる用語でリスクを表現できるためです。そのため、経営層への説明にはよくこの形で説明されることがあります。

ãrisk mapãã®ç»åæ¤ç´¢çµæ

定義2:脅威・資産・脆弱性

さて、「発生確率 × 影響度」でリスクが表現できることがわかりました。

では、次の論点として、「どのように、この発生確率と影響度を評価するか?」という課題がでてきます。正直これは難しい問題で、サイバーリスクの発生確率などを明確に言える人はまずいないでしょう。

そのため、リスクの別の定義を利用してリスクを分析し、その結果から発生確率・影響度を考えていくというアプローチをとっていきます。先ほどのISOの定義に振り返ってみると、リスクとは脅威・資産・脆弱性という3要素で決定するという別の定義が紹介されています。

リスク = 脅威 × 脆弱性 × 資産

脅威・資産・脆弱性という聞きなれない言葉が登場していますが、のちに紹介するように、こちらの方がより具体的に評価できるため、実務的には使いやすい定義だといえます。

各要素の具体的説明に入る前に、先ほどの定義1(発生確率 × 影響度)と定義2の関係性について触れたいと思います。結論から言えば、以下のような関係性を持っています。、実際のリスク分析では、まず脅威・脆弱性・資産を定義・調査し、その結果から発生確率影響度を導き出すという流れになるといえます。

  • 発生確率(定義1)= 脅威 × 脆弱性(定義2)
  • 影響度(定義1)= 資産(定義2)

さて、ISOの定義から2種類の定義とその関係性について確認してきました。

リスク = 発生確率 × 影響度 = 脅威 × 脆弱性 × 資産

では、次に脅威、脆弱性、資産はそれぞれ何を意味するのか、説明していきます。

要素1:「資産」の定義

第一の要素は、資産(Asset)について取り上げたいと思います。資産とは、「情報セキュリティにより守るべき対象」で、以下が挙げられます。

  • 個人情報(PII・PHI)
  • 顧客情報・機密情報
  • 認証情報
  • 金融情報(銀行口座情報、クレジットカード情報)
  • 知的財産情報(製品のドキュメント、特許関連情報、ソースコード)
  • サービス提供リソース(HP、サービス提供環境)
  • 企業ブランド・イメージ
  • 当該企業の特徴(政府との取引が多い、汎用的ソフトウェアを販売している etc.)

情報セキュリティを考える時、まず最初に考えるべきことは「守るべき対象」を正確に把握することです。資産を正確に把握しないと、守るべき資産がないのに耐火金庫を買ったり、珍しい宝石をコインロッカーにしまっておくように不整合が起きてしまいます。英語ではこうした守るべき資産をCrown Jewel(クラウン・ジュエル)と呼び、こうした資産を特定する分析手法をCJA(Crown Jewel Analysis)といいます。詳しくは、Crown Jewels Analysisを参照いただきたいですが、守るべき対象を知るためには、ビジネスプロセス分析、データベースの分析などの分析をして、保持している資産を一覧化して優先度をつけていくというアプローチが必要となります。

要素2:「脆弱性」の定義

第二の要素は、脆弱性(Vulnerability)です。プロセス・技術などに内在する情報セキュリティ上の欠点や欠陥を意味します。ここで注意すべき点は、この「脆弱性」は、防御側がコントロールできるパラメータです。そのため、多くのリスク分析後は、この点を改善する形で対応を行います。

この欠点・欠陥は大きく3種類のレイヤー(3P)で考える必要があります。 

技術(Product / Technology)

技術的な脆弱性とは、「Webサーバにパッチが適用されていない」、「IDSがネットワーク上に設置されていない」、「情報資産がインターネットからアクセス可能な位置に配置されている」などの欠点・欠陥を意味します。

プロセス/管理(Process/Management)

プロセス上の脆弱性とは、「資産管理が適切に行われず、パッチが適用されていないサーバが存在する可能性がある」、「ビジネスプロセス上の観点から、送金処理の検証・承認プロセスが不十分である」、など、業務プロセス上の課題が挙げられます。

人(People)

人の脆弱性とは、Social EngineeringやPhishingなどの課題が挙げられます。但し、人の脆弱性については、Security Awarenessと呼ばれる分野で改善することが一般的ですが、完全な対策にはなり得ない点、注意が必要です。 

要素3:「脅威」の定義

リスクに関する最後の要素、脅威(Threat)について考えています。脅威の定義も様々ですが、重要な点はこの「脅威」は攻撃者の目線で考える必要があるという点です。

詳しい議論は、以下を参照していただきたいですが、結論だけ紹介しておきます。

www.scientia-security.org

脅威は、以下のように定義されます。

脅威 = 敵対的な意図 × 機会 × 能力

但し、リスク分析の観点でいえば、「機会が、既に登場した脆弱性」と同じであること」という注意点が上がられます。「攻撃者から見て攻撃の機会がある」=「防御側から見て脆弱性がある」という点です。上記のことから、リスク分析で脅威を考えるときは、(「機会」の部分は脆弱性(Vulneraiblity)の評価に譲り、)敵対的意図(Intent) × 能力(Capability)だけで評価することが一般的です。*1

リスクマネジメントプロセス

リスク分析アプローチの詳細に入る前に、その上位概念であるリスクマネジメントについて言及をしていきましょう。NIST SP800-30 "Managing Information Security Risk"によれば、リスクマネジメントは以下のようなプロセスとなっています。

f:id:security_consultant:20191214174550p:plain

ASSESSフェーズで、「どんなリスクがどこにあるか?」評価し、RESPONDフェーズでリスクに対応し、最後にMONITORフェーズでリスク関連のアクティビティを監視し、適切にリスクが低減できているか否か、新しい問題は発生していないか見定めます。

FRAMEは、リスクマネジメントプロセスを支える枠組みで、一過性の取り組みではなく、継続して実施すべきことを示しています。

これ以降の記事では、このリスクマネジメントプロセスを使いながら解説をしていきます。

補足:リスクの定義

リスクの定義として「発生確率 × 影響度 = 脅威 × 脆弱性 × 資産」を紹介し、この枠組みで分析していくことを紹介しました。しかし、この定義が唯一の定義ではありません。

例えば、一部の定義では、Threat × Vulnerability を採用している教科書も存在します。特定の「資産」についてリスク分析したい、特定の「資産」が漏洩した場合ビジネスが相当の影響があり、資産に優先順位が存在しない、という場合は、2要素で考えることでリスク分析を単純化することも可能です。

また、FAIR Instituteが出しているFAIR Framework(Factor Analysis of Information Risk)でも、発生確率 × 影響度を軸とした独自のフレームワークを利用しています。

いずれにせよ、どのフレームワークを使うにせよ、きちんと理解して使うことが重要です。

en.wikipedia.org

まとめ

この記事では、以下について言及しました。

  • リスクの定義(2種類の定義)
  • リスクの3要素(資産・脆弱性・脅威)
  • リスクマネジメントプロセス

ここで一番抑えてほしいことは、リスクの定義です。

リスク = 発生確率 × 影響度 = 脅威 × 脆弱性 × 資産

次回の記事では、リスクマネジメントプロセスの最初のフェーズ(ASSESSフェーズ)の説明に入り、具体的なリスク分析のアプローチについて解説を行います。 

www.scientia-security.org

 

*1:厳密にいうと、攻撃側と防御側で見え方が異なるため、厳密には同義ではありません。防御側は内部の事情に熟知しているため弱いポイントが色々見えますが、それすなわち攻撃者が同じように見えるとは限らず、意外と攻撃者からは脆弱なポイントが見えない可能性があります。そのまた逆もあり、FWにRDPなどをうっかり公開しているにも関わらず、内部の人間にはその脆弱性が見えていない可能性もあります。とはいえ、そこまで議論しているとリスク分析が相当複雑なモノになるので、ここでは同義としてとらえましょう。

Intelligence-Driven Threat Intelligenceの解説

先日、Internet Week 2019にてActive Defenseに関する講演を行ってきました。その中の一つとして、Threat Huntingについて紹介を行いました。

Internet Week 2019の公式サイトより、資料はこちらからダウンロードしてください。

www.slideshare.net

今回は、Threat Huntingについて講演の内容から外した部分も含めてまとめたいと思います(一年前ぐらいに同じような記事を書いているため、一部重複します)。

www.scientia-security.org

Threat Huntingの定義(復習)

Amazonのクラウド部門に買収されたSqrrl社のホワイトペーパー``A Framework for Cyber Threat Hunting''の定義が今でも有効です。

We define hunting as the process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions. 

(筆者簡易訳)

既存のセキュリティ対策を回避する高度な脅威を検知・隔離するために、能動的かつ再帰的にネットワーク内を探索するプロセス

プロセスモデル(復習)

プロセスモデルも様々存在します。但し、「どのようにThreat Huntingをやるか?」という点に尽きる為、好きなモデルを使えばよいと考えています。

Intelligence Driven Threat Hunting

最近色々研究した中は、SANS CTI Summit 2018でKeith Gilbert氏が発表したモデル(Intelligence-Driven Threat Intelligence)が一番実効性が高いのではないかと考えています。理由としては、Threat Intelligenceの活用を意識していることが挙げられます。

f:id:security_consultant:20191214135123p:plain

以下にそのプロセスを説明していきます。また、以下に彼の講演ビデオを示します。

www.youtube.com

Step 1 : Intelligence Inputs(脅威インテリジェンスの入手)

第一のステップでは、脅威インテリジェンスを入手し、脅威ハンティングのネタ・手がかりを入手します。ここでは、「良い脅威インテリジェンス」を入手することが重要となり、そのためには、4要素(4A)を満たすことだといえます。*1

  • Acuracy(正確性)
  • Audience Focusd(消費者目線)
  • Actionable(アクショナブル)
  • Adequate Timing(適切なタイミング)

また、入手先として、以下の3種類が挙げられます。

  • 外部ソース(Open):ベンダーレポート・ブログ・無償の脅威インテリジェンス情報
  • 外部ソース(Closed):有償の脅威インテリジェンスサービス・情報コミュニティ
  • 内部ソース:アラート・ベースラインからの差異・ユーザからの通報

Step 2 : Decompose Action(アクションの分解)

第2ステップは、脅威インテリジェンスを読み解き、検証可能な単位に分割するフェーズです。これを正確に理解するためには、IOCの文脈、どんな攻撃手法やツールが利用されているか、攻撃者による可変性(変更しやすいIOCなのか?)について分析を行う必要があります。

Step 3 : Create Hypothesis(仮説構築)

第3ステップは、仮説構築フェーズです。Threat Huntingは「既存のセキュリティ対策を回避する」未知の攻撃を洗い出すことです。そのため、(野生の勘が鋭い人を除き)闇雲に探しても時間を浪費してしまいます。そのため、科学的アプローチ(検証可能な仮説→検証)を行う必要があります。

仮説構築は、大きく2種類の方法があります。

アプローチ1:初級者向け(IOCをそのまま適用)

最近のベンダーレポートは、IOCが一覧として載っているケースも少なくありません。そのため、はじめてThreat Huntingをやられる方々には、当該IOCを利用して仮説構築を行うことを推奨しています。

但し、こうしたIOCは既に公開されている時点で過去の攻撃であり、多くの製品にはシグニチャとして反映されていることが想定されます。そのため、セキュリティ製品が十分でない場合を除き、ほとんどの場合引っかかることはないとは言えます(とはいえ、Threat Huntingのイメージを持つうえでは非常に有効です)

また、クローズドな情報(例:ISACからAmberなどで共有される情報)にアクセスできる場合、その情報はまだセキュリティ製品に反映されている可能性は低いのでそのままIOCを活用することは意味があるといえるでしょう。

アプローチ2:中級者向け(IOCを活用する)

中級者の場合、IOCをそのまま活用するのではなく、一歩踏み込み、攻撃手法(TTPs・IoA)に注目する方法が一般的です。本プロセスを提唱したKeith Gilbert氏によれば、IOCの一般化(Generalization of IOC)という手法を取り上げています。これは、IOCを一段高い目線に引き上げるという考え方です。

f:id:security_consultant:20191214142750p:plain

例えば、攻撃者がマルウェアの持続性メカニズムとして、サービスを悪用したとします。その時、当該サービス名がIOCと共有されるはずです。但し、サービス名はいくらでも変更できますので、直接探してもヒットする可能性は低いでしょう。そのため、この点について一般化を行い、サービス名の作成・変更を検知するというIOCを作成すれば、名前に依存せず検索で引っ掛けることができます。

IOCの議論において、Pyramid of Pain(痛みのピラミッド)と呼ばれる概念がありますが、まさに名前などのレイヤーが低い部分からTTPsという高い目線に切り替えることを推奨しているのが、この「IOCの一般化」という概念です。

f:id:security_consultant:20170113154400p:plain

 

また、仮説構築のベースとなるのは、入手した脅威インテリジェンスですが、それ以外にも加味する要素が2つあります。

第一に、「自社環境が置かれている状況」(IT環境・業種・ビジネス動向)です。脅威インテリジェンスには、IOCのような戦術的インテリジェンス(Tactical Intelligence)もありますが、そのIOCの原点となるThreat Actorは特定の技術を活用したり、特定の業種を狙いうちにするIntent(敵対的な意図)があるはずです。通常、それがマッチしていないと、狙われる可能性は低いといえるはずです。そのため、自社が置かれている環境などを正確に把握することは意味があるといえるでしょう。

第二に、「過去の経験」です。TTPsは色々なバラエティに変化しますが、検知の観点から攻撃に気付けるポイントという点については過去の知見に頼ることができます。また、自社の環境に詳しいアナリストであれば、攻撃されやすいポイントやCrown Jewelに基づいたHuntingができるはずです。以下に、IOCの優先度を高める観点から、検知によく使われるIOCのランキング(*2*3)を示します。

f:id:security_consultant:20191214154145p:plain

Step 4 : Hunt!!

第4ステップは、(仮説の)検証フェーズです。このステップを行う前提として、十分な可視化(Full-Spectrum Visibility)が確保されている必要があります。逆に言えば、行くら具体的で検証しやすい仮説を構築できたとしても、検証を行うすべがなければ、意味がありません。

もちろん、EDRやSIEMなど、可視化するツールが十分に整っている組織はそれらを使えばよいですし、別の方法としてフリーツールを活用する方法もあります。

以下に、Threat Hunting界隈で名前がよく上がるツールを示します*4

f:id:security_consultant:20191214165519p:plain

 

Step 4.5 : After Hunting

仮説検証が終わると、以下の二つの状態になるはずです。

ハンティング成功の場合

あまりないはずですが、「仮説が正しく、攻撃の痕跡を確認できた場合」です。つまり、これは攻撃が既に行われた、あるいは現在進行形でやられていることを意味します。すると、ハンティングプロセスを終了し、Incident Responseモードへ移行します。

また、ここでハンティングに成功した場合、ナレッジをISACなどの各種コミュニティに還元できると非常にベターです。

ハンティング失敗の場合

攻撃の痕跡が確認できない場合」です。原則的にはStep 1 ~ 3へ戻ります。

但し、ここでは「攻撃が行われていない」と短絡的な結論に飛びつかず、なぜ痕跡見つからないか、(いちいち原因究明しないまでも)その理由は意識しておくことが大事です。現在のような高度な攻撃が行われる場合、「攻撃が行われていない」と証明することは「悪魔の証明」で、検証することは難しいといえるでしょう。そのため、こうしたハンディングでも、「○○と××の痕跡がないから、APT XXの攻撃は受けていない」と、一定の蓋然性・合理性をもって判断ができるようにしなければいけないと考えます。

さて、元の議論に戻ると、「攻撃の痕跡が確認できない場合」の理由は複数挙げられます。この理由を考えながら、進めることにより、どのステップに戻るべきなのか、次のHuntingへ入る前に何を気を付けなければいけないか気付くことができます。

  • 「(攻撃の痕跡の)探し方が悪い」
  • 「仮説が正しくない」
  • 「選択した脅威インテリジェンスが適切ではない」

Step 5 & 6 : Enrich Actions & Form Activity Group

さて、Step 5 & 6とは、Diamond Modelを軸にした高度な分析手法を前提としており、Internet Week 2019では説明を省きました。また、通常の組織はStep 4.5までできれば十分だと思います。

ここでは、少し詳細に踏み込みたいと思います。

まず、Step 5 : Enrich Actions とは、今回活用できた仮説(IOC)を既存の情報と結び付け、脅威インテリジェンスの充実化を図ることを意味します。脅威インテリジェンスやフォレンジックの活動において、ピボット(Pivoting)という概念があります。『インテリジェンス駆動型インシデントレスポンス』によれば、「情報の1つを使って、既知、あるいは未知の情報群の特定につなげる技術」と定義されていますが、見つけた新しいIOCから、次のIOCを芋づる式に引き出していくイメージとなります。

例えば、先ほどの「IOCの一般化」で説明した通り、「サービスの作成・変更」という軸で調査を行うと、直近怪しいサービスが作成されていたとしましょう。その場合、サービスの作成時刻、作成したプロセスを新たなキーワードとすることでさらに新しいIOCを見つけ出すことができます。

次に、Step 6 : Form Activity Group です。まず、Activity Groupとは、以下のように定義されます。

common/similar malicious events, adversary processes, and threads

(筆者簡易訳)

共通/類似の悪意のあるイベント、攻撃プロセス、スレッド

 APT XXに狙われる企業で、かつ高度なセキュリティが施されている場合、複数回の侵入(インシデント)が発生しています。その場合、それらの複数のインシデントを横にならべ、共通となる手口・手法をならべ、APT XXの特徴をあぶり出すAttribution技術です。実際にこれを詳しくやるためには、Diamond Modelと呼ばれる手法を使いますが、(一般的な企業で)ここまで実際にやることはほとんどないため、その手法は別途解説したい思います。

 

The Diamond Model For Intrusion Analysis: A Primer (SANS CTI Summit 2014)

補足:専門ベンダーにやってもらうのはいいのでは?

こういう話をユーザ系企業にすると、専門業者(MSSP・MDR-SP)が提供するサービスを使うべき、任せるべきではないか?いう議論になります。確かに、全部とは言えませんが一部セキュリティ監視サービスを提供する企業は、サービスの一環としてこうしたThreat Huntingを実施してくれるでしょう。

それでも筆者は、(体力に余裕がある組織は)自社でもできれば実施したほうが良いと考えています。具体的には、MSSPを使いながら自社でも行う、ハイブリッドモデルを推奨しています。

第一の理由として、「脅威インテリジェンスが共有できないケースも多い」です。特に、ISACなどでは、TLP(Traffic Light Protocol)という情報共有の可能な範囲を定義しており、情報によっては自社内に閉じて検証を行わないといけないこともあるといえます。

また第二の理由として、「自社のおかれている環境」を踏まえ、コンテキストを踏まえて脅威ハンティングできる組織は自社だけだと思います。これは、自社のIT環境だけでなく、ビジネス環境なども踏まえた話になります。また、脅威ハンティングの一つの手法として、アノマリー(異常)に注目する方法がありますが、「何が異常であるか?」、「どこに弱点があるか?」は組織によって異なります。

以上のことから、自社でもやることが望ましいといえるでしょう。但し、私も実施した経験がありますが、こうしたThreat Huntingは終わりがないため、時間があれば限りなく実施することもできてしまいますので1時間なり時間を決めてやるのが望ましいと思います。

参考文献

Threat Huntingを勉強される方のため、いくつか勉強用コンテンツを紹介します。

ThreatHunting Project

このサイトは、Threat Huntingに関する情報が多数集まっているサイトです。特に、Threat Huntingの基礎作成に貢献したSqrrl社のコンテンツもアーカイブされています。私が個人的に3部作と呼んでいるコンテンツも公開されています。

  • 『Huntpedia』
  • 『A Framework for Cyber Threat Hunting』
  • 『Hunt Evil: Your Practical Guide to Threat Hunting』

SANS Institute: Summit Archives

SANSが『Threat Hunting & Incident Response Summit』や『SANS Cyber Threat Summit』と呼ばれるサミットを開いており、その中で関連するコンテンツを見るのも手です。一定の品質が担保されていると感じています。最近では、日本語でその様子をレポートしてくれているケースもあるようです。

jpn.nec.com

同様の手法として、SANSのReading Roomを利用して、関連するホワイトペーパーを読んだり、Irongeek.comなどで関連するカンファレンスの公演を聞くのも一つの手だと思います。

 

また、各種セキュリティベンダーのブログも非常に参考になるでしょう。

まとめ

この記事では、Intelligenceを軸としたThreat Huntingについて説明を行いました。こうした手法は、現在のようにツールでは検知が難しい高度な攻撃者には有効な攻撃手法です。脅威インテリジェンスを活用しようとしている組織の参考になれば幸いです。

*1:翻訳した『インテリジェンス駆動型インシデントレスポンス』によれば、3要件(Accuracy・Audience Focusd・Actionable)が定義されています。一方、Threat Intelligenceの別の書籍である『Effective Threat Intelligence: Building and Running an Intel Team for Your Organization』によれば、次の3要件(Actionable・Certainty・Timing)が説明されています。記載されていない1要素を加えることで、4要素として説明したいと考えています。

*2:https://www.youtube.com/watch?v=9Ndv0W2Uq0U

*3:https://www.darkreading.com/attacks-breaches/top-15-indicators-of-compromise/d/d-id/1140647

*4:一つ一つリンクを張るのが大変だったので、講演資料を張り付けています。気になるものが検索してみて下さい。名前が書かれていない眼のログのツールは、The Zeek Network Security Monitorというツールで以前はBroとして知られていたツールです。また最近では、RedHuntLabsという会社もいくつかという会社もいくつか面白いツールを出していそうです。