FAIRモデルとは何か:サイバーリスクを「高・中・低」ではなく「金額」で説明する方法
概念図
FAIRは、リスクをひと塊として扱わず、頻度と規模に分けて考えます。これにより、どの対策がどこに効くのかを、金額や残存リスクまで含めて説明しやすくなります。
はじめに
サイバーセキュリティの議論では、「このリスクは高い」「この脆弱性は危険である」「この対策は重要である」「このシステムは重点的に守るべきである」といった表現がよく使われます。これらの表現は間違いではありません。しかし、経営判断や投資判断の場面では、それだけでは不十分になることがあります。経営層や事業責任者が知りたいのは、「どれくらい危ないのか」「放置すると、いくら損失が出る可能性があるのか」「対策すると、どれくらい損失を減らせるのか」「その対策費用は妥当なのか」だからです。
そこで役に立つのが、FAIRモデルです。FAIRは Factor Analysis of Information Risk の略で、日本語では「情報リスクの要因分析」と訳せます。FAIR Institute は、FAIRをサイバーセキュリティおよびオペレーショナルリスクを事業視点・金銭的観点で測定、管理、伝達するための標準的な分類体系および定量リスク分析モデルと説明しています。1
FAIRの中心的な考え方は、サイバーリスクを曖昧な感覚ではなく、損失の発生頻度と損失規模に分解して説明することです。FAIR Model Standard v3.0では、リスクを「将来損失の発生頻度と規模の確からしさ」と定義しており、リスク測定は本質的に将来を扱うため、確率的に扱い、不確実性を入力と出力の両方で考慮すべきものとされています。2
FAIRモデルの基本式
FAIRの基本構造は非常にシンプルです。
Risk = Loss Event Frequency × Loss Magnitude
リスク = 損失発生頻度 × 損失規模
つまりFAIRでは、サイバーリスクを「怖いか、怖くないか」ではなく、「一定期間、典型的には年間で、どれくらいの損失が見込まれるか」として捉えます。これにより、セキュリティ対策を単なるコストではなく、損失を減らすための投資として説明しやすくなります。
ただし、ここで注意すべきなのは、FAIRは「正確な一点の金額」を予言する道具ではないということです。FAIR Model Standard v3.0でも、リスク測定には不確実性があり、その不確実性を入力と出力の両方で考慮する必要があるとされています。2 実務では、最小値・最頻値・最大値のように幅を持たせ、前提条件を明示しながら分析する方が現実的です。
なぜ「高・中・低」だけでは足りないのか
多くの組織では、リスク評価に次のような定性的なマトリクスを使います。
| 発生可能性 | 影響度 | リスク評価 |
|---|---|---|
| 高 | 高 | 高 |
| 中 | 高 | 高 |
| 低 | 高 | 中 |
| 中 | 中 | 中 |
| 低 | 低 | 低 |
このような評価は、初期整理としては有効です。しかし、「リスク高」と言ったとき、それが年間100万円相当のリスクなのか、年間10億円相当のリスクなのかは分かりません。また、対策費用が年間1,000万円の場合に妥当なのか、複数の対策候補のうちどれを優先すべきなのか、例外承認した場合にどの程度の残存リスクを受け入れるのかも説明しにくくなります。
FAIRは、この弱点を補うために、リスクを金額で説明できる形へ分解します。CISもFAIRについて、従来の高・中・低のような定性的評価とは異なり、金銭的な指標を提供し、利害関係者がリスクを共通言語で理解しやすくすると説明しています。3
FAIRモデルの基本構造
FAIRでは、リスクを大きく「損失発生頻度」と「損失規模」に分けます。さらに、損失発生頻度は脅威イベント頻度と感受性、損失規模は一次損失と二次損失に分解されます。FAIR Model Standard v3.0の構成でも、Risk、Loss Event Frequency、Threat Event Frequency、Susceptibility、Loss Magnitude、Primary Loss、Secondary Lossという要素で整理されています。4
サイバーリスク
├─ A. 損失発生頻度
│ ├─ 脅威イベント頻度
│ └─ 感受性 / 損失化しやすさ
└─ B. 損失規模
├─ 一次損失
└─ 二次損失
重要なのは、FAIRがリスクを一つの大きな塊として扱わないことです。リスクを、「どのような脅威が、どれくらいの頻度で、どの資産に作用し、どの程度の確率で損失化し、損失化した場合に、どの種類の損失が、どれくらい発生するのか」に分解します。これにより、対策がどこに効くのかも説明しやすくなります。
損失発生頻度とは何か
損失発生頻度とは、実際に金銭的な損失が発生するイベントが、一定期間内にどれくらい起きるかを表すものです。ここで重要なのは、単なる攻撃回数やアラート件数ではないことです。外部から不審な通信が大量にあったとしても、それがすべて損失につながるわけではありません。
脅威イベント
例:攻撃、誤操作、設定ミス、認証情報の悪用、委託先起因の事故
↓
損失化するか
例:管理策が効いたため損失化しない、検知が早く影響が限定された、発見が遅れ損失化した
↓
損失イベント
つまり、「脅威イベントが起きること」と「損失イベントになること」は別です。FAIRでは、この違いを明確に分けます。CISの解説でも、FAIRにおける損失発生頻度は脅威イベント頻度と、脅威イベントが損失イベントに変わる割合としての脆弱性に分解されると説明されています。3
損失規模とは何か
損失規模とは、損失イベントが起きた場合に、どれくらいの金銭的影響が出るかを表すものです。FAIRでは、損失を大きく一次損失と二次損失に分けます。CISの解説では、一次損失の例として生産性低下、交換・復旧、対応コストなどが挙げられ、二次損失の例として競争上の機会損失、評判損失、罰金・判決などが挙げられています。3
| 区分 | 内容 | 例 |
|---|---|---|
| 一次損失 | 自社に直接発生する損失 | 調査費用、復旧費用、外部専門家費用、対応人件費、システム停止による売上損失、顧客通知費用、問い合わせ対応費用、再発防止対応費用 |
| 二次損失 | 外部の反応によって発生する損失 | 顧客離反、取引停止、失注、訴訟、和解金、規制対応、罰金、信用低下、監査対応の増加、契約条件の悪化 |
一次損失は比較的見積もりやすい一方で、二次損失は不確実性が大きくなります。そのため、二次損失は一点の金額で決め打ちせず、幅を持って評価することが重要です。
FAIRで重要なのは「シナリオ」である
FAIRで最も重要なのは、リスクシナリオの定義です。いきなり「当社のサイバーリスクはいくらか」と考えると、範囲が広すぎて数字が意味を持たなくなります。FAIR Model Standard v3.0でも、リスクは明確に定義された損失イベントシナリオの頻度と規模として測定されるべきものとされ、例として「フィッシング攻撃による個人情報の侵害」のような具体的シナリオが示されています。2
よいシナリオには、少なくとも次の要素が含まれます。
| 要素 | 内容 |
|---|---|
| 脅威主体 | 誰が、または何が原因となるか |
| 脅威イベント | どのような事象が起きるか |
| 対象資産 | どのシステム、SaaS製品、データ、業務か |
| 損失イベント | どの時点で金銭損失が発生するか |
| 影響 | どのような損失が発生するか |
シナリオ例としては、「SaaS製品の設定不備により顧客情報が外部から閲覧可能になる」「SaaS製品の認証情報が悪用され、機密情報が持ち出される」「公開Webシステムの脆弱性が悪用され、個人情報が漏えいする」「マルウェア感染により基幹業務システムが数日間停止する」「委託先環境の侵害により自社データが影響を受ける」「内部者の誤操作により重要データが削除される」などが考えられます。
ここでは、特定のセキュリティ製品名や特定のSaaS製品名に寄せる必要はありません。FAIRで見るべきなのは、製品名そのものではなく、「どの資産に対して、どの脅威イベントが起き、どの損失につながるのか」です。
金額定量化に最低限必要な項目
FAIRを使って金額を見積もるために、最低限必要な項目は次のとおりです。
| No | 項目 | 内容 |
|---|---|---|
| 1 | リスクシナリオ | 何が、何に、どのような損失を与えるか |
| 2 | 対象資産 | 対象となるシステム、SaaS製品、業務、データ |
| 3 | 損失イベント | 金銭損失が発生する具体的な事象 |
| 4 | 年間発生頻度 | その損失イベントが年にどれくらい起きそうか |
| 5 | 1回あたり損失額 | 起きた場合、1回あたりいくら失うか |
| 6 | 損失額の内訳 | 調査費、復旧費、売上損失、通知費など |
| 7 | 対策前のリスク額 | 現状の年間損失見込額 |
| 8 | 対策後のリスク額 | 対策後の年間損失見込額 |
| 9 | 対策コスト | 初期費用、年額費用、運用人件費 |
| 10 | 残存リスク | 対策後も残る損失見込額 |
最初から細かくしすぎると、分析が進まなくなります。FAIRは、精密な計算から始めるよりも、粗い仮説を置き、重要なシナリオから深掘りする方が実務的です。
年間損失見込額の考え方
あるシナリオについて、損失イベントの年間発生確率を10%、発生した場合の損失額を5,000万円と見積もったとします。この場合、単純化した年間損失見込額は次のようになります。
10% × 5,000万円 = 500万円
これは、「毎年必ず500万円の損失が出る」という意味ではありません。そうではなく、「確率的に見れば、年間500万円相当のリスクを抱えている」という意味です。保険の考え方に近く、事故は毎年起きるとは限らないものの、事故が起きる確率と損害額を掛け合わせることで、リスクの期待値を考えることができます。
ただし、FAIR Model Standard v3.0は、分析結果を必ず年間損失額だけで表すべきだとはしていません。たとえば「今後12か月で10万ドルを超える損失が発生する確率は50%」のように、一定金額を超える損失の発生確率として示す方法もあり得ると説明しています。2
数字は一点ではなく「幅」で見る
サイバーリスクには不確実性があります。攻撃が成功するか、発見まで何日かかるか、影響件数がどれくらいになるか、顧客がどれくらい離反するか、報道されるか、取引先がどのように反応するかを、正確に一つの数字で表すことは困難です。そのため、実務では次のように幅を持たせます。
| 項目 | 最小 | 最頻 | 最大 |
|---|---|---|---|
| 年間発生確率 | 5% | 15% | 30% |
| 1回あたり損失額 | 1,000万円 | 5,000万円 | 2億円 |
こうすることで、楽観的なケース、もっともありそうなケース、悲観的なケースを分けて考えられます。FAIRの価値は、正確な一点の金額を出すことではなく、「どの前提なら、どれくらいの損失になり得るか」を見える化することにあります。
対策効果をどう表現するか
セキュリティ対策を導入するとき、「安全性が高まる」「可視性が向上する」「検知力が上がる」「統制が強化される」と説明されることがあります。これらは間違いではありませんが、FAIRではもう一段具体化します。その対策は、損失発生頻度を下げるのか、損失規模を下げるのか、その両方に効くのかを明確にします。
| 対策効果 | FAIR上の意味 |
|---|---|
| 予防 | 損失イベントが起きる確率を下げる |
| 検知 | 発見遅延を短くし、被害拡大を抑える |
| 封じ込め | 影響範囲を限定する |
| 復旧 | 停止時間や復旧費用を下げる |
| 抑止 | 脅威イベントの発生可能性を下げる |
| 証跡化 | 説明、報告、監査対応コストを下げる |
たとえば、あるセキュリティ製品を導入した場合、「危険な状態を早期に発見できる」「人手による見逃しを減らせる」「対応までの時間を短くできる」「影響範囲を限定できる」「結果として、損失化確率や損失規模を下げられる」と整理できます。ここで重要なのは、セキュリティ製品を導入したからリスクがゼロになるとは考えないことです。対策後もリスクは残ります。FAIRでは、その残ったリスクを残存リスクとして表現します。
対策前後の比較
FAIRを使うと、対策前後のリスクを比較できます。例として、あるSaaS製品の設定不備に関するシナリオを考えます。
| 区分 | 年間発生確率 | 1回あたり損失額 | 年間損失見込額 |
|---|---|---|---|
| 対策前 | 20% | 5,000万円 | 1,000万円 |
| 対策後 | 8% | 3,000万円 | 240万円 |
この場合、リスク低減額は次のようになります。
1,000万円 - 240万円 = 760万円
もし対策コストが年間300万円であれば、単純比較では「年間300万円の費用で、年間760万円相当のリスク低減が見込める」と説明できます。ただし、これだけで導入が自動決定されるわけではありません。見積もりの不確実性は大きくないか、他に優先すべきリスクはないか、対策の運用負荷は現実的か、対策対象範囲は十分か、残存リスクを誰が受容するのかといった観点も必要です。FAIRは意思決定を自動化するものではなく、意思決定に必要な材料を整理するものです。
費用対効果を見るときの注意点
セキュリティ対策の費用対効果を考えるとき、製品費用だけを見てはいけません。対策コストには、少なくとも次のようなものがあります。
| No | コスト項目 | 内容 |
|---|---|---|
| 1 | 初期費用 | 設計、構築、導入支援 |
| 2 | ライセンス費 | 年額費用、利用者数、対象範囲に応じた費用 |
| 3 | 運用人件費 | アラート確認、設定変更、棚卸し、報告 |
| 4 | 教育費 | 管理者教育、利用部門教育、手順書作成 |
| 5 | 連携費 | 既存システム、ID管理、ログ基盤との連携 |
| 6 | 誤検知対応費 | 不要アラートの確認、チューニング |
| 7 | 業務影響 | 利便性低下、申請増加、作業遅延 |
| 8 | 監査対応費 | 証跡出力、説明資料作成、レビュー |
逆に、リスク低減効果も製品機能だけで決まりません。対象範囲をどこまでカバーできるか、アラートを誰が見るのか、是正判断を誰が行うのか、運用手順が整備されているか、例外管理ができているか、改善状況を継続的に追えるかに左右されます。セキュリティ製品は、導入しただけでは効果が出ません。FAIRで評価する場合も、製品機能、運用体制、対応手順、組織上の責任分担をセットで見る必要があります。
FAIRで使うデータ
FAIR分析では、数字の根拠が重要です。ただし、最初から完璧なデータがそろうことは多くありません。使えるデータには、次のようなものがあります。
| No | データ | 使い道 |
|---|---|---|
| 1 | 過去インシデント記録 | 発生頻度、対応工数、復旧時間 |
| 2 | 障害管理記録 | 停止時間、影響範囲、復旧費 |
| 3 | 問い合わせ履歴 | 顧客影響、対応件数 |
| 4 | ログ・監視記録 | 攻撃頻度、検知件数、異常兆候 |
| 5 | 脆弱性管理台帳 | 未対応期間、対象資産、深刻度 |
| 6 | SaaS製品の設定棚卸し | 設定不備、権限不備、是正状況 |
| 7 | 監査指摘 | 統制不備、再発傾向 |
| 8 | 契約書 | 通知義務、違約金、SLA、損害賠償条項 |
| 9 | 売上・業務KPI | 停止時の時間あたり損失 |
| 10 | 人件費単価 | 対応工数の金額換算 |
| 11 | 外部見積 | 調査、復旧、法律、広報、監査対応 |
| 12 | 業界レポート | 類似インシデントの損失規模 |
数字が不足している場合は、専門家や関係部門の見積もりを使うこともあります。ただし、その場合は必ず、誰が、何を根拠に、どの範囲で、どの程度の不確実性を前提に見積もったのかを残すべきです。FAIRは、数字をもっともらしく見せるための道具ではありません。前提を明らかにして、判断の透明性を高めるための道具です。
FAIRとチェックリストの違い
セキュリティ管理では、チェックリストがよく使われます。たとえば、管理者に多要素認証を設定しているか、重要データへのアクセス権限を棚卸ししているか、ログを取得しているか、脆弱性診断を実施しているか、バックアップを取得しているか、といった確認です。
チェックリストは、統制の有無を確認するには有効です。しかし、チェックリストだけでは、その項目がどの損失シナリオを下げるのか、未対応の場合にどれくらい損失が増えるのか、代替策でどこまで補えるのか、例外を許容してよいのかを説明しにくい場合があります。
FAIRは、チェックリストを置き換えるというより、チェックリストの意味を説明するために使えます。
| 観点 | 例 |
|---|---|
| チェック項目 | 重要システムの管理者認証を強化しているか |
| 対応するリスクシナリオ | 管理者アカウントの悪用により、重要データが漏えいする |
| FAIR上の意味 | 不正アクセスが損失化する確率を下げる |
| 必要な証跡 | 認証設定、管理者一覧、アクセスログ、例外承認記録 |
このように整理すると、チェックリストは単なる作業確認ではなく、リスク説明責任の一部になります。
FAIRと統制基準の関係
FAIRは、統制基準そのものではありません。どの統制を標準必須にするべきか、どの証跡を保存すべきか、どの開発工程でレビューを入れるべきか、どのログを何年保存すべきか、どの職務分離を求めるべきかは、別途、統制基準やセキュリティ基準として定める必要があります。
FAIRが得意なのは、「その統制が、どのリスクを、どれくらい下げるのか」を説明することです。
| 領域 | 主な役割 |
|---|---|
| 統制基準 | 何を守るべきかを定める |
| 実装基準 | どう実装すべきかを定める |
| 証跡管理 | 実施したことを説明可能にする |
| FAIR | リスクと対策効果を金額で説明する |
つまり、FAIRは単独で完結するものではありません。統制基準、実装基準、証跡管理、リスク受容プロセスと組み合わせることで、実務上の価値が高まります。NIST IR 8286 Rev. 1も、サイバーセキュリティリスク情報をエンタープライズリスクマネジメントに統合し、リスクレジスターを用いて組織・システムレベルのリスクを企業レベルへ連携する考え方を示しています。5
FAIRを導入する際の進め方
FAIRを導入する場合、最初から全社すべてのリスクを定量化しようとすると失敗しやすくなります。現実的には、次の順番がよいです。
| Step | 内容 |
|---|---|
| 1 | 重要なリスクシナリオを数個選ぶ |
| 2 | 最低限の項目で粗く金額化する |
| 3 | 経営、事業、IT、セキュリティ部門で前提を確認する |
| 4 | 損失額が大きいシナリオだけ詳細化する |
| 5 | 対策前後のリスク額を比較する |
| 6 | 対策費用、運用負荷、残存リスクを整理する |
| 7 | 導入、追加対策、受容、移転、回避を判断する |
| 8 | 判断根拠と前提を証跡として残す |
最初の対象としては、重要SaaS製品の設定不備による情報漏えい、公開Webシステムの侵害、認証情報悪用による不正アクセス、マルウェア感染による業務停止、委託先起因の情報漏えい、重要データの誤削除、バックアップ不備による復旧遅延などが向いています。重要なのは、全部を一気にやろうとしないことです。FAIRは、重点リスクから始めるべきです。
FAIRでよくある失敗
FAIRを使うときには、いくつか典型的な失敗があります。
| No | 失敗 | 内容 |
|---|---|---|
| 1 | シナリオが大きすぎる | 「サイバー攻撃全般」のように範囲が広すぎる |
| 2 | 数字を一点で断定する | 不確実性を無視して一つの金額だけを示す |
| 3 | 製品効果を過大評価する | 導入すればリスクが大幅に下がると仮定する |
| 4 | 運用負荷を無視する | アラート確認や是正作業の人件費を入れない |
| 5 | 二次損失を軽視する | 顧客離反、契約影響、規制対応を見落とす |
| 6 | 前提を残さない | 誰が何を根拠に見積もったか不明になる |
| 7 | 経営判断と混同する | FAIR結果だけで自動的に意思決定しようとする |
| 8 | 精緻化しすぎる | 初期段階から細かすぎて分析が進まない |
特に注意すべきなのは、FAIRの数字は「正解」ではないという点です。FAIRは未来を正確に予言するものではありません。不確実なリスクについて、前提を置き、幅を持って、できる限り説明可能な形にするためのモデルです。
FAIRの実務的な価値
FAIRの価値は、単に金額を出すことではありません。実務上の価値は、次の点にあります。
| No | 価値 | 内容 |
|---|---|---|
| 1 | 経営会話に変換できる | 技術的なリスクを金額で説明できる |
| 2 | 優先順位を付けやすい | 複数リスクを損失見込額で比較できる |
| 3 | 投資判断に使える | 対策費とリスク低減額を比較できる |
| 4 | 例外承認に使える | 未対応時の残存リスクを説明できる |
| 5 | 説明責任を果たしやすい | 判断の前提と根拠を残せる |
| 6 | チェックリストを意味付ける | 統制項目がどの損失を下げるか説明できる |
| 7 | 部門間対話を促進する | セキュリティ、IT、事業、法務、経営の共通言語になる |
特に重要なのは、説明責任です。「セキュリティ部門が危険だと言ったから」「チェックリストで未対応だったから」「製品ベンダーが必要だと言ったから」という説明だけでは、十分でない場面が増えています。重要なのは、どのリスクを、どの前提で、どれくらいの損失と見積もり、どの対策で、どれくらい下げられると考え、残ったリスクを、誰が受け入れたのかを説明できることです。FAIRは、この説明を支えるためのモデルです。
FAIRは何を置き換え、何を置き換えないのか
FAIRは強力なモデルですが、すべてを置き換えるものではありません。
| 項目 | FAIRで置き換えられるか |
|---|---|
| リスクの金額定量化 | 得意 |
| 投資対効果の説明 | 得意 |
| リスク受容の説明 | 得意 |
| 統制基準の策定 | 単独では不十分 |
| 技術的な脆弱性診断 | 置き換えない |
| セキュリティ設計 | 置き換えない |
| 監査証跡管理 | 置き換えない |
| 法令遵守確認 | 置き換えない |
| インシデント対応手順 | 置き換えない |
| 製品比較 | 補助にはなるが、単独では不十分 |
FAIRは、セキュリティ管理のすべてを置き換えるものではありません。FAIRは、リスクと対策効果を金額で説明するための中核モデルと考えるべきです。
最小テンプレート
FAIRを使ってリスクを整理する場合、まずは次のテンプレートで十分です。
1. リスクシナリオ
| 項目 | 記入欄 |
|---|---|
| シナリオ名 | |
| 対象資産 | |
| 対象データ・業務 | |
| 損失イベント |
2. 対策前リスク
| 項目 | 最小 | 最頻 | 最大 |
|---|---|---|---|
| 年間発生確率 | |||
| 1回あたり損失額 | |||
| 年間損失見込額 |
3. 対策
| 項目 | 内容 |
|---|---|
| 対策内容 | |
| 対策が効く要素 | 発生頻度を下げる / 損失化確率を下げる / 検知を早める / 封じ込めを早める / 復旧時間を短くする / 損失額を小さくする |
4. 対策後リスク
| 項目 | 最小 | 最頻 | 最大 |
|---|---|---|---|
| 年間発生確率 | |||
| 1回あたり損失額 | |||
| 年間損失見込額 |
5. 費用対効果と判断
| 項目 | 記入欄 |
|---|---|
| リスク低減額 | |
| 対策コスト | |
| 正味効果 | |
| 残存リスク | |
| 判断 | 対策実施 / 追加検討 / 代替策検討 / 一時受容 / リスク移転 / リスク回避 |
まとめ
FAIRモデルは、サイバーリスクを金額で説明するための考え方です。基本式は「リスク = 損失発生頻度 × 損失規模」です。しかし、実務上の価値は単なる計算式にありません。FAIRの本当の価値は、リスクをシナリオに分解すること、発生頻度と損失規模を分けて考えること、対策がどの要素を下げるのかを説明すること、対策前後のリスクを比較すること、残存リスクを明示すること、経営判断に使える言葉へ変換することにあります。
サイバーセキュリティでは、技術的な正しさだけでなく、説明責任が重要になっています。「危険だから対策が必要です」ではなく、「このシナリオでは、年間損失見込額がこれくらいあり、対策によりこれくらい下がる見込みで、それでもこれくらいの残存リスクが残る」と説明できることが重要です。
FAIRは、そのための強力な道具です。ただし、FAIRは万能ではありません。統制基準、実装基準、証跡管理、セキュリティ製品の運用、インシデント対応、監査、リスク受容プロセスと組み合わせてこそ、実務で意味を持ちます。FAIRは、サイバーリスクを「怖い話」から「経営判断できるリスク」に変換するためのモデルです。