サイバー攻撃､｢恐い｣で済ませない経営者の視点
事業計画と無関係にセキュリティリスクを評価するのは無理がある。（写真：Wakko / PIXTA）
「中小企業においても数千万単位、場合によっては億単位のお金を要し、結果として経営に多大な影響が発生する」（「JNSAインシデント損害額調査レポート第2版」）にもかかわらず、サイバーセキュリティリスクを自らの課題として認識していない経営者がいる。
インシデントが発生すれば経営に大きな影響が出る
今に始まったことではないが、サイバーセキュリティに関する事件や事故が後を絶たない。自動車工場や港湾業務の停止、病院業務への影響など、事業基盤や社会基盤への影響が目立つようになった。
東洋経済Tech×サイバーセキュリティのトップページはこちら
また、取引先企業や自社の経営層などになりすましてメールを送るビジネスメール詐欺（BEC）や、メール等から偽サイトに誘導して個人情報を搾取するフィッシングなどのオンライン詐欺は、企業や個人から直接的に金銭を盗み出している。
NTT西日本の子会社で、10年にわたって顧客情報を不正に持ち出していた事件も衝撃を与えた。インシデントが発生した場合、事故対応のほか被害者からの損害賠償請求、事業中断による損失など、経営に大きな影響が出る。ITが事業基盤となった現在では、サイバーセキュリティは主要なビジネスリスクの1つであり、経営課題だ。
ここでは、事業視点からサイバーセキュリティ施策の重要性を理解し、その有効性の評価と必要な対策を分析するアプローチを解説する。
サイバーセキュリティ（以下、セキュリティ）リスクへの対応は、事業計画と同じく「未知の未来に向けた取り組み」だが特性は異なる。
事業計画は、簡単に言うと、財務的な指標を使うことで計画の適切性を試算し、実績を評価する手法が確立している。指標化で損益分岐点を明らかにし、事業ごとに投資対効果を分析することもできる。つまり、計画の評価手法と、実績の評価手法が確立している。
一方、セキュリティリスクは、為替変動などの連続性のあるリスクと異なり、不連続なリスクで、既存の数値の増減に基づいた試算はできない。
そのため想定損害額×想定発生確率を使って試算するが、起きなかった事件や事故の損害を売り上げや利益に相当するような実績として表すことはできない。
つまり、セキュリティリスクは、財務指標を使って計測できる事業計画と同じ手法で扱うことは本質的に無理がある。
事業の文脈からセキュリティリスクを捉えて
そもそも、事業計画と無関係にセキュリティリスクを評価することに無理がある。そのため、事業の文脈からセキュリティリスクを捉える必要がある。
まず、実際に起きたセキュリティ事件・事故の報道に基づいて、想定されるサイバー攻撃のシナリオを作成し、ケーススタディを行うことが有効だ。
シナリオに基づいて、セキュリティ担当やIT担当を中心に「�）標罎任�るか」、「��検知・対処できるか」を評価する。
防御ができず、適切な対処ができないシナリオが事業上の脅威に相当するため、事業の担当者を中心に該当するシナリオの「㋐事業リスク」を評価し、「㋑関係者の役割」を明らかにしていく。
この作業を通じて、セキュリティと事業の双方の視点から、システムへの依存度、事件・事故の影響の大きさ、対策の必要性、責任の所在を精査する。一連の作業で、専門領域が異なる多様な関係者が具体的な議論をできるようになるというわけだ。
「事業リスク」の評価は、シナリオに対して想定される「代表的な事象」に対して、「代表的な評価軸」の観点から事象の影響度・深刻度を評価する。
さらに多様な「関係者の役割」をRACI（Responsible〈実行責任者〉、Accountable〈説明責任者〉、Consulted〈協業先・相談先〉、Informed〈報告先〉）に基づいて明らかにしていく。
事象の影響度・深刻度と関係者の役割が明らかになれば、問題を深掘りしていくことができる。
例えば、システムを止める判断は誰が行うのか（誰に責任があるのか）、その判断のために必要な情報は何か。その情報は用意できるのか、用意ができないとすればどのような対応が必要か。事件・事故の公表をどうするか、被害者への保証は必要かなどといったように。
段階的に作業を進めることで、価値観・業務・距離の近い部署から、ファクト・視点・価値観を横断的に共有するのがポイントだ。
�．札�ュリティ関係者で論点と課題を明らかにする、�⊂陬轡后Ρ人冑�門と論点と課題の確認をする、�Ｋ〔魁�広報などの専門家の考えを確認する、�せ�業部門と議論の基盤を構築する、�シ弍朕悗旅佑┐魍稜Г卦掴世隆霹廚鮃獣曚垢襪箸い辰振餽腓澄�
対処すべき問題については、原因・要因・背景・課題・再発防止策の階層で考察したうえで、具体的な施策を検討する。当然、再発防止策は、組織が実施すべきセキュリティ施策そのものに相当する。
原因・要因・背景・課題・再発防止策の分析例
原因：事象の直接の原因 （例）脆弱性の対処漏れ要因：原因が顕在化した理由 （例）脆弱性を収集し、適用を促す仕組みがなかった背景：要因が解決できなかった理由 （例）セキュリティを配慮したシステム運用コストがアサインされておらず、誰が責任者であるかも不明瞭だった課題：背景を解決するための方策 （例）脆弱性などのセキュリティ上の問題を一元的に管理する部門が必要であり、各システムにおいては、セキュリティ運用の責任を明確にする必要がある再発防止策：課題を具体化した施策 （例）��CSIRT業務に脆弱性の収集と周知を含むものとし、実施計画を早急に作成する。�▲轡好謄爐旅獣曄�運用に関する規程・ガイドラインを見直し、セキュリティに配慮した運用責任者を明確にし、必要な予算の確保を必須事項とする
とくに再発防止策は、技術対策や社内規定の作成にとどまりがちだが、事業計画や組織構成まで踏み込む必要がある。段階を踏んで展開することで、事業に立脚したセキュリティ施策への展開が期待できる。
CISOを経営陣に加えることが重要
セキュリティの話は、ホラーストーリーによく似ている。実態のわからないゴースト（攻撃者）が存在し、ゴーストに遭遇すると恐ろしい災いに巻き込まれる。これを避けるには銀の弾丸、セキュリティソリューションしかないと訴えてくる。
しかし、取り組むべき実体がわからないホラーストーリーを計画に落とし込むのは難しい。実務として取り組むためには、何よりも「恐ろしい災い」を事業リスクとして具体化する必要がある。
セキュリティリスクを指標化する試みは、ROSI（Return On Security investment）、KRI（Key Risk Indicators）、保険数理を取り入れた指標化などの取り組みがあり、どれも興味深い考察と手法が提示されている。
しかし、事業リスクを明らかにしないことには、リターンも投資も試算することはできない。
セキュリティ施策は、何らかの基準に対する遵守性で評価されることが多い。もちろん、重要な取り組みだが、遵守性が有効性を保証しているとは限らない。ここで述べた取り組みを通じて、自身の組織のセキュリティ施策の有効性を評価して、課題を明らかにし、高めていくことができると考えている。
最後になるが、ITが事業基盤となった経営環境では、CISO（セキュリティ責任者）を、経営陣に加えることが重要だ。
CISOが経営の考え方や手順を理解し、事業視点を身に付けるだけではなく、事業計画の立案段階からセキュリティリスクの議論・評価を行うことで事業の手戻りを防ぐことも期待できる。
CISOを経営陣として育成していくことも、ITを事業基盤とする現代の経営課題だろう。
（高橋 正和 ： Preferred Networks セキュリティアーキテクト）
