【要点抽出】OMB M-22-09 米国政府のゼロトラスト・サイバーセキュリティ原則への移行
EO14028の第3条で命じられたゼロトラストアーキテクチャの採用に向けて、OMBやCISAからドキュメントが出ています。
今回はその中でもOMBのM-22-09を読みます。
M-22-09とは?
OMBが各省庁宛てに、大統領令を実現するための具体的な方針と、予算確保の見積指示を出す際に覚書(メモランダム)を出します。
覚書を意味する「M-」の後に、発行年度と連番が続きます。
コチラに覚書の一覧があり、毎年20個ずつくらい出ているようです。
M-22-09のタイトルは「Moving the U.S. Government Toward Zero Trust Cybersecurity Principles」 2024年度末までに各省庁にゼロトラストの実現を求める文書です。
ただし、本文書の中でも書かれている通り、この1つだけでゼロトラストの全てが書かれているわけではありません。
より詳しい理解のためには、巻末のAppendix Aに記載されているCISAやNIST、DoDの各ドキュメントもあわせて読んでねという位置づけになっています。
構成は?
全3章構成です。
1.OVERVIEW
2.EXECUTIVE SUMMARY
3.ACTIONS
本書のメインは3章で、この中で以下5つの柱に対する実施要件が定められています。本noteではこの5本柱に求められる内容をまとめます。
A. Identity
B. Devices
C. Networks
D. Applications and Workloads
E. Data
5本柱についての実施要件
A. Identity
この柱を一言でいえば「アイデンティティ管理の仕組みを組織全体で一元化して、フィッシング耐性のあるMFAを採用しろ!」です。
以下、3つのアクションが定められています。
組織全体で一元化されたアイデンティティ管理システムを採用
特に目新しいことではありませんが、アイデンティティ管理の仕組みは一本化することがセキュリティ強化に直結します。
また、その仕組みを人事や契約管理システムと連携させることで、例えば退職イベントに連動したIDの無効化などが実現できます。組織全体で「強力なMFA」の採用
ゼロトラストアーキテクチャですから1度認証したら終わり(=VPN等のネットワークレベルの認証)ではなく、アプリケーションに対する認証を求めています。
この認証に「フィッシング耐性のあるMFA」の採用を求めています。
フィッシング耐性のあるMFAは、機関の職員、請負業者、パートナーには必須。一般ユーザには「その選択肢を与えること」を求めています。
実現手法としてPIV(Personal Identity Verification。詳細はコチラ)を推奨しており、それが使えないならFIDO2やWebAuthnも認めています。
逆に、SMS等を用いたフィッシング耐性のないMFAは廃止を命じています。
このM-22-09の記載を受けて、NIST SP800-63BのAAL2のフィッシング耐性要件が第4版から「Not Required」→「Recommended」に変更されたことは過去のnote(コチラ)で記載した通りです。
その他、パスワードリセット等の回復プロセスは対面確認など攻撃者にとってコストがかかるものを求めたり、パスワードレスの多要素認証を推奨したり、パスワードを使う場合は特殊文字の使用やパスワードの定期変更ポリシーを1年廃止に廃止することを求めています。認可の際にID情報に加えてデバイス情報も考慮
認可制御において、従来のRBAC(役割ベースのアクセスコントロール)に加えてABAC(属性ベースのアクセスコントロール)の採用を求めています。
属性といってもアクセス時刻や場所など様々ありますが、本文書では「認証されたユーザのID情報とともに、少なくとも1つのデバイスレベルの信号を組み合わせるべき」と書いています。
B. Devices
この柱を一言でいえば「完璧にインベントリ管理して、EDRを入れまくれ!」です。
以下、2つのアクションが定められています。
CDMに参加して資産インベントリを作成
セキュリティ管理の最初の一歩である資産管理をしっかりやり遂げ、デバイス・ユーザ・システムを完全に把握してカタログ化することを求めています。
この実現方法として、CDMへの参加を求めています。
CDMについてはかぴさんがまとめられています。
2.EDRの導入
このM-22-09が出るより前に、EO14028の第7条を受けてOMBがM-22-01を出しています。この中で各省庁に対し、EDRの導入とCISAがそれを利用できるようにすることを求めています。
また、一部のシステムではEDRが導入できないものもあります。そうしたものについては、シンクライアント型のデバイスも最小権限の意味でゼロトラストの考え方に沿ってるからいいよねと書いています。
(米国ではシンクラ技術はあまり使われないと聞いたので、個人的には意外な記載でした)
C. Networks
この柱を一言でいえば「通信はとにかく暗号化しつつ、環境を細かく分割せよ!」です。
以下、4つのアクションが定められています。
DNS要求の暗号化
省庁のDNSリゾルバはDNS over HTTPS かDNS over TLS を採用すること、エンドポイント側もそれに対応することを求めています。
このためにCISAのプロアクティブDNSを活用することが義務付けられています。HTTPトラフィックの暗号化
インターネットごしの通信だけでなく、内部トラフィックも含めてHTTPSとすることを求めています。
CISAのDotGovプログラムを通して、HSTSプリロードリストにドメインを登録し、ブラウザからの初回アクセスからHTTPSを強制することを目指しています。
ただし、Webサイト側がHTTPSに対応していないままHSTSプリロードリストに登録してしまうとアクセスできなくなってしまうことから、とっとと暗号化した上でリストに登録するようにヨロシク的なことが書かれています。電子メールの暗号化(の検討)
メールの暗号化は難しいのでCISAのほうでやり方を考えてOMBに提言するよう求めています。環境分離を前提としたゼロトラストアーキテクチャプラン作り
内部に侵入した攻撃者が横移動しづらくなるよう環境を分離することを求めています。「マイクロセグメンテーション」というキーワードは出ないものの、恐らくそれをイメージした内容かと思います。
この実現方法として、仮想化技術により環境が分離され、IDや属性ベースのアクセス制御を行えるクラウドのインフラをうまく使ってねと書いています。
具体的な進め方をゼロトラスト・アーキテクチャ・ロードマップとしてまとめることを各省庁に求めています。
D. Applications and Workloads
この柱を一言でいえば「非公開システムだから安全とか甘えたこと言ってないで、胸張ってインターネットに公開できるくらいしっかりアプリケーションを作れ!」です。
以下、6つのアクションが定められています。
自動と手動でのアプリケーション診断の定期実施
ツールによる脆弱性スキャンやソフトウェアのコード解析に加え、専門家による手動の診断を行うことを求めています。外部ベンダによる診断の実施
タイトルの通りですが、外部診断のネックである調達時間の短縮のために、すぐに診断ベンダを手配できる仕組みを作ることをCISAとGSAに求めています。外部からの脆弱性の指摘を受け付ける環境作り
OMB M-20-32やCISA BOD 20-01に沿って、政府のシステムの脆弱性を発見した外部者からの報告先の整備などを求めています。一部のアプリケーションのインターネット公開化
アプリケーションへアクセスする際にVPNなどの閉域網に頼らず、インターネットごしにアクセスできるようにすることを求めています。要は閉域網神話からのマインドチェンジです。
本書では、閉域網の脱却のために、まずは各省庁が持つModerateレベル(※)のシステムを1つ、1年以内にインターネット公開せよと言っています。
あわせて、そのシステムを攻撃から保護するために、監視の仕組みやDDoS対策やアクセス制御ポリシーの導入を求めています。
※米国にはFISMAという情報セキュリティに関する法律があり、そこでシステムの重要度に応じてLow,Moderate,Highの3レベルに分類することが決められています。LowではなくModerateというところに「ショボいシステムだけインターネット公開してお茶を濁すのはダメ」という意図を感じます。インターネット公開システムの一覧整備
いわゆるアタックサーフェスマネジメントと同じで、インターネットからアクセスできるシステムをしっかり把握することを求めています。
その際に、インターネットごしの外部スキャンを活用することや、インターネットごしにアクセス可能な「.gov以外のホスト名」を各省庁がCISAとGSAに提出することを求めています。
(.govのリストは元々CISAとGSAが管理しているので、それ以外も知りたいという意味)immutable(不変)な仕組みの採用
サーバを作った後にゴチャゴチャ手を加えるから攻撃や脆弱性が入り込むのであり、一回作った環境は使い捨てるという(コンテナで使われるような)immutableの考え方を取り入れることで、最小権限のアーキテクチャが実現できると考えています。
そのために、コードベースでのインフラ管理(IaC)やCI/CDによる自動化などの最新のソフトウエア開発ライフサイクルを取り入れることを求めています。
また、オンプレ環境からクラウドへ移行する際に、CISAによるCloud Security TRA(テクニカルリファレンスアーキテクチャ)を使用せよと言っています。
E. Data
この柱を一言でいえば「データをしっかり分類してセキュリティ対策に役立てよ!」です。
以下、4つのアクションが定められています。
ゼロトラストデータセキュリティガイドの作成
従来から求められていたデータセットのインベントリ管理に加え、メールなどの分散したデータや中間ファイルについても管理することを求めています。
その指針作りとして、OMB主導で共同WGを立ち上げ、データセキュリティガイドを作ると述べています。インシデント対応の自動化
SOARなどを使ってセキュリティの監視と対応を自動化することが必要、と書きだしており、そのために、組織が扱うデータの種類や、誰がアクセスするのかといった情報を集めた上でヒューリスティックな手法で異常検出することを求めています。
具体的な取り組み方として、専門性が高い機械学習モデルではなくスクリプトや正規表現などの単純なアプローチから入ることや、まずはレポートモードで試行して監視結果をチューニングし、偽陰性・疑陽性の改善に努めることを求めています。クラウド上の暗号化した保存データへのアクセス監査
クラウド上のデータを守るために、以下を求めています。
・データへのアクセスや復号化のログを取り、監視する
・上記のログは別のシステムに記録する
・鍵管理や復号化操作をクラウドのインフラに頼るログの管理と活用
OMB M-21-31で定めたログ管理や活用の成熟度モデル(EL0~EL3)のうち、まずは基本レベルであるEL1に到達することを求めています。
例えば以下のような内容を優先する必要があります。
・ログへのアクセス制限
・ログの完全性を確認する仕組み作り
・DNSリクエストの記録
まとめは以上です。
2024年度末と短い期限の中で、この覚書だけでなく次々に出るドキュメントを読んで推進する各省庁の担当者は大変だろうと思います。
また、(OMBが取りまとめているだけあって)ここに書かれている1つ1つが莫大なコストがかかるはずで、それでもなおトップダウンでやると宣言する米国の力強さを感じました。
***はじめての方へ***
これは何のnoteだ?と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら
この記事が気に入ったらサポートをしてみませんか?