米国他 ロシア軍のサイバー工作員が米国およびグローバルな重要インフラを標的にしているので注意してください...

こんにちは、丸山満彦です。

米国の財務省、国務省、サイバーコマンド他、オランダ、チェコ、ドイツ、エストニア、ラトビア、ウクライナ、カナダ、オーストラリア、英国が共同で、警告をだしていますね...

ロシアのGRUユニット29155 サイバー・コンポーネントが攻撃者のようです...

● CISA

・2024.09.05 Russian Military Cyber Actors Target US and Global Critical Infrastructure

Russian Military Cyber Actors Target US and Global Critical Infrastructure	ロシア軍のサイバー工作員が米国およびグローバルな重要インフラを標的に
Summary	要約
The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), and National Security Agency (NSA) assess that cyber actors affiliated with the Russian General Staff Main Intelligence Directorate (GRU) 161st Specialist Training Center (Unit 29155) are responsible for computer network operations against global targets for the purposes of espionage, sabotage, and reputational harm since at least 2020. GRU Unit 29155 cyber actors began deploying the destructive WhisperGate malware against multiple Ukrainian victim organizations as early as January 13, 2022. These cyber actors are separate from other known and more established GRU-affiliated cyber groups, such as Unit 26165 and Unit 74455.	連邦捜査局(FBI)、サイバーセキュリティ・インフラセキュリティ庁(CISA)、国家安全保障局(NSA)は、2020年以降、ロシア連邦軍参謀本部情報総局(GRU)第161特殊訓練センター(Unit 29155)に所属するサイバーアクターが、スパイ行為、妨害行為、風評被害を目的とした世界的な標的に対するコンピューターネットワーク操作の責任者であるとアセスメントしている。GRU Unit 29155のサイバー犯罪者は、2022年1月13日には早くも、複数のウクライナの被害組織に対して破壊的なWhisperGateマルウェアの展開を開始していた。これらのサイバー犯罪者は、Unit 26165やUnit 74455といった、より確立されたGRU関連のサイバーグループとは別物である。
・To mitigate this malicious cyber activity, organizations should take the following actions today:	・この悪意あるサイバー活動を低減するために、組織は今日から以下の対策を講じるべきである。
・Prioritize routine system updates and remediate known exploited vulnerabilities.	・定期的なシステム更新を優先し、既知の脆弱性を修正する。
・Segment networks to prevent the spread of malicious activity.	・悪意ある活動の拡大を防ぐためにネットワークをセグメント化する。
Enable phishing-resistant multifactor authentication (MFA) for all externally facing account services, especially for webmail, virtual private networks (VPNs), and accounts that access critical systems.	フィッシング対策の多要素認証(MFA)を、外部に公開されているすべてのアカウントサービス、特にウェブメール、VPN(仮想プライベートネットワーク)、および重要なシステムにアクセスするアカウントに対して有効にする。
This Cybersecurity Advisory provides tactics, techniques, and procedures (TTPs) associated with Unit 29155 cyber actors—both during and succeeding their deployment of WhisperGate against Ukraine—as well as further analysis (see Appendix A) of the WhisperGate malware initially published in the joint advisory, Destructive Malware Targeting Organizations in Ukraine, published February 26, 2022.	このサイバーセキュリティ勧告では、Unit 29155のサイバー犯罪者に関連する戦術、技術、手順(TTP)を、ウクライナに対するWhisperGateの展開中および展開後に提供するとともに、2022年2月26日に発表された共同勧告「ウクライナの組織を標的とする破壊的マルウェア」で最初に公開されたWhisperGateマルウェアのさらなる分析(附属書Aを参照)も提供する。
FBI, CISA, NSA and the following partners are releasing this joint advisory as a collective assessment of Unit 29155 cyber operations since 2020:	FBI、CISA、NSA、および以下のパートナーは、2020年以降のUnit 29155サイバー作戦の総合的なアセスメントとして、本共同声明を発表する。
・U.S. Department of the Treasury	・米国財務省
・U.S. Department of State (Rewards for Justice)	・米国国務省(正義への報い）
・U.S. Cyber Command Cyber National Mission Force (CNMF)	・米国サイバーコマンド サイバー国家任務部隊(CNMF
・Netherlands Defence Intelligence and Security Service (MIVD)	・オランダ国防情報局(MIVD
・Czech Military Intelligence (VZ)	・チェコ軍情報局(VZ)
・Czech Republic Security Information Service (BIS)	・チェコ共和国安全保障情報局(BIS)
・German Federal Office for the Protection of the Constitution (BfV)	・ドイツ連邦憲法擁護庁(BfV)
・Estonian Internal Security Service (KAPO)	・エストニア国内治安局(KAPO)
・Latvian State Security Service (VDD)	・ラトビア国家保安庁(VDD)
・Security Service of Ukraine (SBU)	・ウクライナ保安庁(SBU)
・Computer Emergency Response Team of Ukraine (CERT-UA)	・ウクライナコンピューター緊急対応チーム(CERT-UA)
・Canadian Security Intelligence Service (CSIS)	・カナダ安全保障情報局(CSIS)
・Communications Security Establishment Canada (CSE)	・カナダ通信安全保障局(CSE)
・Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)	・オーストラリア信号局オーストラリアサイバーセキュリティセンター(ASDのACSC)
・United Kingdom National Cyber Security Centre (NCSC-UK)	・英国国立サイバーセキュリティセンター(NCSC-UK)
For additional information on Russian state-sponsored malicious cyber activity and related indictments, see the recent U.S. Department of Justice (DOJ) press releases for June 26, 2024, and September 5, 2024, FBI’s Cyber Crime webpage, and CISA’s Russia Cyber Threat Overview and Advisories webpage.	ロシア政府による悪意のあるサイバー活動および関連する起訴に関する追加情報は、米国司法省(DOJ)の2024年6月26日および9月5日付のプレスリリース、FBIのサイバー犯罪ウェブページ、およびCISAのロシアのサイバー脅威の概要および勧告ウェブページを参照のこと。

・[PDF] 

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2024.08.29 OXFORD JOURNAL of Cybersecurity 戦争においてサイバー作戦の有用性は限界的

・2024.08.09 米国 国防大学出版局 統合軍クオータリー　「認知戦」

・2024.06.25 Microsoft ロシアはいかにして2024年パリ五輪を妨害しようとしているのか (2024.06.06)

・2024.06.20 米国 サイバーセキュリティ・インフラセキュリティ庁（CISA）と米国選挙支援委員会（EAC）が選挙セキュリティについてのガイドを発表 (2024.06.17)

・2024.05.06 米国 英国 カナダ 親ロシア派ハクティビストによる北米および欧州のOT機器に対する継続的な悪意あるサイバー活動に対するセキュリティ対策

・2024.04.03 マイクロソフトロシアの国家支援行為者であるMidnight Blizzardによるシステムへの侵入に対するSECの開示事例 (2024.01.19, 2024.03.08)

・2024.03.01 米国 英国 オーストラリア カナダ ニュージーランド、ベルギー、ブラジル、フランス、ドイツ、ラトビア、リトアニア、ノルウェー、ポーランド、韓国がロシアや脆弱性についてのいくつかのアラートを出していますね。。。

・2024.02.29 Five eyes ロシア対外情報庁による攻撃手法。時代はクラウドですからね...

・2023.09.25 ロシア 科学技術センター デジタル外交2023：課題と発展動向

・2023.09.01 Five Eyes Android 端末を標的とするInfamous Chisel マルウェアを利用するロシアの脅威行為者に関する報告書

・2023.08.19 ロシア 科学技術センター ：新たなサイバーセキュリティの脅威

・2023.08.11 ロシア 情報セキュリティセンターの設立に約33億ルーブル（約50億円）の予算をつける

・2023.05.20 米国 司法省 LockBit、Babuk、Hiveに関わったロシア人を起訴

・2023.05.17 米国 CISA ブログ コロニアルパイプラインへの攻撃：この2年間で私たちが学んだこと、私たちがやってきたこと (2023.05.07)

・2023.05.12 Five Eyes ロシア連邦保安庁が管理するマルウェアネットワーク「Snake」を破壊

・2023.05.10 ロシア 科学技術センター 大規模言語モデル：認知的な視点

・2023.03.07 ロシア 科学技術センター 認知作戦・心理作戦の理論的・概念的側面

・2023.02.11 米国 英国 ロシアを拠点とするサイバー犯罪組織「Trickbot」のメンバーに制裁を科す

・2022.07.21 カナダ サイバーセキュリティセンター 「サイバー脅威報告：ロシアのウクライナ侵攻に関連するサイバー脅威活動」 (2022.07.14)

・2022.07.18 ロシア 通信・IT・マスメディア監督連邦サービス (Roskomnadzor) が、Google、Apple、Pinterest等の外資企業が、ロシア人利用者のデータベースのローカ保管を確認していないと発表していますね。。。

・2022.06.21 米国 司法省 国際的なサイバー作戦によるロシアのボットネットの破壊

・2022.04.11 米国 司法省 ロシア連邦軍参謀本部情報総局（GRU）が管理するボットネットを裁判所の認可に基づき破壊(2022.04.06)

・2022.04.01 ロシア 外務省 米国とその衛星国による継続的なロシアへのサイバー攻撃についての声明

・2022.03.30 ロシア・ウクライナ紛争に伴うサイバーセキュリティの警告（オーストラリア、英国の場合）

・2022.03.18 米国 CISA FBIがロシアの国家的サイバーアクターによるデフォルトの多要素認証プロトコルと「printnightmare」脆弱性の悪用による脅威の軽減

・2022.03.05 フランス CERT-FRがロシアのウクライナ侵攻に関連した脅威・インシデントレポートを公表していますね。。。

・2022.03.03 米国 司法省 タスクフォース KleptoCapture （ロシアの資金源を断つ？）

・2022.02.22 米国 CISA Alert (AA22-047A) ロシアの国家支援を受けたサイバーアクターが、機密性の高い米国の防衛情報および技術を入手するために、許可を受けた防衛請負業者のネットワークを標的にしている (2022.02.16)

・2022.02.11 防衛省 防衛研究所 ウクライナをめぐるロシアの強要戦術

・2022.02.11 欧州議会 Think Tank 米国とロシアの関係：地政学的側面、安全保障的側面、経済的側面、人的側面

・2022.01.18 ウクライナ ロシアからと考えられるサイバー攻撃の影響はほぼ回復した？

・2022.01.17 米国 GAO サイバーセキュリティ：SolarWindsおよびMicrosoft Exchangeのインシデントに対する連邦政府の対応

・2022.01.16 金銭目的のサイバー攻撃については全ての国が協力できる（コロニアルパイプラインを攻撃した疑いのあるハッカーを米国の要請によりロシアが逮捕）

・2021.12.15 ロシアとインドネシアが国際的な情報セキュリティの協力に関する政府間協定に署名

・2021.12.08 ロシア ドミトリー・チェルニーシェンコ副首相による第16回国連インターネット・ガバナンス・フォーラムでの国際的な法律の調和とIT分野での協力についての講演

・2021.12.07 2021.12.09,10開催予定　Summit for Democracy　民主主義サミット + 中国的民主主義 + ロシアの批判 + EUの参加報告書＋米国政府まとめ

・2021.11.24 ロシア ロシア国内に事務所を開設しなければならないインターネット企業13社を公表

・2021.11.13 米国 財務省 政府一体となったランサムウェア対策によりランサムウェア実行者と仮想通貨取引所に制裁を科す

・2021.11.12 Interpol 最近のサイバー関係の発表（７つ）

・2021.08.05 米国連邦議会上院 国土安全保障・政府問題委員会 「アメリカのデータは危険にさらされている」

・2021.07.13 RuNetの再評価：ロシアのインターネット孤立化とロシアのサイバー行動への影響

・2021.07.12 NATO関連機関が分析したサイバー空間におけるロシアの戦略 at 2021.06.11

・2021.07.04 ロシア連邦大統領令第400号「ロシア連邦の国家安全保障戦略」を公表

・2021.04.22 U.S. White House 副国家安全保障補佐官（サイバー・新技術担当）によるSolarWindsとMicrosoft Exchangeのインシデントに関する声明

・2021.04.22 米国によるロシア制裁後のロシア連邦安全保障会議書記と米国大統領補佐官（国家安全保障担当）との電話会談

・2021.04.16 White HouseはSolarWindsの不正アクセスに関連する行動がロシアによるものと正式に認め制裁を課す大統領令を発出していますね。。。 U.S. サイバー司令部と国土安全保障省-CISAはSolarWindsの不正アクセスに関連するロシア製マルウェアのサンプルを公開

・2020.11.16 ロシアと北朝鮮のハッカーがCOVID 19のワク​​チン研究者からデータを盗もうとしている by Microsoft

・2020.10.27 欧州連合 連合と加盟国を脅かすサイバー攻撃に対する制限的措置に関する決定（CFSP）2019/797の修正（ロシアの件。。。）

・2020.10.27 米国 連邦司法省がサイバースペースでの破壊的行為を世界的に行ったことでロシアのGRUの6人を起訴した (2020.10.19)

・2020.10.27 英国NCSC 東京オリンピック関係者にサイバー攻撃をしていたとしてロシアを非難 (2020.10.19)

・2020.10.14 ノルウェー政府は8月のノルウェー議会の電子メールシステムへのサイバー攻撃はロシアによるものだとする声明を出していますね。。。

・2020.08.22 米国上院の情報委員会が2016年大統領選におけるロシアの影響を調べた報告書（第５巻）を公開していますね。。。

・2020.07.17 英国政府はロシアが2019年の総選挙に違法に取得した政府文書を通じて妨害しようとしたと結論付けた

・2020.06.03 米国 国家安全保障局 (NSA) がEximの脆弱性を悪用するロシアのAPTグループ「Sandworm」に関する警告を公表

・2020.03.26 FBI - FBI Takes Down a Russian-Based Hacker Platform; Arrests Suspected Russian Site Administrator

・2020.04.08 削除できないマルウェア xHelper の仕組みがわかった？

・2020.01.25 通信関連会社元社員 機密情報不正取得で逮捕 ロシアに提供か」

経済産業省 IoT製品に対するセキュリティ適合性評価制度構築方針 (2024.08.23)

こんにちは、丸山満彦です。

経済産業省の産業サイバーセキュリティ研究会の ワーキンググループ3（IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会）が、「IoT製品に対するセキュリティ適合性評価制度構築方針」を公表していますね...

今年の3月15日からの意見募集を踏まえて最終確定していますね...

● 経済産業省 - 産業サイバーセキュリティ研究会 - ワーキンググループ3（IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会）

・2024.08.23 IoT製品に対するセキュリティ適合性評価制度構築方針

・・[PDF] IoT製品に対するセキュリティ適合性評価制度構築方針（本編）

・・[PDF] 別添 ☆1セキュリティ要件・適合基準

（3月15日から変更なし...）

・・[PDF] IoT製品に対するセキュリティ適合性評価制度構築方針（概要説明資料）

意見募集

・[web] IoT製品に対するセキュリティ適合性評価制度構築方針案に対する意見公募（募集期間：2024年3月15日～４月15日）の結果

過去分...

・202403.27 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会最終とりまとめ

・・[PDF] 産業サイバーセキュリティ研究会 ワーキンググループ3 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会 最終とりまとめ

・・[PDF] 別添1　セキュリティ要件一覧

・・[PDF] 別添2　☆1セキュリティ要件・適合基準

・・[PDF] IoT製品のセキュリティ適合性評価制度 ☆1チェックリスト（案）

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2024.08.02 米国 FCC IoTのためのサイバーセキュリティ・ラベリング最終規則

・2024.03.20 米国 連邦通信委員会 (FCC) がIoTサイバーセキュリティ表示プログラム（サイバートラストマーク）の規則を採択 (2024.03.14)

米国...

・2023.07.19 米国 消費者向けIoT製品のセキュリティ認証制度、サイバートラスト・マーク (U.S. Cyber Trust Mark) を発表

・2022.09.24 NIST NISTIR 8425 消費者向けIoT製品のIoTコアベースラインのプロファイル、NISTIR 8431 「NIST基礎の上に築く:IoTセキュリティの次のステップ」ワークショップ概要報告書

・2022.06.19 NISTIR 8425 (ドラフト) 消費者向けIoT製品のIoTコアベースラインのプロファイル

・2022.02.07 NIST ホワイトペーパー ：消費者向けソフトウェアのサイバーセキュリティラベルの推奨規準

・2022.02.06 NIST ホワイトペーパー ：消費者向けIoT製品のサイバーセキュリティラベルの推奨規準

・2021.11.04 NIST 消費者向けソフトウェアのサイバーセキュリティに関するラベリングについての意見募集

・2021.09.02 NIST ホワイトペーパー（ドラフト）：消費者向けIoTデバイスのベースライン・セキュリティ基準

・2021.08.29 NISTIR 8259B IoT非技術的支援能力コアベースライン

・2021.05.13 米国 国家のサイバーセキュリティ向上に関する大統領令

・2020.12.17 NIST SP 800-213 (Draft) 連邦政府向け「 IoTデバイスサイバーセキュリティ要件の確立」、NISTIR 8259B、8259C、8259D

・2020.05.30 NIST IoT機器製造者向けセキュリティの実践資料 NISTIR 8259 Foundational Cybersecurity Activities for IoT Device Manufacturers, NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline

・2020.02.06 NISTがIoT機器製造者向けセキュリティの実践資料のドラフト（Ver.2）を公開していますね。。。

EU

・2024.03.19 欧州議会 AI法 (2024.03.13) とサイバーレジリエンス法を採択 (2024.03.12)

・2024.02.02 欧州委員会 サイバーセキュリティ認証制度 (EUCC) を採択

・2024.01.17 欧州 欧州議会の投票にかけられるサイバーレジリエンス法案 (Cyber Resilience Act)

・2023.12.04 欧州理事会、欧州議会がサイバーレジリエンス法について政治的合意

・2023.05.31 ENISA 新技術に対応したEUサイバーセキュリティ認証の実現可能性を探る

・2023.03.21 ENISA サイバーセキュリティ認証のウェブページを開設

・2023.03.01 IPA 欧州規格 ETSI EN 303 645 V2.1.1 (2020-06)の翻訳の公開

・2023.02.02 ドイツ スペースネットAG社のサービスにITセキュリティラベルを渡す

・2022.12.15 ドイツ フランス IT製品のセキュリティ認証に関する共同文書を発行 （固定時間制認証制度）

・2022.10.31 ドイツ シンガポール 消費者向けIoT製品のサイバーセキュリティ・ラベルの相互承認 (2022.10.20)

・2022.05.09 ドイツ ITセキュリティラベル for 消費者向けスマート製品

・2022.02.03 ドイツ BSI Mail.deの電子メールサービスにITセキュリティラベルを付与

・2021.07.18 独国 BSIがITセキュリティラベルについてのウェブページを公開していますね。。。

英国

・2023.05.04 英国 インターネットに接続するすべての消費者向け製品に適用される最低セキュリティ基準制度が1年後にはじまりますよ〜 (2023.04.29)

・2023.04.25 Five Eyesの国々が安全なスマートシティを作るための共同ガイダンスを発表 (2023.04.20)

・2022.12.11 英国 製品セキュリティおよび電気通信インフラストラクチャ（PSTI）法成立 at 2022.12.06

・2022.01.27 英国 スマートデバイスのサイバーセキュリティ新法に一歩近づくと発表

・2021.12.09 英国 製品セキュリティおよび電気通信インフラストラクチャ（PSTI）法案 at 2021.11.24

中国

・2022.02.15 中国 国家サイバースペース管理局 専門家の解説 ネットワーク重要機器のセキュリティ認証とセキュリティテストによるネットワークセキュリティの基本ディスクの維持

日本

・2024.03.17 経済産業省 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会の最終とりまとめを公表し、制度構築方針案に対する意見公募を開始

・2023.05.17 経済産業省 産業サイバーセキュリティ研究会 WG3 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会 中間とりまとめ

・2022.11.04 経済産業省 第1回 産業サイバーセキュリティ研究会 ワーキンググループ3 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会

バーゼル銀行監督委員会 パブコメ 健全なサードパーティリスク管理のための諸原則について協議 (2024.07.09)

こんにちは、丸山満彦です。

バーゼル銀行監督委員会が、健全なサードパーティリスク管理のための諸原則についてのパブリックコメントを求めています。これは、2005年に銀行・証券・保険の業態横断的な文書である「金融サービスにおけるアウトソーシング」（原題：Outsourcing in Financial Services）を銀行業態について置き換えるものとして作成されているようです。

具体的には銀行のサードパーティリスク管理について、

・銀行に対する９つの原則（取締役会等の責任、リスク管理枠組みの実施、リスク評価、デュー・デリジェンス、契約締結、オンボーディング、継続的なモニタリング、業務継続管理、契約終了）及び

・監督当局に対する３つの原則（銀行のリスク評価、システム全体の集中リスク、当局間の協調）

からなる計12の原則を示していますね...

サードパーティリスクとして、

・サプライチェーンリスク

・集中リスク

という概念も入っていますね。。。

集中リスクは、いわゆるクラウド事業者に対するリスクで、夏井先生が2010年に提唱した「クラウドは竹」という話に通じます(^^)

●  Basel Committee on Banking Supervision

プレス...

・2024.07.09 Basel Committee consults on principles for the sound management of third-party risk

Basel Committee consults on principles for the sound management of third-party risk	バーゼル委員会、健全なサードパーティリスク管理のための諸原則について協議
・The Basel Committee has published a consultation on Principles for the sound management of third-party risk.	・バーゼル委員会は、「健全なサードパーティリスク管理のための諸原則」についての協議を公表した。
・The proposed principles provide guidance to banks and prudential supervisors on effective third-party risk management, aiming to enhance banks' ability to withstand operational disruptions and mitigate the impact of severe disruptive events.	・提案された原則は、効果的なサードパーティ・リスク管理について銀行および健全性監督当局に指針を提供し、銀行の業務中断への耐性強化と深刻な業務中断事象の影響の低減を目的としている。
・Comments on the proposed principles are requested by 9 October 2024.	・提案された原則に関する意見は、2024年10月9日まで求められている。
The Basel Committee on Banking Supervision today published a consultative document proposing Principles for the sound management of third-party risk in the banking sector.	バーゼル銀行監督委員会は本日、銀行セクターにおける健全なサードパーティリスク管理のための諸原則を提案する協議文書を公表した。
Ongoing digitalisation has led to rapid adoption of innovative approaches in the banking sector. As a result, banks have become increasingly reliant on third parties for services that they had not previously undertaken. This increased reliance on third parties beyond the scope of traditional outsourcing, coupled with the expansion of supply chains and rising concentration risks, has necessitated an update to the 2005 Joint Forum paper Outsourcing in financial services, specifically for the banking sector.	デジタル化の進展により、銀行業界では革新的なアプローチが急速に採用されるようになった。その結果、銀行は従来は自社で対応していなかったサービスについて、サードパーティへの依存度を高めている。従来のアウトソーシングの範囲を超えてサードパーティへの依存度が高まっていること、またサプライチェーンの拡大や集中リスクの増大と相まって、2005年の共同フォーラムの論文「金融サービスにおけるアウトソーシング」の更新が必要となっている。
The consultative document consists of 12 high-level principles offering guidance to banks and supervisors on effectively managing and supervising risks from third-party arrangements. The Principles introduce the concept of a third-party life cycle and emphasise overarching concepts such as criticality and proportionality. Furthermore, they delve into the topics of supply chain risk and concentration risk and highlight the importance of supervisory coordination and dialogue across sectors and borders.	この協議文書は、サードパーティ契約から生じるリスクの効果的な管理と監督について、銀行と監督当局に指針を提供する12のハイレベル原則で構成されている。原則では、サードパーティ・ライフサイクルという概念が導入され、重要度や比例性といった包括的な概念が強調されている。さらに、サプライチェーンリスクと集中リスクについても掘り下げ、セクターや国境を越えた監督上の調整と対話の重要性が強調されている。
The Principles complement and expand on the Financial Stability Board's 2023 report Enhancing third-party risk management and oversight – a toolkit for financial institutions and financial authorities. While primarily directed at large internationally active banks and their prudential supervisors, these Principles also offer benefits to smaller banks and authorities in all jurisdictions. They establish a common baseline for banks and supervisors for the risk management of third parties, while providing the necessary flexibility to accommodate evolving practices and regulatory frameworks across jurisdictions.	本原則は、金融安定理事会(FSB)が2023年に発表した報告書「サードパーティ・リスク管理と監督の強化 – 金融機関および金融当局のためのツールキット」を補完し、さらに発展させたものである。本原則は、主に国際的に活動する大手銀行とその監督当局を対象としているが、あらゆる管轄区域の小規模な銀行や当局にもメリットをもたらす。本原則は、サードパーティのリスク管理に関する銀行と監督当局の共通のベースラインを確立する一方で、管轄区域ごとに進化する慣行や規制枠組みに対応するための必要な柔軟性も提供する。
To remain adaptable and applicable to a wide range of technologies, the Principles maintain a technology-neutral stance. As a result, they can be applied to recent trends like artificial intelligence, machine learning and blockchain technology, even though these trends are not explicitly referenced.	幅広いテクノロジーに適応し適用可能であり続けるため、本原則はテクノロジーに中立な立場を維持している。その結果、本原則は、人工知能、機械学習、ブロックチェーン技術といった最近のトレンドにも適用可能である。これらのトレンドは明示的に言及されていないが、それでも適用可能である。

・[PDF] 

・[DOCX][PDF] 仮訳...

原則...

Principle 1: The board of directors has ultimate responsibility for the oversight of all TPSP arrangements and should approve a clear strategy for TPSP arrangements within the bank’s risk appetite and tolerance for disruption.	原則1：取締役会は、すべてのTPSPとの取決めを監督する最終的な責任を有し、銀行のリスクアペタイトと混乱に対する許容度の範囲内で、TPSPとの取決めに関する明確な戦略を承認すべき。
Principle 2: The board of directors should ensure that senior management implements the policies and processes of the third-party risk management framework (TPRMF) in line with the bank’s third-party strategy, including reporting of TPSP performance and risks related to TPSP arrangements, and mitigating actions.	原則2：取締役会は、上級管理職が、サードパーティの実績並びにTPSPとの取り決めに関するリスクの報告及び低減措置を含む戦略に沿って、サードパーティリスク管理の枠組みの方針及びプロセスを実施することを確実にすべき。
Principle 3: Banks should perform a comprehensive risk assessment under the TPRMF to evaluate and manage identified and potential risks both before entering into and throughout a TPSP arrangement.	原則3：銀行は、TPSPとの取決めを締結する前及び取決めを結んでいる間を通じて、特定されたリスク及び潜在的なリスクを評価し管理するために、サードパーティリスク管理の枠組みの下で包括的なリスク評価を行うべき。
Principle 4: Banks should conduct appropriate due diligence on a prospective TPSP prior to entering into an arrangement.	原則4： 銀行は、TPSPとの取決めを締結する前に適切なデュー・デリジェンスを行うべき。
Principle 5: TPSP arrangements should be governed by legally binding written contracts that clearly describe rights and obligations, responsibilities and expectations of all parties in the arrangement.	原則5：TPSPとの取決めは、すべての当事者の権利、責 任及び期待を明確に記述した法的拘束力のある書面による 契約によって管理されるべき。
Principle 6: Banks should dedicate sufficient resources to support a smooth transition of a new TPSP arrangement in order to prioritise the resolution of any issues identified during due diligence or interpretation of contractual provisions.	原則6：銀行は、デュー・デリジェンスや契約条項の解釈の過程で特定されたあらゆる問題の解決を優先させるために、 新たなサードパーティとの取決めに円滑に移行するための十分な資源を投入すべき。
Principle 7: Banks should, on an ongoing basis, assess and monitor the performance and changes in the risks and criticality of TPSP arrangements and report accordingly to board and senior management. Banks should respond to issues as appropriate.	原則7：銀行は、TPSPとの取決めのパフォーマンス、リスクの変化、及び重要性を継続的に評価・監視し、その結果を取締役会や上級管理職に報告し、必要に応じて 問題に対応すべき。
Principle 8: Banks should maintain robust business continuity management to ensure their ability to operate in case of a TPSP service disruption.	原則8：銀行は、TPSPのサービスが中断した場合に業務を継続する能力を確保するために、堅固な業務継続 管理を維持すべき。
Principle 9: Banks should maintain exit plans for planned termination and exit strategies for unplanned termination of TPSP arrangements.	原則9：銀行は、TPSPとの取決めの計画的な終了のための出口計画及び計画外の終了のための出口戦略を 維持すべき。
Principle 10: Supervisors should consider third-party risk management as an integral part of ongoing assessment of banks.	原則10：監督当局は、サードパーティリスク管理を銀行の継続的な評価の不可欠な部分として考慮すべき。
Principle 11: Supervisors should analyse the available information to identify potential systemic risks posed by the concentration of one or multiple TPSPs in the banking sector.	原則11：監督当局は、銀行セクターにおける1つ又は複数のTPSPの集中がもたらす潜在的なシステミック・リスクを特定するために、利用可能な情報を分析すべき。
Principle 12: Supervisors should promote coordination and dialogue across sectors and borders to monitor systemic risks posed by critical TPSPs that provide services to banks.	原則12：監督当局は、セクターや国境を越えて銀行にサービスを 提供する重要なTPSPがもたらすシステミック・リスクをモニターするために、協調と対話を促進すべき。

---

金融庁からの発表...

● 金融庁

・2024.07.12 バーゼル銀行監督委員会による市中協議文書「健全なサードパーティリスク管理のための諸原則」の公表について

本件に関する金融庁・日本銀行作成説明資料

・2024.08.14 [PDF] バーゼル銀行監督委員会による市中協議文書「健全なサードパーティリスク管理のための諸原則」について

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2021.02.17 クラウドは竹 クラウド集中リスク

・2010.05.31 パブリッククラウドコンピューティングサービスは竹である　（夏井説）

こういう視点も...

・2021.02.19 除草剤をまけば強い植物だけが生き残る

米国 FTC ブログ 機能停止を回避し、広範囲にわたるシステム障害

こんにちは、丸山満彦です。

システム更新によるプログラムのバグにより、世界レベルで大規模なシステム障害が発生し、エアライン等に混乱が生じたりしたことも踏まえて？、米国連邦取引委員会が、「機能停止を回避し、広範囲にわたるシステム障害を防ぐ」というブログを載せていますね...

ポイントとしては、

• 厳格なテスト
• 段階的なロールアウト手順
• リスクを最小限に抑える API の開発と使用

というのが挙げられていますね...

会計監査の世界では、昔からIT全般統制の一部として、システムの完全性、可用性についても一部評価されていましたので、上記の内容をみれば、なるほどと思うことも多いように思います...

ということで、基本は重要(^^;;

● U.S. Federal Trade Commission - Office of Technology Blog

・2024.08.13 Avoiding Outages and Preventing Widespread System Failures

Avoiding Outages and Preventing Widespread System Failures	機能停止を回避し、広範囲にわたるシステム障害を防ぐ
Widespread software outages can often be prevented. Resilience – a software program's ability to handle and maintain critical functionality in the face of bugs or other unexpected conditions – is essential given the significant role software plays in the infrastructure of the economy. As with previously discussed security principles, many common types of software flaws can be preemptively addressed through systematic and known processes that prevent or minimize the likelihood of outages. Systematic processes for software resilience include rigorous testing of both code and configuration, incremental rollout procedures, and the development and use of APIs that minimize risk.	広範囲にわたるソフトウェア停止は、しばしば防ぐことができる。レジリエンス（バグやその他の予期せぬ状況に直面しても、重要な機能を処理し、維持するソフトウエアプログラムの能力）は、ソフトウエアが経済のインフラストラクチャーにおいて重要な役割を果たしていることを考えると、不可欠である。先に説明したセキュリティ原則と同様に、一般的なソフトウエアの欠陥の多くは、機能停止の可能性を防止または最小化する体系的かつ既知のプロセスによって、先手を打って対処することができる。ソフトウエアのレジリエンスを向上させる体系的なプロセスには、コードとコンフィギュレーションの両方に対する厳格なテスト、段階的なロールアウト手順、リスクを最小限に抑える API の開発と使用などがある。
Agency staff have acknowledged that resilience can be threatened by lack of competition in critical inputs. Dominant firms pushing maximum adoption of their digital products and services can create single points of failure for entire industries, within and beyond the digital economy. As the number of users relying on the same enterprise software increases, so too can the scale of disruption caused by outages of that software. Every software outage is an opportunity to take a critical look at systems in place to achieve resilience and assess these systems for appropriateness and sufficiency.	省庁のスタッフは、重要なインプットにおける競争の欠如によってレジリエンスが脅かされる可能性があることを認めている。デジタル製品やサービスの最大限の普及を推進する支配的企業は、デジタル経済の内外を問わず、業界全体にとっての単一障害点を生み出しかねない。同じエンタープライズ・ソフトウェアに依存するユーザー数が増えれば、そのソフトウェアの停止によって引き起こされる混乱の規模も大きくなる。ソフトウェアが停止するたびに、レジリエンスを達成するために導入されたシステムを批判的に見 直し、これらのシステムが適切で十分であるかどうかを評価する機会が訪れる。
Beyond code, configuration and data changes can lead to failures. An inability to treat these with the same care and robust processes can lead to outages. Software is made up of code, instructions that tell the computer how to operate. But these instructions may reference configuration files or other data which can also lead to failures. Consider a local ice cream store with a mobile app. The app may contain code for displaying a menu based on a set of items defined in a configuration file (or received from a server). Even if the code for displaying the menu doesn't change, a change to the configuration file could trigger a previously unknown bug — for example an apostrophe being added for the first time with "Cookies 'n Cream" — causing the app to crash.	コードの変更だけでなく、設定やデータの変更も障害につながる可能性がある。これらの変更を同じ注意深さと堅牢なプロセスで処理できないと、サービス停止につながる可能性がある。ソフトウェアはコードで構成されており、コードはコンピュータに操作方法を指示する命令である。しかし、これらの命令は設定ファイルやその他のデータを参照することがあり、それも障害につながる可能性がある。モバイルアプリを導入している地元のアイスクリーム店を考えてみよう。このアプリには、設定ファイル(またはサーバーから受信)で定義されたアイテムのセットに基づくメニューを表示するためのコードが含まれている可能性がある。メニューを表示するためのコードに変更が加えられていなくても、設定ファイルに変更が加えられた場合、例えば「Cookies 'n Cream」の最初の文字にアポストロフィが追加されるなど、これまで知られていなかったバグが引き起こされ、アプリがクラッシュする可能性がある。
The principle of treating code, configuration files, and data changes with the same care is especially critical when building software run by banks, hospitals, and transportation services. Software vendors must use appropriate software architecture and processes to guard against unexpected failures from both code and non-code changes.	コード、コンフィギュレーション・ファイル、データの変更を同じように慎重に扱うという原則は、銀行、病院、交通機関が運営するソフトウェアを構築する際には特に重要である。ソフトウェア・ベンダーは、適切なソフトウェア・アーキテクチャとプロセスを使用して、コードとコード以外の変更の両方による予期せぬ障害に備えなければならない。
Everything Everywhere All at Once may be a great movie – but it's a poor strategy for deploying software changes. Even the most rigorous testing environment can't mirror the diversity of real-world computers. When deploying changes to automatically updating software, one common strategy to mitigate this risk is to initially deploy to a small subset of machines, and then rolling out to more users after it’s confirmed that the smaller subset has continued to function without interruption. It's important to consider this strategy for not just code changes, but also updates to configuration and data.	Everything Everywhere All at Once（すべてを一度に）」は素晴らしい映画かもしれないが、ソフトウェアの変更を展開する戦略としては不適切だ。どんなに厳密なテスト環境でも、実世界のコンピュータの多様性を反映することはできない。自動更新ソフトウェアの変更を展開する場合、このリスクを軽減するための一般的な戦略の1つは、最初に少数のマシンのサブセットに展開し、少数のサブセットが中断することなく機能し続けることが確認された後に、より多くのユーザーに展開することである。コードの変更だけでなく、設定やデータの更新についても、この戦略を検討することが重要だ。
Auto-updating software can be an important mechanism to ensure that critical security or stability updates get deployed in a timely manner. For security software, it can help ensure companies using the software are running a version able catch the latest threats. Yet, software vendors may unnecessarily risk causing widespread outages by deploying these updates broadly without a mechanism to detect and reverse changes that cause major issues for a high percentage of machines before the software is widely deployed.	ソフトウェアの自動更新は、重要なセキュリティ更新や安定性更新をタイムリーに展開するための重要なメカニズムになり得る。セキュリティ・ソフトウェアの場合、そのソフトウェアを使用している企業が、最新の脅威に対応できるバージョンを実行していることを保証するのに役立つ。しかし、ソフトウェアベンダーは、ソフトウェアが広く展開される前に、高い割合のマシンに重大な問題を引き起こす変更を検知し、元に戻す仕組みがないまま、これらのアップデートを広く展開することで、不必要に広範囲に機能停止を引き起こすリスクを負う可能性がある。
Platforms and operating systems that fail to provide resilient APIs risk the stability of the whole system. An API, or application programming interface, is a way for two pieces of software to communicate in a structured way. For example, the local ice cream store's app may use the phone's location API to tell a customer how far they are from the store. A poor API design could mean that a mistake by the app's programmer causes the customer's whole phone to crash, rather than just the app itself. Building APIs that account for human error can help programmers by limiting the damage from mistakes and preventing small issues from becoming larger ones.	レジリエンスAPIを提供できないプラットフォームやオペレーティングシステムは、システム全体の安定性をリスクにさらす。API（アプリケーション・プログラミング・インターフェース）とは、2つのソフトウェアが構造化された方法でコミュニケーションするための方法である。例えば、地元のアイスクリーム店のアプリは、携帯電話の位置情報APIを使用して、顧客に店舗からの距離を伝えるかもしれない。APIの設計が不十分だと、アプリのプログラマーのミスによって、アプリそのものではなく、顧客の携帯電話全体がクラッシュしてしまう可能性がある。ヒューマンエラーを考慮したAPIを構築することは、ミスによる被害を抑え、小さな問題が大きな問題に発展するのを防ぐことで、プログラマーを助けることができる。
However, creating resilient APIs is not an excuse to lock competitors out of the access they need to build effective alternatives. In order to be competitive with a platform or operating system vendor's own offerings, some types of software require broad, low-level access (the ability to read detailed information and control aspects of the inner workings of a system). Some might argue that allowing such access to third parties requires companies to sacrifice resiliency, and that they can only have one or the other. But just as competition through interoperability can coexist with privacy and security, so too can interoperability coexist with reliability. When platforms or operating system build safer versions of these interfaces, they must do so in a way that, to the fullest extent possible, supports, rather than suppresses, the ecosystem of existing and emerging products. Incumbent companies shouldn't use API changes in the name of resilience as an excuse to cut off broad access for competitors, especially not while continuing to retain broad access for their own offerings.	しかし、レジリエンスAPIを作ることは、競合他社が効果的な代替手段を構築するために必要なアクセスを締め出す言い訳にはならない。プラットフォームやオペレーティングシステムベンダーが提供するものと競争力を持つためには、ソフトウェアの種類によっては、広範で低レベルのアクセス（詳細な情報を読んだり、システムの内部動作の側面を管理したりする能力）が必要になる。このようなアクセスをサードパーティに許可すると、企業はレジリエンスを犠牲にしなければならず、どちらか一方しか手に入れることができないと主張する人もいるかもしれない。しかし、相互運用性を通じた競争がプライバシーやセキュリティと共存できるように、相互運用性も信頼性と共存できる。プラットフォームやオペレーティングシステムがこれらのインターフェースの安全なバージョンを構築する際には、可能な限り、既存製品や新興製品のエコシステムを抑制するのではなく、むしろサポートするような方法で行わなければならない。レジリエンシーの名の下にAPIを変更することは、競合他社への幅広いアクセスを遮断する口実としてはならない。
Widespread software outages can lead to substantial consumer injury including the inability to access critical services and financial loss. Given the enormous impacts on consumers, small businesses, and the public that arise from failures in computer systems, FTC staff will continue to monitor such developments and investigate when warranted. The FTC has long examined companies' computer systems to determine whether proper steps were taken to secure the systems and the consumer data they hold. The FTC’s record investigating computer systems has shown that there are steps companies can take to minimize the likelihood of bad outcomes. While the state of the art in software continues to improve, there are known approaches that systemically and preemptively address many potential issues, either entirely preventing them or dramatically reducing the likelihood of them occurring.	広範なソフトウェア停止は、重要なサービスへのアクセス不能や金銭的損失など、消費者に多大な損害をもたらす可能性がある。コンピュータ・システムの障害によって消費者、中小企業、一般大衆に甚大な影響が及ぶことを考慮し、FTCのスタッフは今後もこのような事態の発生を監視し、必要な場合には調査を行う。FTCは長年にわたり、企業のコンピューター・システムを調査し、システムおよびシステムが保有する消費者データのセキュリティに適切な措置が取られているかどうかを判断してきた。FTCのコンピューター・システムに関する調査実績は、企業が悪い結果を招く可能性を最小限に抑えるために講じることのできる措置があることを示している。ソフトウエアの技術水準は向上し続けているが、潜在的な問題の多くに体系的かつ先制的に対処し、その発生を完全に防止するか、あるいはその可能性を劇的に低減するアプローチが知られている。
Thank you to the staff who contributed to this post: Simon Fondrie-Teitler, Hannah Garden-Monheit, Wells Harrell, Amritha Jayanti, Erik Jones, Stephanie T. Nguyen, Shaoul Sussman, Grady Ward, Ben Wiseman.	この投稿に協力してくれたスタッフに感謝する： Simon Fondrie-Teitler、Hannah Garden-Monheit、Wells Harrell、Amritha Jayanti、Erik Jones、Stephanie T. Nguyen、Shaoul Sussman、Grady Ward、Ben Wiseman。

---

ちなみに、

映画 Everything Everywhere All at Once

 ・[wikipedia]

予告編

・[YouTube]

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2024.08.11 CROWDSTRIKE ファルコンのトラブルの根本原因分析報告書 (2024.08.06)

・2024.08.05 米国 GAO ブログ CrowdStrikeの混乱がソフトウェア・アップデートによる主要なサイバー脆弱性を浮き彫りにする (2024.07.30)

・2024.07.20 米国 CISAもCrowdStrikeの更新の問題について情報提供をしていますね...はやい...

米国 NIST SP 1800-35（第4次初期ドラフト） ゼロトラストアーキテクチャの実装 (2024.07.30)

こんにちは、丸山満彦です。

NISTがSP 1800-35（第4次初期ドラフト） ゼロトラストアーキテクチャの実装を公表し、意見募集をしていますね...

かなり詳細なドキュメントです...

本文中にこの文書の利用の前提条件が書いているのですが、重要です...

Assumptions	前提条件
This project is guided by the following assumptions:	このプロジェクトは、以下の前提条件に基づいている：
NIST SP 800-207, Zero Trust Architecture is a definitive source of ZTA concepts and principles.	NIST SP 800-207「Zero Trust Architecture」は、ZTAの概念と原則の決定的な情報源である。
Enterprises that want to migrate gradually to an increasing use of ZTA concepts and principles in their network environments may desire to integrate ZTA with their legacy enterprise and cloud systems.	ネットワーク環境においてZTAの概念と原則を徐々に使用するように移行したいエンタープライズは、ZTAをレガシーエンタープライズシステムとクラウドシステムに統合することを望むかもしれない。
To prepare for a migration to ZTA, enterprises may want to inventory and prioritize all resources that require protection based on risk. They will also need to define policies that determine under what set of conditions subjects will be given access to each resource based on attributes of both the subject and the resource (e.g., location, type of authentication used, user role), as well as other variables such as day and time.	ZTAへの移行の準備として、エンタープライズは、リスクに基づいて保護が必要なすべてのリソースをインベントリ化し、優先順位をつけることが考えられる。また、対象者とリソースの属性（場所、認証の種類、ユーザーの役割など）、および曜日や時間などの変数に基づいて、どのような条件で対象者に各リソースへのアクセスを許可するかを決定するポリシーを定義する必要がある。
Enterprises should use a risk-based approach to set and prioritize milestones for their gradual adoption and integration of ZTA across their enterprise environment.	企業は、リスクベースのアプローチを使用して、エンタープライズ環境全体で段階的に ZTA を採用し、統合するためのマイルストーンを設定し、優先順位をつけるべきである。
There is no single approach for migrating to ZTA that is best for all enterprises.	すべてのエンタープライズにとって最適なZTAへの移行方法は一つではない。
ZTA is a set of concepts and principles, not a set of technical specifications that can be complied with. Therefore, zero trust compliance is not an objective. Rather, the objective is continuous improvement of the access control processes and policies in accordance with the principles of ZTA.	ZTAは概念と原則の集合であり、準拠可能な技術仕様の集合ではない。したがって、ゼロ・トラスト・コンプライアンスは目的ではない。むしろ、ZTAの原則に従ってアクセス管理プロセスとポリシーを継続的に改善することが目的である。
Devices, applications, and other non-human entities can have different levels of capabilities:	デバイス、アプリケーション、およびその他の人間以外の事業体は、異なるレベルの能力を持つことができる：
Neither host-based firewalls nor host-based intrusion prevention systems (IPS) are mandatory components; they are, however, capabilities that can be added when a device is capable of supporting them.	ホストベースのファイアウォールもホストベースの侵入防御システム（IPS）も必須コンポーネントではない。
Some limited functionality devices that are not able to host firewall, IPS, and other capabilities on their own may be associated with services that provide these capabilities for them. In this case, both the device and its supporting services can be considered the subject in the ZTA access interaction.	ファイアウォール、IPS、およびその他の機能を単独でホストできない機能制限付きデバイスの中には、これらの機能を提供するサービスに関連しているものもある。この場合、ZTAアクセス相互作用では、デバイスとそのサポー トサービスの両方が主体と見なされる。
Some devices are bound to users (e.g., desktop, laptop, smartphone); other devices are not bound to users (e.g., kiosk endpoints, servers, applications, services). Both types of devices can be subjects and request access to enterprise resources.	あるデバイスはユーザーにバインドされる（例：デスクトップ、ラップトップ、スマー トフォン）が、他のデバイスはユーザーにバインドされない（例：キオスクエンドポイン ト、サーバー、アプリケーション、サービス）。どちらのタイプのデバイスもサブジェクトとなり、エンタープライズリソースへのアクセスを要求することができる。
ZTA components used in any given enterprise solution should be interoperable regardless of their vendor origin.	任意のエンタープライズソリューションで使用されるZTAコンポーネントは、ベンダーの出自に関係なく相互運用可能でなければならない。

● NIST - ITL

・2024.07.30 NIST SP 1800-35 (4th Preliminary Draft) Implementing a Zero Trust Architecture

NIST SP 1800-35 (4th Preliminary Draft) Implementing a Zero Trust Architecture	NIST SP 1800-35（第4次初期ドラフト） ゼロトラストアーキテクチャの実装
Announcement	発表
The NIST National Cybersecurity Center of Excellence (NCCoE) has released the fourth version of our preliminary draft practice guide, Implementing a Zero Trust Architecture (NIST SP 1800-35), for public comment. This publication outlines results and best practices from the NCCoE effort to work with 24 vendors to demonstrate end-to-end zero trust architectures.	NISTナショナル・サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）は、ゼロトラスト・アーキテクチャの実装（NIST SP 1800-35）の初期ドラフト第4版を公開し、パブリックコメントの募集を開始した。本書は、NCCoEが24のベンダーと協力してエンドツーエンドのゼロトラスト・アーキテクチャの実証に取り組んだ結果とベストプラクティスを概説している。
Starting with this release, we are introducing our traditional NIST SP 1800-35 document in two formats; one High-Level Document in PDF Format and one Full Document in Web Format. The document in PDF format is meant to serve as introductory reading with insight into the project effort (since it provides a high-level summary of project goals, reference architecture, various ZTA implementations, and findings).	今回のリリースから、従来のNIST SP 1800-35文書を、PDF形式のハイレベル文書とWeb形式の完全文書の2つの形式で紹介する。PDF形式のドキュメントは、プロジェクトの取り組みについての洞察（プロジェクトの目標、リファレンス・アーキテクチャ、様々なZTA実装、調査結果のハイレベルな要約を提供するため）を提供する入門的な読み物として機能することを意図している。
The web format document provides in-depth details about technologies leveraged, their integrations and configurations, and the use cases and scenarios demonstrated. It also contains information on the implemented security capabilities and their mappings to the NIST Cybersecurity Framework (CSF) versions 1.1 and 2.0, NIST SP 800-53r5, and security measures outlined in “EO-Critical Software” under Executive Order 14028.	ウェブ形式の文書では、活用された技術、それらの統合と構成、実証されたユースケースとシナリオに関する詳細な情報が提供される。また、実装されたセキュリティ機能とNISTサイバーセキュリティフレームワーク（CSF）バージョン1.1および2.0、NIST SP 800-53r5、および大統領令14028の「EO-Critical Software」に概説されたセキュリティ対策とのマッピングに関する情報も含まれている。
...	...
Abstract	要旨
A zero trust architecture (ZTA) enables secure authorized access to enterprise resources that are distributed across on-premises and multiple cloud environments, while enabling a hybrid workforce and partners to access resources from anywhere, at any time, from any device in support of the organization’s mission.	ゼロトラストアーキテクチャ（ZTA）は、オンプレミスや複数のクラウド環境に分散しているエンタープライズリソースへの安全な認可アクセスを可能にすると同時に、ハイブリッドワーカーやパートナーが、組織のミッションをサポートするために、いつでも、どこからでも、どのデバイスからでもリソースにアクセスできるようにする。
This NIST Cybersecurity Practice Guide explains how organizations can implement ZTA consistent with the concepts and principles outlined in NIST Special Publication (SP) 800-207, Zero Trust Architecture. The NCCoE worked with 24 collaborators under Cooperative Research Development Agreements (CRADAs) to integrate commercially available technology to build 17 ZTA example implementations and demonstrate a number of common use cases. Detailed technical information on each build can serve as a valuable resource for your technology implementers by providing models they can emulate. The lessons learned from the implementations and integrations can benefit your organization by saving time and resources. This guide also includes mappings of ZTA principles to commonly used security standards and guidance.	このNISTサイバーセキュリティ実践ガイドでは、NIST特別刊行物（SP）800-207「Zero Trust Architecture」に概説されている概念と原則に沿って、組織がZTAを実装する方法を説明している。NCCoE は、CRADA（Cooperative Research Development Agreements：共同研究開発契約）に基づく 24 の共同研究者と協力し、市販の技術を統合して 17 の ZTA 実装例を構築し、多くの一般的なユースケースを実証した。各実装に関する詳細な技術情報は、技術実装者が模倣できるモデルを提供することで、貴重なリソースとなる。実装と統合から学んだ教訓は、時間とリソースを節約することで、組織に利益をもたらす。このガイドには、ZTA の原則と一般的に使用されているセキュリティ標準やガイダンスのマッピングも含まれている。

・[PDF] NIST SP 1800-35 high-level overview

目次...

Exective Summary	エグゼクティブサマリー
1 Introduction to the Guide	1 ガイドの序文
1.1 Audience	1.1 対象者
1.2 Scope	1.2 適用範囲
1.3 How to Use This Guide	1.3 本ガイドの使用方法
2 Project Overview	2 プロジェクトの概要
2.1 Motivation for the Project	2.1 プロジェクトの動機
2.2 Challenges in Implementing ZTA	2.2 ZTA導入の課題
2.3 Project Approach	2.3 プロジェクトのアプローチ
2.4 Collaborators and Their Contributions	2.4 協力者とその貢献
3 Architecture and Builds	3 アーキテクチャとビルド
3.1 General ZTA Reference Architecture	3.1 一般的なZTAリファレンスアーキテクチャ
3.2 EIG Crawl Phase Reference Architecture	3.2 EIGクロールフェーズリファレンスアーキテクチャ
3.3 EIG Run Phase Reference Architecture	3.3 EIG実行フェーズのリファレンスアーキテクチャ
3.4 SDP, Microsegmentation, and SASE Reference Architecture	3.4 SDP、マイクロセグメンテーション、SASEリファレンスアーキテクチャ
3.5 ZTA Laboratory Physical Architecture	3.5 ZTAラボの物理アーキテクチャ
3.6 Builds Implemented	3.6 実装されたビルド
4 Build Implementation Instructions	4 ビルド実装手順
5 General Findings	5 一般的な調査結果
5.1 EIG Crawl Phase Findings	5.1 EIGクロールフェーズの結果
5.2 EIG Run Phase Findings	5.2 EIG実行フェーズの結果
5.3 SDP, Microsegmentation, and SASE Phase Findings	5.3 SDP、マイクロセグメンテーション、SASEフェーズの結果
6 Functional Demonstrations	6 機能デモ
6.1 Demonstration Methodology	6.1 実証方法
6.2 Demonstration Use Cases	6.2 実証ユースケース
6.2.1 Use Case A: Discovery and Identification	6.2.1 ユースケースA：発見と特定
6.2.2 Use Case B: Enterprise-ID Access	6.2.2 ユースケース B：エンタープライズ ID アクセス
6.2.3 Use Case C: Collaboration: Federated-ID Access	6.2.3 ユースケース C：コラボレーション： 統合IDアクセス
6.2.4 Use Case D: Other-ID Access	6.2.4 ユースケース D： その他のIDアクセス
6.2.5 Use Case E: Guest: No-ID Access	6.2.5 ユースケースE：ゲスト： IDなしアクセス
6.2.6 Use Case F: Confidence Level	6.2.6 ユースケースF：信頼レベル
6.2.7 Use Case G: Service-Service Interaction	6.2.7 ユースケースG：サービス間インタラクション
6.2.8 Use Case H: Data Level Security Scenarios	6.2.8 ユースケースH：データ・レベルのセキュリティ・シナリオ
6.3 Functional Demonstration Results	6.3 機能実証結果
6.3.1 Demonstration Result Summaries	6.3.1 実証結果の概要
6.3.2 Demonstration Results in Full	6.3.2 実証結果全文
7 Risk and Compliance Management	7 リスクとコンプライアンスのマネジメント
7.1 Risks Addressed by the ZTA Reference Architecture	7.1 ZTAリファレンスアーキテクチャが対処するリスク
7.2 ZTA Security Mappings	7.2 ZTAセキュリティマッピング
8 Zero Trust Journey Takeaways	8 ゼロ・トラスト・ジャーニーの要点
8.1 Discover and Inventory the Existing Environment	8.1 既存環境の発見とインベントリ作成
8.2 Formulate Access Policy to Support the Mission and Business Use Cases	8.2 使命とビジネスユースケースをサポートするアクセスポリシーを策定する
8.3 Identify Existing Security Capabilities and Technology	8.3 既存のセキュリティ能力と技術を識別する
8.4 Eliminate Gaps in Zero Trust Policy and Processes by Applying a Risk-Based Approach Based on the Value of Data	8.4 データの価値に基づくリスクベースアプローチを適用することで、ゼロトラストポリシーと プロセスのギャップをなくす
8.5 Implement ZTA Components (People, Process, and Technology) and Incrementally Leverage Deployed Security Solutions	8.5 ZTA の構成要素（人、プロセス、技術）を実装し、展開済みのセキュリティソリュ ーションを段階的に活用する
8.6 Verify the Implementation to Support Zero Trust Outcomes	8.6 ゼロトラストの成果をサポートするために実装を検証する
8.7 Continuously Improve and Evolve Due to Changes in Threat Landscape, Mission, Technology, and Regulations	8.7 脅威の状況、ミッション、技術、規制の変化に応じて継続的に改善し、進化させる
Appendix A List of Acronyms	附属書 A 頭字語リスト
Appendix B References	附属書 B 参考文献
Appendix C Change Log	附属書 C 変更履歴

エグゼクティブサマリー

Exective Summary	エグゼクティブサマリー
A zero trust architecture (ZTA) can help your organization to protect its data and resources no matter where they are located. A ZTA can also enable your workforce, contractors, partners, and other authorized parties to securely access the data and resources they need from anywhere at any time. ZTAs implement a risk-based approach to cybersecurity — continuously evaluating and verifying conditions and requests to decide which access requests should be permitted, then ensuring that each access is properly safeguarded commensurate with risk. Because of their effectiveness against both internal and external threats, ZTAs are increasingly being implemented, and some organizations are already required by legislation or regulation to use ZTAs.	ゼロトラストアーキテクチャ（ZTA）は、組織のデータとリソースがどこにあろうと、それらを保護するのに役立つ。ZTAはまた、従業員、請負業者、パートナー、その他の認可された関係者が、いつでもどこからでも必要なデータやリソースに安全にアクセスすることを可能にする。ZTAはサイバーセキュリティにリスクベースのアプローチを導入している。どのアクセス要求を許可すべきかを決定するために、条件と要求を継続的に評価・検証し、各アクセスがリスクに見合った適切な保護を受けていることを保証する。ZTAは、内部および外部の脅威に対して有効であるため、導入が進んでおり、すでに法律や規制によってZTAの使用を義務付けられている組織もある。
This guide is intended to help your organization plan how to gradually evolve its existing environments and technologies to a ZTA over time. The insights in this guide are based on a project being led by the National Cybersecurity Center of Excellence (NCCoE) in collaboration with 24 ZTA technology providers. Together they have built 17 example ZTA solutions in lab environments and demonstrated each build’s ability to meet the principles of ZTA. Detailed technical information on each build can also serve as a valuable resource for your technology implementers by providing models they can emulate. The lessons they have learned from the implementations and integrations can benefit your organization by saving time and resources.	本ガイドは、既存の環境とテクノロジーを時間をかけて徐々にZTAに進化させる方法を、組織が計画するのに役立つことを目的としている。このガイドの洞察は、国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）が24のZTAテクノロジー・プロバイダと協力して主導しているプロジェクトに基づいている。彼らは共同で、17のZTAソリューション例をラボ環境で構築し、各構築がZTAの原則を満たす能力を実証した。各構築に関する詳細な技術情報は、模倣可能なモデルを提供することで、技術実装者にとって貴重なリソースとなる。実装と統合から学んだ教訓は、時間とリソースを節約することで、組織に利益をもたらす。
By utilizing this guide, your organization can be better positioned to implement a ZTA that achieves the following:	このガイドを活用することで、あなたの組織は、以下を実現するZTAを実装するためのより良いポジションを得ることができる：
・Supports user access to resources regardless of user location or device (managed or unmanaged)	・ユーザーの場所やデバイス（管理型、非管理型）に関係なく、リソースへのユーザーアクセスをサポートする。
・Protects sensitive information and other business assets and processes regardless of their location (on-premises or cloud-based)	・場所（オンプレミスまたはクラウドベース）に関係なく、機密情報およびその他のビジネス資産とプロセスを防御する。
・Limits breaches by making it harder for attackers to move through an environment and by addressing the insider threat (insiders are not automatically trusted)	・攻撃者が環境内を移動することを困難にし、インサイダーの脅威（インサイダーは自動的に信頼されるわけではない）に対処することで、侵害を制限する。
・Performs continuous, real-time monitoring, logging, and risk-based assessment and enforcement of corporate policy	・継続的なリアルタイムのモニタリング、ロギング、リスクベースのアセスメントを行い、企業ポリシーを実施する。

・[HTML] NIST SP 1800-35 Full Document

Implementing a Zero Trust Architecture: Full Document	ゼロ・トラスト・アーキテクチャを導入する： 完全文書
Executive Summary	エグゼクティブサマリー
Introduction to the Guide	序文
Project Overview	プロジェクトの概要
Architecture and Builds	アーキテクチャとビルド
Builds Implemented	実装されたビルド
Build Architecture Details	ビルドアーキテクチャの詳細
Build Implementation Instructions	ビルド実装手順
Enterprise 1 Build 1 (E1B1) - EIG Crawl - Okta Identity Cloud and Ivanti Access ZSO as PEs Product Guides	エンタープライズ 1 ビルド 1（E1B1） - EIG クロール - Okta Identity Cloud および Ivanti Access ZSO を PE として使用 製品ガイド
Enterprise 2 Build 1 (E2B1) - EIG Crawl - Ping Identity Ping Federate as PE Product Guides	エンタープライズ2ビルド1（E2B1） - EIGクロール - PEとしてのPing Identity Ping Federate製品ガイド
Enterprise 3 Build 1 (E3B1) - EIG Crawl - Azure AD Conditional Access (later renamed Entra Conditional Access) as PE Product Guides	エンタープライズ3ビルド1（E3B1） - PE製品ガイドとしてEIG Crawl - Azure AD Conditional Access（後にEntra Conditional Accessに改称
Enterprise 1 Build 2 (E1B2) - EIG Run - Zscaler ZPA Central Authority (CA) as PE Product Guides	エンタープライズ1ビルド2（E1B2） - EIG Run - PE製品ガイドとしてのZscaler ZPA Central Authority（CA）
Enterprise 3 Build 2 (E3B2) - EIG Run - Microsoft Azure AD Conditional Access (later renamed Entra Conditional Access), Microsoft Intune, Forescout eyeControl, and Forescout eyeExtend as PEs Product Guides	Enterprise 3 Build 2 (E3B2) - EIG Run - PE製品ガイドとしてのMicrosoft Azure AD Conditional Access（後にEntra Conditional Accessに改名）、Microsoft Intune、Forescout eyeControl、Forescout eyeExtend
Enterprise 1 Build 3 (E1B3) - SDP - Zscaler ZPA CA as PE Product Guides	エンタープライズ1ビルド3（E1B3） - SDP - PEとしてのZscaler ZPA CA製品ガイド
Enterprise 2 Build 3 (E2B3) - Microsegmentation - Cisco ISE, Cisco Secure Workload, and Ping Identity Ping Federate as PEs Product Guides	エンタープライズ2ビルド3（E2B3） - マイクロセグメンテーション - PEとしてのCisco ISE、Cisco Secure Workload、Ping Identity Ping Federate製品ガイド
Enterprise 3 Build 3 (E3B3) - SDP and Microsegmentation - Microsoft Azure AD Conditional Access (later renamed Entra Conditional Access), Microsoft Intune, Microsoft Sentinel, Forescout eyeControl, and Forescout eyeExtend as PEs Product Guides	エンタープライズ 3 ビルド 3（E3B3） - SDP とマイクロセグメンテーション - PE として Microsoft Azure AD Conditional Access（後に Entra Conditional Access に改称）、Microsoft Intune、Microsoft Sentinel、Forescout eyeControl、Forescout eyeExtend を提供する。
Enterprise 4 Build 3 (E4B3) - EIG Run - IBM Security Verify as PE Product Guides	エンタープライズ 4 ビルド 3（E4B3） - EIG ラン - PE としての IBM Security Verify 製品ガイド
Enterprise 1 Build 4 (E1B4) - SDP - Appgate SDP Controller as PE Product Guides	エンタープライズ1ビルド4（E1B4） - SDP - PEとしてのAppgate SDPコントローラ 製品ガイド
Enterprise 2 Build 4 (E2B4) - SDP and SASE - Symantec Cloud Secure Web Gateway, Symantec ZTNA, and Symantec Cloud Access Security Broker as PEs Product Guides	エンタープライズ 2 ビルド 4（E2B4） - SDP および SASE - PE として Symantec Cloud Secure Web Gateway、Symantec ZTNA、Symantec Cloud Access Security Broker 製品ガイド
Enterprise 3 Build 4 (E3B4) - SDP - F5 BIG-IP, F5 NGINX Plus, Forescout eyeControl, and Forescout eyeExtend as PEs Product Guides	エンタープライズ3ビルド4（E3B4） - SDP - PEとしてのF5 BIG-IP、F5 NGINX Plus、Forescout eyeControl、およびForescout eyeExtend製品ガイド
Enterprise 4 Build 4 (E4B4) - SDP, Microsegmentation, and EIG - VMware Workspace ONE Access, VMware Unified Access Gateway, and VMware NSX-T as PEs Product Guides	エンタープライズ 4 ビルド 4（E4B4） - SDP、マイクロセグメンテーション、EIG - PE として VMware Workspace ONE Access、VMware Unified Access Gateway、VMware NSX-T 製品ガイド
Enterprise 1 Build 5 (E1B5) - SASE and Microsegmentation - PAN NGFW and PAN Prisma Access as PEs Product Guides	エンタープライズ1ビルド5（E1B5） - SASEおよびマイクロセグメンテーション - PAN NGFWおよびPAN Prisma AccessをPEとした製品ガイド
Enterprise 2 Build 5 (E2B5) - SDP and SASE - Lookout SSE and Okta Identity Cloud as PEs Product Guides	エンタープライズ2ビルド5（E2B5） - SDPおよびSASE - Lookout SSEおよびOkta Identity CloudをPEとして使用する場合の製品ガイド
Enterprise 3 Build 5 (E3B5) - SDP and SASE - Microsoft Entra Conditional Access (formerly Azure AD Conditional Access) and Microsoft Security Service Edge as PEs Product Guides	Enterprise 3 Build 5（E3B5） - SDPおよびSASE - Microsoft Entra Conditional Access（旧Azure AD Conditional Access）およびMicrosoft Security Service EdgeをPEとして製品ガイドに追加
Enterprise 1 Build 6 (E1B6) - SDP and Microsegmentation - Ivanti Neurons for Zero Trust Access as PEs Product Guides	エンタープライズ1ビルド6（E1B6） - SDPとマイクロセグメンテーション - Ivanti Neurons for Zero Trust Access（PEとしてのIvanti Neurons）製品ガイド
Hardening Information	ハードニング情報
General Findings	一般的な調査結果
Functional Demonstrations	機能デモ
Demonstration Terminology	デモの用語
Use Case A: Discovery and Identification of IDs, Assets, and Data Flows	ユースケースA：ID、資産、データフローの発見と識別
Use Case B: Enterprise-ID Access	ユースケースB：エンタープライズIDアクセス
Use Case C: Collaboration: Federated-ID Access	ユースケースC：コラボレーション： 統合IDアクセス
Use Case D: Other-ID Access	ユースケースD： その他のIDアクセス
Use Case E: Guest: No-ID Access	ユースケースE：ゲスト： IDなしアクセス
Use Case F: Confidence Level	ユースケースF：信頼度
Use Case G: Service-Service Interactions	ユースケースG：サービス間相互作用
Use Case H: Data Level Security Scenarios	ユースケースH：データ・レベルのセキュリティ・シナリオ
Functional Demonstration Result Summaries	機能デモ結果サマリー
Functional Demonstration Results	機能デモ結果
EIG Crawl Phase Demonstration Results	EIGクロール・フェーズの実証結果
EIG Run Phase Demonstration Results	EIG実行フェーズの実証結果
SDP, Microsegmentation, and SASE Phase Demonstration Results	SDP、マイクロセグメンテーション、SASEフェーズの実証結果
Risk and Compliance Management	リスクおよびコンプライアンス・マネジメント
Risks Addressed by the ZTA Reference Architecture	ZTA参照アーキテクチャが対処するリスク
ZTA Security Mapping Context and Terminology	ZTAセキュリティマッピングのコンテキストと用語
Mappings	マッピング
Zero Trust Journey Takeaways	ゼロ・トラスト・ジャーニーの要点
Glossary	用語集
Acronyms	略語

---

● まるちゃんの情報セキュリティ気まぐれ日記

1800-35...

・2023.09.16 NIST SP 1800-35（第2次初期ドラフト） ゼロトラストアーキテクチャの実装　Vol.E リスクとコンプライアンスマネジメント

・2023.08.24 NIST SP 1800-35（第3次初期ドラフト） ゼロトラストアーキテクチャの実装　Vol.D 機能デモ

・2023.07.23 NIST SP 1800-35（第2次初期ドラフト） ゼロトラストアーキテクチャの実装 (Vol. B, C)

・2022.08.10 NIST SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）(Vol. C, D)

・2022.07.09 NIST SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）(Vol. B)

・2022.06.07 NIST SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）(Vol. A)

800-207他

・2023.09.17 NIST SP 800-207A マルチクラウド環境におけるクラウドネイティブ・アプリケーションにおけるアクセス制御のためのゼロトラストアーキテクチャモデル

・2023.04.23 NIST SP 800-207A（ドラフト）マルチクラウド環境におけるクラウドネイティブ・アプリケーションにおけるアクセス制御のためのゼロトラストアーキテクチャモデル

・2022.12.12 カナダ サイバーセキュリティセンター 「ゼロトラスト・セキュリティモデル - ITSAP.10.008」

・2022.05.08 NIST ホワイトペーパー CSWP 20 ゼロトラストアーキテクチャのための計画：連邦政府管理者向け計画策定ガイド

・2022.03.15 米国 CISA 意見募集 ゼロトラスト原則のエンタープライズ・モビリティへの適用 (2022.03.07)

・2021.09.09 米国 CISA 意見募集 ゼロトラスト成熟度モデル

・2021.06.30 金融庁 「ゼロトラストの現状調査と事例分析に関する調査報告書」の公表

・2021.03.01 米国国家安全保障局 (NSA) ゼロトラストセキュリティモデルに関するガイダンス

・2020.12.14 PwC Japanが「NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳」を公表していますね。。。

・2020.08.14 NIST SP 800-207 Zero Trust Architecture

・2020.02.14 NIST SP 800-207(Draft) Zero Trust Architecture (2nd Draft)

米国 NIST SP 800-201 NISTクラウドコンピューティング・フォレンジック参照アーキテクチャ

こんにちは、丸山満彦です。

NISTが、クラウドコンピューティング環境下でのフォレンジックのための参照アーキテクチャを公表しましたね...

クラウド環境下でのフォレンジックの課題の整理と、その対応についてのまとめていますね...

● NIST - ITL

・2024.07.30 NIST Cloud Computing Forensic Reference Architecture: SP 800-201

NIST Cloud Computing Forensic Reference Architecture: SP 800-201	NIST クラウドコンピューティング・フォレンジック参照アーキテクチャ： SP 800-201
The final version of NIST Special Publication (SP) 800-201, NIST Cloud Computing Forensic Reference Architecture, is now available. This document addresses the need to support a cloud system’s forensic readiness, which is the ability to collect digital forensic evidence quickly and effectively with minimal investigation costs by proactively addressing known challenges that could impact such data collection. Forensic readiness supports incident response processes and procedures, secure internal enterprise operations, and criminal justice and civil litigation system functions.	NIST特別刊行物（SP）800-201「NIST Cloud Computing Forensic Reference Architecture」の最終版が公開された。この文書では、クラウドシステムのフォレンジック対応力をサポートする必要性に対処している。フォレンジック対応力とは、データ収集に影響を与える可能性のある既知の課題に積極的に対処することで、最小限の調査コストで迅速かつ効果的にデジタル・フォレンジック証拠を収集する能力のことである。フォレンジック対応能力は、インシデント対応プロセスや手順、安全な企業内オペレーション、刑事司法や民事訴訟システムの機能をサポートする。
The document presents a reference architecture to help users understand the forensic challenges that might exist for an organization’s cloud system based on its architectural capabilities. The architecture identifies challenges that require mitigation strategies and how a forensic investigator would apply those strategies to a particular forensic investigation. The reference architecture is both a methodology and an initial implementation that can be used by cloud system architects, cloud engineers, forensic practitioners, and cloud consumers to analyze and review their cloud computing architectures for forensic readiness.	この文書では、組織のクラウドシステムに存在する可能性のあるフォレンジックの課題を、そのアーキテ クチャ能力に基づいてユーザーが理解できるように、参照アーキテクチャを提示している。アーキテクチャは、緩和戦略を必要とする課題を特定し、フォレンジック調査者が特定のフォレンジック調査にそれらの戦略をどのように適用するかを示している。この参照・アーキテクチャは、クラウド・システム・アーキテクト、クラウド・エンジニア、フォレンジック専門家、クラウド利用者が、クラウド・コンピューティング・アーキテクチャをフォレンジック対応可能かどうかを分析・検討するための方法論であり、初期実装でもある。

報告書

・2024.07.30

NIST SP 800-201 NIST Cloud Computing Forensic Reference Architecture	NIST SP 800-201 NISTクラウドコンピューティング・フォレンジック参照アーキテクチャ
Abstract	概要
This document summarizes the research performed by the NIST Cloud Computing Forensic Science Working Group and presents the NIST Cloud Computing Forensic Reference Architecture (CC FRA or FRA), whose goal is to provide support for a cloud system’s forensic readiness. The CC FRA helps users understand the cloud forensic challenges that might exist for an organization’s cloud system. It identifies challenges that require at least partial mitigation strategies and how a forensic investigator would apply those strategies to a particular forensic investigation. The CC FRA presented here is both a methodology and an initial implementation. Users are encouraged to customize this initial implementation for their specific situations and needs.	本文書は、NISTクラウドコンピューティング・フォレンジック・サイエンス・ワーキンググループが実施した研究を要約し、クラウドシステムのフォレンジック対応性をサポートすることを目的としたNISTクラウドコンピューティング・フォレンジック参照アーキテクチャ（CC FRAまたはFRA）を提示するものである。CC FRAは、ユーザーが組織のクラウドシステムに存在する可能性のあるクラウド・フォレンジックの課題を理解するのに役立つ。それは、少なくとも部分的な緩和戦略を必要とする課題を特定し、フォレンジック調査者が特定のフォレンジック調査にそれらの戦略をどのように適用するかを特定する。ここで紹介するCC FRAは、方法論であると同時に初期実装でもある。ユーザは、この初期実装をそれぞれの状況やニーズに合わせてカスタマイズすることが推奨される。

・[PDF] NIST.SP.800-201

・[DOCX][PDF] 仮訳

クラウドセキュリティアライアンス AIモデルのリスクマネジメントフレームワーク (2024.07.23)

こんにちは、丸山満彦です。

クラウドセキュリティアライアンスが、AIモデルのリスクマネジメントフレームワークを公表していますね....

アプローチ方法が目新しく感じました。参考になるところも多そうです...

これもいずれCSA-Japanが翻訳をしてくれると助かりますね...

● Cloud Security Alliance; CSA

・2024.07.23 AI Model Risk Management Framework

AI Model Risk Management Framework	AIモデルのリスクマネジメントフレームワーク
Sophisticated machine learning (ML) models present exciting opportunities in fields such as predictive maintenance and smart supply chain management. While these ML models hold the potential to unlock significant innovation, their increasing use also introduces inherent risks. Unaddressed model risks can lead to substantial financial losses, regulatory issues, and reputational harm. To address these concerns, we need a proactive approach to risk management.	洗練された機械学習（ML）モデルは、予測保守やスマート・サプライ・チェーン管理などの分野でエキサイティングな機会をもたらしている。これらのMLモデルは、重要なイノベーションを引き出す可能性を秘めている一方で、その利用の拡大には固有のリスクも伴う。未対処のモデル・リスクは、多額の財務的損失、規制上の問題、風評被害につながる可能性がある。これらの懸念に対処するためには、リスクマネジメントへの積極的なアプローチが必要である。
This paper from the CSA AI Technology and Risk Working Group discusses the importance of AI model risk management (MRM). It showcases how model risk management contributes to responsible AI development and deployment and explores the core components of the framework. These components work together to identify and mitigate risks and improve model development through a continuous feedback loop.	CSA AIテクノロジー・リスクワーキンググループの本ペーパーでは、AIモデルリスク・マネジメント（MRM）の重要性について論じている。モデルリスク・マネジメントがいかに責任あるAIの開発と展開に貢献するかを紹介し、フレームワークの中核的な構成要素を探る。これらの構成要素は、継続的なフィードバックループを通じて、リスクを特定・軽減し、モデル開発を改善するために協働する。
Key Takeaways:	主な要点
Benefits of a comprehensive AI risk management framework, including the more responsible use of AI, enhanced transparency, informed decision-making processes, and robust model validation	包括的なAIリスクマネジメントフレームワークのメリット：より責任あるAIの利用、透明性の向上、十分な情報に基づいた意思決定プロセス、強固なモデル検証など。
Elements, benefits, and limitations of the four core components: AI model cards, data sheets, risk cards, and scenario planning	4つのコア・コンポーネントの要素、利点、限界： AIモデルカード、データシート、リスクカード、シナリオプランニング
How to combine the core components into a comprehensive AI risk management framework	コア・コンポーネントを組み合わせて包括的なAIリスクマネジメントのフレームワークを構築する方法

・[PDF]

・[DOCX][PDF] 仮訳

Table of Contents	目次
Acknowledgments	謝辞
Executive Summary	エグゼクティブサマリー
Intended Audience	対象読者
Scope	スコープ
Introduction	序文
The Need and Importance of MRM	MRMの必要性と重要性
The Four Pillars: Model Cards, Data Sheets, Risk Cards, Scenario Planning	4つの柱モデルカード、データシート、リスクカード、シナリオプランニング
Benefits of a Comprehensive Framework	包括的なフレームワークの利点
Core Components	コア・コンポーネント
1. Model Cards: Understanding the Model	1. モデルカード：モデルを理解する
2. Data Sheets: Examining the Training Data	2. データシート：トレーニングデータを検証する
3. Risk Cards: Identifying Potential Issues	3. リスクカード：潜在的な問題の識別
4. Scenario Planning: The “What If” Approach	4. シナリオ・プランニング：「もしも」の場合のアプローチ
Combining Techniques: A Holistic Approach	技術を組み合わせる：ホリスティック・アプローチ
1. Leveraging Model Card Information for Risk Cards	1. リスクカードのモデルカード情報を活用する
2. Using Data Sheets to Enforce Model Understanding	2. データシートを使ってモデルの理解を強制する
3. Using Risk Cards to Inform Scenario Planning	3. リスクカードをシナリオ・プランニングに活用する
4. Scenario Planning Feedback to Risk Management and Development	4. シナリオ・プランニングをリスクマネジメントと開発にフィードバックする
5. AI MRM in Action	5. AI MRMの実際
Conclusion and Future Outlook	結論と今後の展望
References	参考文献
Appendix 1: AI Frameworks, Regulations, and Guidance	附属書1：AIの枠組み、規制、ガイダンス

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
The widespread adoption of sophisticated machine learning (ML) models presents exciting opportunities in fields like predictive maintenance, fraud detection, personalized medicine, autonomous vehicles, and smart supply chain management [1]. While these models hold the potential to unlock significant innovation and drive efficiency, their increasing use also introduces inherent risks, specifically those stemming from the models themselves. Unmitigated model risks can lead to substantial financial losses, regulatory issues, and reputational harm. To address these concerns, we need a proactive approach to risk management. Model Risk Management (MRM) is a key factor for fostering a culture of responsibility and trust in developing, deploying, and using artificial intelligence (AI) and ML models, enabling organizations to harness their full potential while minimizing risks.	高度な機械学習（ML）モデルの広範な採用は、予知保全、不正検知、個別化医療、自律走行車、スマートサプライチェーン管理[1] といった分野にエキサイティングな機会をもたらしている。これらのモデルは、重要なイノベーションを解き放ち、効率化を推進する可能性を秘めている一方で、その利用の拡大には、固有のリスク、特にモデル自体に起因するリスクも導入される。モデル・リスクを未然に防ぐことは、多額の財務的損失、規制上の問題、風評被害につながる可能性がある。これらの懸念に対処するためには、リスクマネジメントへの積極的なアプローチが必要である。モデル・リスク・マネジメント（MRM）は、人工知能（AI）やMLモデルの開発、展開、使用において、責任と信頼の文化を醸成するための重要な要素であり、組織がリスクを最小限に抑えながら、その潜在能力を最大限に活用することを可能にする。
This paper explores the importance of MRM in ensuring the responsible development, deployment, and use of AI models. It caters to a broad audience with a shared interest in this topic, including practitioners directly involved in AI development and business and compliance leaders focusing on AI governance.	本稿では、AIモデルの責任ある開発、展開、利用を確保するためのMRMの重要性を探る。AI開発に直接携わる実務者や、AIガバナンスに焦点を当てるビジネスおよびコンプライアンスのリーダーなど、このトピックに共通の関心を持つ幅広い読者を対象としている。
The paper highlights the inherent risks associated with AI models, such as data biases, factual inaccuracies or irrelevancies (known colloquially as “hallucinations” or “fabrications”[2]), and potential misuse. It emphasizes the need for a proactive approach to ensure a comprehensive MRM framework. This framework is built on four interconnected pillars: Model Cards, Data Sheets, Risk Cards, and Scenario Planning. These pillars work together to identify and mitigate risks and improve model development and risk management through a continuous feedback loop. Specifically, Model Cards and Data Sheets inform risk assessments, and Risk Cards guide Scenario Planning. Scenario Planning refines risk management and model development.	本稿は、データのバイアス、事実の不正確さや関連性のなさ（俗に「幻覚」や「捏造」と呼ばれる）[2] ）、誤用の可能性など、AIモデルに内在するリスクを強調している。これは、包括的なMRMフレームワークを確保するためのプロアクティブアプローチの必要性を強調している。この枠組みは、相互に関連した4つの柱で構築されている：モデルカード、データシート、リスクカード、シナリオプランニングである。これらの柱は、継続的なフィードバックのループを通じて、リスクを特定し、軽減し、モデル開発とリスクマネジメントを改善するために協働する。具体的には、モデルカードとデータシートはリスクアセスメントに情報を提供し、リスクカードはシナリオプランニングの指針となる。シナリオ・プランニングは、リスクマネジメントとモデル開発を改善する。
By implementing this framework, organizations can ensure the safe and beneficial use of ML models with key benefits such as:	このフレームワークを導入することで、組織はMLモデルを安全かつ有益に使用することができる：
●      Enhanced transparency and explainability	●         透明性と説明可能性の向上
●      Proactive risk mitigation and “security by design”	●         プロアクティブなリスク低減と "セキュリティ・バイ・デザイン"
●      Informed decision-making	●         情報に基づいた意思決定
●      Trust-building with stakeholders and regulators	●         ステークホルダーや規制当局との信頼構築
This paper emphasizes the importance of MRM for harnessing the full potential of AI and ML while minimizing risks.	本稿では、リスクを最小限に抑えながらAIやMLの可能性を最大限に活用するためのMRMの重要性を強調する。

[1] McKinsey & Company “The state of AI in 2023: Generative AI’s breakout year”	[1]マッキンゼー・アンド・カンパニー「2023年のAI事情：生成的AIがブレイクする年"
[2] NIST AI 600-1 “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”	[2]NIST AI 600-1 「人工知能リスクマネジメントフレームワーク」：生成的人工知能プロファイル"

クラウドセキュリティアライアンス セキュリティガイダンス バージョン5 (2024.07.15)

こんにちは、丸山満彦です。

クラウドセキュリティアライアンスのセキュリティガイダンスが改訂されてバージョン5になりましたね...

最近の技術動向を踏まえて、改訂されているようです...　CSAジャパンから正式な翻訳版がでるのでしょうかね...

12のドメインはこんな感じ...

Domain 1: Cloud Computing Concepts & Architectures	ドメイン1：クラウドコンピューティングの概念とアーキテクチャ
Domain 2: Cloud Governance and Strategies	ドメイン2：クラウドガバナンスと戦略
Domain 3: Risk, Audit and Compliance	ドメイン3：リスク、監査、コンプライアンス
Domain 4: Organization Management	ドメイン4：組織管理
Domain 5: Identity and Access Management	ドメイン5：アイデンティティとアクセス管理
Domain 6: Security Monitoring	ドメイン6: セキュリティ監視
Domain 7: Infrastructure & Networking	ドメイン7：インフラとネットワーキング
Domain 8: Cloud Workload Security	ドメイン8：クラウドワークロードセキュリティ
Domain 9: Data Security	ドメイン9：データセキュリティ
Domain 10: Application Security	ドメイン10：アプリケーションセキュリティ
Domain 11: Incident Response & Resilience	ドメイン11：インシデントレスポンスとレジリエンス
Domain 12: Related Technologies & Strategies	ドメイン12：関連技術と戦略

● Cloud Security Alliance; CSA

・2024.07.15 CSA Security Guidance for Critical Areas of Focus in Cloud Computing

CSA Security Guidance for Critical Areas of Focus in Cloud Computing	クラウド・コンピューティングにおける重要分野の CSA セキュリティガイダンス
Read the best practices recommended by security experts for staying secure in the cloud.	クラウドでセキュリティを維持するために、セキュリティの専門家が推奨するベストプラクティスを読む。
Cloud computing offers tremendous benefits in agility, resiliency, economy, and security. However, the security benefits only appear if you adopt cloud-native models and adjust your architectures and security controls to align with the capabilities of cloud platforms.	クラウド・コンピューティングは、俊敏性、レジリエンス、経済性、セキュリティの面で非常に大きなメリットをもたらす。しかし、セキュリティ上のメリットは、クラウドネイティブモデルを採用し、クラウドプラットフォームの機能に合わせてアーキテクチャとセキュリティ制御を調整した場合にのみ現れる。
The Cloud Security Alliance’s Security Guidance for Critical Areas of Focus in Cloud Computing outlines cloud security best practices that have been developed and refined by CSA's extensive community of experts. Emphasizing the practical application of security principles in real-world scenarios, this comprehensive guide equips professionals with actionable skills. Learn how to adopt and implement a cloud-native approach that addresses modern challenges in complex cloud environments.	クラウド・セキュリティ・アライアンスの「クラウド・コンピューティングにおける重要分野のセキュリティガイダンス」は、CSAの広範な専門家コミュニティによって開発・改良されたクラウド・セキュリティのベスト・プラクティスの要約を示している。実世界のシナリオにおけるセキュリティ原則の実践的な適用に重点を置いたこの包括的なガイドは、専門家に実用的なスキルを提供する。複雑なクラウド環境における最新の課題に対処するクラウドネイティブアプローチを採用し、実装する方法を学ぶことができる。
All NEW content with Security Guidance v5! Version 5 provides a comprehensive understanding of the essential security measures needed in today's cloud landscape. Completely revamped from v4, the v5 body of knowledge includes the latest in cloud architecture, cloud native security, workloads, virtual networking, data security, DevSecOps, Zero Trust, Generative AI, and much more. V5 also includes vital information about risk management, achieving compliance, optimizing organizational cloud security strategies, and understanding the shared responsibility model. Security Guidance v4 is still available for download here.	セキュリティガイダンスv5.の内容を一新！バージョン5では、今日のクラウド環境で必要不可欠なセキュリティ対策を包括的に理解できる。v4から完全に刷新されたv5の知識体系には、クラウドアーキテクチャ、クラウドネイティブセキュリティ、ワークロード、仮想ネットワーキング、データセキュリティ、DevSecOps、ゼロトラスト、生成的AIなどの最新情報が含まれている。V5には、リスクマネジメント戦略、コンプライアンスの達成、組織のクラウドセキュリティ戦略の最適化、責任共有モデルの理解などに関する重要な情報も含まれている。セキュリティガイダンスv4はまだここからダウンロードできる。

Domain 1: Cloud Computing Concepts & Architectures	ドメイン1：クラウドコンピューティングの概念とアーキテクチャ
This domain lays the foundational framework for the Cloud Security Alliance (CSA) Security Guidance. It covers the definitions, baseline terminologies, controls, deployment, and architectural models crucial for understanding cloud computing. Learners will explore the transformative impact of cloud computing and its benefits when properly understood and adopted, emphasizing the importance of cloud-native capabilities and services.	この領域は、クラウド・セキュリティ・アライアンス（CSA）のセキュリティ・ガイダンスの基礎となる枠組みを構築する。クラウドコンピューティングを理解するために重要な定義、基本的な用語、制御、展開、アーキテクチャーモデルをカバーする。学習者は、クラウドコンピューティングがもたらす変革的な影響と、クラウドネイティブの機能とサービスの重要性を強調しながら、適切に理解し、採用した場合のその利点を探求する。
Domain 2: Cloud Governance and Strategies	ドメイン2：クラウドガバナンスと戦略
Focusing on the governance framework of policies, procedures, and controls, this domain ensures transparency and accountability within cloud environments. It addresses strategic guidance, risk management, compliance monitoring, and budget allocation. Learners will understand key governance frameworks and regulations such as ISO/IEC 38500:2024, ISACA COBIT, ISO/IEC 27014:2020, and GDPR.	ポリシー、手順、コントロールのガバナンスフレームワークに焦点を当て、クラウド環境における透明性と説明責任を確保する。戦略的ガイダンス、リスクマネジメント、コンプライアンス監視、予算配分を扱う。学習者は、ISO/IEC 38500:2024、ISACA COBIT、ISO/IEC 27014:2020、GDPRなどの主要なガバナンスフレームワークと規制を理解する。
Domain 3: Risk, Audit and Compliance	ドメイン3：リスク、監査、コンプライアンス
This domain delves into evaluating cloud service providers (CSPs), establishing cloud risk registries, and implementing approval processes. It covers compliance and auditing, including compliance inheritance, and introduces tools and technologies for governance, risk, and compliance (GRC) processes. Emphasis is placed on robust risk management frameworks, compliance with regulatory standards, and leveraging tools and technologies for effective governance.	この領域では、クラウドサービスプロバイダ（CSP）の評価、クラウドリスク登録の確立、承認プロセスの実施について掘り下げる。コンプライアンスの継承を含むコンプライアンスと監査をカバーし、ガバナンス、リスク、コンプライアンス（GRC）プロセスのためのツールとテクノロジーを紹介する。強固なリスクマネジメントフレームワーク、規制標準への準拠、効果的なガバナンスのためのツールとテクノロジーの活用に重点を置いている。
Domain 4: Organization Management	ドメイン4：組織管理
Learners will explore the overall management of cloud environments, including organizing and validating the security assurance of CSPs and securing individual cloud service deployments. This domain highlights the importance of tenancy in a multitenant environment, key controls for managing hierarchy, and best practices for managing multiple cloud deployments. It also covers organization-level security management nuances and strategies for hybrid and multi-cloud environments.	学習者は、CSPのセキュリティ保証の組織化と検証、個々のクラウド・サービスのデプロイメントの安全確保など、クラウド環境の全体的な管理について探求する。この領域では、マルチテナント環境におけるテナントの重要性、階層を管理するための主要なコントロール、複数のクラウド配備を管理するためのベストプラクティスを取り上げる。また、ハイブリッド環境とマルチクラウド環境における組織レベルのセキュリティ管理のニュアンスと戦略についても取り上げる。
Domain 5: Identity and Access Management	ドメイン5：アイデンティティとアクセス管理
This domain ensures that only authorized identities have the right access to resources. It covers fundamental IAM concepts, the characteristics and challenges of IAM in the cloud, and effective management strategies. Key topics include multi-factor authentication (MFA), just-in-time (JIT) access, identity federation, policy-based access control (PBAC), and secure identity providers (IdPs).	このドメインでは、認可されたIDのみがリソースに正しくアクセスできるようにする。基本的なIAMの概念、クラウドにおけるIAMの特徴と課題、効果的な管理戦略について説明する。主なトピックとして、多要素認証（MFA）、ジャストインタイム（JIT）アクセス、IDフェデレーション、ポリシーベースアクセス管理（PBAC）、安全なIDプロバイダ（IdP）などがある。
Domain 6: Security Monitoring	ドメイン6: セキュリティ監視
Focusing on the distinct aspects of security monitoring in cloud environments, this domain covers cloud telemetry, management plane logs, service and resource logs, and advanced monitoring tools. Learners will explore hybrid and multi-cloud setups, the role of logs, events, and configuration detection in security monitoring, and the use of Generative Artificial Intelligence (GenAI) for enhancing cloud security.	クラウド環境におけるセキュリティモニタリングの明確な側面に焦点を当て、クラウドテレメトリー、管理プレーンのログ、サービスとリソースのログ、および高度なモニタリングツールをカバーする。学習者は、ハイブリッドクラウドとマルチクラウドのセットアップ、セキュリティ監視におけるログ、イベント、構成検知の役割、クラウドセキュリティを強化するための生成的人工知能（GenAI）の使用について探求する。
Domain 7: Infrastructure & Networking	ドメイン7：インフラとネットワーキング
This domain covers managing the overall infrastructure footprint and network security. Key topics include Software Defined Networks (SDN), security groups, container networking, connectivity options, Zero Trust Architectures (ZTA), and Secure Access Service Edge (SASE). Emphasis is placed on implementing secure architectures, integrating security early in the development lifecycle, and maintaining vigilant monitoring.	この領域では、インフラ全体のフットプリントとネットワーク・セキュリティを管理する。主なトピックとして、SDN（Software Defined Networks）、セキュリティグループ、コンテナネットワーキング、接続オプション、ZTA（Zero Trust Architectures）、SASE（Secure Access Service Edge）などがある。セキュアなアーキテクチャの実装、開発ライフサイクルの早い段階でのセキュリティの統合、警戒監視の維持に重点を置く。
Domain 8: Cloud Workload Security	ドメイン8：クラウドワークロードセキュリティ
Learners will explore securing various cloud workloads, including virtual machines (VMs), containers, serverless functions (FaaS), AI, and platform as a service (PaaS). The domain covers practices such as VM image security automation, enforcing least privilege, regular vulnerability assessments, customizing container configurations, securing API endpoints, managing secrets, adversarial training for AI workloads, and regular security audits for PaaS environments.	学習者は、仮想マシン（VM）、コンテナ、サーバーレス機能（FaaS）、AI、Platform as a Service（PaaS）など、さまざまなクラウドワークロードのセキュリティを探求する。この領域では、VMイメージのセキュリティ自動化、最小特権の強制、定期的な脆弱性アセスメント、コンテナ構成のカスタマイズ、APIエンドポイントのセキュリティ確保、シークレットの管理、AIワークロードの敵対的トレーニング、PaaS環境の定期的なセキュリティ監査などのプラクティスをカバーする。
Domain 9: Data Security	ドメイン9：データセキュリティ
This domain addresses the complexities of data security within cloud environments, emphasizing the need for resilient practices to safeguard information. It explores strategies, tools, and practices essential for protecting data in-transit and at rest. Key topics include data classification, cloud storage types, advanced encryption methods, and access controls. The domain also provides a primer on cloud storage and examines key concepts and technologies shaping the future of data security. Learning objectives include understanding data security fundamentals, data classifications and states, cloud storage security measures, key management, protecting computing workloads, posture management, and advanced data security concepts.	この領域では、クラウド環境におけるデータセキュリティの複雑さを取り上げ、情報を保護するためのレジリエンスの必要性を強調する。この領域では、転送中および静止中のデータを保護するために不可欠な戦略、ツール、およびプラクティスを探求する。主なトピックとしては、データ格付、クラウドストレージの種類、高度な暗号化手法、アクセス管理などがある。また、クラウドストレージの入門書も提供し、データセキュリティの未来を形作る重要な概念や技術についても検討する。学習目標には、データセキュリティの基礎、データ格付と状態、クラウドストレージのセキュリティ対策、鍵管理、コンピューティングワークロードの保護、姿勢管理、高度なデータセキュリティの概念などを理解することが含まれる。
Domain 10: Application Security	ドメイン10：アプリケーションセキュリティ
This domain focuses on the practice of using security controls to protect computer applications from external threats. It covers the entire lifecycle of application security, from early design and threat modeling to maintaining and defending production applications. Cloud computing advancements necessitate stable, scalable, and secure progress in application development. Key topics include microservices, API exposure, DevOps approaches, shared responsibility models, third-party libraries, security features from cloud providers, programmable infrastructure, and stateless architectures. Emphasis is placed on secure architecture, IAM, DevSecOps, continuous monitoring, threat modeling, and automated security testing.	この領域では、コンピュータアプリケーションを外部の脅威から保護するためのセキュリティ対策の実践に焦点を当てる。初期の設計や脅威のモデル化から本番アプリケーションの保守・防御まで、アプリケーションセキュリティのライフサイクル全体をカバーする。クラウド・コンピューティングの進歩は、アプリケーション開発における安定性、拡張性、安全性の向上を必要とする。主なトピックとしては、マイクロサービス、APIエクスポージャー、DevOpsアプローチ、責任共有モデル、サードパーティ・ライブラリ、クラウドプロバイダのセキュリティ機能、プログラマブル・インフラストラクチャ、ステートレス・アーキテクチャなどがある。セキュアなアーキテクチャ、IAM、DevSecOps、セキュリティの継続的なモニタリング、脅威モデリング、自動化されたセキュリティテストに重点を置く。
Domain 11: Incident Response & Resilience	ドメイン11：インシデントレスポンスとレジリエンス
This domain covers critical aspects of incident response (IR) in cloud environments, addressing unique challenges introduced by cloud adaptation. It provides best practices for cloud incident response (CIR) and resilience, organized according to the IR Lifecycle described in the CSA Cloud Incident Response Framework and NIST SP 800-61 Rev. 2. Key frameworks include ISO/IEC 27035 and ENISA Strategies for IR. Emphasis is placed on preparation, detection and analysis, containment, eradication and recovery, and post-incident analysis. Effective communication and information sharing between CSPs and CSCs, internal IR teams, law enforcement, and key partners are crucial for strengthening CIR capabilities.	この領域では、クラウド環境におけるインシデントレスポンス（IR）の重要な側面をカバーし、クラウドの適応によってもたらされる独自の課題に対処する。クラウドインシデントレスポンス（CIR）とレジリエンスのベストプラクティスを提供し、CSAクラウドインシデントレスポンスフレームワークとNIST SP 800-61 Rev.2に記載されているIRライフサイクルに沿って整理している。主要なフレームワークには、ISO/IEC 27035 および ENISA Strategies for IR が含まれる。準備、検知と分析、封じ込め、根絶と復旧、インシデント発生後の分析に重点が置かれている。CIR 能力の強化には、CSP と CSC、社内の IR チーム、法執行機関、および主要なパートナ ー間の効果的なコミュニケーションと情報共有が不可欠である。
Domain 12: Related Technologies & Strategies	ドメイン12：関連技術と戦略
This domain explores various angles for analyzing cloud security challenges using perspectives (lenses) and processes. It covers critical security areas such as organization management, IAM, security monitoring, network, workload, application, and data. Key technologies and strategies include Zero Trust (ZT), Artificial Intelligence (AI), and Threat and Vulnerability Management (TVM). Practices include continuous verification of users and devices, least privilege principles, multi-factor authentication, micro-segmentation, encryption, threat detection, access control, policy enforcement, machine learning for anomaly detection, risk management, CSPM, and continuous monitoring. Integrating AI into TVM enhances threat detection and response, maintaining a robust security posture.	この領域では、視点（レンズ）とプロセスを用いてクラウドセキュリティの課題を分析するための様々な角度から検討する。組織管理、IAM、セキュリティ監視、ネットワーク、ワークロード、アプリケーション、データなどの重要なセキュリティ分野をカバーする。主要な技術と戦略には、ゼロ・トラスト（ZT）、人工知能（AI）、脅威・脆弱性管理（TVM）などがある。実践には、ユーザーとデバイスの継続的検証、最小特権原則、多要素認証、マイクロセグメンテーション、暗号化、脅威検知、アクセス管理、ポリシー実施、異常検知のための機械学習、リスクマネジメント、CSPM、継続的モニタリングなどが含まれる。AIをTVMに統合することで、脅威検知と対応が強化され、強固なセキュリティ態勢が維持される。

・2024.07.15 Security Guidance for Critical Areas of Focus in Cloud Computing v5

Security Guidance for Critical Areas of Focus in Cloud Computing v5	クラウド・コンピューティングにおける重要分野のセキュリティガイダンス v5
Cloud computing has firmly cemented its place as the foundation of the information security industry. The Cloud Security Alliance’s Security Guidance v5 is professionals' go-to resource for understanding modern cloud components and cloud security best practices. Balancing foundational knowledge with in-depth exploration of specialized topics across 12 domains, this essential document equips professionals with actionable skills and enables them to effectively address modern cloud security challenges.	クラウド・コンピューティングは、情報セキュリティ業界の基盤としての地位を確固たるものにしている。クラウド・セキュリティ・アライアンスのセキュリティガイダンスv5は、最新のクラウド・コンポーネントとクラウド・セキュリティのベスト・プラクティスを理解するための、専門家にとって最適なリソースである。基礎的な知識と12のドメインにわたる専門的なトピックの詳細な探求のバランスが取れたこの重要な文書は、専門家に実用的なスキルを身につけさせ、最新のクラウドセキュリティの課題に効果的に対処できるようにする。
This fifth version is built on previous iterations of the Security Guidance and is enhanced with a decade’s worth of insights about the skills needed to be successful in today's complex environments. Additions include the latest developments in Zero Trust, Generative AI, CI/CD, Security Monitoring and Operations, Resilience, Cloud Telemetry and Security Analytics, and Data Lakes. Version 5 also has reduced coverage of Laws and Regulations and has removed the Security-as-a-Service domain.	第5版となる本書は、これまでの「セキュリティガイダンス」をベースに、今日の複雑な環境で成功するために必要なスキルに関する10年分の知見を盛り込んだ。ゼロ・トラスト、生成的AI、CI/CD、セキュリティモニタリングと運用、レジリエンス、クラウド・テレメトリーとセキュリティ分析、データレイクなどの最新動向が追加されている。また、バージョン5では、法規制の範囲が縮小され、Security-as-a-Serviceのドメインが削除された。
Note that Security Guidance is no longer the primary study material for the Certificate of Cloud Security Knowledge (CCSK). Access the CCSK v5 Study Guide here. Security Guidance v5 provides a more comprehensive understanding of the 12 domains, but is not required to pass the CCSK v5 exam.	セキュリティガイダンスは、Certificate of Cloud Security Knowledge (CCSK)の主要な学習教材ではなくなっている。CCSK v5 Study Guideはこちらから。セキュリティガイダンスv5は、12のドメインをより包括的に理解するためのプロバイダであるが、CCSK v5試験に合格するために必要なものではない。
Cloud Security Domains Covered:	クラウド・セキュリティ・ドメイン
・Cloud Computing Concepts and Architectures	・クラウド・コンピューティングの概念とアーキテクチャ
・Cloud Governance	・クラウドガバナンス
・Risk, Audit, and Compliance	・リスク、監査、コンプライアンス
・Organization Management	・組織管理
・Identity and Access Management	・アイデンティティとアクセス管理
・Security Monitoring	・セキュリティ監視
・Infrastructure and Networking	・インフラとネットワーキング
・Cloud Workload Security	・クラウドワークロードセキュリティ
・Data Security	・データセキュリティ
・Application Security	・アプリケーションセキュリティ
・Incident Response and Resilience	・インシデントレスポンスとレジリエンス
・Related Technologies and Strategies	・関連技術と戦略

・[PDF]

目次...

Introduction to Security Guidance v5	セキュリティガイダンス v5 序文
Domain 1: Cloud Computing Concepts & Architectures	ドメイン1：クラウドコンピューティングの概念とアーキテクチャ
Learning Objectives	学習目標
1.1 Defining Cloud Computing	1.1 クラウドコンピューティングの定義
1.2 Cloud Computing Models	1.2 クラウドコンピューティングモデル
1.3 Reference & Architecture Models	1.3 参照モデルとアーキテクチャモデル
1.4 Cloud Security Scope, Responsibilities, & Models	1.4 クラウドセキュリティの範囲、責任、およびモデル
Summary & Areas of Critical Focus - Governance & Operations	要約と重点分野 - ガバナンスと運用
Domain 2: Cloud Governance and Strategies	ドメイン2：クラウドガバナンスと戦略
Learning Objectives	学習目標
2.1 Cloud Governance	2.1 クラウドガバナンス
2.2 Effective Cloud Governance	2.2 効果的なクラウドガバナンス
2.3 The Governance Hierarchy	2.3 ガバナンスの階層構造
2.4 Key Strategies & Concepts	2.4 主要な戦略と概念
Summary	要約
Domain 3: Risk, Audit and Compliance	ドメイン3：リスク、監査、コンプライアンス
3.1. Cloud Risk Management	3.1. クラウドのリスクマネジメント
3.2 Compliance & Audit	3.2 コンプライアンスと監査
3.3 Governance, Risk, and Compliance: Tools & Technologies	3.3 ガバナンス、リスク、コンプライアンス ツールとテクノロジー
Summary	要約
Domain 4: Organization Management	ドメイン4：組織管理
Introduction	序文
Learning Objectives	学習目標
4.1 Organization Hierarchy Models	4.1 組織階層モデル
4.2 Managing Organization-Level Security	4.2 組織レベルのセキュリティを管理する
4.3 Considerations for Hybrid & Multi-Cloud Deployments	4.3 ハイブリッドクラウドとマルチクラウドの導入に関する考慮事項
Summary	要約
Recommendations	推奨事項
Additional Resources	その他のリソース
Domain 5: Identity and Access Management	ドメイン5：アイデンティティとアクセス管理
Introduction	序文
Learning Objectives	学習目標
5.1 How IAM is Different in the Cloud	5.1 クラウドにおけるIAMの違い
5.1 Fundamental Terms	5.1 基本用語
5.2 Federation	5.2 フェデレーション
5.3 Strong Authentication & Authorization	5.3 強力な認証と認可
5.4 IAM Policy Types for Public Cloud	5.4 パブリッククラウドのIAMポリシータイプ
5.5 Least Privilege & Automation	5.5 最小特権と自動化
Summary	要約
Domain 6: Security Monitoring	ドメイン6: セキュリティ監視
Introduction	序文
Learning Objectives	学習目標
6.1 Cloud Monitoring	6.1 クラウド監視
6.2 Cloud Telemetry Sources	6.2 クラウドテレメトリソース
6.3 Collection Architectures	6.3 コレクションアーキテクチャ
6.4 Detection & Security Analytics	6.4 検知とセキュリティ分析
6.5 Generative AI for Security Monitoring	6.5 セキュリティ監視のための生成的AI
Summary	要約
Domain 7: Infrastructure & Networking	ドメイン7：インフラとネットワーキング
Introduction	序文
Learning Objectives	学習目標
7.1 Cloud Infrastructure Security	7.1 クラウドインフラのセキュリティ
7.2 Cloud Network Fundamentals	7.2 クラウドネットワークの基礎
7.3 Cloud Connectivity	7.3 クラウド接続性
7.4 Zero Trust & Secure Access Service Edge	7.4 ゼロトラストとセキュアアクセスサービスエッジ
Summary	要約
Domain 8: Cloud Workload Security	ドメイン8：クラウドワークロードセキュリティ
Introduction	序文
Learning Objectives	学習目標
8.1 Introduction to Cloud Workload Security	8.1 クラウドワークロードセキュリティの序文
8.2 Virtual Machines	8.2 仮想マシン
8.3 Securing Containers	8.3 コンテナのセキュリティ
8.4 PaaS Security	8.4 PaaSのセキュリティ
8.5 Securing Serverless or Function as a Service	8.5 サーバーレスまたはサービスとしての機能のセキュリティ確保
8.6 AI Workloads	8.6 AIワークロード
Summary	要約
Domain 9: Data Security	ドメイン9：データセキュリティ
Introduction	序文
Learning Objectives	学習目標
9.1 Data Classification & Storage Types	9.1 データ分類とストレージタイプ
9.2 Securing Specific Cloud Workload Types	9.2 特定のクラウドワークロードタイプの保護
9.3 Securing Specific Storage Types	9.3 特定のストレージタイプの保護
Summary	要約
Domain 10: Application Security	ドメイン10：アプリケーションセキュリティ
Introduction	序文
Learning Objectives	学習目標
10.1 Secure Development Lifecycle	10.1 安全な開発ライフサイクル
10.2 Secure Cloud Applications Architecture	10.2 安全なクラウドアプリケーションアーキテクチャ
10.3 Identity & Access Management Application Security	10.3 IDとアクセス管理アプリケーションセキュリティ
10.4 DevSecOps: CI/CD & Application Testing	10.4 DevSecOps：CI/CDとアプリケーションテスト
10.5 Serverless & Containerized Application Considerations	10.5 サーバーレスとコンテナ化アプリケーションの考慮事項
Summary	要約
Domain 11: Incident Response & Resilience	ドメイン11：インシデントレスポンスとレジリエンス
Introduction	序文
Learning Objectives	学習目標
11.1 Incident Response	11.1 インシデントレスポンス
11.2 Preparation	11.2 準備
11.3 Detection & Analysis	11.3 検知と分析
11.4 Containment, Eradication & Recovery	11.4 封じ込め、根絶、復旧
11.5 Post-Incident Analysis	11.5 インシデント発生後の分析
11.6 Resilience	11.6 レジリエンス
Summary	要約
Domain 12: Related Technologies & Strategies	ドメイン12：関連技術と戦略
Introduction	序文
Learning Objectives	学習目標
12.1 Zero Trust	12.1 信頼ゼロ
12.2 Artificial Intelligence	12.2 人工知能
12.3 Threat & Vulnerability Management	12.3 脅威と脆弱性の管理
Summary	要約

・[PDF] 

米国 NIST SP 800-233（初期公開ドラフト） クラウドネイティブアプリケーションのサービスメッシュプロキシモデル (2024.07.19)

こんにちは、丸山満彦です。

NISTが、クラウドネイティブアプリケーションのサービスメッシュプロキシモデルについての初期公開ドラフトを公表し、意見募集をしていますね...

これからはこっちですかね...

● NIST - ITL

・2024.07.19 NIST SP 800-233 (Initial Public Draft) Service Mesh Proxy Models for Cloud-Native Applications

NIST SP 800-233 (Initial Public Draft) Service Mesh Proxy Models for Cloud-Native Applications	NIST SP 800-233（初期公開ドラフト） クラウドネイティブアプリケーションのサービスメッシュプロキシモデル
Announcement	発表
The service mesh has become the de facto application services infrastructure for cloud-native applications. It enables an application’s runtime functions (e.g., network connectivity, access control, etc.) through proxies that form the data plane of the service mesh. Different proxy models or data plane architectures have emerged, depending on the distribution of the network layer functions (i.e., L4 and L7) and the granularity of association of the proxies to individual services/computing nodes.	サービスメッシュは、クラウドネイティブ・アプリケーションのための事実上のアプリケーション・サービス・インフラとなっている。サービスメッシュは、サービスメッシュのデータプレーンを形成するプロキシを通じて、アプリケーションのランタイム機能（ネットワーク接続、アクセス管理など）を実現する。ネットワークレイヤー機能（L4とL7）の配分と、個々のサービス／コンピューティングノードへのプロキシの関連付けの粒度に応じて、異なるプロキシモデルやデータプレーンアーキテクチャが出現している。
The purposes of this document are two-fold:	この文書の目的は2つある：
Develop a threat profile for each of the data plane architectures by considering a set of potential threats to various proxy functions and assign scores to the impacts and likelihoods of their exploits.	様々なプロキシ機能に対する潜在的な脅威のセットを考慮することによって、 各データプレーンアーキテクチャの脅威プロファイルを作成し、その悪用の 影響と可能性にスコアを割り当てる。
Analyze the service mesh capabilities that are required for each class of cloud-native applications with different risk profiles (i.e., low, medium, and high) and provide recommendations for the data plane architectures or proxy models that are appropriate and applicable for each class.	異なるリスクプロファイル（低、中、高）を持つクラウドネイティブアプリケーションの各クラスに必要なサービスメッシュ機能を分析し、各クラスに適切で適用可能なデータプレーンアーキテクチャまたはプロキシモデルの推奨を提供する。
Abstract	概要
The service mesh has become the de-facto application services infrastructure for cloud-native applications. It enables the various runtime functions (network connectivity, access control etc.) of an application through proxies which thus form the data plane of the service mesh. Depending upon the distribution of the network layer functions (L4 & L7) and the granularity of association of the proxies to individual services/computing nodes, different proxy models or data plane architectures have emerged. The purpose of this document is to develop a threat profile for each of the data plane architectures through a detailed threat analysis in order to make recommendations for their applicability (usage) for cloud-native applications with different security risk profiles.	サービスメッシュは、クラウドネイティブアプリケーションの事実上のアプリケーションサービスインフラとなっている。サービスメッシュは、サービスメッシュのデータプレーンを形成するプロキシを通じて、アプリケーションの様々な実行時機能（ネットワーク接続、アクセス管理など）を実現する。ネットワークレイヤー機能（L4とL7）の配分と、個々のサービス／コンピューティングノードへのプロキシの関連付けの粒度に応じて、異なるプロキシモデルやデータプレーンアーキテクチャが出現している。この文書の目的は、詳細な脅威分析を通じて、それぞれのデータプレーンアーキテクチャの脅威プロ ファイルを作成し、異なるセキュリティリスクプロファイルを持つクラウドネイティブアプリケーショ ンに適用（使用）するための推奨を行うことである。

・[PDF] NIST.SP.800-233.ipd

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
Run-time services for Cloud-native applications, consisting of multiple loosely coupled components called microservices, are sometimes provided through a centralized infrastructure called a service mesh. These services include secure communication, service discovery, resiliency, and authorization of application communication. These services are mainly provided through Proxies that form the data plane of the service mesh, the layer that handles application traffic at runtime and enforces policy.	マイクロサービスと呼ばれる複数の疎結合コンポーネントで構成されるクラウドネイティブ・アプリケーションのランタイム・サービスは、サービス・メッシュと呼ばれる集中型インフラを通じてプロバイダされることがある。これらのサービスには、セキュアなコミュニケーション、サービス・ディスカバリ、レジリエンス、アプリケーション・コミュニケーションの認可などが含まれる。これらのサービスは主に、サービスメッシュのデータプレーンを形成するプロキシ（実行時にアプリケーションのトラフィックを処理し、ポリシーを実施するレイヤー）を通じて提供される。
The functions that the proxies provide can be broadly categorized into two groups, based on the OSI model’s network layer to which those functions pertain to. These groups are: Layer 4 (“L4”) and Layer 7 (“L7”). In majority of deployments of service mesh in production environments today, all proxy functions (providing services in both L4 and L7 layers) are packed into a single proxy that is assigned to a single microservice. This service mesh proxy model is called a sidecar proxy model since the proxy is not only associated with a single service but is implemented to execute in the same network space as the service.	プロキシが提供する機能は、OSIモデルのネットワークレイヤーに基づき、2つのグループに大別できる。これらのグループは以下の通りである： レイヤー4（「L4」）とレイヤー7（「L7」）である。今日、本番環境におけるサービスメッシュのデプロイメントの大部分 では、すべてのプロキシ機能（L4とL7の両方のレイヤーのサービスを提供する）は、単一のマイクロサービスに割り当てられる単一のプロキシにまとめられる。このサービスメッシュのプロキシモデルは、プロキシが一つのサービ スに関連付けられるだけでなく、サービスと同じネットワーク空間で実行されるように実装されるので、サイドカープロキシモデルと呼ばれる。
However, performance and resource considerations have led to the exploration of alternate proxy models which involve not only splitting up of L4 and L7 functions into different proxies (instead of a single proxy) but also the association or assignments of these proxies to either a single service or a group of services, thus enabling the proxies to be implemented at different locations - at the granularity of a node rather than at the level of services. Though different models are theoretically possible, we consider only those service mesh proxy models in the data plane implementation of commonly used service mesh offerings, at different stages.	しかしながら、パフォーマンスとリソースを考慮した結果、L4とL7機能を(単一 のプロキシの代わりに)異なるプロキシに分割するだけでなく、これらのプロキシを単一 のサービスまたはサービスグループのいずれかに関連付けたり割り当てたりするこ とで、プロキシを異なる場所(サービスレベルではなくノードの粒度)で実装することを 可能にする、別のプロキシモデルの探究につながった。理論的には様々なモデルが可能であるが、ここでは、一般的に使用され ているサービスメッシュのデータプレーンの実装において、様々な段階のサービスメッシュプロキシモデルのみを考察する。
We then consider a set of potential/likely threats to various proxy functions. Each of the threats may result in different types of exploits in different proxy models. This variation is due to several factors such as: attack surface (communication patterns to which a particular proxy is exposed), number of clients (services) served and OSI layer functions they provide (e.g., L7 functions are more complicated and likely to have more vulnerabilities than L4 functions).  The two main contributions of this document are as follows:	次に、様々なプロキシ機能に対する潜在的/可能性のある一連の脅 威について考察する。各脅威は、異なるプロキシモデルにおいて異なるタイプのエクスプロイトをもたらすかもしれない。この変化は、攻撃対象領域(特定のプロキシがさらされるコミュニケーションパターン)、提供されるクライアント(サービス)の数、お よびそれらが提供するOSIレイヤーの機能(例えば、L7機能はL4機 能よりも複雑で、より多くの脆弱性を持つ可能性が高い)などのいくつかの要因によるものである。 本文書の2つの主要な貢献は以下のとおりである：
1. The nature of exploits possible for each threat in each of the proxy models are characterized by assigning scores to the impact and likelihood of each of these threats in each of the proxy models or architectural patterns resulting in a threat profile associated with each architectural pattern or proxy model of service mesh.	1. 各プロキシモデルにおける各脅威の影響度と可能性にスコアを割り当てることで、各プロキシモデルにおいて可能な悪用の性質を特徴づけ、その結果、サービスメッシュの各アーキテクチャパターンまたはプロキシモデルに関連付けられた脅威プロファイルを作成する。
2. Each threat profile inherently has a built-in set of security tradeoffs at an architectural level. The implications of these tradeoffs in meeting the requirements associated with security risk profile of different cloud-native applications are analyzed to make a broad set of recommendations towards specific architectural patterns that are appropriate for applications with different security risk profiles.	2. 各脅威プロファイルには、アーキテクチャレベルでのセキュリティトレードオ フのセットが本質的に組み込まれている。さまざまなクラウドネイティブアプリケーションのセキュリ ティリスクプロファイルに関連する要件を満たす上で、これらのトレードオフが持つ意味を分析し、さまざまなセキュリティリスクプロファイルを持つアプリケーションに適した特定のアーキテクチャパターンに向 けて、幅広い推奨を行う。

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. L4 and L7 Functions of Proxies	1.1. プロキシのL4とL7の機能
1.2. Objective & Target Audience	1.2. 目的と対象読者
1.3. Relationship to Other NIST Documents	1.3. 他のNIST文書との関係
1.4. Document Structure	1.4. 文書の構造
2. Typical Service Mesh Data Plane Capabilities and Associated Proxy Functions	2. 典型的なサービスメッシュのデータプレーン機能と関連するプロキシ機能
3. Proxy Models (Data plane Architectures) in Service Mesh Implementations	3. サービスメッシュ実装におけるプロキシモデル（データプレーンアーキテクチャ
3.1. L4 and L7 Proxy per Service Instance - Sidecar Model (DPA-1)	3.1. サービスインスタンスごとのL4およびL7プロキシ - サイドカーモデル（DPA-1）
3.2. Shared L4 - L7 per Service Model (DPA-2)	3.2. サービスごとの共有L4-L7モデル（DPA-2）
3.3. Shared L4 and L7 Model (DPA-3)	3.3. 共有L4およびL7モデル（DPA-3）
3.4. L4 and L7 Part of the Application Model (DPA-4)	3.4. アプリケーションモデルのL4とL7部分（DPA-4）
4. Data Plane Architectures Threat Scenarios and Analysis Methodology	4. データプレーンアーキテクチャ 脅威シナリオと分析手法
4.1. Threat analysis Methodology	4.1. 脅威分析手法
5. Detailed Threat Analysis for Data Plane Architectures	5. データプレーンアーキテクチャの詳細脅威分析
5.1. Threat Analysis for L4 and L7 Proxy per Service Instance - Sidecar Model (DPA-1)	5.1. サービスインスタンスごとの L4 および L7 プロキシの脅威分析 - サイドカーモデル（DPA-1）
5.1.1. Compromised L4 Proxy (TR-1)	5.1.1. 侵害された L4 プロキシ(TR-1)
5.1.2. Compromised Application Container (TR-2)	5.1.2. 侵害されたアプリケーションコンテナ(TR-2)
5.1.3. Compromise of Business Data (TR-3)	5.1.3. 業務データの漏洩 (TR-3)
5.1.4. Compromised L7 Proxy (TR-4)	5.1.4. 侵害された L7 プロキシ(TR-4)
5.1.5. Compromise of Shared L7 Proxy (TR-5)	5.1.5. 共有 L7 プロキシの侵害(TR-5)
5.1.6. Outdated Client Libraries in Applications (TR-6)	5.1.6. アプリケーションの古いクライアントライブラリ (TR-6)
5.1.7. Denial of Service (TR-7)	5.1.7. サービス拒否 (TR-7)
5.1.8. Resource Consumption (TR-8)	5.1.8. リソースの消費 (TR-8)
5.1.9. Privileged L4 Proxy (TR-9)	5.1.9. 特権 L4 プロキシ (TR-9)
5.1.10. Data Plane (Service Mesh) Bypassed (TR-10)	5.1.10. データプレーン（サービスメッシュ）のバイパス（TR-10）
5.2. Threat Analysis for Shared L4 - L7 per Service Model (DPA-2)	5.2. サービスモデル（DPA-2）ごとの共有 L4 - L7 の脅威分析
5.2.1. Compromised L4 Proxy (TR-1)	5.2.1. 侵害された L4 プロキシ（TR-1）
5.2.2. Compromised Application Container (TR-2)	5.2.2. 侵害されたアプリケーションコンテナ（TR-2）
5.2.3. Compromise of Business Data (TR-3)	5.2.3. 業務データの漏洩 (TR-3)
5.2.4. Compromised L7 Proxy (TR-4)	5.2.4. 侵害された L7 プロキシ(TR-4)
5.2.5. Compromise of Shared L7 Proxy (TR-5)	5.2.5. 共有 L7 プロキシの侵害(TR-5)
5.2.6. Outdated Client Libraries in Applications (TR-6)	5.2.6. アプリケーションの古いクライアントライブラリ (TR-6)
5.2.7. Denial of Service (TR-7)	5.2.7. サービス拒否 (TR-7)
5.2.8. Resource Consumption (TR-8)	5.2.8. リソースの消費 (TR-8)
5.2.9. Privileged L4 Proxy (TR-9)	5.2.9. 特権 L4 プロキシ (TR-9)
5.2.10. Data Plane (Service Mesh) Bypassed (TR-10)	5.2.10. データプレーン（サービスメッシュ）のバイパス（TR-10）
5.3. Threat Analysis for Shared L4 and L7 Model (DPA-3)	5.3. 共有 L4 及び L7 モデルの脅威分析(DPA-3)
5.3.1. Compromised L4 Proxy (TR-1)	5.3.1. 侵害された L4 プロキシ(TR-1)
5.3.2. Compromised Application Container (TR-2)	5.3.2. 侵害されたアプリケーションコンテナ（TR-2）
5.3.3. Compromise of Business Data (TR-3)	5.3.3. 業務データの漏洩 (TR-3)
5.3.4. Compromised L7 Proxy (TR-4)	5.3.4. 侵害された L7 プロキシ(TR-4)
5.3.5. Compromise of Shared L7 Proxy (TR-5)	5.3.5. 共有 L7 プロキシの侵害(TR-5)
5.3.6. Outdated Client Libraries in Applications (TR-6)	5.3.6. アプリケーションの古いクライアントライブラリ (TR-6)
5.3.7. Denial of Service (TR-7)	5.3.7. サービス拒否 (TR-7)
5.3.8. Resource Consumption (TR-8)	5.3.8. リソースの消費 (TR-8)
5.3.9. Privileged L4 Proxy (TR-9)	5.3.9. 特権 L4 プロキシ (TR-9)
5.3.10. Data Plane (Service Mesh) Bypassed (TR-10)	5.3.10. データプレーン(サービスメッシュ)のバイパス (TR-10)
5.4. Threat Analysis for L4 and L7 within Application Model (gRPC proxyless Model (DPA-4))	5.4. アプリケーションモデル(gRPC プロキシレスモデル(DPA-4))内の L4 及び L7 の脅威分析
5.4.1. Compromised L4 Proxy (TR-1)	5.4.1. 侵害された L4 プロキシ(TR-1)
5.4.2. Compromised Application Container (TR-2)	5.4.2. 侵害されたアプリケーションコンテナ(TR-2)
5.4.3. Compromise of Business Data (TR-3)	5.4.3. 業務データの漏洩 (TR-3)
5.4.4. Compromised L7 Proxy (TR-4)	5.4.4. 侵害された L7 プロキシ(TR-4)
5.4.5. Compromise of Shared L7 Proxy (TR-5)	5.4.5. 共有 L7 プロキシの侵害(TR-5)
5.4.6. Outdated Client Libraries in Applications (TR-6)	5.4.6. アプリケーションの古いクライアントライブラリ (TR-6)
5.4.7. Denial of Service (TR-7)	5.4.7. サービス拒否 (TR-7)
5.4.8. Resource Consumption (TR-8)	5.4.8. リソースの消費 (TR-8)
5.4.9 Privileged L4 Proxy (TR-9)	5.4.9 特権 L4 プロキシ (TR-9)
5.4.10 Data Plane (Service Mesh) Bypassed (TR-10)	5.4.10 データプレーン(サービスメッシュ)のバイパス(TR-10)
6. Recommendations Based on Application Security Risk Profile	6. アプリケーションセキュリティリスクプロファイルに基づく推奨事項
6.1. Cloud-Native Applications with Low Risk Profile	6.1. リスクプロファイルが低いクラウドネイティブアプリケーション
6.2. Cloud-Native Applications with Medium Risk Profile …	6.2. リスクプロファイルが中程度のクラウドネイティブ・アプリケーション
6.3. Cloud-Native Applications with High Risk Profile	6.3. 高リスクプロファイルのクラウドネイティブアプリケーション
7. Summary and Conclusions	7. まとめと結論
References	参考文献

---

Figure 1 – L4 and L7 Proxy per Service Instance (Side Car Model) (DPA-1)

図1 - サービスインスタンスごとのL4およびL7プロキシ（サイドカーモデル）（DPA-1）

Figure 2 – Shared L4 - L7 per Service Model (DPA-2)

図2 - サービスごとの共有L4 - L7 モデル（DPA-2）

Figure 3 – Shared L4 - L7 Model (DPA-3)

図3 - 共有L4 - L7モデル（DPA-3）

Figure 4 – L4 and L7 Part of the Application Model (gRPC proxyless Model) (DPA-4)

図4-アプリケーションモデル（gRPCプロキシレスモデル）のL4とL7の部分（DPA-4）

フランス 情報システム安全保障庁 機密情報システムをクラウドでホスティングするための推奨事項

こんにちは、丸山満彦です。

フランスの情報システム安全保障庁 機密情報システムをクラウドでホスティングするための推奨事項を公表していますね...欧州では、欧州クラウドサービス認証スキーム（EUCS）が現在策定中ですので、それが確定すれば、そちらに移行することになります。

● Agence nationale de la sécurité des systèmes d'information; ANSSI

・2024.07.09 Recommandations pour l’hébergement des SI sensibles dans le cloud

Recommandations pour l’hébergement des SI sensibles dans le cloud	機密情報システムをクラウドでホスティングするための推奨事項
La série de recommandations de l’ANSSI est un outil d’aide à la décision pour des entités envisageant un hébergement cloud pour leurs systèmes d’information (SI) sensibles.	ANSSIの一連の勧告は、機密情報システム（IS）のクラウド・ホスティングを検討している事業者のための意思決定ツールである。
Recommandations pour l'hébergement dans le cloud des systèmes d'information sensibles	機密情報システムをクラウドでホスティングするための推奨事項
Pour répondre aux enjeux de sécurité liés au cloud, l’ANSSI a développé une série de recommandations pour l’hébergement dans le cloud qui précisent, en fonction du type de système d’information (SI), de la sensibilité des données et du niveau de la menace, les types d’offres cloud à privilégier.	クラウドがもたらすセキュリティ上の課題に対応するため、ANSSIはクラウドでのホスティングに関する一連の勧告を策定した。この勧告では、情報システム（IS）の種類、データの機密性、脅威のレベルに応じて、どのようなクラウドサービスが望ましいかを規定している。
La série de recommandations de l’ANSSI constitue un outil d’aide à la décision pour les entités qui envisagent un hébergement cloud pour leurs systèmes d’information de niveau diffusion restreinte, les SI sensibles des opérateurs d’importance vitale et des opérateurs de services essentiels, ainsi que des systèmes d’information d’importance vitale (SIIV).	ANSSIの一連の勧告は、流通制限（DR）情報システム、極めて重要な事業者の機密情報システム、不可欠なサービスを提供する事業者の機密情報システム、および重要情報システム（SIIV）のクラウド・ホスティングを検討する事業者のための意思決定ツールである。
Il est à noter que ces recommandations ne s’appliquent pas aux systèmes d’information classifiés et que tous les systèmes d’information n’ont pas vocation à recourir aux solutions cloud. Elles s’inscrivent, par ailleurs, en cohérence avec la doctrine « cloud au centre » de l’État.	これらの勧告は、機密情報システムには適用されないこと、また、すべての情報システムがクラウド・ソリューションを使用する運命にあるわけではないことに留意すべきである。また、フランス政府の「クラウド・アット・ザ・センター」政策にも合致している。
Recommandations de l’ANSSI pour l’hébergement des systèmes d’information sensibles dans le cloud	機密情報システムをクラウドでホスティングするためのANSSI勧告

機密情報システムをクラウドでホスティングする際の推奨事項...

・[PDF] RECOMMANDATIONS POUR L’HÉBERGEMENT DANS LE CLOUD DES SYSTÈMES D’INFORMATION SENSIBLES

・[DOCX][PDF] 仮訳

FAQ...

・2024.07.08 FAQ sur les recommandations de l’ANSSI pour l’hébergement des SI sensibles dans le cloud

FAQ sur les recommandations de l’ANSSI pour l’hébergement des SI sensibles dans le cloud	機密情報システムをクラウドでホスティングするためのANSSI勧告に関するFAQ
Questions-réponses concernant les recommandations d’hébergement des systèmes d’information sensibles dans le cloud.	機密情報システムをクラウドでホスティングするための推奨事項に関する質問と回答。
La série de recommandations  de l’ANSSI pour l’hébergement des systèmes d’information sensibles dans le cloud (accessible ici) est un outil d’aide à la décision pour des entités envisageant un hébergement cloud pour leurs systèmes d’information (SI) sensibles.	機密情報システムをクラウドでホスティングするためのANSSI勧告シリーズ（こちらから入手可能）は、機密情報システム（IS）のクラウドホスティングを検討している事業者のための意思決定ツールである。
Cette FAQ vise à répondre aux questions principales concernant les recommandations de l’agence. La liste des questions-réponses sera progressivement enrichie.	このFAQは、ANSSIの勧告に関する主な質問に答えることを目的としている。質問と回答のリストは順次拡大していく予定である。
1. Les recommandations de l’ANSSI ont-elles un caractère obligatoire ?	1. ANSSIの勧告は義務なのか？
La série de recommandations mis à disposition par l’ANSSI est un outil d’aide à la décision non contraignant. Certains points précis évoqués dans le document sont toutefois obligatoires (en cohérence avec la doctrine « Cloud au centre » de l’Etat qui impose pour l’administration, et plus spécifiquement pour les données sensibles, de recourir à des solutions cloud qualifiées SecNumCloud).	ANSSIが提供する一連の勧告は、拘束力のない意思決定ツールである。しかし、この文書で提起されている具体的な指摘の中には、義務的なものもある（フランス政府の「Cloud at the centre」政策に沿ったもので、政府部門、特に機密データについては、SecNumCloud認定クラウド・ソリューションの利用を義務付けている）。
2. Comment utiliser ces recommandations ?	2. これらの推奨事項はどのように利用できるのか？
Dans le cadre d’un projet de migration d’un système d’information sensible vers un hébergement cloud, les recommandations de l’ANSSI peuvent être utilisées comme un outil d’aide à la décision qui permettent d’identifier des étapes essentielles de toute réflexion à conduire en amont d‘une éventuelle migration, en prenant en compte les différents aspects techniques et organisationnels de celle-ci. Le document précise les types d’offres cloud à privilégier, en fonction du type de système d’information, de la sensibilité des données et du niveau de menace associé.	機密情報システムをクラウドホスティングに移行するプロジェクトの一環として、ANSSIの勧告は、移行に関連する様々な技術的・組織的側面を考慮しながら、移行前に行うべき協議の重要な段階を特定するための意思決定ツールとして利用することができる。同文書では、情報システムの種類、データの機密性、関連する脅威のレベルに応じて、どのようなクラウドサービスが望ましいかを規定している。
3. Quelles sont les recommandations de sécurité à suivre lors de la migration d’un système d’information vers un hébergement cloud ?	3. 情報システムをクラウド・ホスティングに移行する場合、どのようなセキュリティ勧告に従うべきか？
L’ANSSI recommande que la décision de migrer des systèmes d’information vers des solutions cloud soit toujours éclairée par une étude d’impact, notamment métier et juridique, ainsi qu’une analyse de risques.	ANSSIは、情報システムをクラウド・ソリューションに移行する決定には、リスク分析だけでなく、影響調査、特にビジネスと法務に関する調査を必ず行うことを推奨している。
En complément des précautions d’emploi indiquées dans le document mis à disposition par l’ANSSI, il est important que l’entité responsable du système d’information s’assure des bonnes configurations et de la sécurité des solutions cloud choisies. Ainsi, il est de la responsabilité des entités d’identifier l’offre la plus adaptée à leurs besoins, d’acquérir les licences idoines auprès des offreurs cloud, ainsi que de configurer les bonnes options de sécurité. Par ailleurs, l’insertion d’une clause de réversibilité permet d’éviter toute dépendance à une offre cloud unique et à ses évolutions futures.	ANSSIが提供する文書に記載されている使用上の注意事項に加えて、情報システムの責任主体は、選択したクラウド・ソリューションが適切に設定され、安全であることを確認することが重要である。そのため、自社のニーズに最も適したサービスを特定し、クラウドプロバイダーから適切なライセンスを取得し、適切なセキュリティオプションを設定することは、事業体の責任である。さらに、可逆性条項を盛り込むことで、単一のクラウド・オファリングとその将来の発展への依存を避けることができる。
D’autres bonnes pratiques sont à privilégier, notamment des audits réguliers de la solution ; le suivi des accès ; le suivi des vulnérabilités du fournisseur cloud ; etc	その他のベスト・プラクティスとしては、ソリューションの定期的な監査、アクセス監視、クラウド・プロバイダーの脆弱性の監視などがある。
4. Comment s’articulent les recommandations de l’ANSSI avec le futur schéma de certification européen pour les services cloud (EUCS) ?	4. ANSSIの勧告は、将来的に欧州で導入されるクラウドサービスの認証スキーム（EUCS）とどのように整合するのか？
Le schéma de certification européen services cloud (EUCS) est actuellement en cours d’élaboration. Les recommandations de l’ANSSI pour l’hébergement des SI sensibles dans le cloud seront mises à jour lors de l’entrée en application du schéma de certification européen EUCS.	クラウドサービスの欧州認証スキーム（EUCS）は現在策定中である。機密情報システムをクラウドでホスティングするためのANSSIの勧告は、EUCSの欧州認証スキームが発効した時点で更新される予定である。
5. Où trouver plus d’informations sur le Visa de sécurité SecNumCloud évoqué dans les recommandations?	5. 勧告に記載されているSecNumCloud Security Visaの詳細情報はどこで入手できるか？
Nous vous invitons à consulter :	以下を参照されたい。
La rubrique dédiée au Visa de sécurité SecNumCloud ;	SecNumCloudセキュリティビザのセクション；
La FAQ dédiée au Visa de sécurité SecNumCloud.	SecNumCloudセキュリティビザに関するFAQを参照されたい。

クラウド・アット・ザ・センター

・Le Cloud pour les administrations

セキュリティ認定

・認定製品・サービスの一覧

・SecNumCloudサービスの一覧

資格認定のための要件

・Référentiels d'exigences pour la qualification

Prestataires d'accompagnement et de conseil en sécurité des systèmes d’information (PACS)	情報システムセキュリティサポート・コンサルタントプロバイダ（PACS）
PACS – référentiel d’exigences – v1.0	PACS要求事項フレームワーク - v1.0
Le référentiel PACS a pour objectif d’assister les responsables de la sécurité des systèmes d’information et leurs équipes dans leurs missions de protection des systèmes d’information, et notamment d’homologation de sécurité, de gestion des risques, de conception d’architectures sécurisées, et de préparation à la gestion de crises d’origine cyber.	PACS標準の目的は、情報システムセキュリティマネージャとそのチームが情報システムを保護するための作業、特にセキュリティ認証、リスクマネジメント、安全なアーキテクチャの設計、サイバー危機管理の準備において支援することである。
Le référentiel couvre activités:	この標準は以下の活動を対象としている：
Conseil en homologation de sécurité des systèmes d’information ;	情報システムセキュリティ認証コンサルティング
Conseil en gestion des risques de sécurité des systèmes d’information ;	情報システムセキュリティリスクマネジメントのコンサルティング
Conseil en sécurité des architectures des systèmes d’information ;	情報システムアーキテクチャーセキュリティコンサルティング
Conseil en préparation à la gestion de crise d’origine cyber.	サイバー危機管理準備コンサルティング
Prestataire  d’audit de la sécurité des systèmes d’information (PASSI)	情報システムセキュリティ監査サービスプロバイダー（PASSI）
PASSI – référentiel d’exigences – v2.0	PASSI - 要求事項の枠組み - v2.0
Le référentiel d’exigences relatif aux prestataires d’audit de la sécurité des systèmes d’information est un ensemble de règles qui s’imposent aux prestataires qui désirent obtenir une qualification de leurs services dans ce domaine. Il couvre des exigences relatives au prestataire d’audit, à son personnel ainsi qu’au déroulement des audits.	情報システムセキュリティ監査プロバイダのための要求事項枠組みは、この分野のサービスの資格取得を希望するプロバイダのための一連の規則である。監査プロバイダ、そのスタッフ、および監査の実施に関する要求事項を網羅している。
La qualification peut être délivrée aux prestataires d’audit pour les activités suivantes : audit d’architecture, audit de configuration, audit de code source, tests d’intrusion, audit organisationnel et physique.	監査プロバイダは、アーキテクチャ監査、コンフィギュレーション監査、ソースコード監査、侵入テスト、組織的監査、物理的監査を実施する。
Prestataire de réponse aux incidents de sécurité (PRIS)	セキュリティインシデント対応サービスプロバイダ（PRIS）
PRIS – référentiel d’exigences – v2.0	PRIS - 要求事項の枠組み - v2.0
Le référentiel d’exigences relatif aux prestataires de réponse aux incidents de sécurité est un ensemble de règles qui s’imposent aux prestataires qui désirent obtenir une qualification de leurs services dans ce domaine. Il couvre des exigences relatives au prestataire de réponse aux incidents, à son personnel ainsi qu’au déroulement des prestations de réponse aux incidents.	セキュリティインシデント対応サービスプロバイダのための要求事項枠組みは、この分野のサービスの認定を希望するサービスプロバイダのための一連の規則である。インシデントレスポンス プロバイダ、そのスタッフ、およびインシデントレスポンス サービスの提供方法に関連する要件を網羅している。
La qualification peut être délivrée aux prestataires de réponse aux incidents pour les activités suivantes : pilotage technique, analyse système, analyse réseau et analyse de codes malveillants.	インシデントレスポンス・プロバイダは、技術管理、システム分析、ネットワーク分析、悪質コード分析の各活動について、資格認定を受けることができる。
Prestataire de détection des incidents de sécurité (PDIS)	セキュリティインシデント検知サービスプロバイダ（PDIS）
PDIS – Référentiel d’exigences – v.2.0	PDIS - 要求事項参照文書 - v.2.0
PDIS – Requirements reference document – v.2.0	PDIS - 要求事項参照文書 - v.2.0
Le référentiel d’exigences relatif aux prestataires de détection des incidents de sécurité est un ensemble de règles qui s’imposent aux prestataires qui désirent obtenir une qualification de leurs services dans ce domaine. Il couvre des exigences relatives au prestataire de détection des incidents, à son personnel ainsi qu’au déroulement des prestations de détection des incidents.	セキュリティインシデント検知サービスプロバイダのための要求事項参照文書は、この分野のサービス認定を希望するプロバイダのための一連の規則である。インシデント検知プロバイダ、そのスタッフ、およびインシデント検知サービスの提供に関連する要件を網羅している。
La qualification peut être délivrée aux prestataires de détection des incidents pour l’ensemble de l’activité de détection d’incidents de sécurité.	セキュリティ・インシデント検知活動全体に対するインシデント検知プロバイダには、資格認定 を与えることができる。
Prestataires de vérification d'identité à distance (PVID)	リモート ID 検証サービス・プロバイダ（PVID）
PVID – référentiel d’exigences – v1.1	PVID - 要件リポジトリ - v1.1
Les exigences formulées par ce référentiel portent sur le prestataire et la sécurité du système d’information permettant de fournir le service de vérification d’identité à distance. Il vise à créer une offre de services de vérification d’identité à distance robuste et répondant au besoin de confiance des utilisateurs, des commanditaires de telles prestations et des régulateurs. Ce référentiel permet d’attester que la mise en œuvre des mesures de réduction de la fraude pertinente par les services certifiés selon deux niveaux de garantie : substantiel et élevé.	この標準に規定される要件は、サービス・プロバイダおよびリモート ID 検証サービスを提供 するために使用される情報システムのセキュリティに関するものである。この規格の目的は、利用者、このようなサービスを委託する者、および規制当局の信頼性の必要 性を満たす、堅固な一連のリモート ID 検証サービスを作成することである。この標準は、認証されたサービスが、実質的および高水準という 2 つの保証レベルで、 関連する不正削減手段を実装していることを認証する。
Moyens d'identification électronique (MIE)	電子 ID 手段（MIE）
MIE – référentiel d’exigences – v1.2	MIE - 要件フレームワーク - v1.2
Le référentiel d’exigences pour les moyens d’identification électronique précise au niveau national les spécifications techniques et les procédures minimales définies dans le règlement d’exécution 2015/1502 pour les niveaux de garantie :	電子的識別手段の要件リポジトリは、実施規則 2015/1502 で定義された技術仕様および保証レベ ルの最低手順を国家レベルで規定している：
Faible: l’objectif est de limiter le risque d’usurpation ou d’altération de l’identité de la personne. Par exemple : les moyens d’identification électronique reposant sur un identifiant / mot de passe ;	低：目的は、本人識別の簒奪または改ざんのリスクを制限することである。例：識別子／パスワードに基づく電子的識別手段；
Substantiel: l’objectif est de limiter substantiellement le risque d’usurpation ou d’altération de l’identité de la personne. Par exemple : certains moyens d’identification électronique reposant sur deux facteurs d’authentification ;	実質的：目的は、個人の ID の簒奪または改ざんのリスクを実質的に制限することである。例：2 つの認証要素に基づく特定の電子的識別手段；
Élevé: l’objectif est d’empêcher le risque d’usurpation ou d’altération de l’identité de la personne. Par exemple : certains moyens d’identification électronique reposant sur deux facteurs d’authentification dont l’un repose sur un composant cryptographique qualifié par l’ANSSI.	高：目的は、個人の ID の簒奪または改ざんのリスクを防止することである。例：2 つの認証要素に基づく特定の電子 ID 手段で、そのうちの 1 つは ANSSI が認定する暗号化要素に基づくもの。
Prestataire de services sécurisés d’informatique en nuage (SecNumCloud)	セキュア・クラウド・コンピューティング・サービス・プロバイダ（SecNumCloud）
SecNumCloud – référentiel d’exigences – v3.2	SecNumCloud - 要件フレームワーク - v3.2
Le référentiel d’exigences relatif aux prestataires de service d’informatique en nuage est un ensemble de règles qui s’imposent aux prestataires qui désirent obtenir une qualification de leurs services dans ce domaine. Il couvre des exigences relatives au prestataire de service d’informatique en nuage, à son personnel ainsi qu’au déroulement des prestations.	クラウドコンピューティング・サービス・プロバイダのための要求事項リポジトリは、この分野のサービスの資格取得を希望するプロバイダのための一連のルールである。クラウドコンピューティング・サービス・プロバイダ、そのスタッフ、サービスの提供に関する要件を網羅している。
La qualification peut être délivrée aux prestataires de service d’informatique en nuage pour des services de type SaaS (Software as a service), PaaS (Platform as a service) et IaaS (Infrastructure as a service.	資格は、SaaS（Software as a service）、PaaS（Platform as a service）、IaaS（Infrastructure as a service）サービスのクラウドコンピューティング・サービス・プロバイダに与えられる。
Prestataires d’administration et de maintenance sécurisées (PAMS)	セキュアな管理・保守サービスプロバイダ（PAMS）
PAMS – référentiel d’exigences – v1.1	PAMS - 要件フレームワーク - v1.1
Le référentiel d’exigences relatif aux prestataires d’administration et de maintenance sécurisées est un ensemble de règles qui s’imposent aux prestataires qui désirent obtenir une qualification de leurs services dans ce domaine. Il couvre des exigences relatives aux prestataires d’administration et de maintenance sécurisées, à son personnel ainsi qu’au déroulement des prestations. La qualification peut être délivrée au prestataire de d’administration et de maintenance pour l’ensemble de l’activité d’administration et de maintenance sécurisée.	セキュアな管理・保守サービスプロバイダのための要件フレームワークは、この分野のサービス認定を希望するサービスプロバイダのための一連のルールである。これは，安全な管理及び保守プロバイダ，そのスタッフ及びサービス提供方法に関連する要件を網羅 している。この資格は、安全な管理・保守活動全体について、管理・保守サービスプロバイダに発行することができる。
Prestataires de services relatifs à la confiance numérique	デジタルトラストサービス・プロバイダ
Les référentiels d’exigences relatifs aux prestataires de services de confiance formalisent les règles applicables aux organismes désirant obtenir une qualification dans les domaines suivants :	トラストサービス・プロバイダに対する要求事項の枠組みは、以下の分野における資格取得を希望する組織に適用される規則を正式に定めたものである：
Délivrance de certificats électroniques	電子証明書の発行
Horodatage électronique	電子タイムスタンプ
Validation des signatures et cachets électroniques	電子署名および電子スタンプの検証
Conservation des signatures et cachets électroniques	電子署名および電子スタンプの保管
Envoi recommandé électronique	電子書留郵便
Les référentiels d’exigences pour la qualification des prestataires de services de confiance au titre du Référentiel Général de Sécurité sont disponibles ici.	General Security Reference Framework に基づくトラストサービス・プロバイダの資格要件のリポジトリは、こちらで入手できる。
Les référentiels d’exigences pour la qualification des prestataires de services de confiance au titre du règlement n°910/2014 « eIDAS » sont disponibles ici.	規則No.910/2014「eIDAS」に基づくトラストサービス・プロバイダの資格要件のリポジトリはこちらで入手できる。