防衛装備庁が参考にしたことで注目高まる「NIST SP800-171」　企業が倣う際に着目すべき要点

「NIST SP800-171」が注目される3つの要因

　NIST（米国国立標準技術研究所）が発行するセキュリティガイドラインの1つ、「NIST SP800-171」がサプライチェーンのセキュリティでも注目されている。背景には大きく3つの要因があるという。

　第一に、サプライチェーンへの攻撃が増加していること、攻撃内容が多様化していることがある。ニュートン・コンサルティング 執行役員 兼 CISO プリンシパルコンサルタントの内海良氏は、最近の攻撃パターンとして「物理被害サプライチェーン攻撃」「ソフトウェアサプライチェーン攻撃」「アイランドホップ攻撃（クラウド・MSP）」「アイランドホップ攻撃（その他）」の4つを挙げた。

　第二が、経済安全保障推進の機運が高まっていることだ。これまでは国土防衛の観点から語られることが多かった安全保障の考え方が、経済分野にまで拡がっている。特に、最近の米中関係の緊張は高まるばかりだ。経済のグローバル化の恩恵を受けられた時代は過去のものとなり、今後は友好国同士が構成する経済圏内での活動を前提に、サプライチェーンネットワークを見直さざるを得ない。

　第三に、調達基準が強化された要因も大きい。まず、2022年4月に防衛装備庁が発表した「防衛産業サイバーセキュリティ基準」が2023年5月から適用開始になった。この調達基準は、SP800-171を参考に内容の見直しがあり、旧基準にはなかった「検知」「対応」「復旧」の項目追加で、新基準はより厳格なものになった。もう一つ、内閣サイバーセキュリティセンター（NISC）が定めた「政府機関等のサイバーセキュリティ対策のための統一基準群（以降、政府統一基準）」整備の背景にも、サプライチェーンへのサイバー攻撃リスクの増大が関係している。この政府統一基準では、NISTのサプライチェーンリスク管理要件を参考にした、情報セキュリティ対策を委託先との契約に含めるとともに、委託期間を通じた実行を求めている。「SP800-171とサプライチェーンへのサイバーセキュリティ対策は密接に関わっている」と内海氏は評した。

　日本の各種ガイドライン策定のプロセスが、米国政府の動向に追随するとするならば、「今後はSP800-171が日本で認証制度化される可能性がある」と内海氏は予測する。その前例になるのが、米FedRAMP（Federal Risk and Authorization Management Program）制度を基に、制度化されたISMAP（Information system Security Management and Assessment Program）である。米国ではクラウドサービス事業者はFedRAMP認証を取得していなければ、政府および関連事業者との取引はできない。同様に、政府との取引を視野に入れ、日本のクラウド事業者がISMAP認証制度を取得する傾向も顕著になってきた。SP800-171を参照しているCMMC（Cybersecurity Maturity Model Certification）認定制度の日本版を検討する動きも出てきた。今後の対策強化に向けては、早めにガイドラインの内容を理解しておきたいところだ。

CSFとの大きな違いは？

　SP800-171は、2015年6月に最初に公開された「Rev 1.0」から始まり、2020年2月に「Rev 2.0」の改訂を経て、2024年初頭には「Rev 3.0」の公開が予定されている。また、セキュリティ対策基準の「NIST サイバーセキュリティフレームワーク 2.0（以下、CSF 2.0）」が2024年2月に公開されたばかりでもある。同フレームワークの1.0は2014年4月、1.1が2018年4月に出たことを踏まえると、久しぶりの大きな改訂になる。内海氏が示した大きな変更点は、「1. フレームワーク対象の拡大」「2. ガバナンス機能の追加」「3. カテゴリー・サブカテゴリーの整理」「4. サプライチェーンリスクマネジメントの強化」「5. ガイダンスの強化」「6. 参考資料の追加」であった。

　また、以前は「識別」「防御」「検知」「対応」「復旧」の大きく5つだった機能に、CSF 2.0ではこの5つを包括する「ガバナンス」機能が追加になった。ガバナンス機能は、組織がサイバーセキュリティ戦略を支援する内部決定をどう行うかについての指針を示すものだ。さらに、以前は識別機能にあった「サプライチェーンリスク管理」は、ガバナンス機能に移行し、多くの対策項目が追加になった。NISTの方向性として、サプライチェーンリスク管理対策の重要度が高まっていることが、CSF 2.0の変更内容からも読み取れる。

　では、SP800-171とCSFは何が違うのか。内海氏は明確な違いとして「守るべき対象の定義」を挙げ、CUI（Controlled Unclassified Information：機密以外の重要情報）の扱い方を指摘。SP800-171がCUIを保護するためのセキュリティガイドラインであるのに対し、CUIよりも重要性の高いCI（Classified Information）を保護するセキュリティガイドラインにはNIST SP800-53がある。内海氏は「SP800-171を参照する場合、保護するべき情報を規定した上で、サプライチェーン全体で共通のセキュリティ対策を実施しなくてはならない」と訴えた。

　たとえば、米国連邦政府から直接仕事を請け負う場合、事業者だけで仕事を完結させるとは限らない。その場合、政府からの仕事を受注した事業者（Tier1）が、SP800-171の要件を満たしたCUIの保護を講じるだけでなく、下請事業者（Tier2）、孫請事業者（Tier3）、その先の委託事業者（Tier4）を含むすべての事業者にSP800-171の要件を満たした保護対策が求められる。「サプライチェーン全体で一定のセキュリティレベルを保ち、CUIを保護するのがSP800-171の根本的な考え方になる。そのための110項目が指定されている」と内海氏は説明した。

CUIを見極めるためのポイントを伝授

　SP800-171の110項目とはどのような内容か。Rev 2.0では、戦略レベルと技術的な対策をバランスよく14の分類、110の項目として整理している。内海氏は独自で「組織・スキル」「ルール・プロセス」「テクノロジー」「物理セキュリティ」の4つに分類している例を紹介した。

　SP800-171の詳細を読み込むと、細かい要件の記述が多く、全部に対応しなければならないのかと考えるかもしれない。実際、米国政府と取引をしている日本企業はさほど多くないはずだ。しかし、取引している場合は、SP800-171が指定するCUI、もしくは防衛産業における保護すべき情報が指定されているかの確認は必須となる。そうでなくても、SP800-171は、CUIを扱う日本の一般企業にとって、実は参考にできる点が多い。今は米国政府との取引がなくても、今後のビジネスで海外進出を視野に入れている場合もあるだろう。将来に備えた対応を検討するときに役立つはずだ。ニュートン・コンサルティングではSP800-171への準拠に向けたセキュリティ構築支援や監査支援を行っているほか、2024年1月には自社においても「NIST SP800-171」に準拠したことを公表した。

　対応すると決めた場合にやるべきことは、CUIの見極めだ。内海氏が勧めたのは「CUI Registry」を参照すること。CUI Registryとは、米NARA（国立公文書記録管理局）が「重要インフラ」「防衛」「輸出管理」を始めとする20のグループごとにCUIカテゴリーを整理したもので、保護すべきCUIの例も提示されている。代表的なものには、「情報システムの脆弱性情報」「個人識別情報（PII）」「研究・技術データ」「技術図面」などがある。今後に備えた準備を進める場合は、自社で勝手にCUIを定義するのではなく、CUI Registryを参考に自社の情報資産を精査することが望ましい。

　その後の対策の勘所として内海氏が挙げたのが、「システム境界と認証・認可」「暗号化」の2点になる。まず、システム境界の設置では、外部公開システム用にDMZ（DeMilitarized Zone）環境を作ること、および社内システム用には、オフィス環境、サーバー環境、セキュア環境の用に、セグメントを分けての監視、管理をSP800-171では要求している。また、SP800-171準拠対象システムへのアクセスでは、ID／パスワード方式ではなく、多要素認証方式が必須となる。もう1つの暗号化では、インターネット空間を使う通信では暗号化が必須となるが、データセンター内の通信やデータセンター間の通信での暗号化は任意となる。暗号化通信では、FIPS（連邦情報処理規格）に準拠した暗号モジュールあるいは暗号アルゴリズムの利用が必須となる点も注意しておきたいところだ。利用中の技術がFIPS準拠か否かは、CMVP（Cryptographic Module Validation Program）あるいはCAVP（Cryptographic Algorithm Validation Program）のサイトから確認できると、内海氏は紹介した。

公開目前のSP800-171 Rev 3.0の動向を分析

　ここまでの説明にあったSP800-171は、すべてRev 2.0の内容を前提としている。最後に内海氏は、まもなく公開となるSP800-171 Rev 3.0（2024年初頭予定）の動向について触れた。まだ正式版は公開されていないものの、2023年11月に出たFPD（Final Public Draft）版によれば、従来の14ファミリーに、「計画」「システムとサービスの調達」「サプライチェーンリスクマネジメント」の3つのファミリーが追加されることがわかっている。追加ファミリーがこれから強化するべき領域を指しているとすれば、これまで以上にサプライチェーンリスクへの対策に力を入れる必要が出てきそうだ。

　また、Rev 2.0からRev 3.0で要件項目数がどうなるかも気になるところだ。これは110項目から95項目に減るとわかっているという。ただし、よく読むと、以前は1つの要件項目に1つの管理項目だったものが、1つの要件項目に複数の管理項目が対応する改訂になっている。管理項目数は全部で266個にもなり、以前と比べて必要な対策は142％増しになってしまう。正式版が出てきた時に確認しなくてはならないが、新しい対策を講じるための負担は増加すると内海氏はみている。

　一方、負担が軽減する可能性が見えてきたのが暗号化である。該当する要件の記述からFIPS暗号化の指定がなくなっており、内海氏は「クライアントをサポートするプロジェクトでは、FIPS準拠かどうかを確認する作業の負荷が大きい。たとえば、組織内のセキュリティポリシーで暗号化のガイドラインを定め、それに準拠すればいいのであれば助かる」と見解を述べた。取引先を含めたサプライチェーン全体のセキュリティ対策が必要になるほど、SP800-171の重要性は高まる。正式版の公開が待たれる。