セキュリティ対策には真剣に取り組んでいる。それでも「結局、何が守られていて、何が手薄なのか」と聞かれると、答えに詰まる組織は少なくありません。インシデント報道を受けてバックアップを見直し、取引先の要請に答え、ベンダーの提案も検討してきた。それぞれの対応は正当でも、全体としての設計図が誰の手元にもない状態は珍しくありません。
NISTサイバーセキュリティフレームワーク（CSF）は、こうした設計図を取り戻すための「共通言語」として、世界中の組織に参照されてきました。技術文書としてではなく、経営判断のための地図として読むと、その価値が見えてきます。
※NISTとはNational Institute of Standards and Technologyの略で「ニスト」と読みます。日本語では米国立標準技術研究所と呼ばれます。
- セキュリティ対策を「担当者任せ」にすることの経営上のリスクは何か
- NIST CSFは、経営にどのような判断を求めているのか
- 自社の規模と文脈で、セキュリティ対策をどこから考えるべきか
1. セキュリティ対策が「場当たり」になる構造
この記事では、インシデントや取引先の要請などのイベントに対応する受動的な状態を、便宜的に「場当たり対応」と呼びます。一つひとつの対応に間違いはなく、担当者が怠けているわけでもありません。問題は対応の妥当性ではなく、誰がどこまでのリスクを許容するかという判断が、どこにも明文化されていないことにあります。
技術的な実装はIT部門が担当しますが、どのリスクをどの程度まで許容するかは、本来は経営判断の領域です。ところが現実には、この「リスク許容度の決定」がうやむやなまま、技術担当者がその都度判断しているケースが多くあります。
リスク許容度とは、「この事象が起きたら、どこまで事業として耐えられるか」という問いへの答えです。たとえば、同じ「システム停止」でも、社内の情報共有ツールが半日使えない状態と、受注処理や決済のシステムが半日止まる状態では、事業へのインパクトがまったく異なります。顧客情報の漏えい、請求処理の停止、取引先への納期遅延——どの事態をどの程度まで許容できるかを整理することが、リスク許容度を決める出発点になります。この判断ができていない組織では、何に投資すべきかも、何を優先すべきかも、定まらないままになります。
そこには、気づかれにくい構造的な問題があります。経営者にとってサイバーリスクは見えにくく、結果が出るまで時間がかかり、比較対象もありません。「何も起きていない」ことがセキュリティの成果なのか、単に運が良かっただけなのかが判然としないのです。この不確実性が投資の判断を後回しにし、組織のセキュリティを「担当者の経験と感覚」に依存させる構造を生みます。
経営者がセキュリティを「技術部門の仕事」として切り離すとき、実際に切り離しているのはリスク管理の意思決定です。その構造を変えるために必要なのは、技術の習得ではなく、リスクを経営として扱うための言語と枠組みを持つことです。
ここで取り上げるNISTサイバーセキュリティフレームワーク（Cybersecurity Framework: CSF）は、米国発のフレームワークです。日本企業の経営者であれば、経済産業省とIPAが策定した「サイバーセキュリティ経営ガイドライン」の方が、より身近に感じられるかもしれません。このガイドラインとNIST CSFは、対応関係がチェックシートで整理されており、経営者がサイバーリスクを経営課題として扱うという問題意識を共有しています。だとすれば、国際的に参照されるこの地図を、経営の言葉で理解しておくことには、それだけの意味があるはずです。
2. NIST CSFとは何か ～成り立ちと2.0への進化
NIST CSFは、米国国立標準技術研究所（NIST）が公開するサイバーセキュリティのフレームワークです。その出発点は、2013年2月にオバマ大統領が署名した大統領令13636「重要インフラのサイバーセキュリティ改善」にあります(出典①)。重要インフラへの度重なるサイバー侵入こそが対策強化の必要性を示しているという趣旨が、大統領令の冒頭に記されています（”Repeated cyber intrusions into critical infrastructure demonstrate the need for improved cybersecurity.”）。電力・通信・金融・医療などの重要インフラに対するサイバー脅威が現実のものとなる中、政府と民間が共通の言語でリスクに向き合うための枠組みが求められました。
ここで重視すべきは、このフレームワークが「義務」ではなく「自発的な参照」として設計されたことです。規制ではなくガイダンスという立場を取ったことで、幅広い産業が参加しやすくなりました。義務化ではなく「使う組織が実際に使える形」にこだわったことが、幅広い組織に受け入れられる基盤になりました。
2014年に初版（1.0）が公開され、2018年に版1.1へ更新されました。そして2024年2月、10年間の運用経験を踏まえてCSF 2.0が公開されています(出典②)。
CSF 2.0は、Core・Profile・Tiersという3つの要素で構成されています(出典②p.1)。
- Core：組織が達成すべき望ましいサイバーセキュリティの成果を、機能・カテゴリ・サブカテゴリという階層で定義したもの
- Profile：自組織の現状と目標をCoreの成果に照らして記述する仕組み
- Tiers：組織のサイバーセキュリティリスクのガバナンスと管理の実践がどの程度体系的かを、4段階（Tier 1：部分的・個別対応／Tier 2：リスク情報を考慮／Tier 3：反復可能／Tier 4：適応的）で特徴づけるもの
本稿では、経営としてリスク許容度を明文化し、現状と目標の差を判断可能な形にすることに焦点を当てるため、その直接の道具となるCoreとProfileを中心に取り上げます。Tiersは、CoreとProfileが扱う「何を・どこまで実現するか」とは別の角度から、自組織のリスク管理の実践がどの程度体系化されているかを捉える際に参照するものです。
以下では、2.0でCoreに加えられた最大の変化から見ていきます。
2.0における最大の変化は「Govern（統治）」機能の追加です。初版からの5機能（特定・防御・検知・対応・復旧）に対し、2.0はこれらすべてを束ねる「経営レベルの意思決定と方針の維持」を独立した機能として位置づけました。加えて、適用対象を「重要インフラ」から「あらゆる規模・業種の組織」へと明確に拡大しています。規模や業種、成熟度を問わずあらゆる組織が使えるようにという方針は、文書自体にも明記されています（”used by any organization — regardless of its size, sector, or maturity”）(出典②)。
この変化は、CSFが従来から持っていたリスク管理の枠組みとしての性格を、経営・統治の側からさらに明確にしたものと捉えられます。技術的な対策だけでなく、その前提となる戦略、役割、方針、監督を独立した機能として示したことに、2.0の大きな意味があります。
序文（Preface）には、以下のように書かれています。
The CSF describes desired outcomes that are intended to be understood by a broad audience, including executives, managers, and practitioners, regardless of their cybersecurity expertise. Because these outcomes are sector-, country-, and technology-neutral, they provide an organization with the flexibility needed to address their unique risks, technologies, and mission considerations. Outcomes are mapped directly to a list of potential security controls for immediate consideration to mitigate cybersecurity risks.
CSFは、サイバーセキュリティの専門知識の有無にかかわらず、経営幹部・管理職・実務担当者を含む幅広い読者が理解できることを意図した望ましい成果を示しています。これらの成果はセクター・国・技術に中立であるため、組織は自社固有のリスク・技術・使命上の考慮事項に対処するために必要な柔軟性を得られます。各成果には、サイバーセキュリティリスクの軽減に向けてすぐに参照できるよう、具体的なセキュリティコントロールの候補が直接紐づけられています。(筆者翻訳)
出典②Prefaceより引用
- 出典①: The White House「Executive Order 13636 – Improving Critical Infrastructure Cybersecurity」（2013年2月12日）
- 出典②: NIST「The NIST Cybersecurity Framework 2.0 (NIST.CSWP.29)」（2024年2月26日）
※CSWPはCybersecurity White Paperの略称
3. 6つの機能を経営の言葉で読む
CSF 2.0の核心は、6つの機能（Function）から成るコア構造にあります。それぞれの技術的な実装を知る前に、各機能が経営者に何を問うているかを理解することが、フレームワークを「使える道具」にする条件です。6機能の定義と構造はCSWP.29のSection 2（p.3〜5）に記載されており、Fig. 2（p.5）ではGovernを中心に据え、他の5機能をその周囲に配した「ホイール図」として全体像が示されています(出典②)。
出典②p.5より引用
3-1. Govern（統治）——経営者自身が問われる層
2.0で新設されたこの機能は、残る5機能すべての土台になります。CSWP.29 Section 2はGovernを「組織のサイバーセキュリティリスク管理の戦略・期待・方針が確立・伝達・監視される」（”The organization’s cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.”）機能と定義しています(出典②p.3)。同文書はGovernが「ホイールの中心」にあるのは、他の5機能の実装全体に影響を与えるからだとも説明しています（”GOVERN is in the center of the wheel because it informs how an organization will implement the other five Functions.”）(出典②p.4)。
この機能が弱い組織では、他の5機能に投資しても「誰が何を決めるか」が曖昧なまま残ります。その根底には、3つの層が欠けていることが多いようです。何を優先するかという判断基準がない、誰が決めるかという責任分界がない、そして一度決めた後に環境変化へ追随する継続的な見直しがない——この3つです。セキュリティインシデント発生時の混乱をたどると、個別対策の不足だけでなく、この3層が十分に設計されていなかったことが背景に見える場合があります。これは、セキュリティに限った話ではなく、デジタル化が進む組織全般に共通する構造的な問題でもあります。
Governは、その3層を経営として設計する機能です。自社のサイバーリスクに関する判断基準は、誰が、どのような根拠で、いつ見直す形で決められているでしょうか。
3-2. Identify（特定）——守るべき「何」を定義する
CSWP.29 Section 2はIdentifyを「組織の現在のサイバーセキュリティリスクが理解される」（”The organization’s current cybersecurity risks are understood.”）機能と定義しています(出典②p.3)。どのような資産（データ、システム、人、プロセス）があり、それぞれにどのようなリスクが伴うかを把握することです。「何を守るか」が定まらなければ、「どう守るか」は定まりません。
経営者にとってのIdentifyは、自社の事業を支える「デジタル的な重心」はどこかを問うことです。顧客データか、設計情報か、受注・請求のシステムか——その答えによって、以降のすべての優先順位が変わります。自社の事業継続に本当に不可欠なデータ・システム・取引関係は何か、経営として答えを持っているでしょうか。
3-3. Protect（防御）——「守るべきもの」を守れているか
CSWP.29 Section 2はProtectを「組織のサイバーセキュリティリスクを管理するための安全策が講じられる」（”Safeguards to manage the organization’s cybersecurity risks are used.”）機能と定義しています(出典②p.4)。アクセス制御、認証、データ保護、セキュリティ教育などが含まれます。経営者にとっての問いは「守るべきものを、許容できる水準で守れているか」という判断で、過剰でも過小でもない「妥当な線」を引くことが求められます。
厄介なのは、その「妥当な線」が正しかったかどうかは、何も起きなかった年にはほとんど検証できないということです。守りを厚くするほど安心は増えますが、その安心にどこまでの予算を割くかという判断には、技術的な正解が用意されているわけではありません。すべてを守ろうとして、守るべきものの優先順位をかえって曖昧にしていないでしょうか。
3-4. Detect（検知）——「気づける状態」にあるか
CSWP.29 Section 2はDetectを「起こりうるサイバーセキュリティ攻撃や侵害が発見・分析される」（”Possible cybersecurity attacks and compromises are found and analyzed.”）機能と定義しています(出典②p.4)。侵害をゼロにすることは現実的ではないという前提に立ち、「何かが起きていることに気づける状態にあるか」を問います。検知能力のない組織は、被害が拡大してから初めて問題を知ることになります。
経営に問われているのは、成果が見えにくい投資をどう正当化するかでもあります。検知の仕組みが機能していれば、「何も起きていない」だけでなく、「起こるかもしれなかった」が見えるようになります。その可視化こそが、次の判断の根拠になります。発生を防ぐだけでなく、異常に気づく責任と手順は、組織の中に明確に決まっているでしょうか。
3-5. Respond（対応）——事前に決める意思決定の連鎖
CSWP.29 Section 2はRespondを「検知されたサイバーセキュリティインシデントに関する行動が取られる」（”Actions regarding a detected cybersecurity incident are taken.”）機能と定義しています(出典②p.4)。「何かあったとき誰が何をするか」を決めておくことは、発生後の混乱を大幅に減らします。対応の質は、訓練と事前設計によって左右されます。
たとえば、業務システムを止める判断を誰が下せるのか、どの規模の被害から経営層や取締役会に報告を上げるのか——こうした線引きを、インシデントの最中に初めて議論する組織は少なくありません。発生後に誰が、どの順序で、どこまで判断するかは、事前に設計されているでしょうか。
3-6. Recover（復旧）——「どこまで戻れれば許容できるか」を決める
CSWP.29 Section 2はRecoverを「サイバーセキュリティインシデントによって影響を受けた資産と業務が復旧される」（”Assets and operations affected by a cybersecurity incident are restored.”）機能と定義しています(出典②p.4)。すべてを元通りにすることが目標ではなく、事業として受け入れ可能な状態に戻るための計画と能力が問われます。その「受け入れ可能な状態」の基準を決めるのは、Governで定めたリスク許容度です。
どの状態まで戻れれば、事業として許容できるのか——その答えを経営として持っているかどうかが、Recoverの本質を決めます。
この6機能は、独立した対策項目の羅列ではありません。Governで定める方針や優先順位は他の5機能を方向づけ、Identifyで把握したリスクはProtectやDetectなどの設計に影響します。ただし、6機能は上から順に完了させる工程ではありません。実際には相互に関連しながら、継続的かつ並行して取り組むものです。その関係性を意識して読むことで、個別対策を全体のリスク管理へ結びつけやすくなります。
ただし、ここまでの整理は、問いを認識しただけの状態にすぎません。「誰がどこまでのリスクを許容するか」という判断を、実際に文章として残し、共有可能な形にする作業は、まだ済んでいません。次章では、その作業を具体的に見ていきます。
4. 取り組みを始めるためのステップ
ここでは、組織規模にかかわらず共通して使える最小限の進め方を整理します。ここでの目的は、経営として判断すべき論点を見える形にすることです。
第1章で触れた問題に、ここでもう一度立ち戻ります。リスク許容度の判断がどこにも明文化されていない、という状態は、6機能を理解しただけでは変わりません。判断を実際に文章として書き出し、誰もが参照できる形に構造化する作業がなければ、CSFはただの知識のままで終わります。
CSFを実際に活用するための手順は、「プロファイル」という概念を中心に組み立てられています。プロファイルとは、自組織の現状と目標をCSFの機能・カテゴリに照らして記述したもので、CSF活用の中心的な道具になります。CSF Organizational Profileは、「組織の現在または目標とするサイバーセキュリティの状態を、CSF Coreの成果の観点から記述する仕組み」（”a mechanism for describing an organization’s current and/or target cybersecurity posture in terms of the CSF Core’s outcomes”）と定義されています(出典②p.26)。曖昧なままにしてきた判断を、構造を持った言葉として残していく作業そのものが、ここでのプロファイル作成です。
NISTはプロファイル作成の具体的な手順を、CSWP.29のFig. 3（p.6）および補足文書NIST SP 1301（Quick Start Guide: Creating Organizational Profiles）にまとめています(出典②③)。
出典②p.6より引用
以下はその5ステップの構造に沿った説明です。
ステップ1：プロファイルのスコープを定める
プロファイルは、組織全体を対象にするか、特定のシステムや事業領域に絞るかを最初に決めます。CSWP.29 Section 3.1はこれを「スコープを明確にするために、プロファイルの基盤となる高レベルの事実と前提を文書化すること」（”Document the high-level facts and assumptions on which the Profile will be based to define its scope”）と説明しています(出典②p.7)。スコープを決めるのは技術的な作業ではなく、「何を対象に議論するか」を経営として決める意思決定です。
ステップ2：必要な情報を収集する
CSWP.29 Section 3.1はこのステップを「プロファイルを作成するために必要な情報を収集すること」（”Gather the information needed to prepare the Organizational Profile”）と位置づけています(出典②p.7)。具体例として、組織の方針、リスク管理の優先事項とリソース、事業影響分析（BIA: Business Impact Analysis）、適用される法令・規制・業界基準、現行の実践やツール、担当者の役割などが挙げられています。
SP 1301はステップ2の解説に付随する形で、優先順位付けをプロファイルの中核的な考え方として位置づけており、「目標プロファイルの中心的な考え方は、適用可能なCSFの成果に対して異なる優先順位を決定すること」（”The central notion of a Target Profile is to determine differing priorities for applicable CSF outcomes”）と説明しています(出典③p.4)。情報収集と並行して、プロファイルで扱う成果の選択と優先順位付けが行われます。
ステップ3：プロファイルを作成する
CSWP.29 Section 3.1はこのステップを「選択したCSFの各成果について、どんな情報をプロファイルに含めるべきかを決定し、必要な情報を文書化すること」（”Determine what types of information the Profile should include for the selected CSF outcomes, and document the needed information”）と説明しています(出典②p.7)。現状（Current Profile）と目標（Target Profile）の両方を記述します。
同節はさらに、目標プロファイルの計画と優先順位付けに役立てるために、現状プロファイルで見えてきたリスクの状況を考慮すること（”Consider the risk implications of the Current Profile to inform Target Profile planning and prioritization”）、またコミュニティプロファイル（特定の業種や用途を対象に、複数の組織が共有する目標に応えるために作成・公開されたCSF成果のベースライン）を目標プロファイルの出発点として活用することも選択肢として示しています（”consider using a Community Profile as the basis for the Target Profile”）(出典②p.7)。
CSWP.29 Section 3.1は現状プロファイルを「組織が現在達成している（または達成しようとしている）成果を特定し、各成果がどの程度達成されているかを明らかにするもの」（”specifies the Core outcomes that an organization is currently achieving (or attempting to achieve) and characterizes how or to what extent each outcome is being achieved”）、目標プロファイルを「組織がサイバーセキュリティリスク管理の目標を達成するために選択・優先した、望ましい成果の状態を特定するもの」（”specifies the desired outcomes that an organization has selected and prioritized for achieving its cybersecurity risk management objectives”）と定義しています(出典②p.6)。
現状プロファイルも目標プロファイルも、技術部門が単独で作るものではなく、経営が主体的に関与するものです。
ステップ4：ギャップを分析し、アクションプランを作成する
現状プロファイルと目標プロファイルの差分を可視化し、優先順位を付けたアクションプランを作成します。CSWP.29 Section 3.1はこれを「現状プロファイルと目標プロファイルの差分を特定・分析し、優先順位付きのアクションプランを策定すること」（”Conduct a gap analysis to identify and analyze the differences between the Current and Target Profiles, and develop a prioritized action plan to address those gaps”）と説明しています(出典②p.7)。
すべてのギャップを同時に埋めることは現実的ではありません。「最初の1手」を経営として選ぶことがここでの目的です。
ステップ5：アクションプランを実施し、プロファイルを更新する
アクションプランを実行し、その結果をプロファイルに反映させます。CSWP.29 Section 3.1はこのステップを「ギャップに対処し、組織を目標プロファイルへと近づけるためにアクションプランに従うこと」（”Follow the action plan to address the gaps and move the organization toward the Target Profile”）と説明しています(出典②p.7)。アクションプランには全体の期限を設けることも、継続的に進めることもできます。
このサイクルは一度で完結するものではありません。CSWP.29のPrefaceには「サイバーセキュリティのリスクは絶えず拡大しており、それらのリスク管理は継続的なプロセスでなければならない」（”Cybersecurity risks are expanding constantly, and managing those risks must be a continuous process.”）と明記されており(出典②p.iv)、Section 3.1もこのサイクルを「継続的改善に向けて必要に応じて繰り返す」（”an organization can repeat these steps as often as needed”）ものと位置づけています(出典②p.7)。
一度作って終わりにするのではなく、このサイクルを回し続けることそのものが、CSF活用の本体だといえます。
5. 企業規模で変わる「どこから手をつけるか」
ここまでのステップは、組織の規模を問わず同じ手順で進みます。違うのは、現状プロファイルと目標プロファイルに、どこまでの深さと範囲を求めるかという点です。規模が小さいからといって、6機能のうち気に入った機能だけを残し、残りを存在しないものとして扱ってよいわけではありません。むしろ規模によって変わるのは、どこを深く掘り、どこを簡潔な記述で済ませるか、という優先順位の置き方です。
大企業にとってのCSFは、「既存のセキュリティ対策を整理・説明するための共通言語」としての価値が大きいといえます。複数の事業部門、複数のシステム、複数のベンダーが絡む環境では、バラバラに積み上がった対策を経営として俯瞰できる地図が必要になります。CSFのGovern機能を起点に経営レベルでのリスク方針を明文化し、既存の取り組みをCSFの機能に紐づけて、現状プロファイルを作ることが第一のステップになります。業界基準、取引先の評価、調達要件などでCSFとの対応関係を説明する必要がある組織では、共通言語としての価値がさらに高まります。
中小企業にとっての問いは、「どのリスクが自社事業にとって致命的か」です。中小企業では、特定のシステム、担当者、取引先への依存が事業全体に直結している場合があります。代替手段や復旧に投入できる資源が限られる組織では、一つの停止や情報漏えいが経営全体へ及ぼす影響も大きくなります。したがって、企業規模から対策水準を決めるのではなく、自社の事業を止めかねない依存関係を特定することが出発点になります。その依存関係の把握が、プロファイルの形を決めます。取引先からサプライチェーンセキュリティ評価への対応を求められるケースでは、評価項目とCSFの機能の対応を確認することで、自社のリスク許容度と外部要件を照らし合わせる起点にもなります。
個人事業主・小規模事業者にとっても、6機能は等しく存在しています。異なるのは、各機能のインパクトの大きさと、許容できるリスクの性質です。個人事業主・小規模事業者では、すべての機能を詳細な文書や専任体制に落とし込むことは現実的ではありません。それでも、「誰が何を決めるか」「何に依存しているか」「どのように守るか」「異常にどう気づくか」「発生時にどう動くか」「どの状態まで復旧するか」という6機能の問い自体は残ります。重要なのは機能を省略することではなく、自社の規模に見合う簡潔さで答えを残すことです。
CSFは本来、義務ではなく自発的に参照される枠組みとして設計されました。しかし、取引先からの評価要請や調達要件への組み込みが進めば、実務上は「選んで使う地図」から「説明のために持っておく地図」へと性格が変わることもあります。だからこそ、自社のリスク許容度と外部要件を混同せず、両者を照らし合わせて考える姿勢が必要になります。
規模を問わず、プロファイルの出発点は「何が守れていないか」ではなく「何を守る必要があるか」です。その答えは、組織の事業内容とリスク許容度が決めるものであって、規模が決めるものではありません。
結び
NISTサイバーセキュリティフレームワークの価値は、「何をすべきか」を教えることではなく、「何を決めるべきか」を問うことにあります。技術部門と経営者が同じ地図を使って話せるようになる——この「共通言語」としての機能が、CSFが10年以上にわたって世界中で参照され続けてきた理由の一つなのでしょう。
第1章で触れたとおり、日本企業にとっての「経営の地図」は、CSFだけではありません。経済産業省とIPAによる「サイバーセキュリティ経営ガイドライン」も、NIST CSFと重なる問題意識を持ちながら、日本企業の経営者に向けて整理された実務的な地図です。なぜ海外の枠組みとは別に、独自のガイドラインを設ける判断がされたのか——その経緯と、両者の役割の違いについては、別の記事で改めて取り上げたいと思います。
リスクを可視化し、「どこまでを許容するか」を経営として判断できる状態をつくること。CSFという一つの地図を、経営の言葉として手元に置けたなら、本稿の役割はそこまでです。その地図をどのように使い、どこから進むかは、それぞれの組織が自らの事業とリスクに照らして決めることになります。
粕谷英雄
サマーオーシャンコンサルティング
ソフトウェア開発、情報システム刷新、DX推進などの実務知見をもとに、デジタル化に関する意思決定を支援。デジタルを経営に活かすための視点や推進の考え方を整理して発信しています。
