先日オンラインで開催された『金融ISAC アニュアルカンファレンス 2020』において、『2019年度金融ISACアワード（個人賞）』を頂戴しました。ありがとうございます！！
受賞に伴い、アワード受賞記念講演として、『Intelligence Driven Securityの＜ことはじめ＞』と題して、脅威インテリジェンスの活用についてお話させていただきました。金融ISACはクローズドなカンファレンスのため、講演は会員企業に限定されますが、資料の共有について、金融ISACと会社の許可が下りましたので公開します。
今回の講演では、これから脅威インテリジェンスの活用を開始する金融機関を想定し、脅威インテリジェンスの分類や、活用手法などについてお話しさせていただきました。既に脅威インテリジェンスの活用に取り組まれている企業にとっては、基本的な内容かもしれませんが、ご参考になれば幸いです。
前回（その２）は、リスク分析について深くご紹介しました。
大きく、６種類のステップでやることをご紹介します。
上記のプロセスは、上記のプロセスは、NIST SP800-30 "Managing Information Security Risk"におけるリスクマネジメントプロセスにおいて、「Assess」フェーズに該当します。今回は、残りの二つのプロセス「Respond」と「Monitor」をご紹介します。
リスク分析を経てリスクを特定した後は、リスクへの対応を行います。リスク対応戦略は大きく４種類存在します。一般的には、リスク低減 → リスク受容をすることが一般的な戦略となります。
リスク低減（Risk Mitigation）において、セキュリティコントロールを実装することが一般的です。分類は様々ですが、セキュリティコントロールは複数のカテゴリーに分類されます*2。
ここでのポイントは、多層防御（Defense-In-Depth）の観点から、複数種類のコントロールを組み合わせていくことが重要だとされています。例えば、アクセスコントロールによる予防的コントロールを実装した後、ログ監視による発見的コントロールを入れるなど組み合わせていくことが重要です。
さて、リスクマネジメントプロセスにおける最後のフェーズはモニタリングです。これは、以下の観点から、リスクと対応を監視し、何か変化があればリスク分析・リスク対応をやり直していくというプロセスです。
さて、上記の結果から、リスクマネジメントとは、リスク分析 → リスク対応 → リスクモニタリングを行っていくことだと言えます。そのため、リスク管理とはこの地道なプロセスを繰り返してく、PDCAサイクルにほかなりません。
さて、リスク分析・管理について少し補足しておきましょう。
第１回では、リスクとは、「脅威 × 脆弱性 × 資産」と紹介しました。しかし、一部のリスク分析では、「脅威 × 脆弱性」だけでリスク分析をする、さらにはCSCなどのフレームワークを使い、実質的に脆弱性だけでリスク評価をする場合もあります。
このように、リスク分析は簡略化をすることができます。
例えば、「資産は複数種類存在しない」、「いずれの資産も情報漏洩すればビジネス上大きな影響がある」など資産分析の種類によって分析結果がぶれない場合、省略することは可能です。
また、脅威についても、省略することが可能です。例えば、「脅威として特定のシナリオを想定している」、あるいは「いずれの脅威に対しても全力で対応する必要がある」などの場合、脅威をいくら考えても仕方ない場合があります。そうした場合、省略をすることが可能です。
特に、資産・脅威という二つのパラメータは、防御側でコントロールが難しいパラメータです。（一応、資産は防御側で管理できるパラメータなのですが、「これは非常にリスクが高い資産なので破棄しましょう」と主張したところでビジネス側は絶対に受け入れないでしょう）。そのため、当該２つのパラメータについては整理さえできれば簡略化することができます。
上記のように、リスク分析を簡略化し、CSCによる「脆弱性」評価だけによるリスク分析をよくチェックリストアプローチと呼ぶことがあります。ようするに、CSCなどのチェックリストを用意し、YES/NO、あるいは５段階評価などで成熟度を測っていく方法です。このアプローチ自体は、簡単にでき、なにをやらなければいけないか明確にできるアプローチであるためとっかかりとしては非常に良いでしょう。下記記事で紹介した、CIS CSATは典型的なチェックリストアプローチのツールです。
しかし、これだけに頼ることは推奨しません。むしろ、CSCなどの棚卸をネットワーク図に当てはめ、攻撃シナリオを意識しながら分析していく、シナリオベースアプローチを利用することをを推奨します。そうしないと、落とし穴が生まれてしまう可能性があるためです。
例を挙げて説明します。例えば、ある企業Xは重要な業務システム・業務データをすべてクラウドに依存しているとしましょう。一方、チェックリストアプローチでチェックすると、（社内OA環境については）全て完璧に対策をできていました。この場合、正しいリスク分析はできているといえるでしょうか。
答えはNOです。上記の場合、一つの攻撃シナリオとしては、クラウドへの攻撃を考えるべきです。しかし、チェックリストに集中してしまい、「どんなネットワークか？」、「実際の攻撃シナリオは何か？」という点をおろそかにすると、本質を見失います。そのため、チェックリストアプローチは重要なアプローチですが、きちんと本質を見失いように攻撃シナリオを意識しながら分析していくことが必要になります。
さて、今回は「リスク分析・管理」の最終回ということで、リスクマネジメントプロセスの残りのフェーズについてご紹介しました。また、シナリオベースアプローチの重要性についてもお話をしました。
このように、リスク分析・リスク管理はセキュリティ施策の基礎となる方法ですが、こうした考えがあまり明確に書かれている資料がないため、ご参考になれば幸いです。
前回は、リスクの定義、リスクマネジメントプロセスについて紹介しました。
前回のポイントは、リスクの定義です。改めて復習しておきましょう。
リスク = 発生確率 × 影響度 = 脅威 × 脆弱性 × 資産
今回は、リスクマネジメントプロセスの「ASSESS」フェーズについて具体的に紹介していきたいと思います。
リスク分析とは、大きく３つの特徴があるといえます。
NIST SP800-30によれば、脅威ベース、脆弱性ベース、資産ベースの３種類のアプローチが紹介されています。但し、結局全要素を分析する必要があるので、どこから手を付けるのか、というだけの話だと考えられます。
例えば、一つのアプローチとして、以下の方法で分析する方法があります。
それでは、各ステップごとに検討を進めていきたいと思います。
資産の特定とは、文字通り自社の資産（システム・データ）を特定することです。そのためには、大きく３種類を特定します。
第一に、ネットワーク図の策定です。具体的に、自社環境がどんなシステムを持っているか、どんな構成をしているか正確に理解するために、ネットワーク図を作ります。
第二に、データ資産リストとは、どんなデータを保持しており、性質、重要度、考えられる影響などを整理します。これを整理することで、影響度（Impact）が分析できるようになります。
第三に、ビジネスプロセスの特定で、具体的にどんな業務プロセスを持っているか整理を行います。この目的は、次で説明する通り、上記で整理したデータがビジネスプロセス上どのように流れていくか、そのデータフローを理解するために行います。
上記３種類の情報を集めたら、最後にマッピングを行います。マッピングとは、特定したデータ資産をネットワーク図、ビジネスプロセスにマッピングしていく作業で、ビジネスプロセス上のデータフロー、ネットワーク図上のデータフローなどを把握することが可能となります。
次に、脅威の特定を行います。脅威の特定とは、具体的な想定される脅威について、敵対的意図（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は知的財産の窃取を目的にしており、医療分野などを攻撃対象とし、次のような攻撃手法で知られています。
このように攻撃グループを分析することで、脅威（Intent × Capability）を分析することも可能です。脅威グループについては、次のリソースなどを活用することができます。
さて、ここで重要なことは２点です。
第一に、攻撃者の意図（Intent）と、既に特定した「資産」と合致している必要があります。先ほど例に挙げたAPT41の場合、知的財産を狙うため、資産としては知的財産がある必要があります。
第二に、ここで特定した攻撃手法は、ネットワーク図やビジネスプロセスにマッピングしてあげる必要があります。以下に、その例を挙げています。
「脆弱性の特定」とは、自社の脆弱性を特定することです。
では、脆弱性とは何でしょうか？様々な定義があると思いますが、ここでは以下の定義を採用しておきましょう。
脆弱性 = （理想のセキュリティ状態）ー（現在の状態）
脆弱性とは、あるべきセキュリティの状態（To-Be）と現在のセキュリティ状態（As-Is）のギャップという定義です。例えば、MS17-010脆弱性が脆弱性と認識される理由は以下の通りです。
但し、リスク分析では特定の脆弱性について分析するわけではありません。むしろ、システム全体の脆弱性を洗い出していきます。
さて、これをシステム全体の脆弱性を分析する場合、セキュリティフレームワークを利用する方法が一般的です。セキュリティフレームワークは一般に、セキュリティのあるべき姿を示しているため、そのフレームワークを使って現状を分析することでシステム全体の脆弱性を明らかにすることができます。
個人的には、CIS ControlsがCIS CSATという無償分析ツールなども公開をしており使いやすいと思います。CISコントロールの詳細についてはこちらを参照してください。
このフェーズは、資産・脅威・脆弱性を利用して、残存リスク（Residual Risk）を特定します。
具体的なフェーズは、以下の通りです（既に実施済内容も含みます）。
例えば、以下のように資産を特定します。
＜顧客データ：重要度（High ~ Very High）＞
資産と攻撃シナリオをネットワーク図にマッピングし、ネットワーク図上の攻撃シナリオを特定します。
特定した攻撃シナリオと現在のセキュリティ対策・不足しているセキュリティ対策を組み合わせて、どの脆弱性（不足したセキュリティ対策）が単一障害点（SPF：Single Point of Failure）になるか、どの脆弱性（不足したセキュリティ対策）が実装されれば攻撃シナリオを止められるか、分析を行います。
その結果を、ネットワーク図にマッピングしていきます。
その後、上記の結果から、残存リスクをまとめていきます。
残存リスクシナリオ（Threat × Vulnrability ：High ~ Very High）
攻撃者がカスタマイズされたマルウェアを利用した場合、Office 365とエンドポイントのウイルス対策を回避された場合内部に侵入されます。しかし、侵入後、EDRが存在せず、SOCの能力も低いため、マルウェアを検知することが難しい。また、C&C通信は、Webフィルタリングのアップデートが適切になされていないため、検知できない可能性があります。
次に、発生確率・影響度を導き出します。既に示した通り、それぞれの定義は以下の通りです。
ここから、R-Map（リスクマップ）へマッピングを行います。既に述べた通り、特にNon-ITの経営層にとってこの図は良いコミュニケーションツールであり、意思決定ツールになります。
次に、上記の結果を踏まえて、アウトプットを作成します。具体的には、上記のようなR-Mapに加え、優先度付きの対策一覧を出すことで具体的なアクションに結び付けていくことができます。
今回は、リスク分析の具体的手法について説明してきました。このやり方は全てではありませんが、一つのやり方としてとらえていただければと思います。この評価では、ネットワーク図とビジネスプロセスへのマッピングへ帰着させることを強く意識しています。
その理由としては、ネットワーク図やビジネスプロセスを無視すると、本質的な脅威を見落とす可能性があるためです。たとえば、重要資産がクラウド環境に依存している環境において、いくらオンプレのセキュリティを語っても意味がありません。むしろ、きちんと実態に即した分析をする意味で、実際のビジネスプロセスとネットワーク図に帰着させることが重要だと思います。
次回は、NIST SP800-30 "Managing Information Security Risk"のリスクマネジメントプロセスの残り二つ（Respond・Monitor）とリスク分析の補足議論について行いたいと思います。
CIS Controlsとは、CIS（Center for Internet Security）が管理しているサイバーセキュリティのフレームワークで、CSC（Critical Security Control）とも呼ばれます。
通常、セキュリティを担当するように言われた際、自分だけで考えていくと多くの考慮漏れが発生します。フレームワークはそういった考慮漏れがないよう、多くの専門家が検討に参加し、網羅性を担保した考え方です。
ちなみに、サイバーセキュリティのフレームワークはこれだけでなく、様々な種類があります（一部、法制度なども含まれます）。
先ほど「網羅性」という単語を使いましたが、多くのフレームワークは特徴を持っており、CIS Controlsはサイバー攻撃に対する技術的対策をメインとするフレームワークです。
CIS Controlsの歴史は、2008 年にさかのぼります。国防総省（DoD）のセキュリティ支出に対して優先度をつける為、国防長官府（Office of the Secretary of Defense）がNSAに対して、「無数あるセキュリティ対策の優先度をつけるプロジェクト支援」を依頼をしたのが始まりとされています。
NSAに協力要請が届いた理由は、以下だといわれています。
もともと政府利用前提とされていた内容ですが、NSAが持つ官民連携の枠組みを活用し、CIS・SANS Institute、様々な有識者を巻き込んで2009年度頃に公開され、現在ではVer.7.1までに進化しています。SANSが以前が全面的に協力していたこともあり、SANS Top 20 とか、SANS Critical Security Controlと呼ばれていた時代もあります。
こうした経緯から、CIS Controlは、サイバー攻撃の技術的対策に特化したフレームワークだと知られています。
より詳しい歴史を知りたい方は、こちらを参照してください。
CIS Controls自体は、以下に公開されていますので実際に読んでみることを推奨していますが、読み解く上でのポイントをいくつか紹介したいと思います。（ダウンロード）
CIS Controlsは、大きく５種類の原則があります。
特に注目すべきは、「測定とメトリクス」と「自動化」というポイントだと思います。まず、「想定とメトリクス」とは、日々の取り組みを定量化していくという点です。これは、日々のセキュリティプログラムの意義を経営層に説明する上で非常に重要な取り組みです。
また、CIS Controlsは「自動化」を推奨しています。これは、米国のセキュリティ人材市場が流動的で、人に依存したプロセスが組みづらく、また人間はミスをしやすいのでその可能性を排除したいという考えから、こうしたことに言及しています。
こうした「測定とメトリクス」や「自動化」などの取り組みを全面に押し出すガイドラインは珍しいといえます。
さて、CIS Controlsは20種類のコントロールで成立しています。元々、サイバー攻撃対策の優先度を決めるフレームワークだけあり、技術的、NISTフレームワークの５カテゴリー（特定・予防・検知・対応・復旧）をバランス良く入っています。
CIS Controlsは、Basic・Foundational・Organizational の３種類に分類されます。
Basicに分類されるCIS Control 1 ~ 6までは必要不可欠であり、最初にやるべきCyber Hygiene（サイバー公衆衛生）として知られています。そのため、Cyber Hygieneについて聞かれた場合は、この６つのコントロールを提示すればよいことになります。
各CIS Controlsは、以下の４項目が必ず書かれています。
その重要性と各コントロールを実現するためのサブコントロールが表現されています。また、先ほどキーワードで挙げた通り、自動化に向けた「手順・ツール」と実装例としての「システムエンティティ図」なども紹介しています。
CIS Controlsの利点は、様々なリソースが公開されている点が挙げられます。
例えば、CIS Controlsに伴って対策を実装するのであれば、当然次の疑問は、「何がソリューションになるか？」でしょう。昔は、SANSが認定製品リストのようなものを作っていたのですが、現在は中立性を優先してか、そういった情報は出なくなっています。以下に、古いバージョンも含めてリンクを張っておきます。
また、Windows 10とCSCについては以下で整理されています。
CSCを活用する方法として、自社のセキュリティ態勢を評価することができる点です。
実際に、CSCは成熟度を評価するツール（CIS CSAT : CIS CSC Self-Assessment Tools）を提供しています。
もともと、こうした自己評価ツールとして、AuditScript社のExcel評価ツールを推奨していましたが、CSCの管理元であるCSC CSATというツールを出したため、これを使うのが良いと考えています（実際、このフレームワーク自体もAuditScript社の内容を参照しているようです）。私も登録して使ってみましたが、Evidenceを登録させたり、承認機能があり、同業他社との比較をしたり、報告用PPTを自動作成してくれたりと、無償でも非常によくできているツールだと思います。
もちろん、セキュリティ企業に依頼すれば、独自フレームワーク等を使い、インタビューやエビデンスを分析してもらい、第三者的観点での評価を得ることができます。しかし、こうした評価は多くの予算と労力を必要としますので、自社でCSCで評価できる人材がいる、予算が少ない企業はこうした無償ツールを使うことも一つの手段だとできます。
他のフレームワークとの関係性については、上記のCIS CSATがマッピングを整理していますし、また資料もいくつか存在します。
こうしたフレームワークに基づく評価として、オープンフレームワークとコンサルティング会社が提供する独自フレームワークのどちらを使うべきかという議論があります。個人的にはオープンなフレームワークの利用を推奨していますが、メリット・デメリットを踏まえて判断すべき内容だと考えています。
オープンなフレームワークは、多数の専門家による知見が結集されている一方、使い方に成熟する必要があったり、コンセプトによっては期待する網羅性が担保されていない可能性があります（例えば、CSCのは技術的対策を中心としているため、内部不正やプロセスという面では弱い可能性があります）。
一方、コンサルティング会社の独自フレームワークは、様々なフレームワークを組み合わせているケースが大半のため、より多くの網羅性がカバーされていたり、個社の性質によってはよりマッチしている可能性があります。一方、ロックインの要因になる、他社比較が難しい、グループ内・業界内の共通言語になりづらい、評価に偏りがでる可能性がある、サービス提供停止になる可能性があるなど、デメリットもあります。
個人的には、こうした評価は、一過性ではなく継続的に実施すべき内容ですので、できるだけオープンフレームワークを使うことが望ましいと考えていますが、それぞれのメリット・デメリットを判断しながら決定するのが望ましいといえます。
今回は簡単にCSCの概要と自己評価ツールについて整理しました。こうしたフレームワークによる点検は継続的に見直していくべき内容ですので、ツールを使いながら整理していくと良いかと思います。
*1:実際、TAO（Tailered Access Operation）と呼ばれる攻撃チームを持っています。
セキュリティの世界にいると、「リスク分析」や「リスクベースアプローチ」という単語を非常によく耳にします。「リスク」という概念は、セキュリティに限らず様々な局面において登場しますが、意外とその定義は難しく、明確なイメージを持っている人は少ないと思います。
今回は、様々な学術的知見や各種標準をみながら、「リスク」への理解を深めたいと思います。
まず、リスクの定義について探ってみましょう。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.
（著者翻訳）
想定される脅威が資産の持つ脆弱性を悪用した結果、組織に対して悪影響を与える潜在的可能性。これは、イベントの発生確率ともたらされる結果の組み合わせで評価される。
この定義は大きく２種類の定義が含まれています。ひとつづつ分析していきましょう。
まず、「イベントの発生確率ともたらされる結果の組み合わせで評価される」という部分に焦点を当ててみます。この定義は、リスクの標準的な定義として採用されており、現在では以下のように表現します。
リスク = 発生確率（Likelihood） ×影響度（Impact）
まず、発生確率（Likelihood）とは、「セキュリティイベントが実際に発生する確率」を意味します。一方、影響度（Impact）とは、「セキュリティイベントが発生したことにより発生する損失の大きさ」を意味します。この二つの要素がわかれば、セキュリティリスクを決定できるという考え方です。
リスク分析の結果は、R-Map（リスクマップ）と呼ばれる発生確率と影響度のマトリックスで可視化していきます。この表現が好まれる理由は、２軸で非常にシンプルであること、発生頻度と影響度というセキュリティの専門家でなくても理解できる用語でリスクを表現できるためです。そのため、経営層への説明にはよくこの形で説明されることがあります。
さて、「発生確率 × 影響度」でリスクが表現できることがわかりました。
では、次の論点として、「どのように、この発生確率と影響度を評価するか？」という課題がでてきます。正直これは難しい問題で、サイバーリスクの発生確率などを明確に言える人はまずいないでしょう。
そのため、リスクの別の定義を利用してリスクを分析し、その結果から発生確率・影響度を考えていくというアプローチをとっていきます。先ほどのISOの定義に振り返ってみると、リスクとは脅威・資産・脆弱性という３要素で決定するという別の定義が紹介されています。
リスク = 脅威 × 脆弱性 × 資産
脅威・資産・脆弱性という聞きなれない言葉が登場していますが、のちに紹介するように、こちらの方がより具体的に評価できるため、実務的には使いやすい定義だといえます。
各要素の具体的説明に入る前に、先ほどの定義１（発生確率 × 影響度）と定義２の関係性について触れたいと思います。結論から言えば、以下のような関係性を持っています。、実際のリスク分析では、まず脅威・脆弱性・資産を定義・調査し、その結果から発生確率・影響度を導き出すという流れになるといえます。
さて、ISOの定義から２種類の定義とその関係性について確認してきました。
リスク = 発生確率 × 影響度 = 脅威 × 脆弱性 × 資産
では、次に脅威、脆弱性、資産はそれぞれ何を意味するのか、説明していきます。
第一の要素は、資産（Asset）について取り上げたいと思います。資産とは、「情報セキュリティにより守るべき対象」で、以下が挙げられます。
情報セキュリティを考える時、まず最初に考えるべきことは「守るべき対象」を正確に把握することです。資産を正確に把握しないと、守るべき資産がないのに耐火金庫を買ったり、珍しい宝石をコインロッカーにしまっておくように不整合が起きてしまいます。英語ではこうした守るべき資産をCrown Jewel（クラウン・ジュエル）と呼び、こうした資産を特定する分析手法をCJA（Crown Jewel Analysis）といいます。詳しくは、Crown Jewels Analysisを参照いただきたいですが、守るべき対象を知るためには、ビジネスプロセス分析、データベースの分析などの分析をして、保持している資産を一覧化して優先度をつけていくというアプローチが必要となります。
第二の要素は、脆弱性（Vulnerability）です。プロセス・技術などに内在する情報セキュリティ上の欠点や欠陥を意味します。ここで注意すべき点は、この「脆弱性」は、防御側がコントロールできるパラメータです。そのため、多くのリスク分析後は、この点を改善する形で対応を行います。
この欠点・欠陥は大きく３種類のレイヤー（3P）で考える必要があります。
技術的な脆弱性とは、「Webサーバにパッチが適用されていない」、「IDSがネットワーク上に設置されていない」、「情報資産がインターネットからアクセス可能な位置に配置されている」などの欠点・欠陥を意味します。
プロセス上の脆弱性とは、「資産管理が適切に行われず、パッチが適用されていないサーバが存在する可能性がある」、「ビジネスプロセス上の観点から、送金処理の検証・承認プロセスが不十分である」、など、業務プロセス上の課題が挙げられます。
人の脆弱性とは、Social EngineeringやPhishingなどの課題が挙げられます。但し、人の脆弱性については、Security Awarenessと呼ばれる分野で改善することが一般的ですが、完全な対策にはなり得ない点、注意が必要です。
リスクに関する最後の要素、脅威（Threat）について考えています。脅威の定義も様々ですが、重要な点はこの「脅威」は攻撃者の目線で考える必要があるという点です。
詳しい議論は、以下を参照していただきたいですが、結論だけ紹介しておきます。
脅威は、以下のように定義されます。
脅威 = 敵対的な意図 × 機会 × 能力
但し、リスク分析の観点でいえば、「機会が、既に登場した「脆弱性」と同じであること」という注意点が上がられます。「攻撃者から見て攻撃の機会がある」＝「防御側から見て脆弱性がある」という点です。上記のことから、リスク分析で脅威を考えるときは、（「機会」の部分は脆弱性（Vulneraiblity）の評価に譲り、）敵対的意図（Intent） × 能力（Capability）だけで評価することが一般的です。*1
リスク分析アプローチの詳細に入る前に、その上位概念であるリスクマネジメントについて言及をしていきましょう。NIST SP800-30 "Managing Information Security Risk"によれば、リスクマネジメントは以下のようなプロセスとなっています。
ASSESSフェーズで、「どんなリスクがどこにあるか？」評価し、RESPONDフェーズでリスクに対応し、最後にMONITORフェーズでリスク関連のアクティビティを監視し、適切にリスクが低減できているか否か、新しい問題は発生していないか見定めます。
FRAMEは、リスクマネジメントプロセスを支える枠組みで、一過性の取り組みではなく、継続して実施すべきことを示しています。
これ以降の記事では、このリスクマネジメントプロセスを使いながら解説をしていきます。
リスクの定義として「発生確率 × 影響度 = 脅威 × 脆弱性 × 資産」を紹介し、この枠組みで分析していくことを紹介しました。しかし、この定義が唯一の定義ではありません。
例えば、一部の定義では、Threat × Vulnerability を採用している教科書も存在します。特定の「資産」についてリスク分析したい、特定の「資産」が漏洩した場合ビジネスが相当の影響があり、資産に優先順位が存在しない、という場合は、２要素で考えることでリスク分析を単純化することも可能です。
また、FAIR Instituteが出しているFAIR Framework（Factor Analysis of Information Risk）でも、発生確率 × 影響度を軸とした独自のフレームワークを利用しています。
いずれにせよ、どのフレームワークを使うにせよ、きちんと理解して使うことが重要です。
この記事では、以下について言及しました。
ここで一番抑えてほしいことは、リスクの定義です。
リスク = 発生確率 × 影響度 = 脅威 × 脆弱性 × 資産
次回の記事では、リスクマネジメントプロセスの最初のフェーズ（ASSESSフェーズ）の説明に入り、具体的なリスク分析のアプローチについて解説を行います。
*1:厳密にいうと、攻撃側と防御側で見え方が異なるため、厳密には同義ではありません。防御側は内部の事情に熟知しているため弱いポイントが色々見えますが、それすなわち攻撃者が同じように見えるとは限らず、意外と攻撃者からは脆弱なポイントが見えない可能性があります。そのまた逆もあり、FWにRDPなどをうっかり公開しているにも関わらず、内部の人間にはその脆弱性が見えていない可能性もあります。とはいえ、そこまで議論しているとリスク分析が相当複雑なモノになるので、ここでは同義としてとらえましょう。
