Five Eyes +α イベントロギングと脅威検知のベストプラクティス

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

ファイブアイズ＋日本＋韓国＋シンガポール＋オランダのセキュリティセンターが協力して「イベントロギングと脅威検知のベストプラクティス」を公表していますね...

参考になることも多いように思います...

・ログについての組織全体の方針を決めなはれ

・ログの収集と相関は一元管理しなはれ

・収集したログは改ざんされんように、漏れんようにしなはれ

・脅威に関連させて検知戦略を立なはれ

ということですかね...

ベストプラクティスの目次...

Best practices	ベストプラクティス
Enterprise-approved event logging policy	エンタープライズが承認したイベントロギングポリシー
Event log quality	イベントログの品質
Captured event log details	キャプチャされたイベントログの詳細
Operational Technology considerations	運用技術 (OT) に関する考慮事項
Additional resources	追加リソース
Content and format consistency	コンテンツとフォーマットの一貫性
Additional resources	追加リソース
Timestamp consistency	タイムスタンプの一貫性
Event log retention	イベントログの保持
Centralised log collection and correlation	ログの収集と相関の一元化
Logging priorities for enterprise networks	エンタープライズ・ネットワークのログの優先順位
Logging priorities for operational technology	運用技術 (OT) のログの優先順位
Logging priorities for enterprise mobility using mobile computing devices	モバイルコンピューティングデバイスを使用するエンタープライズモビリティのログの優先順位
Logging priorities for cloud computing	クラウドコンピューティングにおけるロギングの優先順位
Secure storage and event log integrity	安全な保存とイベントログの完全性
Secure transport and storage of event logs	イベントログの安全な転送と保存
Protecting event logs from unauthorised access, modification and deletion	イベントログの不正アクセス、変更、削除からの防御
Centralised event logging enables threat detection	イベントログの一元化が脅威検知を可能にする
Timely ingestion	適時の取り込み
Detection strategy for relevant threats	関連する脅威の検知戦略
Detecting living off the land techniques	現地調達技術の検知
Cloud considerations	クラウドに関する考慮事項
Operational technology considerations	運用技術 (OT) に関する考慮事項

● U.S. CISA

・2024.08.21 ASD’s ACSC, CISA, FBI, and NSA, with the support of International Partners Release Best Practices for Event Logging and Threat Detection

ASD’s ACSC, CISA, FBI, and NSA, with the support of International Partners Release Best Practices for Event Logging and Threat Detection	ASDのACSC、CISA、FBI、NSA、国際的なパートナーの支援によりイベントログと脅威検知のベストプラクティスをリリース
Today, the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), CISA, FBI, NSA, and international partners are releasing Best Practices for Event Logging and Threat Detection. This guide will assist organizations in defining a baseline for event logging to mitigate malicious cyber threats.	本日、オーストラリア信号総局のオーストラリア・サイバーセキュリティセンター（ASD's ACSC）、CISA、FBI、NSA、および国際的なパートナーは、イベントロギングと脅威検知のベストプラクティスをリリースする。このガイドは、悪意のあるサイバー脅威を軽減するために、イベントロギングのベースラインを定義する際に組織を支援するものである。
The increased prevalence of malicious actors employing living off the land (LOTL) techniques, such as living off the land binaries (LOLBins) and fileless malware, highlights the importance of implementing and maintaining an effective event logging program.	現地調達バイナリ（LOLBins）やファイルレスマルウェアのような現地調達（LOTL）テクニックを採用する悪意ある事業者の増加傾向は、効果的なイベントロギングプログラムの実装と維持の重要性を浮き彫りにしている。
CISA encourages public and private sector senior information technology (IT) decision makers, operational technology (OT) operators, network administrators, network operators, and critical infrastructure organizations to review the best practices in the guide and implement recommended actions. These actions can help detect malicious activity, behavioral anomalies, and compromised networks, devices, or accounts.	CISAは、公共部門および民間部門の上級情報技術（IT）意思決定者、運用技術（OT）オペレータ、ネットワーク管理者、ネットワークオペレータ、および重要インフラストラクチャ組織に対し、本ガイドのベストプラクティスを検討し、推奨されるアクションを実施するよう奨励している。これらの行動は、悪意のある活動、行動の異常、侵害されたネットワーク、デバイス、またはアカウントの検知に役立つ。
For more information on LOTL techniques, see joint guidance Identifying and Mitigating Living Off the Land Techniques and CISA’s Secure by Design Alert Series.	LOTL テクニックの詳細については、共同ガイダンス「現地調達テクニックの識別と低減」および CISA の「Secure by Design Alert Series」を参照のこと。
For more information and guidance on event logging and threat detection, see CISA’s Secure Cloud Business Applications (SCuBA) products, network traffic analysis tool Malcom, and Logging Made Easy.	イベント・ロギングと脅威検知に関する詳細な情報とガイダンスについては、CISA の Secure Cloud Business Applications（SCuBA）製品、ネットワーク・トラフィック分析ツール Malcom、Logging Made Easy を参照のこと。

・[PDF] 

日本...

● 内閣官房サイバーセキュリティセンター (NISC)

・2024.08.22 国際文書「Best practices for event logging and threat detection」に署名しました

・[PDF]

オーストラリア...

● Australian Cyber Security Centre; ASCS

プレス...

・2024.08.22 Best practices for event logging and threat detection

Best practices for event logging and threat detection	イベントロギングと脅威検知のベストプラクティス
Today we have released new guidance on Best practices for event logging and threat detection. It outlines best practice for event logging and threat detection for cloud services, enterprise information technology (IT) networks, enterprise mobility and operational technology (OT) networks.	本日、我々はイベントロギングと脅威検知のベストプラクティスに関する新しいガイダンスを発表した。このガイダンスは、クラウドサービス、エンタープライズ情報技術（IT）ネットワーク、エンタープライズモビリティ、運用技術（OT）ネットワークにおけるイベントロギングと脅威検知のベストプラクティスを概説している。
The advice assumes a basic understanding of event logging and is intended primarily for cyber security practitioners, IT managers, OT operators, network administrators and network operators within medium to large organisations.	このアドバイスは、イベントロギングの基本的な理解を前提としており、主に中規模から大規模の組織内のサイバーセキュリティ実務者、IT管理者、OTオペレータ、ネットワーク管理者、ネットワークオペレータを対象としている。
There are four key factors to consider when pursuing event logging and threat detection best practice:	イベントロギングと脅威検知のベストプラクティスを追求する際に考慮すべき4つの重要な要素がある：
1. Develop an enterprise-approved logging policy.	1. エンタープライズで承認されたロギングポリシーを策定する。
2. Centralise log collection and correlation.	2. ログの収集と相関を一元化する。
3. Maintain log integrity, including through secure log storage.	3. 安全なログ保管を含め、ログの完全性を維持する。
4. Develop a detection strategy for relevant threats.	4. 関連する脅威の検知戦略を策定する。
This publication has been released in cooperation with the following international partners:	本書は、以下の国際的なパートナーの協力を得て発行された：
・United States (US) Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI) and the National Security Agency (NSA)	・米国サイバーセキュリティ・インフラセキュリティ庁（CISA）、連邦捜査局（FBI）、国家安全保障局 （NSA）。
・United Kingdom (UK) National Cyber Security Centre (NCSC-UK)	・英国(UK) ナショナル・サイバー・セキュリティ・センター(NCSC-UK)
・Canadian Centre for Cyber Security (CCCS)	・カナダ・サイバーセキュリティセンター（CCCS）
・New Zealand National Cyber Security Centre (NCSC-NZ) and Computer Emergency Response Team (CERT NZ)	・ニュージーランド国家サイバーセキュリティセンター(NCSC-NZ)及びコンピュータ緊急対応チーム(CERT NZ)
・Japan National Center of Incident Readiness and Strategy for Cybersecurity (NISC) and Computer Emergency Response Team Coordination Center (JPCERT/CC)	・日本内閣サイバーセキュリティセンター(NISC)及びコンピュータ緊急対 応チームコーディネーションセンター(JPCERT/CC)
・The Republic of Korea National Intelligence Services (NIS) and NIS’s National Cyber Security Center (NCSC-Korea)	・韓国国家情報院(NIS)及び NIS 国家サイバーセキュリティセンター(NCSC-Korea)
・Singapore Cyber Security Agency (CSA)	・シンガポール サイバーセキュリティ庁（CSA）
・The Netherlands General Intelligence and Security Service (AIVD) and Military Intelligence and Security Service (MIVD).	・オランダ国家情報安全保障局（AIVD）および軍情報安全保障局（MIVD）。
To learn more about these key factors, read the Best practices for event logging and threat detection publication.	これらの重要な要因の詳細については、イベント・ロギングと脅威検知のベスト・プラクティスを参照されたい。

ベストプラクティス...

・2024.08.22 Best Practices for Event Logging and Threat Detection

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

Best Practices for Event Logging and Threat Detection	イベントロギングと脅威検知のベストプラクティス
Executive summary	エグゼクティブサマリー
This publication defines a baseline for event logging best practices to mitigate cyber threats. It was developed by the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) in cooperation with the following international partners:	本書は、サイバー脅威を軽減するためのイベントロギングのベストプラクティスのベースラインを定義する。本書は、オーストラリア信号局（Australian Signals Directorate）のオーストラリア・サイバー・セキュリティ・センター（Australian Cyber Security Centre: ASD's ACSC）が、以下の国際的なパートナーと協力して作成した：
・United States (US) Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI) and the National Security Agency (NSA)	・米国サイバーセキュリティ・インフラセキュリティ庁（CISA）、連邦捜査局（FBI）、国家安全保障局 （NSA）。
・United Kingdom (UK) National Cyber Security Centre (NCSC-UK)	・英国(UK) ナショナル・サイバー・セキュリティ・センター(NCSC-UK)
・Canadian Centre for Cyber Security (CCCS)	・カナダ・サイバーセキュリティセンター（CCCS）
・New Zealand National Cyber Security Centre (NCSC-NZ) and Computer Emergency Response Team (CERT NZ)	・ニュージーランド国家サイバーセキュリティセンター(NCSC-NZ)及びコンピュータ緊急対応チーム(CERT NZ)
・Japan National Center of Incident Readiness and Strategy for Cybersecurity (NISC) and Computer Emergency Response Team Coordination Center (JPCERT/CC)	・日本内閣サイバーセキュリティセンター(NISC)及びコンピュータ緊急対 応チームコーディネーションセンター(JPCERT/CC)
・The Republic of Korea National Intelligence Services (NIS) and NIS’s National Cyber Security Center (NCSC-Korea)	・韓国国家情報院(NIS)及び NIS 国家サイバーセキュリティセンター(NCSC-Korea)
・Singapore Cyber Security Agency (CSA)	・シンガポール サイバーセキュリティ庁（CSA）
・The Netherlands General Intelligence and Security Service (AIVD) and Military Intelligence and Security Service (MIVD).	・オランダ国家情報安全保障局（AIVD）および軍情報安全保障局（MIVD）。
Event logging supports the continued delivery of operations and improves the security and resilience of critical systems by enabling network visibility. This guidance makes recommendations that improve an organisation’s resilience in the current cyber threat environment, with regard for resourcing constraints. The guidance is of moderate technical complexity and assumes a basic understanding of event logging.	イベント・ロギングは、業務の継続的な提供を支援し、ネットワークの可視化を可能にすることで、 重要なシステムのセキュリティとレジリエンスを改善する。このガイダンスは、レジリエンスの制約を考慮しつつ、現在のサイバー脅威環境における組織のレジリエンスを改善するための勧告を行う。このガイダンスは、技術的に中程度の複雑さを持ち、イベントロギングの基本的な理解を前提としている。
An effective event logging solution aims to:	効果的なイベントロギング・ソリューションの目的は以下のとおりである：
・send alerts to the network defenders responsible for monitoring when cyber security events such as critical software configuration changes are made or new software solutions are deployed	・重要なソフトウェア構成の変更や新しいソフトウェアソリューションの導入などのサイバーセキュリティイベントが発生したときに、監視を担当するネットワーク防御担当者にアラートを送信する。
・identify cyber security events that may indicate a cyber security incident, such as malicious actors employing living off the land (LOTL) techniques or lateral movement post-compromise	・意のある行為者が現地調達（LOTL）技術を使用したり、侵害後に横方向に移動したりするなど、サイバーセキュリティインシデントを示す可能性のあるサイバーセキュリティイベントを識別する。
・support incident response by revealing the scope and extent of a compromise	・侵害の範囲と程度を明らかにすることで、インシデント対応を支援する。
・monitor account compliance with organisational policies	・組織のポリシーに対するアカウントのコンプライアンスを監視する。
・reduce alert noise, saving on costs associated with storage and query time	・アラートノイズを低減し、ストレージやクエリにかかるコストを削減する。
・enable network defenders to make agile and informed decisions based on prioritisation of alerts and analytics	・アラートと分析結果の優先順位付けに基づき、ネットワーク防御担当者が情報に基づいた迅速な意思決定を行えるようにする。
・ensure logs and the logging platforms are useable and performant for analysts.	・ログとロギング・プラットフォームが、アナリストにとって使用可能で高性能であることを保証する。
There are four key factors to consider when pursuing logging best practices:	ロギングのベストプラクティスを追求する際に考慮すべき4つの重要な要素がある：
1. enterprise-approved event logging policy	1. エンタープライズが承認したイベントロギング方針
2. centralised event log access and correlation	2. イベントログへのアクセスと相関の一元化
3. secure storage and event log integrity	3. 安全な保存とイベントログの完全性
4. detection strategy for relevant threats.	4. 関連する脅威の検知戦略
Introduction	序文
The increased prevalence of malicious actors employing LOTL techniques, such as LOTL binaries (LOLBins) and fileless malware, highlights the importance of implementing and maintaining an effective event logging solution. As demonstrated in the joint-sealed publication Identifying and Mitigating Living Off the Land Techniques, Advanced Persistent Threats (APTs) are employing LOTL techniques to evade detection. The purpose of this publication is to detail best practice guidance for event logging and threat detection for cloud services, enterprise networks, enterprise mobility, and operational technology (OT) networks. The guidance in this publication focuses on general best practices for event logging and threat detection; however, LOTL techniques feature as they provide a great case study due to the high difficulty in detecting them.	LOTL バイナリ（LOLBin）やファイルレスマルウェアのような LOTL テクニックを採用する悪意ある事業者 の増加傾向は、効果的なイベントロギングソリューションを実装し、維持することの重要性を浮き 彫りにしている。共同発行の『現地調達手法の検知と低減』で示したように、高度な持続的脅威（APT）は検知を回避するために LOTL 手法を採用している。本書の目的は、クラウドサービス、エンタープライズネットワーク、エンタープライズモビリティ、オペレーショナルテクノロジー（OT）ネットワークのイベントロギングと脅威検知に関するベストプラクティスのガイダンスを詳述することである。本書のガイダンスは、イベントロギングと脅威検知のための一般的なベストプラクティスに重点を置いているが、LOTL 技術は検知の難易度が高いため、優れたケーススタディとなる。
Audience	想定読者
This guidance is technical in nature and is intended for those within medium to large organisations. As such, it is primarily aimed at:	本ガイダンスは、本質的に技術的であり、中規模から大規模の組織内の人々を対象としている。そのため、主に以下を対象としている：
・senior information technology (IT) and OT decision makers	・上級情報技術（IT）およびOTの意思決定者
・IT and OT operators	・IT および OT オペレーター
・network administrators	・ネットワーク管理者
・critical infrastructure providers.	・重要インフラプロバイダー

ベストプラクティス本文...

↓

Continue reading "Five Eyes +α イベントロギングと脅威検知のベストプラクティス"

FIRSTサービスフレームワークに基づくチームの種類 (2024.07)

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

FIRSTは、CSIRT Services Framework [PDF 日本語 Ver2.1]を公表していますが、それに基づいて、SOC、CSIRT、PSRIT、ISACがどのような役割を果たすべきかみたいな話ですかね...

例えば、フレームワームに沿った見出しをつけると次のような感じ...

サービスエリア	SOC	CSIRT	PSIRT	ISAC
情報セキュリティ イベントマネジメント
監視と検知	必須	-	-	-
イベント分析	必須	-	-	-
情報セキュリティインシデントマネジメント
情報セキュリティインシデント報告の受付	-	必須	-	-
情報セキュリティインシデントの分析	-	必須	-	-
アーティファクトとフォレンジック痕跡の分析	-	-	-	-
緩和と回復	-	必須	-	-
情報セキュリティインシデントの調整	-	必須	-	-
危機管理支援	-	-	-	-
脆弱性管理
脆弱性の発見・調査	-	-	-	-
脆弱性報告の取得	-	-	必須	-
脆弱性分析	-	-	必須	-
脆弱性の調整	-	-	必須	-
脆弱性の開示	-	-	必須	-
脆弱性対応	-	-	必須	-
状況把握
データ収集	-	-	-	必須
分析と統合	-	-	-	必須
コミュニケーション	-	-	-	必須
知識移転
啓発	-	-	-	-
トレーニングと教育	-	-	-	-
演習	-	-	-	-
技術およびポリシーに関するアドバイス	-	-	-	-

興味深いです...

● FIRST

・2024.07 Team Types Within the Context of FIRST Services Frameworks (Ver 1.0)

・[PDF] [HTML]

目次...

Team Types Within the Context of FIRST Services Frameworks	FIRSTサービスフレームワークに基づくチームの種類
1. Purpose	1. 目的
2. Background	2. 背景
3. Team Types: Capabilities that Handle Security Incidents, Threats, and Vulnerabilities	3. チームの種類:セキュリティインシデント、脅威、脆弱性に対応する能力
3.1 Computer Security Incident Response Teams (CSIRTs)	3.1 コンピュータセキュリティ・インシデント対応チーム(CSIRT)
3.2 Information Sharing and Analysis Centers (ISACs)	3.2 情報共有分析センター(ISAC)
3.3 Product Security Incident Response Teams (PSIRTs)	3.3 製品セキュリティインシデントレスポンスチーム(PSIRT)
3.4 Security Operations Centers (SOCs)	3.4 セキュリティ・オペレーション・センター(SOC)
4. Overview and Considerations	4. 概要と考慮事項
4.1 Defining Four Basic Team Types	4.1 4つの基本的なチームタイプの定義
4.2 Why Knowledge Transfer Is Not a Must for Any Team Type	4.2 知識の伝達がどのチームタイプにも必須ではない理由
4.3 Why We Did Not Define Managed Security Service Providers	4.3 マネージド・セキュリティ・サービス・プロバイダを定義しなかった理由
4.4 Why We Did Not Define a SOC as Part of a CSIRT or Vice Versa	4.4 なぜSOCをCSIRTの一部と定義しなかったのか、またはその逆も同様であるのか
4.5 Why We Did Not Define a New Name for a Combined CSIRT and PSIRT	4.5 CSIRTとPSIRTを組み合わせた新しい名称を定義しなかった理由
4.6 Why We Did Not Define CDC or NCSC	4.6 CDC または NCSC を定義しなかった理由
ANNEX 1: Acknowledgments	附属書 1:謝辞
ANNEX 2: Supporting Resources	附属書 2:参考資料

米国 FBI サイバーアクションチームの紹介 (2024.07.23)

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

FBIが、サイバーアクションチーム (CAT) についての説明をしていますね...

サイバーアクションチーム (CAT)は、約65名からなるチームで、特別捜査官、コンピュータ科学者、情報分析官、FBIの各支部と本部の情報技術専門家を活用した捜査を迅速に進めるためのフライ・チーム。

重要なサービスに対する大規模なサイバー脅威や攻撃に対応するため、数時間以内に世界中に展開することができるということのようです。

層が厚いですよね...それでも、日本でも参考になる部分があると思います...

● Federal Breau of Investigation; FBI

・2024.07.23 Meet the Cyber Action Team - Rapid response fly team can deploy across the globe within hours to respond to major cyber threats

Meet the Cyber Action Team	サイバーアクションチームの紹介
Rapid response fly team can deploy across the globe within hours to respond to major cyber threats	大規模なサイバー脅威に対応するため、数時間以内に世界中に展開できる迅速な対応フライチーム
Across the globe, malicious cyber activity threatens public safety and national and economic security. Criminals target organizations such as schools, hospitals, power and utility companies, and other critical infrastructure entities that serve communities.	世界中で、悪質なサイバー活動が公共の安全と国家・経済の安全を脅かしている。犯罪者は、学校、病院、電力会社、公益事業会社など、地域社会に貢献する重要なインフラ事業体を標的としている。
As the lead federal agency for investigating cyberattacks and intrusions, the FBI developed a specialty group—the Cyber Action Team, or CAT—that can deploy across the globe within hours to respond to major cyber threats and attacks against these critical services.	サイバー攻撃や侵入を捜査する連邦政府の主要機関として、FBIはサイバーアクションチーム（CAT）という専門グループを開発した。CATは、これらの重要なサービスに対する大規模なサイバー脅威や攻撃に対応するため、数時間以内に世界中に展開することができる。
Composed of about 65 members, CAT is an investigative rapid response fly team that leverages special agents, computer scientists, intelligence analysts, and information technology specialists from across FBI field offices and Headquarters.	約65人のメンバーで構成されるCATは、特別捜査官、コンピュータ科学者、情報分析官、FBIの各支部と本部の情報技術専門家を活用した捜査迅速対応フライチームである。
"We respond onsite to victims who may include national government entities, private companies, or even sometimes foreign partner networks that have been compromised by an adversary," said Scott Ledford, head of the Cyber Action Team and the Advanced Digital Forensics Team. "Our job is to help conduct the investigation—we collect digital evidence and locate, identify, and reverse engineer malware. We also help the victim understand when they were compromised and how, writing a timeline and a narrative of that intrusion with the ultimate goal of identifying who is responsible, attributing that attack.	「サイバー・アクション・チームとアドバンスド・デジタル・フォレンジック・チームの責任者であるスコットレドフォードは、次のように述べた。「私たちは、敵対者によって侵害された国家事業体や民間企業、時には外国のパートナー・ネットワークなどの被害者に現場で対応する。「私たちの仕事は、デジタル証拠を収集し、マルウェアの場所を特定し、識別し、リバースエンジニアリングすることである。私たちはまた、被害者がいつ、どのように侵入されたかを理解する手助けをし、その侵入のタイムラインと物語を書く。」
CAT was established in 2005 in response to an increase in the number and complexity of computer intrusion investigations in FBI field offices. At the time, not all field offices had personnel with the cyber expertise necessary to properly respond to and investigate sophisticated computer intrusions.	CATは2005年、FBI支局におけるコンピュータ侵入捜査の増加と複雑化に対応して設立された。当時、すべての支局に、高度なコンピュータ侵入に適切に対応し、捜査するのに必要なサイバー専門知識を持つ職員がいたわけではなかった。
"There was this transition that was taking place between what investigations the FBI was responsible for and the types of crimes that we were starting to see," explained Ledford. "Cyber was such a growing threat at the time, and so it became necessary that some field offices would reach out and say, ‘Hey, do you know of any cyber experts who can help me work through an investigation?"	レドフォードは次のように説明した。「FBIが担当する捜査と、私たちが目にし始めた犯罪の種類との間に、このような移行が起こっていた。当時、サイバーは脅威を増していたため、いくつかの支局が、"捜査に協力してくれるサイバー専門家を知らないか？"と連絡を取ることが必要になった。」
As the team formalized its processes and expanded, in 2016, the Presidential Policy Directive 41, "United States Cyber Incident Coordination" was signed, setting forth principles for the federal government’s response to cyber incidents involving government or private sector entities. The FBI was appointed the lead federal agency for cyber threat response activities.	チームがそのプロセスを正式化し、拡大するにつれて、2016年には大統領政策指令41号「合衆国サイバーインシデント・コーディネーション」が署名され、政府機関や民間企業が関与するサイバー事件に対する連邦政府の対応原則が示された。FBIは、サイバー脅威への対応活動を主導する連邦機関に任命された。
"From an investigative standpoint, the FBI is unique. We're one of the few agencies in the U.S. government that has both law enforcement and counterintelligence authorities," said Ledford. "And those authorities, and the American people's trust in us, help us to deliver a unique blend of national security and criminal investigative skills, expertise, and resources to implement that blended response and help facilitate an investigation, regardless of whether it leads us overseas or to a courtroom here in the U.S."	レドフォードは次のように述べた。「捜査の観点から見ると、FBIはユニークだ。我々は、法執行と防諜の両権限を持つ、米国政府でも数少ない機関のひとつだ。そして、これらの権限と米国民の信頼が、国家安全保障と犯罪捜査のスキル、専門知識、リソースを独自に融合させ、海外であろうと米国内の法廷であろうと、その融合した対応を実施し、捜査の円滑化を支援するのに役立っている」。
The bulk of CAT’s cases usually involve the FBI identifying an organization with a particular intrusion that’s either so complex or large-scale that the local field office requests additional assistance.	CATが担当するケースの大半は、FBIが、現地支局が追加支援を要請するほど複雑または大規模な、特定の侵入を行った組織を特定することにある。
In one case, CAT deployed to a health care company that a separate intrusion investigation had identified as compromised. CAT’s response helped lead to the identification of several compromised systems and accounts on their network. While working alongside the company, CAT disrupted the threat—and prevented further exploitation across their network.	あるケースでは、CATは、別の侵入調査によって侵害が確認された医療関連企業に派遣された。CATの対応により、同社のネットワーク上で侵害された複数のシステムとアカウントが特定された。CATは、同社と協力しながら、脅威を阻止し、同社のネットワーク全体でさらなる悪用を防止した。
CAT also receives requests from FBI legal attachés, the State Department, the National Security Council, and the White House to assist other countries when they face cyberattacks.	CATはまた、FBIの法務担当官、国務省、国家安全保障会議、ホワイトハウスからも、他国がサイバー攻撃に直面した際の支援要請を受けている。
"It could be a country that doesn't have the resources or the expertise that the U.S. government has, and they've reached out and asked for help," said Ledford. “There can be a NATO or a non-NATO ally country that says, 'We've been hit hard by this adversary, and we don't have the localized personnel, we don't have the resources, we don't have the expertise to respond to this. Can you help us with it?"	レドフォードは次のように述べた。「米国政府が持っているような資源や専門知識を持たない国が、手を差し伸べて助けを求めているのだ。NATOやNATO以外の同盟国が、我々はこの敵対勢力から大きな打撃を受けており、これに対応するための現地要員も資源も専門知識もないと言うこともある。私たちを助けてくれないか？」
In another case, CAT deployed overseas to provide incident response support to a NATO ally that had been targeted by a destructive cyberattack. CAT responded and worked together with U.S. partners to determine the initial intrusion vector, identify other networks that were impacted, collect and analyze digital evidence, and ultimately attribute the intrusion to a foreign government. The NATO ally severed diplomatic ties with the foreign government, closed the foreign government’s in-country embassy, and evicted them from the country.	別のケースでは、CATが海外に派遣され、破壊的なサイバー攻撃の標的となったNATOの同盟国にインシデント対応支援を提供した。CATはこれに対応し、米国のパートナーと協力して、最初の侵入経路の特定、影響を受けた他のネットワークの特定、デジタル証拠の収集と分析を行い、最終的に侵入を外国政府に帰属させた。NATOの同盟国は外国政府との外交関係を断絶し、外国政府の国内大使館を閉鎖し、外国政府を国内から追い出した。
"We have some talented people, and they work hard every single day," said Ledford. "It's an honor to sit alongside them."	レドフォードは、「優秀なスタッフがいて、彼らは毎日懸命に働いている。「彼らと一緒に仕事ができるのは光栄なことだ」と、述べた。
Key Tactic: Strong Communication Skills	重要な戦術：強力なコミュニケーション能力
In addition to excellent technical skills, CAT members are closely vetted for strong communication skills. Ledford explained that part of the CAT applicant selection process entails a multi-day live technical exercise that's designed and curated by CAT:	優れた技術スキルに加えて、CATのメンバーは、強力なコミュニケーション・スキルについても綿密に審査される。レドフォードは、CATの応募者選考プロセスの一環として、CATが設計・監修する数日間のライブ技術演習が行われると説明した：
"We design a network environment. We may mimic an industry, for example, an electric utility. And then we compromise that environment, and we litter it with artifacts, digital evidence, and malware. Then we task applicants to investigate this cyber incident and present their findings.	「私たちはネットワーク環境を設計する。私たちはネットワーク環境を設計する。例えば、電力会社など、ある業界を模倣することもある。そして、その環境を侵害し、人工物、デジタル証拠、マルウェアを散乱させる。そして、応募者にこのサイバー事件を調査し、調査結果を発表するよう課す。
At the end of the five days, applicants present their findings, and we identify who has the technical capability and expertise to find digital evidence of a crime hidden within this mountain of data that we've thrown at them.	5日間が終了した時点で、申請者は調査結果を発表し、私たちが投げかけたデータの山の中に隠された犯罪のデジタル証拠を見つける技術的能力と専門知識を持つ者を特定する。
If the applicant passes that phase of that selection exercise, we invite them to participate in a panel presentation. Our CAT members will play the roles of the victims we’re trying to help and their own resource teams, for example, a company CEO, a U.S. attorney, a third-party legal counsel, or IT administrator.	その選考を通過した申請者には、パネル・プレゼンテーションに参加してもらう。CATのメンバーは、私たちが助けようとしている被害者役と、それぞれのリソース・チーム役、たとえば会社のCEO、米国弁護士、第三者の法律顧問、IT管理者などを演じる。
You're essentially giving us the narrative of the cyber intrusion. You're telling us a story about what happened. While some of the panel questions will be very technical in nature, some will be more basic questions—the applicant will need to be able to explain to a CEO, for example, who might not have technical expertise, what the problem was and how to fix it. We're looking to see whether you can take something that's exceptionally technically complex and explain it in such a way that everyone in the room understands it.	あなたは本質的に、サイバー侵入の物語を我々に伝えることになる。何が起こったかについてのストーリーを語っているのだ。パネルの質問の中には、本質的に非常に技術的なものもあるが、より基本的な質問もある。申請者は、例えば技術的な専門知識を持たないCEOに対して、何が問題で、どのように解決するかを説明できる必要がある。技術的に非常に複雑なことを、その場にいる全員が理解できるように説明できるかどうかを見ているのだ。
We're also looking for interpersonal ability. For example, in the case of a company CEO, at that moment during a cyberattack, they may be going through one of the most stressful times of their company's existence—there may be data leaked that can make or break that company's future and their profits, as well as their ability to employ people and their ability to deliver services to their customers. You need the communications skills to interact with them during a difficult time and gain trust."	また、対人能力も見ている。例えば、企業のCEOの場合、サイバー攻撃を受けているその瞬間は、会社の存続に関わる最もストレスの多い時かもしれない。会社の将来や利益を左右しかねないデータが流出し、従業員を雇用する能力や顧客にサービスを提供する能力も失われるかもしれない。困難な時期に彼らと対話し、信頼を得るためのコミュニケーション・スキルが必要なのだ。"
Advanced Digital Forensics Team	アドバンスト・デジタル・フォレンジック・チーム
The Advanced Digital Forensics (ADF) Team is a specialized team of malware reverse engineers and intrusion analysts that works with CAT. The ADF Team assists field offices when the level of malware or intrusion analysis required during an investigation exceeds the field office’s existing capabilities.	アドバンスト・デジタル・フォレンジック（ADF）チームは、マルウェア・リバース・エンジニアと侵入アナリストの専門チームで、CATと連携している。ADF チームは、調査中に必要とされるマルウェアや侵入の分析レベルが、現場事務所の既存の能力を超える場合に、現場事務所を支援する。
"When CAT deploys onsite, we don’t want to overwhelm the victims with FBI personnel," said Ledford. "But there's so many more people involved in the response during that investigation than the folks represented onsite. Our ADF Team is often working on the case remotely in real-time. They're seeing the data we collected in real-time. We're pulling that into our deployment cluster. We're ingesting that data and making it available. And then everyone is jumping in and looking at the data and trying to answer those investigative questions and figure out what happened and connecting the dots."	レドフォードは次のように述べた。「CATが現場に配備される際、FBIの人員で被害者を圧倒したくない。しかし、捜査中の対応には、現場の代表者よりも多くの人々が関わっている。私たちのADFチームは、多くの場合、リアルタイムでリモートで事件に取り組んでいる。彼らは我々が収集したデータをリアルタイムで見ている。我々はそのデータをデプロイメント・クラスターに取り込んでいる。そのデータを取り込み、利用可能にする。そして、誰もが飛び込んでデータを見て、捜査上の疑問に答え、何が起こったのかを突き止め、点と点を結ぼうとしている」。
The ADF Team also assists in analyzing data from ongoing cases. Though these situations may not always be in tandem with a CAT deployment, the field offices and others rely on the ADF Team’s expertise to thoroughly analyze data or break down malware to help the field office understand what the data consists of, what it means, and how they can potentially turn it into an investigative lead to help advance a case.	ADFチームは、現在進行中の事件のデータ分析も支援している。このような状況は、必ずしもCATの展開と連動しているとは限らないが、現場事務所などがデータを徹底的に分析したり、マルウェアを分解したりして、現場事務所がデータの構成や意味を理解し、それを捜査の手がかりに変えて事件を進展させる可能性を理解できるようにするために、ADFチームの専門知識を頼りにしている。
Ledford explained, "ADF operates in the shadow sometimes, but they're as much a part of the FBI's ability and the FBI Cyber Division's ability to respond to cyber adversaries and provide services to victims of computer intrusions, even though they're not always right there onsite with the victim."	レドフォードは、次のように説明した。「ADFは、時には影で活動することもあるが、サイバー敵対者に対応し、コンピュータ侵入の被害者にサービスを提供するFBIの能力、FBIサイバー課の能力の一部である。」

英国 意見募集：ソフトウェアベンダーのための実践規範 (2024.08.02)

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

英国政府は、ソフトウェアの開発と流通における一般的な誤りを防止し、ソフトウェア・ベンダーとその顧客との情報共有を改善のために、ソフトウェアベンダーのための実践規範のドラフトを公表し、意見募集をしていますね...１週間と短いですね...

同時に発表されている「AIのサイバーセキュリティ」と連動しているようです...

● GOV.UK

・2024.08.02 A Code of Practice for Software Vendors: call for views

意見対象は次...

・2024.08.02 Call for views on the Code of Practice for Software Vendors

目次...

Contents	目次
Executive summary	エグゼクティブサマリー
Chapter 1: Introduction	第1章：序文
Chapter 2: DSIT activity	第2章：DSITの活動
Chapter 3: How organisations procuring software should use this Code of Practice	第3章：ソフトウェアを調達する組織は、この実践規範をどのように利用すべきか
Chapter 4: Voluntary Code of Practice for Software Vendors	第4章：ソフトウェアベンダーのための自主規範
Chapter 5: Supporting materials	第5章：参考資料
Chapter 6: How to respond to the call for views	第6章：意見募集への対応方法
Annex A: Full Code of Practice	附属書A：実施規範全文
Annex B: Implementation guidance example	附属書B：実施ガイダンス例
Annex C: Call for views survey questionnaire	附属書C：意見募集調査アンケート

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

Executive summary	エグゼクティブサマリー
In January 2024, the Department for Science, Innovation and Technology (DSIT) published the government response to the call for views on software resilience and security for businesses and organisations. This response outlined the Government’s proposed policy package that aims to raise the baseline expectations of software security, and to improve software resilience across the UK.	2024年1月、科学技術革新省（DSIT）は、企業・組織のためのソフトウェアのレジリエンスとセキュリティに関する意見募集に対する政府の回答を公表した。この回答では、ソフトウェア・セキュリティに対する基本的な期待を高め、英国全体のソフトウェア・レジリエンスを改善することを目的とした、政府の政策パッケージ案を概説した。
This document provides businesses with the opportunity to provide feedback on the Government’s primary proposed policy intervention that was developed in response to engagement with stakeholders: the Code of Practice for Software Vendors.	本書は、利害関係者とのエンゲージメントに応じて策定された政府の主要な政策介入案である「ソフトウェア・ベンダーのための実施規範」に対するフィードバックを提供する機会を企業に提供するものである。
The Code of Practice for Software Vendors outlines the fundamental security and resilience measures that should reasonably be expected of all organisations that develop and / or sell software to organisational customers. It includes guidance on how software should be developed, built, deployed and maintained, and how vendors can communicate with effectively with customers that procure their software. In engaging with this Code of Practice, software vendors will significantly improve the cyber resilience of their product and services.	ソフトウェア・ベンダーのための実施規範」は、ソフトウェアを開発し、あるいは組織の顧客に販売するすべての組織に合理的に期待されるべき基本的なセキュリティとレジリエンスの対策を概説している。これには、ソフトウ ェアをどのように開発、構築、配備、保守すべきか、また、ベンダーがソフトウ ェアを調達する顧客とどのように効果的なコミュニケーションをとるべきか に関する指針も含まれている。この実践規範に取り組むことで、ソフトウェア・ベンダーは、その製品とサービスのサイバー・レジリエンスを大幅に改善することができる。
The Code of Practice is made up of 21 provisions over 4 principles:	この実施規範は、4つの原則を含む21の条項で構成されている：
・Principle 1: Secure design and development: this principle ensures that the product or service is appropriately secure when provided.	・原則1：安全な設計と開発：この原則は、製品やサービスがプロバイダとして提供される際に、適切に安全であることを保証する。
・Principle 2: Build environment security: this principle ensures that the appropriate steps are taken to minimise the risk of build environments becoming compromised and protect the integrity and quality of the software.	・原則2：ビルド環境のセキュリティ：この原則は、ビルド環境が危険にさらされるリスクを最小化し、ソフトウェアの完全性と品質を保護するための適切な措置が講じられていることを保証する。
・Principle 3: Secure deployment and maintenance: this principle ensures that the product or service remains secure throughout its lifetime, to minimise the likelihood and impact of vulnerabilities.	・原則3：安全な配備と保守：この原則は、製品またはサービスがその耐用年数を通じて安全であり続け、脆弱性の可能性と影響を最小化することを保証する。
・Principle 4: Communication with customers: this principle ensures that vendor organisations provide sufficient information to customers to enable effective risk and incident management.	・原則4：顧客とのコミュニケーション：この原則は、効果的なリスクマネジメントとインシデントマネジメントを可能にするために、ベンダー組織が十分な情報を顧客に提供することを保証する。
The Code of Practice, co-designed with industry leaders, academics, and technical experts from the National Cyber Security Centre, has been developed to support any organisation that develops and/or sells software to be sold to organisational customers (B2B). This includes organisations that sell solely software products or services, or organisations selling digital products or services that contain software. The government and co-creators have been mindful that organisations vary in size, capacity and resources, and organisations will have to engage in risk assessments to determine the most effective way in which they can follow this Code of Practice. Nevertheless, the Code of Practice provides clarity on key, underlying principles that represent best practices to help software vendors develop and distribute software securely.	この実施規範は、業界のリーダー、学者、National Cyber Security Centreの技術専門家と共同で策定したもので、組織の顧客（B2B）に販売するソフトウェアを開発・販売するあらゆる組織を支援するために作成された。これには、ソフトウェア製品やサービスのみを販売する組織や、ソフトウェアを含むデジタル製品やサービスを販売する組織が含まれる。政府と共同作成者は、組織の規模、能力、リソースがさまざまであることを念頭に置いており、組織は、この実施規範に従うための最も効果的な方法を決定するために、リスクアセスメントに取り組まなければならない。とはいえ、この実施規範は、ソフトウェアベンダーがソフトウェアを安全に開発・配布するためのベストプラクティスを代表する重要な基本原則を明確にするものである。
Technical controls and implementation guidance will be published alongside the Code of Practice. This will set out the minimum set of objective controls that a software vendor should demonstrate to provide confidence in the resilience of their software product or service as well as guidance to support organisations in identifying the best implementation options for them.	技術的な管理と実装の手引きは、この「実施規範」とともに公表される予定である。これは、ソフトウェアベンダーが、そのソフトウェア製品やサービスのレジリエンスに対する信頼性を提供するために示すべき客観的な管理の最小限のセットと、組織にとって最適な実装オプションを特定するための支援ガイダンスを規定するものである。
This call for views aims to gather views on the market need for the Code of Practice for Software Vendors, the audience that this policy should be addressing, and the suitability of the Code and proposed supporting materials.	この意見募集は、ソフトウェアベンダーのための実施規範の市場ニーズ、この方針が取り組むべき対象者、実施規範と支援資料案の適合性について意見を集めることを目的としている。

・[PDF]

コードプラクティス...

Annex A: Full Code of Practice	附属書 A：実施規範全文
Principle 1: Secure design and development	原則1：安全な設計と開発
This principle ensures that the software product or service is appropriately secure when provided.	この原則は、ソフトウェア製品またはサービスがプロバイダとして提供される際に、適切にセキュアであることを保証するものである。
The Senior Responsible Officer in vendor organisations shall do the following:	ベンダ組織の上級責任者は、以下を実施しなければならない：
1.1 Ensure the organisation follows an established secure development framework.	1.1 組織が確立されたセキュアな開発フレームワークに従っていることを確認する。
1.2 Ensure the organisation understands the composition of their software products and services and that risks linked to the ingestion and maintenance of third-party components, including open-source components, are assessed throughout the lifecycle.	1.2 組織がソフトウェア製品及びサービスの構成を理解し、オープンソースソフトウェアコンポーネントを含むサードパーティ製コンポーネントの取り込み及び保守に関連するリスクを、ライフサイクル全体を通じてアセスメントする。
1.3 Ensure the organisation has a clear process for testing software before distribution.	1.3 組織は、配布前にソフトウェアをテストするための明確なプロセスを持っていることを確認する。
1.4 Ensure that the organisation follows secure by default principles throughout the development lifecycle of the product.	1.4 組織が、製品の開発ライフサイクルを通じて、セキュアバイデフォルトの原則に従うことを確実にする。
The Senior Responsible Officer in vendor organisations should do the following:	ベンダ組織の上級責任者は、以下のことを行うべきである：
1.5 Ensure secure by design principles are followed throughout the development process.	1.5 開発プロセス全体を通じて、セキュアバイデザインの原則に確実に従う。
1.6 Encourage the use of appropriate security tools and technologies to make sure that the default options throughout development and distribution are secure.	1.6 適切なセキュリティツールや技術の使用を奨励し、開発・配布のデフォルトオプショ ンがセキュアであることを確認する。
Principle 2: Build environment security	原則 2: 構築環境のセキュリティ
This principle ensures that the appropriate steps are taken to minimise the risk of build environments becoming compromised and protect the integrity and quality of the software.	この原則は、ビルド環境が危険にさらされるリスクを最小化し、ソフトウエアの完全性と品 質を保護するために適切な措置が取られることを保証するものである。
The Senior Responsible Officer in vendor organisations shall do the following:	ベンダー組織の上級責任者は、以下を実施するものとする：
2.1 Ensure the build environment is protected against unauthorised access.	2.1 ビルド環境が不正アクセスから確実に保護されるようにする。
The Senior Responsible Officer in vendor organisations should do the following:	ベンダ組織の上級責任者は、以下を実施すること：
2.2 Ensure changes to the environment are controlled and logged.	2.2 環境への変更が確実に管理され、履歴が記録されるようにする。
2.3 Ensure you are using a build pipeline you trust.	2.3 信頼できるビルドパイプラインを使用していることを確認する。
Principle 3: Secure deployment and maintenance	原則3：安全な配備と保守
This principle ensures that the product or service remains secure throughout its lifetime, to minimise the likelihood and impact of vulnerabilities.	この原則は、脆弱性の可能性と影響を最小化するために、製品またはサービスがその存続期間を通じて安全であり続けることを保証するものである。
The Senior Responsible Officer in vendor organisations shall do the following:	ベンダー組織の上級責任者は、以下を実施する：
3.1 Ensure that software is distributed securely to customers.	3.1 ソフトウェアが顧客に安全に配布されるようにする。
3.2 Ensure the organisation implements and publishes an effective vulnerability disclosure process.	3.2 組織が効果的な脆弱性開示プロセスを実施し、公開することを確実にする。
3.3 Ensure the organisation has processes in place for proactively detecting and managing vulnerabilities in software components it uses and software it develops, including a documented process to assess the severity of vulnerabilities and prioritise responses.	3.3 組織が、脆弱性の重大性を評価し、対応の優先順位を決定するための文書化されたプロセスを含め、使用するソフトウェアコンポーネント及び開発するソフトウェアの脆弱性を事前に検知し、管理するためのプロセスを備えていることを確実にする。
3.4 Ensure that vulnerabilities are appropriately reported to the relevant parties.	3.4 脆弱性を関係者に適切に報告する。
3.5 Ensure the organisation provides timely security updates, patches and notifications to its customers.	3.5 セキュリティアップデート、パッチ、通知をタイムリーに提供する。
Senior leaders in vendor organisations should do the following:	ベンダー組織のシニアリーダーは、次のことを行うべきである：
3.6 Make a public affirmation that the organisation would welcome security researchers to test software products and services provided by the organisation as part of its vulnerability disclosure process.	3.6 脆弱性公開プロセスの一環として、組織が提供するソフトウエア製品やサービスをセキュリ ティ研究者がテストすることを歓迎することを公言する。
Principle 4: Communication with customers	原則4：顧客とのコミュニケーション
This principle ensures that vendor organisations provide sufficient information to customers to enable effective risk and incident management.	この原則は、効果的なリスクマネジメントとインシデントマネジメントを可能にするために、ベンダ組織が 顧客に十分な情報を提供することを保証するものである。
Senior Responsible Officers in software vendor organisations shall do the following:	ソフトウェアベンダ組織の上級責任者は、以下を実施する：
4.1 Ensure the organisation provides information to the customer, in an accessible way, specifying the level of support and maintenance provided for the software product/ service being sold.	4.1 組織が、販売するソフトウェア製品／サービスに関して提供されるサポート及び保守のレベルを明記した情報を、利用しやすい方法で顧客に提供することを確実にする。
4.2 Ensure the organisation provides at least 1 year’s notice to customers, in an accessible way, of when the product or service will no longer be supported or maintained by the vendor.	4.2 組織は、製品またはサービスがベンダによってサポートまたは保守されなくなる時期について、少なくとも1年前に、利用しやすい方法で顧客に通知することを確実にする。
4.3 Ensure information is made available to customers in an appropriate and timely manner about notable incidents that may cause significant impact to customer organisations.	4.3 顧客組織に重大な影響を及ぼす可能性のある注目すべきインシデントについて、適切かつタイムリーな方法で顧客に情報が提供されるようにする。
Senior Responsible Officers in vendor organisations should do the following:	ベンダー組織の上級責任者は、以下のことを行うべきである：
4.4 Ensure that high level information about the security and resilience standards, frameworks, organisational commitments and procedures followed by the organisation is made available to customers.	4.4 組織が従うセキュリティ及びレジリエンスの標準、枠組み、組織のコミットメント及び 手続きに関するハイレベルの情報が顧客に提供されるようにする。
4.5 Ensure that the organisation proactively supports affected customers during and following a cyber security incident to contain and mitigate the impacts of an incident. How this would be done should be documented and agreed in contracts with the customer.	4.5 組織が、サイバーセキュリティインシデント発生中及び発生後に、影響を受ける顧 客を積極的に支援し、インシデントの影響を抑制・軽減することを確実にする。その方法は、文書化し、顧客との契約で合意する。
4.6 Provide customer organisations with guidance on how to use, integrate, and configure the software product or service securely.	4.6 ソフトウェア製品またはサービスを安全に使用、統合、設定する方法に関するガイダンスを顧客組織に提供する。

サンプル...

Annex B: Implementation guidance example	附属書 B：実装ガイダンスの例
Below is an example of how the implementation guidance will be designed and structured. Work on the accompanying implementation guidance is ongoing, but the guidance will be published alongside the Code of Practice and technical controls detailed above.	以下は、実施ガイダンスの設計と構成の例である。付随する実施ガイダンスの作成は現在進行中であるが、ガイダンスは、上記で詳述した実施規範および技術的管理とともに公表される予定である。
Principle 1: Secure design & development	原則1：安全な設計と開発
Good security engineering means building technologies that remain usable and resilient throughout their lifetime, even in the face of a cyber attack. Achieving this outcome needs to begin in the design and development phase so that user need and security are baked into the product or service. Ensuring that engineering processes and practices minimise both the likelihood and possible impact of a security compromise plays an essential part in gaining assurance in vendor competence and the products and services producing.	優れたセキュリティ工学とは、サイバー攻撃に直面しても、生涯を通じて使用可能でレジリエンスを維持できる技術を構築することである。この成果を達成するためには、設計・開発の段階から着手し、ユーザのニーズとセキュリティを製品やサービスに組み込む必要がある。セキュリティ侵害の可能性と起こりうる影響の両方を最小化するエンジニアリングプロセスと実践を確保することは、ベンダーの能力と製造される製品・サービスに対する保証を得る上で不可欠な役割を果たす。
Developers are not necessarily security experts and the security toolbox available to them can make it difficult to navigate cyber security technical complexities, leading to implementation mistakes that could have been avoided. The selection of the toolbox available to developers should therefore consider its usability and maintenance, as well as functionality and cost. This support to developers can be through access to experts, training, positive security cultures and processes as well as the availability of up-to-date tools.	開発者は必ずしもセキュリティの専門家ではなく、利用可能なセキュリティツールボックスを利用することで、サイバーセキュリティの技術的な複雑性を理解することが難しくなり、回避できたはずの実装ミスにつながる可能性がある。そのため、開発者が利用できるツールボックスの選択は、機能やコストだけでなく、使いやすさや保守性も考慮する必要がある。開発者に対するこのような支援は、専門家へのアクセス、トレーニング、積極的なセキュリ ティ文化やプロセス、最新のツールの利用可能性などを通じて行うことができる。
By implementing the provisions in the Software Vendor Code of Practice, not only will the software product or service be more cyber resilient by default, but it will also be more stable and easier to maintain.	ソフトウェアベンダー規範」の規定を実施することで、ソフトウ ェア製品またはサービスは、デフォルトでよりサイバーレジリエンスに優れ るだけでなく、より安定し、保守も容易になる。
1.1 Ensure the organisation follows an established secure development framework.	1.1 組織が確立された安全な開発フレームワークに従っていることを確認する。
Technical control: Follow a secure development framework.	技術的な管理を行う： セキュアな開発フレームワークに従う。
Using a secure development framework across your engineering projects will provide a consistent and repeatable way to support developers to ensure security has been considered at the right time. They are proactive approaches to building security into a product or service that incorporate people, processes and technology aspects. By not following a secure development framework, important cyber security decisions may #be missing# and inevitably will need to be bolted on at the end of the development process and/or cause more cost during deployment.	エンジニアリングプロジェクト全体でセキュア開発フレームワークを使用するこ とにより、開発者を支援する一貫した反復可能な方法が提供され、適切な時点でセ キュリティが考慮されていることが確認される。セキュア開発フレームワークは、人、プロセス、技術の各側面から製品またはサービスにセ キュリティを組み込むための事前予防的なアプローチである。セキュアな開発フレームワークに従わない場合、重要なサイバーセキュリティに関する意思決定が欠落し、必然的に開発プロセスの最後に追加する必要が生じたり、導入時にコストが増大したりする可能性がある。
You may wish to publish a description of which framework you are using, and which controls have been implemented. You should be able to demonstrate conformance to a secure development framework across your development and deployment activities.	どのフレームワークを使用し、どのような管理策を導入したかを公表するとよい。開発および配備の活動全体にわたって、セキュアな開発フレームワークへの準拠を実証 できるべきである。
A good secure development framework should include the following topics as a minimum:	優れたセキュア開発フレームワークには、最低限以下の項目を含めるべきである：
Threat modelling – techniques used to understand how the product or service might be attacked or otherwise fail.	脅威モデリング - 製品やサービスがどのように攻撃される可能性があ るか、あるいは他の方法で失敗する可能性があるかを理解するた めに使用される技術
Requirements capture – understanding and recording security and user needs.	要件の収集 - セキュリティ及びユーザのニーズを理解し、記録する。
Governance and roles – how the approach to ensuring secure design & development is controlled and directed.	ガバナンスと役割 - 安全な設計・開発を確保するためのアプローチがどのように管理され、指揮されるか。
Test strategy – consistent approaches to verification that have sufficient rigour and coverage.	テスト戦略 - 十分な厳密性と網羅性を有する検証への一貫したアプロー チを行う。
Data management – understanding what data exists and how it should be appropriately protected throughout its lifecycle.	データ管理 - どのようなデータが存在し、ライフサイクルを通じてどのように 適切に保護されるべきかを理解する。
Configuration management – consistent approaches to tracking changes, implementing version control, and enabling reproducibility.	構成管理 - 変更を追跡し、バージョン管理を実施し、再現性を可能にする一貫したアプローチ。
Which secure development framework you decide to use is a business decision based on what will fit best with the culture and existing processes of your organisation. There are many secure development frameworks available “off-the-shelf”, examples include:	どのセキュア開発フレームワークを使用するかは、組織の文化や既存のプロ セスに最も適合するものに基づいて、ビジネス上の意思決定を行う。多くのセキュア開発フレームワークが「既製品」として入手可能である：

個人情報保護委員会 第１回 個人情報保護法のいわゆる３年ごと見直しに関する検討会

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

「第１回 個人情報保護法のいわゆる３年ごと見直しに関する検討会」が2024.07.31に開催されていますね...

● 個人情報保護委員会

・2024.07.31 １回 個人情報保護法のいわゆる３年ごと見直しに関する検討会

「個人情報保護法　いわゆる３年ごと見直しに係る検討の中間整理」に関する意見募集について議論されることになっていたようですね...

資料...

[PDF]	資料１	開催要綱（案）
[PDF]	資料２	主婦連合会御提出資料
[PDF]	資料３	新経済連盟御提出資料
[PDF]	資料４	全国消費者団体連絡会御提出資料
[PDF]	資料５	全国消費生活相談員協会御提出資料
[PDF]	資料６	日本IT 団体連盟御提出資料
[PDF]	資料７	日本経済団体連合会御提出資料
[PDF]	参考資料１	「個人情報保護法 いわゆる３年ごと見直しに係る検討の中間整理」概要
[PDF]	参考資料２	「個人情報保護法 いわゆる３年ごと見直しに係る検討の中間整理」本文

委員については、事前に発表されていますね。。。森先生がメンバーですね...

・2024.07.24 個人情報保護法のいわゆる３年ごと見直しに関する検討会の開催について

・・[PDF] 個人情報保護法のいわゆる３年ごと見直しに関する検討会構成員等名簿

---

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

・2024.06.28 個人情報保護委員会 意見募集 いわゆる3年ごと見直しに係る検討の中間整理

米国 NIST SP 800-231 バグフレームワーク（BF）： サイバーセキュリティの弱点と脆弱性の公式化

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

NISTが、NIST SP 800-231 バグフレームワーク（BF）： サイバーセキュリティの弱点と脆弱性の公式化を公表しましたね...

これだけで、76ページありますが、これから続々とこのシリーズが公表されるようですね...

● NIST - ITL

プレス

・2024.07.30 NIST Releases SP 800-231, Bugs Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities

NIST Releases SP 800-231, Bugs Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities	NIST、SP 800-231「Bugs Framework（BF）」をリリース： サイバーセキュリティの弱点と脆弱性を形式化する
NIST Special Publication (SP) 800-231, Bugs Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities, is now available. It presents an overview of the Bugs Framework (BF) systematic approach and methodologies for the classification of bugs and faults per orthogonal by operation software and hardware execution phases, formal specification of weaknesses and vulnerabilities, definition of secure coding principles, generation of comprehensively labeled weakness and vulnerability datasets and vulnerability classifications, and development of BF-based algorithms and systems.	NIST特別刊行物（SP）800-231「Bugs Framework（BF）：サイバーセキュリティの弱点と脆弱性を形式化する」が公開された： サイバーセキュリティの弱点と脆弱性を形式化する）が入手可能になった。本書は、バグズ・フレームワーク（Bugs Framework：BF）の体系的なアプローチと、ソフトウェアとハードウェアの実行フェーズによる直交ごとのバグと障害の分類、弱点と脆弱性の正式な仕様化、安全なコーディング原則の定義、包括的にラベル付けされた弱点と脆弱性のデータセットと脆弱性の分類の生成、BFに基づくアルゴリズムとシステムの開発のための方法論の概要を示している。
The current state of the art in describing security weaknesses and vulnerabilities are the Common Weakness Enumeration (CWE) and the Common Vulnerabilities and Exposures (CVE). However, the CWE and CVE use a one-dimensional list approach to organizing the entries and natural language descriptions. They do not exhibit methodologies for systematic comprehensive labeling of weaknesses and vulnerabilities, tracking the weaknesses underlying a vulnerability, or root cause identification from a security failure.	セキュリティの弱点と脆弱性を記述する技術の現状は、CWE（Common Weakness Enumeration）とCVE（Common Vulnerabilities and Exposures）である。しかし、CWEとCVEは、項目と自然言語の記述を整理するために、一次元のリストアプローチを使用している。これらは、弱点と脆弱性の体系的で包括的なラベリング、脆弱性の根底にある弱点の追跡、セキュリティ障害からの根本原因の特定などの方法論を示していない。
SP 800-231 presents the BF formal system (and methods) that comprises:	SP 800-231 は、BF 形式システム（および方法）を提示している：
・Bugs models of distinct execution phases with orthogonal sets of operations in which specific bugs and faults could occur	特定のバグや欠陥が発生する可能性のある操作の直交するセットを持つ、明確な実行フェーズのバグモデル
・Structured, multidimensional, orthogonal, and context-free weakness taxonomies	構造化された、多次元、直交、文脈自由な脆弱性分類法
・Vulnerability state and specification models as chains of weaknesses toward failures	故障に向かう弱点の連鎖としての脆弱性の状態と仕様モデル
・A formal language for the unambiguous causal specification of weaknesses and vulnerabilities	弱点と脆弱性の因果関係を明確に規定するための形式言語
・Tools that facilitate the generation of CWE2BF and CVE2BF mappings and formal weakness and vulnerability specifications and their graphical representations	CWE2BFとCVE2BFのマッピング、弱点と脆弱性の公式仕様とそのグラフィカル表現の生成を容易にするツール。
The BF formalism guarantees precise descriptions with clear causality of weaknesses (including CWE) and vulnerabilities (including CVE) and complete, orthogonal, and context-free weakness-type coverage. It forms the basis for the formal definition of secure coding principles, such as memory safety. It also enables the creation of comprehensively labeled weakness and vulnerability datasets, vulnerability classifications, and BF-based bug identification and vulnerability detection, analysis, and resolution or mitigation systems.	BFフォーマリズムは、弱点（CWEを含む）と脆弱性（CVEを含む）の因果関係を明確にした正確な記述と、完全、直交、文脈のない弱点タイプカバレッジを保証する。メモリ安全性のようなセキュアコーディング原則の形式的定義の基礎を形成する。また、包括的にラベル付けされた弱点と脆弱性のデータセット、脆弱性の分類、BFに基づくバグの特定と脆弱性の検出、分析、解決または緩和システムの作成を可能にする。

本文

・2024.07.30 NIST SP 800-231 Bug Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities

NIST SP 800-231 Bug Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities	NIST SP 800-231 バグフレームワーク（BF）： サイバーセキュリティの弱点と脆弱性の公式化
Abstract	概要
The Bugs Framework (BF) is a classification of security bugs and related faults that features a formal language for the unambiguous specification of software and hardware security weaknesses and vulnerabilities. BF bugs models, multidimensional weakness and failure taxonomies, and vulnerability models define the lexis, syntax, and semantics of the BF formal language and form the basis for the definition of secure coding principles. The BF formalism supports a deeper understanding of vulnerabilities as chains of weaknesses that adhere to strict causation, propagation, and composition rules. It enables the generation of comprehensively labeled weakness and vulnerability datasets and multidimensional vulnerability classifications. It also enables the development of new algorithms for code analysis and the use of AI models and formal methods to identify bugs and detect, analyze, prioritize, and resolve or mitigate vulnerabilities.	バグフレームワーク（Bugs Framework：BF）は、ソフトウェアやハードウェアのセキュリティ上の弱点や脆弱性を明確に仕様化するための形式的な言語を特徴とする、セキュリティ上のバグや関連する障害の分類である。BFのバグモデル、多次元的な弱点と故障の分類法、脆弱性モデルは、BF形式言語の語彙、構文、意味論を定義し、安全なコーディング原則の定義の基礎を形成する。BFフォーマリズムは、厳密な因果関係、伝播、合成規則に従う弱点の連鎖として、脆弱性をより深く理解することをサポートする。これにより、包括的にラベル付けされた弱点と脆弱性のデータセットと、多次元的な脆弱性の分類を生成することができる。また、コード解析のための新しいアルゴリズムの開発や、バグを特定し、脆弱性を検出、分析、優先順位付け、解決または緩和するためのAIモデルと形式的手法の利用も可能になる。

[PDF] NIST.SP.800-231

目次...

1. Introducton	1. 導入
2. Current State of the Art	2. 技術の現状
3. Bugs Framework Formalism	3. バグズ・フレームワークの形式論
3.1. BF Operaton	3.1. BF演算子
3.2. BF Bug, Fault, and Weakness	3.2. BF バグ、故障、弱点
3.3. BF Vulnerability	3.3. BFの脆弱性
3.4. BF Bug Identficaton	3.4. BFバグの特定
4. BF Security Concepts	4. BFのセキュリティ概念
5. BF Bugs Models	5. BFバグのモデル
5.1. BF Input/Output Check ( INP) Bugs Model	5.1. BF入出力チェック（INP）バグ・モデル
5.2. BF Memory ( MEM) Bugs Model	5.2. BF メモリ ( MEM ) バグモデル
5.3. BF Data Type ( DAT) Bugs Model	5.3. BFデータ型（DAT）バグモデル
6. BF Taxonomy	6. BF分類法
6.1. BF Weakness Classes	6.1. BF弱点クラス
6.2. BF Failure Class	6.2. 故障クラス
6.3. BF Methodology	6.3. BFメソドロジー
7. BF Vulnerability Models	7. BF脆弱性モデル
7.1. BF Vulnerability State Model	7.1. BF脆弱性状態モデル
7.2. BF Vulnerability Specificaton Model	7.2. BF脆弱性特定化モデル
8. BF Formal Language	8. BF形式言語
8.1. BF Lexis	8.1. BFレクシス
8.2. BF Syntax	8.2. BF構文
8.3. BF Semantcs	8.3. BFの意味
9. BF Secure Coding Principles	9. BFセキュアコーディングの原則
9.1. Input/Output Check Safety	9.1. 入出力チェックの安全性
9.2. Memory Safety	9.2. メモリの安全性
9.3. Data Type Safety	9.3. データ型の安全性
10. BF Tools	10. BFツール
10.1. BFCWE Tool	10.1. BFCWEツール
10.2. BFCVE Tool	10.2. BFCVEツール
10.3. BF GUI Tool	10.3. BF GUIツール
11. BF Datasets and Systems	11. BFデータセットとシステム
11.1. BFCWE Dataset	11.1. BFCWEデータセット
11.2. BFCVE Dataset	11.2. BFCVEデータセット
11.3. BF Vulnerability Classificatons	11.3. BF脆弱性分類
11.4. BF Systems	11.4. BFシステム
12. Conclusion	12. おわりに
References	参考文献

米国 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] 仮訳

英国 RUSI ランサムウェア被害者の体験

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

英国のシンクタンク、英国王立防衛安全保障研究所 (The Royal United Services Institute for Defence and Security Studies; RUSI) が、ランサムウェ被害者等へのインタビューを取りまとめた報告書を公表していますね...

興味深いです...

● The Royal United Services Institute for Defence and Security Studies; RUSI

・2024.07.02 ‘Your Data is Stolen and Encrypted’: The Ransomware Victim Experience

‘Your Data is Stolen and Encrypted’: The Ransomware Victim Experience	「データが盗まれ、暗号化された」： ランサムウェア被害者の体験
This paper aims to understand the wide range of harm caused by ransomware attacks to individuals, organisations and society at large.	本稿の目的は、ランサムウェア攻撃によって個人、組織、社会全体にもたらされる幅広い被害を理解することである。
More individuals and organisations in the UK and globally are becoming victims of ransomware. However, little is known about their experiences. This paper sheds light on the victim experience and identifies several key factors that typically shape such experiences. These factors are context specific and can either improve or worsen the victim experience. They include the following:	ランサムウェアの被害者となる個人や組織は、英国だけでなく世界的に増加している。しかし、彼らの経験についてはほとんど知られていない。本稿では、被害者の経験に光を当て、そのような経験を形成するいくつかの重要な要因を特定する。これらの要因は文脈に固有であり、被害体験を改善することも悪化させることもある。それらには以下のようなものがある：
Timing of an incident, which may happen after a victim has increased their cyber security measures or at an already stressful time for an organisation, such as the beginning of a school year.	インシデントが発生したタイミング（被害者がサイバーセキュリティ対策を強化した後や、学年の初めなど、組織にとってすでにストレスの多い時期に発生する可能性がある）。
Level of preparation in the form of strong cyber security measures and contingency plans explicitly tailored to respond to a cyber incident.	強力なサイバーセキュリティ対策や、サイバーインシデントへの対応を明確にしたコンティンジェンシープランなどの準備レベル。
Human factors, such as the workplace environment and pre-existing dynamics which are often reinforced during an incident. Good levels of unity can bring staff together during a moment of crisis, but a lack of leadership or a blame culture are likely to aggravate the harm experienced during the incident.	インシデント発生時に強化されることの多い職場環境や既存の力学などの人的要因。良好な団結力は、危機の瞬間にスタッフを団結させることができるが、リーダーシップの欠如や非難文化は、インシデント中に経験した被害を悪化させる可能性が高い。
Engagement with third-party service providers, such as those providing technical incident response or legal services, can alleviate the negative aspects of the victim experience by providing critical legal, technical or other help. However, they may aggravate the harm by providing poor services or losing valuable time in responding to the incident.	技術的なインシデント対応や法的サービスを提供するプロバイダなど、サードパーティーのサービスプロバイダとの関わりは、重要な法的、技術的、その他の支援を提供することによって、被害者の体験の否定的な側面を軽減することができる。しかし、不十分なサービスを提供したり、インシデント対応に貴重な時間を費やしたりすることで、被害を悪化させる可能性もある。
A successful communications campaign is highly context- and victim-specific. It must include external and internal communications with staff members not part of the immediate response to ensure a good workplace culture.	コミュニケーション・キャンペーンを成功させるためには、被害者の状況に特化したものでなければならない。良好な職場風土を確保するためには、緊急対応に加わっていないスタッフとの外部および内部コミュニケーションを含めなければならない。
For support, many victims turn to public sector institutions such as law enforcement. Expectations for technical support and expertise from law enforcement are generally low, but victims feel especially unsupported where phone calls are not returned and there is no engagement or feedback loop. The National Cyber Security Centre enjoys a better reputation. However, there is widespread uncertainty about its role and the thresholds that must be met for it to provide support. This poses a reputational risk.	被害者の多くは、法執行機関などの公的機関に支援を求める。法執行機関に対する技術支援や専門知識への期待は一般的に低いが、被害者は、電話がつながらない、関与やフィードバックのループがない場合、特に支援されていないと感じる。国家サイバーセキュリティセンターの評判は良い。しかし、同センターの役割や、同センターが支援を提供するために満たさなければならない基準値については、広く不透明な部分がある。これは風評リスクをもたらす。
Understanding how ransomware attacks are personally felt by victims and what factors aggravate or alleviate the harm they experience is key for policymakers seeking to implement measures to minimise harm as much as possible.	ランサムウェア攻撃を受けた被害者が個人的にどのように感じているのか、どのような要因が被害を悪化させたり軽減させたりしているのかを理解することは、被害を可能な限り最小化するための対策を実施しようとする政策立案者にとって重要である。

・[PDF] 

・[DOCX][PDF] 仮訳

目次...

Executive Summary	エグゼクティブ・サマリー
Summary of Recommendations	提言のまとめ
Introduction	はじめに
I. Existing Insights on the Ransomware Victim Experience	I.ランサムウェア被害者の経験に関する既存の洞察
II. Factors Affecting the Victim Experience	II.被害者体験に影響を与える要因
The Scale, Timing and Context of the Incident	インシデントの規模、時期、背景
Size of Organisation	組織の規模
Level of Preparation	準備のレベル
Pre-Existing Workplace Culture	既存の職場文化
Paying (or Not Paying) a Ransom Demand	身代金要求の支払い（あるいは不払い）について
Internal and External Communications	社内外コミュニケーション
Transparency and Information Sharing	透明性と情報共有
The Influence of Regulators	規制当局の影響力
III. The Role of Government, the NCSC and Law Enforcement	III.政府、NCSC、法執行機関の役割
Types of Support	サポートの種類
How NCSC and Law Enforcement Support is Allocated	NCSCと法執行機関の支援の配分方法
The Impact of Police Support: Perspectives from Victims and Stakeholders	警察の支援の影響：被害者と関係者の視点
The Impact of NCSC and NCA Support: Perspectives from Victims and Stakeholders	NCSCとNCAの支援の影響：被害者とステークホルダーからの視点
Conclusion and Recommendations	結論と提言
Recommendations for Victims and Victim Organisations	被害者と被害組織への提言
Recommendations for Private Sector Service Providers	民間サービス・プロバイダーへの提言
Recommendations for Policymakers and Public Institutions	政策立案者と公的機関への提言
About the Authors	著者について

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

Executive Summary	エグゼクティブ・サマリー
More individuals and organisations in the UK and globally are becoming victims of ransomware. However, little is known about their experiences. This paper sheds light on the victim experience and identifies several key factors that typically shape such experiences.	ランサムウェアの被害に遭う個人や組織が、英国をはじめ世界的に増えている。しかし、彼らの体験についてはほとんど知られていない。本稿では、被害者の体験に光を当て、そのような体験を形成するいくつかの重要な要因を明らかにする。
These factors are context-specific and can either improve or worsen the victim experience. They include the following:	これらの要因は状況によって異なり、被害者の体験を改善することも悪化させることもある。以下のようなものがある：
• Timing of an incident, which may happen after a victim has increased their cyber security measures or at an already stressful time for an organisation, such as the beginning of a school year.	• インシデントが発生するタイミングは、被害者がサイバーセキュリティ対策を強化した後や、年度初めなど組織にとってすでにストレスの多い時期に発生する可能性がある。
• Level of preparation in the form of strong cyber security measures and contingency plans explicitly tailored to respond to a cyber incident.	• 強力なサイバーセキュリティ対策と、サイバーインシデントに対応するために明確に調整されたコンティンジェンシープランという形での準備のレベル。
• Human factors, such as the workplace environment and pre-existing dynamics which are often reinforced during an incident. Good levels of unity can bring staff together during a moment of crisis, but a lack of leadership or a blame culture are likely to aggravate the harm experienced during the incident.	• 職場環境や既存の力関係などの人的要因は、インシデント時に強化されることが多い。良好な団結力は、危機の瞬間にスタッフを団結させることができるが、リーダーシップの欠如や非難文化は、インシデント時に経験した被害を悪化させる可能性が高い。
• Engagement with third-party service providers, such as those providing technical incident response or legal services, can alleviate the negative aspects of the victim experience by providing critical legal, technical or other help. However, they may aggravate the harm by providing poor services or losing valuable time in responding to the incident.	• 技術的なインシデント対応や法的サービスを提供するような第三者サービス・プロバイダーとの関わりは、重要な法的、技術的、またはその他の支援を提供することによって、被害者の経験の否定的な側面を軽減することができる。しかし、不十分なサービスを提供したり、インシデントに対応するために貴重な時間を失ったりすることで、被害を悪化させる可能性もある。
• A successful communications campaign is highly context and victim specific. It must include external and internal communications with staff members not part of the immediate response to ensure a good workplace culture.	• 成功するコミュニケーション・キャンペーンは、非常に文脈や被害者に特化したものである。良好な職場風土を確保するためには、緊急対応に加わっていないスタッフとの外部・内部コミュニケーションを含めなければならない。
For support, many victims turn to public sector institutions such as law enforcement. Expectations for technical support and expertise from law enforcement are generally low, but victims feel especially unsupported where phone calls are not returned and there is no engagement or feedback loop. The National Cyber Security Centre enjoys a better reputation. However, there is widespread uncertainty about its role and the thresholds that must be met for it to provide support. This poses a reputational risk.	被害者の多くは、法執行機関などの公的機関に支援を求めている。法執行機関に対する技術支援や専門知識への期待は一般的に低いが、被害者は、電話がつながらない、関与やフィードバックのループがないなど、特に支援されていないと感じている。国家サイバーセキュリティセンターの評判は良い。しかし、同センターの役割や、同センターが支援を提供するために満たさなければならない基準値については、広く不透明な部分がある。これは風評リスクをもたらしている。
Understanding how ransomware attacks are personally felt by victims and what factors aggravate or alleviate the harm they experience is key for policymakers seeking to implement measures to minimise harm as much as possible.	ランサムウェア攻撃を受けた被害者が個人的にどのように感じているのか、またどのような要因が被害を悪化させたり軽減させたりしているのかを理解することは、被害を可能な限り最小化するための対策を実施しようとする政策立案者にとって重要な鍵となる。
Summary of Recommendations	提言のまとめ
• While ransomware causes many kinds of harm, mitigating the psychological impact of ransomware attacks needs to be at the centre of the support given to (potential) victims preparing for and responding to a ransomware incident.	• ランサムウェアは様々な被害をもたらすが、ランサムウェア攻撃による心理的影響を軽減することは、ランサムウェアのインシデントに備え、対応する（潜在的な）被害者へのサポートの中心に据える必要がある。
ú   Third-party service providers also need to recognise that efforts mitigating the psychological impact of ransomware attacks are critical to improving victims’ experience. They must therefore form part of their technical, legal or other services.	ú   サードパーティのサービスプロバイダーもまた、ランサムウェア攻撃の心理的影響を緩和する取り組みが、被害者の体験を改善するために不可欠であることを認識する必要がある。そのため、技術的、法的、その他のサービスの一部を構成する必要がある。
ú   Public policy on ransomware must centre on measures that mitigate victims’ harm. This includes acknowledging and mitigating the psychological impact on victims, for example through counselling, compensation or time off in lieu.	ú   ランサムウェアに関する公共政策は、被害者の被害を軽減する対策を中心に据える必要がある。これには、例えばカウンセリング、補償、代休などを通じて、被害者の心理的影響を認め、軽減することが含まれる。
• Victims should aim for the right balance of discretion and transparency within their external and internal communications.	• 被害者は、対外的および対内的なコミュニケーションにおいて、慎重さと透明性の適切なバランスを目指すべきである。
• Third-party service providers should actively enable information sharing, subject to the consent of parties, among past, current and potential victims through their networks.	• 第三者サービス・プロバイダーは、当事者の同意を前提に、過去、現在、潜在的な被害者の間で、ネットワークを通じた情報共有を積極的に可能にすべきである。
• Law enforcement and intelligence agencies should establish a positive feedback loop that shares success stories and notifies victims when the information they share has been successfully used for intelligence and law enforcement activities.	• 法執行機関と情報機関は、成功事例を共有し、被害者が共有した情報が諜報活動や法執行活動にうまく利用された場合に被害者に通知する、前向きなフィードバック・ループを確立すべきである。
• Government authorities need to clarify the tasks of relevant public institutions and their role in the ransomware response, including who can receive support and under what circumstances.	• 政府当局は、誰がどのような状況で支援を受けることができるかを含め、ランサムウェア対応における関連公的機関の任務とその役割を明確にする必要がある。
• Given year-on-year increases in the frequency of incidents, the resourcing of the Information Commissioner’s Office should be routinely assessed to enable timely assessments of ransomware breaches.	• インシデントの発生頻度が年々増加していることから、ランサムウェアによる侵害をタイムリーに評価できるよう、情報コミッショナー事務局のリソースを定期的に評価すべきである。

循環取引に対応する内部統制に関する共同研究報告 by 公益社団法人日本監査役協会、一般社団法人日本内部監査協会、日本公認会計士協会 (2023.04.08)

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

公益社団法人日本監査役協会、一般社団法人日本内部監査協会、日本公認会計士協会が共同で「循環取引に対応する内部統制に関する共同研究報告」を取りまとめて、発表していましたね...

このブログでも紹介していますが、昨年の11月27日にドラフトを公開し、意見募集した結果を踏まえたものになっていますね...

いろいろなコメントは、公開草案を紹介したブログ記事に書いています(^^)

● 日本内部監査協会

・2024.04.08「循環取引に対応する内部統制に関する共同研究報告」の公表について

[PDF] 

● 日本監査役協会

・2024.04.08 「循環取引に対応する内部統制に関する共同研究報告」を公表

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

・2023.11.30 公認会計士協会 「循環取引に対応する内部統制に関する共同研究報告」（公開草案）

・2022.09.05 証券取引等監視委員会 開示検査事例集（令和３事務年度）

・2020.03.13 ネットワンシステムズ 「納品実体のない取引に関する調査　最終報告書（開示版）」

・2020.01.28 循環取引

・2011.10.24 公認会計士協会 確定 ＩＴ委員会研究報告「ＩＴに対応した監査手続事例～事例で学ぶよくわかるＩＴに対応した監査～」

・2011.07.10 公認会計士協会 パブコメ ＩＴ委員会研究報告「ＩＴに対応した監査手続事例～事例で学ぶよくわかるＩＴに対応した監査～」

・2008.07.28 監査提言集から読み取る内部統制の文書化の限界・・・

・2008.07.22 JICPA 監査提言集

・2007.07.15 東証 加ト吉の改善報告書

・2007.04.25 加ト吉 「不適切な取引行為に関する報告等」

Five Eyes 中国国家主導のサイバー活動： 重要インフラリーダーのための行動 (2024.03.19)

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

Five Eyesが、「中国国家主導のサイバー活動： 重要インフラリーダーのための行動」を公表していますね...ボルトタイフーンの脅威に対するインフラ事業者向けの行動指針ということのようです...

● CISA

・2024.03.19 PRC State-Sponsored Cyber Activity: Actions for Critical Infrastructure Leaders

PRC State-Sponsored Cyber Activity: Actions for Critical Infrastructure Leaders	中国国家主導のサイバー活動： 重要インフラリーダーのための行動
The fact sheet, PRC State-Sponsored Cyber Activity: Actions for Critical Infrastructure Leaders, warns critical infrastructure leaders of the urgent risk posed by Volt Typhoon and provides guidance on specific actions to prioritize the protection of their organization from this threat activity.	ファクトシート「中国国家主導のサイバー活動：重要インフラリーダーのための行動」は、ボルトタイフーンがもたらす緊急リスクを重要インフラリーダーに警告し、この脅威活動から組織を守ることを優先するための具体的行動に関する指針を提供している。
CISA and its partners strongly urge critical infrastructure organizations leaders to read the guidance provided in the joint fact sheet to defend against this threat. For more information on Volt Typhoon related activity, see PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure alongside supplemental Joint Guidance: Identifying and Mitigating Living off the Land Techniques. To learn more about secure by design principles and practices, visit Secure by Design.	CISAとそのパートナーは、重要インフラ組織のリーダーに対し、この脅威から身を守るために共同ファクトシートで提供されているガイダンスを読むよう強く求めている。ボルト台風に関連する活動の詳細については、補足的な共同ガイダンスとともに、「中国の国家支援組織が米国の重要インフラを侵害し、持続的なアクセスを維持している。」を参照のこと： 現地調達技術の識別と低減」を参照されたい。セキュア・バイ・デザインの原則と実践の詳細については、セキュア・バイ・デザインを参照のこと。

・[PDF]

サマリー...

Summary	概要
This fact sheet provides an overview for executive leaders on the urgent risk posed by People’s Republic of China (PRC) state-sponsored cyber actors known as “Volt Typhoon.” CISA—along with the National Security Agency (NSA), the Federal Bureau of Investigation (FBI), and other U.S. government and international partners[1]—released a major advisory on Feb. 7, 2024, in which the U.S. authoring agencies warned cybersecurity defenders that Volt Typhoon has been pre-positioning themselves on U.S. critical infrastructure organizations’ networks to enable disruption or destruction of critical services in the event of increased geopolitical tensions and/or military conflict with the United States and its allies. This is a critical business risk for every organization in the United States and allied countries.[2]	このファクトシートは、「ボルト・タイフーン」として知られる中華人民共和国（PRC）の国家支援によるサイバー行為者がもたらす緊急リスクについて、経営幹部向けに概要を説明するものである。CISAは2024年2月7日、国家安全保障局（NSA）、連邦捜査局（FBI）、その他の米国政府および国際的なパートナー[1]とともに重大な勧告を発表し、その中で米国の認可機関は、ボルトタイフーンが地政学的な緊張の高まりや米国およびその同盟国との軍事衝突が発生した場合に、重要なサービスの中断や破壊を可能にするために、米国の重要インフラ組織のネットワーク上にあらかじめ配置されていることをサイバーセキュリティの擁護者に警告した。これは、米国および同盟国のすべての組織にとって重大なビジネスリスクである[2]。
The advisory provides detailed information related to the groups’ activity and describes how the group has successfully compromised U.S. organizations, especially in the Communications, Energy, Transportation Systems, and Water and Wastewater Systems Sectors.[3] The authoring organizations urge critical infrastructure owners and operators to review the advisory for defensive actions against this threat and its potential impacts to national security.	この勧告は、グループの活動に関連する詳細な情報を提供し、特にコミュニケーション、エネルギー、輸送システム、上下水道システム部門において、グループがどのように米国の組織への侵害に成功したかを説明している[3]。認可団体は、重要インフラの所有者および運営者に対し、この脅威および国家安全保障への潜在的な影響に対する防御措置のために、この勧告を確認するよう促している。
CISA and partners[4] are releasing this fact sheet to provide leaders of critical infrastructure entities with guidance to help prioritize the protection of critical infrastructure and functions. The authoring agencies urge leaders to recognize cyber risk as a core business risk. This recognition is both necessary for good governance and fundamental to national security.	CISAとパートナー[4]は、重要インフラ事業体のリーダーに、重要インフラと機能の防御に優先順位をつけるための指針を提供するために、このファクトシートを公表する。認可機関は、サイバー・リスクを中核的な事業リスクとして認識するようリーダーに促す。この認識は、優れたガバナンスに必要であると同時に、国家安全保障の基本である。

[1] U.S. Department of Energy (DOE), U.S. Environmental Protection Agency (EPA), U.S. Transportation Security Administration (TSA), Australian Signals Directorate’s (ASD’s) Australian Cyber Security Centre (ACSC), Canadian Communications Security Establishment’s (CSE’s) Canadian Centre for Cyber Security (CCCS), United Kingdom National Cyber Security Centre (NCSC-UK), and New Zealand National Cyber Security Centre (NCSC-NZ)	[1] 米国エネルギー省（DOE）、米国環境保護局（EPA）、米国運輸保安局（TSA）、オーストラリア信号局（ASD）のオーストラリア・サイバー・セキュリティ・センター（ACSC）、カナダコミュニケーション・セキュリティ・エスタブリッシュメント（CSE）のカナダ・サイバー・セキュリティ・センター（CCCS）、英国国家サイバー・セキュリティ・センター（NCSC-UK）、ニュージーランド国家サイバー・セキュリティ・センター（NCSC-NZ）。
[2] CCCS assesses that Canada would likely be affected as well, due to cross-border integration. ASD’s ACSC and NCSC-NZ assess Australian and New Zealand critical infrastructure, respectively, could be vulnerable to similar activity from PRC state-sponsored actors.	[2] CCCSは、国境を越えた統合により、カナダも影響を受ける可能性が高いと評価している。ASDのACSCとNCSC-NZは、それぞれオーストラリアとニュージーランドの重要インフラが、PRCの国家支援者による同様の活動に対して脆弱性を持つ可能性があると評価している。
[3] See Critical Infrastructure Sectors | CISA for descriptions of critical infrastructure sectors.	[3] 重要インフラ部門の説明については、重要インフラ部門｜CISAを参照のこと。
[4] NSA, FBI, DOE, EPA, TSA, U.S. Department of the Treasury, ASD’s ACSC, CCCS, NCSC-UK, and NCSC-NZ	[4] NSA、FBI、DOE、EPA、TSA、米国財務省、ASDのACSC、CCCS、NCSC-UK、およびNCSC-NZ。

---

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

・2024.02.12 Five Eyes 中華人民共和国の支援を受けたサイバーアクターが米国の重要インフラに潜伏し、攻撃できる体制を整えていると判断... (2024.02.07)

・2024.02.03米国 司法省 重要インフラのハッキングを隠蔽するために使用された中華人民共和国のボットネットを破壊（だから、IoT認証が重要...）

・2023.06.11 Five Eyes 中華人民共和国の国家支援サイバー攻撃者は検知を逃れるために現地調達型対応をする (2023.05.24)