概要
委託先から情報が漏れても、発注元の責任は免れません。
サプライチェーンを情報セキュリティリスクか如何にまもるか。
NIST SP800-171について調査したので皆さんに共有いたします。
問題意識
- F-35の開発関連企業においてサイバー攻撃
- 盗まれた情報は「機密情報」では無かったが、重要なデータであった
- F-35に関する30GB分のデータ
- 他に対潜哨戒機に関する情報も摂取
- 盗まれた企業は再々委託先の中小企業
- システム管理者1人だけ
- admin/guestなど、脆弱なID/PASSを使用していた
- 盗まれた情報は「機密情報」では無かったが、重要なデータであった
機密情報でなくとも重要な情報はある。
規模の大小を問わず、情報漏洩した際のダメージは全体に及ぶ
→サプライチェーン全体で情報セキュリティに取り組む必要性
[1]防衛装備庁における情報セキュリティ基準の改正に係る取組
米国の取り組み
取り扱うデータをCI/CUIにわける
- CI (Classified Information)
- 政府の機密情報
- CUI (Controlled Unclassified Information)
- 一般情報(機密情報以外)ではあるが、重要な情報
取扱データによって遵守する規格が以下のように変わる
| 取扱データ | NIST | 英語名 | 日本語名 |
|:—————:|:————:|:——-—:|:———:|
| CI | NIST SP800-53 rev.4 | Recommended Security Controls for Federal Information Systems | 連邦政府情報システムおよび連邦組織のためのセキュリティ管理策とプライバシー管理策 |
| CUI | NIST SP800-171 rev.1 | Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations | 連邦政府外のシステムと組織における管理された非格付け情報の保護 |
CUI取扱の委託先が守るべきは SP800-171となる。
CUIを「処理、格納、通信」する民間企業のシステムはSP800-171による保護を最低限の対策と定め、CUIの保全を求めている(32連邦規則(CFR)2002.14)
NIST SPの文章構造
図は [2]NIST SP800-171はサイバー時代の黒船か? より抜粋
NIST CSF (Cyber Security Framework)は上位規定になります。
NIST SP800-53はCSFの方針を受け、策定されています。
NIST SP800-171はSP800-53から抜粋する形で構成されています。
重要なこととして、ISO27001など従来規格は特定と防御と、侵入されないことに重点がありましたが、CSFは、侵入後についても考慮がなされています。
[3]NRI NIST サイバーセキュリティフレームワークの実践的な使い方 がわかりやすいです。
要するに、軍事の世界でいう「ダメコン」ですね。
実際の規格書はIPAが和訳を置いていてくれています。
[4]セキュリティ関連NIST文書
NIST SP800-171
サプライチェーンの情報セキュリティを守るという目的のSP800-171ですが、これを守るのは委託先でしょうか?発注元でしょうか?
委託先です。委託先が主体的にSP800-171に遵守するようにします。
発注元は委託先が本当にSP800-171に遵守したかを確認します。かくにんの仕方は次項で触れます。
SP800-171は技術要件と非技術要件に大別されます。
技術要件(77項目)
- 3.1 アクセス制御
- CUI(重要データ)へのアクセス制御のこと
- 3.4 構成設定管理
- secure configurationなどのこと
- 3.5 識別と認証
- 認証周りです
- 3.7 メンテナンス
- 3.10 物理的保護
- 3.13 システムと通信の保護
- 通信部分の保護
- 3.14 システムと情報の完全性
- PCなどのシステムを如何に守るか
非技術要件(33項目)
- 3.2 意識と訓練
- 3.3 監査と責任追跡性
- 3.6 インシデントレスポンス
- 3.8 メディア保護
- 3.9 人的セキュリティ
- 3.11 リスクアセスメント
- 3.12 セキュリティアセスメント
実際にSP800-171を読んでみるのが良いです。
[4]セキュリティ関連NIST文書
結局、「これ、どういった意図なの?どういう意味なの?」と解読していくしかないですね。。
準拠の難しさ
現実、米国の防衛産業において対応はスムーズに進んでいるとは言い難いそうです。
準拠したというので監査してみたら適切な対応がなされていなかったそうです。
原因は「NIST SP800-171に準拠するとは具体的にどのような要求を満たすことなのか」への理解不足にあったようです。
[5]デロイト 国際協調のスタートラインとしてのサイバーセキュリティ より
実際に規格を読むと、さもありなん。。という印象を受けるかと思います。
クラウドの活用
個別の企業がそれぞれ単独でセキュリティ対策を取るのは非常に大変。
発注する側についても各社各様の対策の取り方についてすべて準拠性の評価を行うのは限界がある。
ということで認定を受けたセキュアなクラウドの使用が推奨されているそうです。
[5]デロイト 国際協調のスタートラインとしてのサイバーセキュリティ より
クラウド内で処理が完結できれば、オンプレ側はそこまでセキュリティを求めなくてもいいですもんね。
もちろん、クラウドから重要データをダウンロードしちゃえる仕様だと、ダメでしょうが。
このクラウド使用の選択肢を与えているのが FedRAMP: Federal Risk and Authorization Management Program です。
委託先の準拠をどのように判断するか
- まず自らの会社(つまり委託先)でSP800-171への対応が完了と認識
- 完了したことを客観的に評価する
- 自己評価 or 第三者評価
では委託先が本当に準拠したことを、発注元がどのように確認するのでしょうか?
米国国防総省は、防衛産業がSP800-171への対応を行ったか否かについて、監査や認証のような主体的確認を行わないそうです。
各企業の自己宣言を受理することによって、代替しているとのこと。
情報漏洩が発生したら事実調査の一環で委託先会社に行きつき、SP800-171への準拠度を確認、不備があれば訴追。だそうです。
[5]デロイト 国際協調のスタートラインとしてのサイバーセキュリティ より
委託先の情報セキュリティの監査は頭の痛い問題ですが、米国国防総省の取り組みの仕方は、楽ですね。。
監査したからといって本当に委託先の状況が分かるかと言えば、正直わからないと思います。
それならいざコトが起こったら訴追するぞと脅せば、委託先も主体的に取り組まざるを得ない。ということを狙っているのでしょう。
主体的に取り組まないと、なにごともうまくいかないですもんね。。
NIST SP800-171準拠に強制力を持たせる
最後に、サプライチェーン全体を守るためにNIST SP800-171準拠というのはわかりました。では発注元に対して、委託先にSP800-171準拠を強制させること自体を強制させる仕組みについて解説します。
発注元が準拠を求めないなら絵に描いた餅ですからね。
- まず大統領令でCUI情報の定義を行うよう各省庁に対し命令。
- 定義したCUI情報は国立公文書記録管理局(NARA)が管理するCUIレジストリに登録しなければならない。
- CUIレジストリに登録されたCUI情報についてはNIST SP800-171準拠しなければならない
- 民の方でCUI保護措置が取られていないことがわかると、所管省庁自身がNARAによって訴追される★
★の部分がポイントです。これなら強制力がありますね。。
[5]デロイト 国際協調のスタートラインとしてのサイバーセキュリティより
参考
[1]防衛装備庁における情報セキュリティ基準の改正に係る取組