セキュリティの世界にいると、「リスク分析」や「リスクベースアプローチ」という単語を非常によく耳にします。「リスク」という概念は、セキュリティに限らず様々な局面において登場しますが、意外とその定義は難しく、明確なイメージを持っている人は少ないと思います。
今回は、様々な学術的知見や各種標準をみながら、「リスク」への理解を深めたいと思います。
リスクの定義
まず、リスクの定義について探ってみましょう。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）について取り上げたいと思います。資産とは、「情報セキュリティにより守るべき対象」で、以下が挙げられます。
- 個人情報（PII・PHI）
- 顧客情報・機密情報
- 認証情報
- 金融情報（銀行口座情報、クレジットカード情報）
- 知的財産情報（製品のドキュメント、特許関連情報、ソースコード）
- サービス提供リソース（HP、サービス提供環境）
- 企業ブランド・イメージ
- 当該企業の特徴（政府との取引が多い、汎用的ソフトウェアを販売している etc.）
情報セキュリティを考える時、まず最初に考えるべきことは「守るべき対象」を正確に把握することです。資産を正確に把握しないと、守るべき資産がないのに耐火金庫を買ったり、珍しい宝石をコインロッカーにしまっておくように不整合が起きてしまいます。英語ではこうした守るべき資産をCrown Jewel（クラウン・ジュエル）と呼び、こうした資産を特定する分析手法をCJA（Crown Jewel Analysis）といいます。詳しくは、Crown Jewels Analysisを参照いただきたいですが、守るべき対象を知るためには、ビジネスプロセス分析、データベースの分析などの分析をして、保持している資産を一覧化して優先度をつけていくというアプローチが必要となります。
要素2：「脆弱性」の定義
第二の要素は、脆弱性（Vulnerability）です。プロセス・技術などに内在する情報セキュリティ上の欠点や欠陥を意味します。ここで注意すべき点は、この「脆弱性」は、防御側がコントロールできるパラメータです。そのため、多くのリスク分析後は、この点を改善する形で対応を行います。
この欠点・欠陥は大きく３種類のレイヤー（3P）で考える必要があります。
技術（Product / Technology）
技術的な脆弱性とは、「Webサーバにパッチが適用されていない」、「IDSがネットワーク上に設置されていない」、「情報資産がインターネットからアクセス可能な位置に配置されている」などの欠点・欠陥を意味します。
プロセス/管理（Process/Management）
プロセス上の脆弱性とは、「資産管理が適切に行われず、パッチが適用されていないサーバが存在する可能性がある」、「ビジネスプロセス上の観点から、送金処理の検証・承認プロセスが不十分である」、など、業務プロセス上の課題が挙げられます。
人（People）
人の脆弱性とは、Social EngineeringやPhishingなどの課題が挙げられます。但し、人の脆弱性については、Security Awarenessと呼ばれる分野で改善することが一般的ですが、完全な対策にはなり得ない点、注意が必要です。
要素3：「脅威」の定義
リスクに関する最後の要素、脅威（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などをうっかり公開しているにも関わらず、内部の人間にはその脆弱性が見えていない可能性もあります。とはいえ、そこまで議論しているとリスク分析が相当複雑なモノになるので、ここでは同義としてとらえましょう。
