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.	・重要インフラプロバイダー

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

↓

Best practices	ベストプラクティス
Enterprise-approved event logging policy	エンタープライズが承認したイベントロギングポリシー
Developing and implementing an enterprise approved logging policy improves an organisation’s chances of detecting malicious behaviour on their systems and enforces a consistent method of logging across an organisation’s environments. The logging policy should take into consideration any shared responsibilities between service providers and the organisation. The policy should also include details of the events to be logged, event logging facilities to be used, how event logs will be monitored, event log retention durations, and when to reassess which logs are worthy of collection.	エンタープライズが承認したロギングポリシーを策定し、実施することは、組織のシステム上の悪意ある行動を検知する可能性を向上させ、組織の環境全体で一貫したロギング方法を強制する。ロギングポリシーは、サービスプロバイダーと組織の間で共有される責任を考慮すべきである。ポリシーはまた、ロギングされるイベント、使用されるイベントロギング機能、イベントログの監視方法、イベントログの保存期間、どのログが収集に値するか再評価する時期などの詳細を含むべきである。
Event log quality	イベントログの品質
Organisations are encouraged to implement an event logging policy focused on capturing high-quality cyber security events to aid network defenders in correctly identifying cyber security incidents. In the context of cyber security incident response and threat detection, event log quality refers to the types of events collected rather than how well a log is formatted. Log quality can vary between organisations due to differences in network environments, the reason behind the need to log, differences in critical assets and the organisation’s risk appetite.	組織は、ネットワーク防御者がサイバーセキュリティインシデントを正しく識別するのを支援するために、高品質のサイバーセキュリティイベントをキャプチャすることに重点を置いたイベントロギング方針を実施することが推奨される。サイバーセキュリティのインシデント対応と脅威検知の文脈では、イベントログの品質とは、ログの書式の良し悪しよりも、収集されたイベントの種類を指す。ログの質は、ネットワーク環境の違い、ログの必要性の理由、重要な資産の違い、組織のリスク選好度によって、組織によって異なる可能性がある。
Useful event logs enrich a network defender’s ability to assess security events to identify whether they are false positives or true positives. Implementing high-quality logging will aid network defenders in discovering LOTL techniques that are designed to appear benign in nature.	有用なイベント・ログは、セキュリティ・イベントをアセスメントし、誤検知か真陽性かを識別するネットワーク防御者の能力を高める。高品質なロギングを実装することは、ネットワーク防御者が LOTL テクニックを発見する際に役立つ。
Note: Capturing a large volume of well-formatted logs can be invaluable for incident responders in forensics analysis scenarios. However, organisations are encouraged to properly organise logged data into ‘hot’ data storage that is readily available and searchable, or ‘cold’ data storage that has deprioritised availability and is stored through more economical solutions – an important consideration when evaluating an organisation’s log storage capacity.	注： フォレンジック分析シナリオにおいて、インシデント対応者にとって、適切にフォーマットされた大量のログをキャプチャすることは非常に貴重である。しかし、組織は、ログデータを、すぐに利用可能で検索可能な「ホット」データストレージ、または可用性を優先せず、より経済的なソリューションを通じて保存される「コールド」データストレージに適切に整理することが推奨される。
For more information on how to prioritise collection of high-quality event logs please refer to CISA’s Guidance for Implementing M-21-3: Improving the Federal Government’s Investigative and Remediation Capabilities [1].	高品質なイベントログの収集の優先順位付けの方法についての詳細は、CISA の「M-21-3: 連邦政府の調査・修復能力の改善のためのガバナンス」[1]を参照されたい。
To strengthen detection of malicious actors employing LOTL techniques, some relevant considerations for event logging include:	LOTL 技術を使用する悪意ある行為者の検知を強化するために、イベントロギングに関連するいくつかの考慮事項がある：
・On Linux-based systems, logs capturing the use of curl, systemctl, systemd, python and other common LOLBins leveraged by malicious actors.	・Linux ベースのシステムでは、curl、systemctl、systemd、python、その他悪意ある行為者が利用する一般的な LOLBin の使用をキャプチャするログを記録する。
・On Microsoft Windows-based systems, logs capturing the use of wmic.exe, ntdsutil.exe, Netsh, cmd.exe, PowerShell, mshta.exe, rundll32.exe, resvr32.exe and other common LOLBins leveraged by malicious actors. Ensure that logging captures command execution, script block logging and module logging for PowerShell, and detailed tracking of administrative tasks.	・Microsoft Windows ベースのシステムでは、wmic.exe、ntdsutil.exe、Netsh、 cmd.exe、PowerShell、mshta.exe、rundll32.exe、resvr32.exe、その他悪意ある行為者が利用する一般的な LOLBin の使用をキャプチャしたログを記録する。ロギングにより、コマンドの実行、スクリプトブロックのロギング、PowerShell のモジュールのロギング、管理タスクの詳細な追跡を確実に行う。
・For cloud environments, logging all control plane operations, including API calls and end user logins. The control plane logs should be configured to capture ‘read’ and ‘write’ activities, administrative changes, and authentication events.	・クラウド環境の場合、API 呼び出しやエンドユーザのログインを含む、すべてのコ ントロールプレーン操作のログを記録する。制御プレーンのログは、「読み取り」と「書き込み」のアクティビティ、管理者の変更履歴、認証イベントをキャプチャするように構成されるべきである。
Captured event log details	キャプチャされたイベントログの詳細
As a part of an organisation’s event logging policy, captured event logs should contain sufficient detail to aid network defenders and incident responders. If a logging solution fails to capture data relevant to security, its effectiveness as a cyber security incident detection capability is heavily impacted.	組織のイベントロギングポリシーの一部として、キャプチャされたイベントログは、ネットワーク防御者とインシデント対応者を支援するのに十分な詳細を含むべきである。ロギング・ソリューションがセキュリティに関連するデータをキャプチャできなければ、サイバー・セキュリティ・インシデント検知機能としての有効性に大きな影響を与える。
The US Office of Management and Budget’s M-21-31 [2] outlines a good baseline for what an event log should capture, if applicable:	米国行政管理予算局の M-21-31 [2]は、該当する場合、イベントログが何を捕捉すべきかの良い基本基準を概説している：
・properly formatted and accurate timestamp (millisecond granularity is ideal)	適切にフォーマットされた正確なタイムスタンプ（ミリ秒単位が理想的）。
・event type (status code)	・イベントタイプ（ステータスコード）
・device identifier (MAC address or other unique identifier)	・デバイス識別子（MACアドレスまたは他の一意の識別子） ・セッション/トランザクションID
・session/transaction ID	・セッション/トランザクションID
・autonomous system number	・自律システム番号
・source and destination IP (includes both IPv4 and IPv6)	・送信元と宛先IP（IPv4とIPv6の両方を含む）
・status code	・ステータスコード
・response time	・応答時間
・additional headers (e.g. HTTP headers)	・追加ヘッダ（HTTPヘッダなど）
・the user ID, where appropriate	・必要に応じて、ユーザーID
・the command executed, where appropriate	・必要に応じて、実行されたコマンド
・a unique event identifier to assist with event correlation, where possible.	・可能であれば、イベント相関を支援するための一意なイベント識別子。
Note: Where possible, all data should be formatted as ‘key-value-pairs’ to allow for easier extraction.	注：可能であれば、すべてのデータは、抽出を容易にするために「キーと値のペア」としてフォーマットされるべきである。
Operational Technology considerations	運用技術 (OT) に関する考慮事項
Network administrators and network operators should take into consideration the OT devices within their OT networks. Most OT devices use embedded software that is memory and/ or processor constrained. An excessive level of logging could adversely affect the operation of those OT devices. Additionally, such OT devices may not be capable of generating detailed logs, in which case, sensors can be used to supplement logging capabilities. Out-of-band log communications, or generating logs based on error codes and the payloads of existing communications, can account for embedded devices with limited logging capabilities.	ネットワーク管理者とネットワークオペレータは、OT ネットワーク内の OT デバイスを考慮する必要がある。ほとんどの OT デバイスは、メモリおよび／またはプロセッサに制約のある組み込みソフトウ ェアを使用している。過度のロギングは、これらの OT デバイスの動作に悪影響を及ぼす可能性がある。さらに、そのような OT デバイスは詳細なログを生成できないかもしれない。帯域外のログコミュニケーション、またはエラーコードと既存の通信のペイロードに基づいてログを生成することで、ロギング機能が制限された組み込みデバイスを説明することができる。
Additional resources	追加リソース
The following resources include examples of details to be logged:	以下のリソースは、ロギングされる詳細の例を含んでいる：
・ASD’s ACSC’s Information Security Manual (ISM) provides event log details to record in the Guidelines for System Monitoring .	・ASDのACSCの情報セキュリティマニュアル(ISM)は、システム監視のガイドラインに記録すべきイベントログの詳細を提供している。
・CISA’s Guidance for Implementing M-21-31: Improving the Federal Government’s Investigative and Remediation Capabilities details another approach to prioritising log collection and is aimed at US federal civilian executive branch organisations.	・CISA の「M-21-31 実施のためのガイダンス」： CISA の「M-21-31: Improving the Federal Government's Investigative and Remediation Capabilities」は、ログ収集の優先順位を決める別のアプローチを詳述しており、米国連邦文民行政機関を対象としている。
・NIST has outlined OT considerations for event logging in their Guide to Operational Technology (OT) Security.	・NIST は、「運用技術（OT）セキュリティのためのガイド」の中で、イベントロギングに関する OT の 考慮事項を概説している。
・For examples of detection uses cases, consider visiting the MITRE ATT&CK® list of data sources.	・検知のユースケースの例については、データソースの MITRE ATT&CK® リストの閲覧を検討すること。
Content and format consistency	コンテンツとフォーマットの一貫性
When centralising event logs, organisations should consider using a structured log format, such as JSON, where each type of log captures and presents content consistently (that is, consistent schema, format and order).This is particularly important when event logs have been forwarded to a central storage facility as this improves a network defender’s ability to search for, filter and correlate event logs. Since logs may vary in structure (or lack thereof), implementing a method of automated log normalisation is recommended. This is an important consideration for logs that can change over time or without notice such as software and Software-as-a-Service (SaaS) logs.	イベントログを一元化する場合、組織は、JSON のような構造化されたログ形式を使用することを検討すべきであ り、そこでは、各タイプのログは一貫したコンテンツを取得し、提示する（すなわち、一貫したスキーマ、 形式、順序）。ログの構造（またはその欠如）は様々であるため、自動化されたログの正規化の方法を実装することが推奨される。これは、ソフトウェアやSaaS（Software-as-a-Service）のログのように、時間の経過とともに、あるいは予告なしに変更される可能性のあるログにとって重要な考慮事項である。
Timestamp consistency	タイムスタンプの一貫性
Organisations should consider establishing an accurate and trustworthy time source and use this consistently across all systems to assist network defenders in identifying connections between event logs. This should also include using the same date-time format across all systems. Where possible, organisations should use multiple accurate time sources in case the primary time source becomes degraded or unavailable. Note that, particularly in distributed systems, time zones and distance can influence how timestamps read in relation to each other. Network owners, system owners and cyber security incident responders are encouraged to understand how this could impact their own environments. ASD's ACSC and co-authors urge organisations to consider implementing the recommendations below to help ensure consistent timestamp collection.	組織は、正確で信頼できるタイムソースを確立し、これをすべてのシステムで一貫して使用することで、ネットワーク防御者がイベントログ間の関連を特定するのを支援することを検討すべきである。これには、すべてのシステムで同じ日付-時刻形式を使用することも含まれる。可能であれば、組織は、プライマリタイムソースが劣化したり、利用できなくなったりした場合に備えて、複数の正確なタイムソースを使用すべきである。特に分散システムでは、タイムゾーンや距離がタイムスタンプの読み取りに影響することがある。ネットワーク所有者、システム所有者、サイバーセキュリティインシデント対応者は、自身の環境にどのような影響があるかを理解することが推奨される。ASDのACSCと共著者は、タイムスタンプ収集の一貫性を確保するために、以下の推奨事項の実施を検討するよう組織に促している。
・Time servers should be synchronised and validated throughout all environments and set to capture significant events, such as device boots and reboots.	・タイムサーバーはすべての環境で同期され、検証され、デバイスの起動や再起動などの重要なイベントを捕捉するように設定されるべきである。
・Using Coordinated Universal Time (UTC) has the advantage of no time zones as well as no daylight savings, and is the preferred time standard.	・協定世界時（UTC）を使用すると、タイムゾーンがなく、サマータイムもないという利点があり、望ましい標準時である。
・・Implement ISO 8601 formatting, with the year listed first, followed by the month, day, hour, minutes, seconds, and milliseconds (e.g. 2024-07-25T20:54:59.649Z).	・ISO8601書式を採用し、年を最初に、月、日、時、分、秒、ミリ秒の順に記載する（例：2024-07-25T20:54:59.649Z）。
・Timesharing should be unidirectional. The OT environment should synchronise time sync with the IT environment and not the other way around.	・時間共有は一方向でなければならない。OT環境はIT環境と時間同期をとるべきであり、その逆ではない。
・Data historians may be implemented on some operational assets to record and store time-series data of industrial processes running on the computer system. These can provide an additional source of event log data for OT networks.	・データヒストリは、コンピュータシステム上で実行される産業プロセスの時系列データを記録・ 保存するために、運用資産に実装されることがある。これらは、OTネットワークのイベントログデータの追加ソースを提供することができる。
Additional resources	追加リソース
・ASD's ACSC has released Windows Event Logging and Forwarding guidance that details important event categories and recommendations for configurations, log retention periods and event forwarding.	・ASDのACSCは、Windowsイベントログと転送のガイダンスをリリースした。このガイダンスは、重要なイベントカテゴリーと、構成、ログ保存期間、イベント転送の推奨事項を詳述している。
・For more information about logging, please explore CISA's Logging Made Easy (LME), a no-cost solution providing essential log management for small to medium-sized organisations, on CISA's website or Github page.	・ロギングの詳細については、CISA のウェブサイトや Github ページで、中小規模の組織に不可欠 なログ管理を提供する無償のソリューション、Logging Made Easy（LME）を参照されたい。
・The Joint SIGINT Cyber Unit (JSCU) of the AIVD and MIVD has published a repository on GitHub with a Microsoft Windows event logging and collections baseline focused on finding balance between forensic value and optimising retention. You can find this repository on the JSCU’s GitHub.	・AIVD と MIVD の合同シギント・サイバー・ユニット（JSCU）は、フォレンジックの価値と保存の最適化 のバランスを見つけることに焦点を当てた、Microsoft Windows のイベント・ロギングと収集のベースラインの リポジトリを GitHub で公開している。このリポジトリはJSCUのGitHubで見ることができる。
Event log retention	イベントログの保持
Organisations should ensure they retain logs for long enough to support cyber incident investigations. Default log retention periods are often insufficient. Log retention periods should be informed by an assessment of the risks to a given system and any regulatory requirements that may apply to the organisation. When determining how long to retain logs, consider that, in some cases, it can take up to 18 months to discover a cyber incident and some malware can dwell on the network from 70 to 200 days before causing overt harm [3]. Log retention periods should also be compliant with any regulatory requirements and cyber security frameworks that may apply in an organisation’s jurisdiction. Logs that are crucial in confirming an intrusion and its impact should be prioritised for longer retention.	組織は、サイバーインシデント調査をサポートするのに十分な期間、ログを保持することを保証すべきである。デフォルトのログ保存期間では不十分なことが多い。ログの保存期間は、特定のシステムに対するリスクアセスメントと、組織に適用される可能性のある規制要件によって決定されるべきである。ログの保存期間を決定する際には、サイバーインシデントを発見するまでに最大で18カ月かかるケースがあること、また、マルウェアの中には、明白な被害をもたらすまでに70日から200日間もネットワーク上に滞留するものがあることを考慮する必要がある[3]。ログの保存期間は、組織の管轄区域で適用される可能性のある規制要件やサイバーセキュリティの枠組みにも準拠する必要がある。侵入とその影響を確認する上で極めて重要なログは、長期保存を優先すべきである。
It is important to review log storage allocations, in parallel with retention periods. Insufficient storage is a common obstacle to log retention. For example, many systems will overwrite old logs when their storage allocation is exhausted. The longer that logs can be kept, the higher the chances are of determining the extent of a cyber security incident, including the potential intrusion vectors that require remediation. For effective security logging practices, organisations should implement data tiering such as hot and cold storage. This ensures that logs can be promptly retrieved to facilitate querying and threat detection.	保存期間と並行して、ログのストレージ割り当てを見直すことが重要である。十分なストレージがないことは、ログ保存の一般的な障害である。例えば、多くのシステムは、ストレージの割り当てがなくなると、古いログを上書きする。ログの保存期間が長ければ長いほど、改善が必要な潜在的な侵入ベクトルを含め、サイバーセキュリティインシデントの程度を判断できる可能性が高くなる。効果的なセキュリティ・ロギングの実践のために、組織はホット・ストレージやコールド・ストレージなどのデータ階層化を実施すべきである。これにより、ログを迅速に取得し、クエリや脅威の検知を容易にすることができる。
Centralised log collection and correlation	ログの収集と相関の一元化
The following sections detail prioritised lists of log sources for enterprise networks, OT, cloud computing and enterprise mobility using mobile computing devices. The prioritisation takes into consideration the likelihood that the logged asset will be targeted by a malicious actor, as well as the impact if the asset were to be compromised. It also prioritises log sources that can assist in identifying LOTL techniques. Please note that this is not an exhaustive list of log sources and their threats, and their priority may differ between organisations.	以下のセクションでは、エンタープライズネットワーク、OT、クラウドコンピューティング、モバイルコンピューティングデバイスを使用するエンタープライズモビリティのログソースの優先順位リストを詳述する。優先順位付けは、ログに記録された資産が悪意のある行為者に標的にされる可能性と、資産が侵害された場合の影響を考慮に入れている。また、LOTL 手法の識別に役立つログ・ソースに優先順位をつける。これは、ログ・ソースとその脅威の網羅的なリストではなく、優先順位は組織によって異なる可能性があることに注意すること。
Logging priorities for enterprise networks	エンタープライズ・ネットワークのログの優先順位
Enterprise networks face a large variety of cyber threats. These include malware, malicious insiders, and exploitation of unpatched applications and services. In the context of LOTL, enterprise networks provide malicious actors with a wide variety of native tools to exploit.	エンタープライズ・ネットワークは、多種多様なサイバー脅威に直面している。これには、マルウェア、悪意のある内部者、パッチが適用されていないアプリケーションやサービスの悪用などが含まれる。LOTL の文脈では、エンタープライズネットワークは、悪意のある行為者に悪用するための多様なネイティブツールを提供する。
ASD's ACSC and co-authors recommend that organisations prioritise the following log sources within their enterprise network:	ASDのACSCと共著者は、組織がエンタープライズネットワーク内の以下のログソースを優先することを推奨している：
1. critical systems and data holdings likely to be targeted	1.標的とされる可能性のある重要なシステムやデータ保有物
2. internet-facing services, including remote access, network metadata, and their underlying server operating system	2.リモートアクセス、ネットワークメタデータ、基礎となるサーバーオペレーティングシステムを含む、インターネットに面したサービス
3. identity and domain management servers	3. IDおよびドメイン管理サーバー
4. any other critical servers	4. その他重要なサーバー
5. edge devices, such as boundary routers and firewalls	5. バウンダリ・ルーターやファイアウォールなどのエッジ・デバイス
6. administrative workstations	6. 管理ワークステーション
7. highly privileged systems such as configuration management, performance and availability monitoring (in cases where privileged access is used), Continuous Integration/Continuous Delivery (CI/CD), vulnerability scanning services, secret and privilege management	7. 構成管理、パフォーマンスと可用性の監視（特権アクセスが使用される場合）、継続的インテグレーション/継続的デリバリー（CI/CD）、脆弱性スキャンサービス、秘密および特権管理などの高度な特権システム。
8. data repositories	8. データリポジトリ
9. security-related and critical software	9. セキュリティ関連の重要なソフトウェア
10. user computers	10. ユーザーコンピュータ
11. user application logs	11. ユーザー・アプリケーションのログ
12. web proxies used by organisational users and service accounts	12. 組織ユーザー及びサービスアカウントが使用するウェブプロキシ
13. DNS services used by organisational users	13. 組織ユーザーが使用する DNS サービス
14. email servers	14. 電子メールサーバー
15. DHCP servers	15. DHCPサーバー
16. legacy IT assets (that are not previously captured in critical or internet-facing services).	16.レガシーIT資産（クリティカルなサービスやインターネットに面したサービスではこれまで把握されていないもの）。
ASD's ACSC and co-authors recommend organisations monitor lower priority logs as well. These include:	ASDのACSCと共著者は、組織は優先順位の低いログも監視することを推奨している。これには以下が含まれる：
・underlying infrastructure, such as hypervisor hosts	・ハイパーバイザーホストなどの基盤インフラ
・IT devices, such as printers	・プリンタなどのITデバイス
・network components such as application gateways.	・アプリケーションゲートウェイなどのネットワークコンポーネント。
Logging priorities for operational technology	運用技術 (OT) のログの優先順位
Historically, IT and OT have operated separately and have provided distinct functions within organisations. Advancements in technology and digital transformation have led to the growing interconnectedness and convergence of these networks. Organisations are integrating IT and OT networks to enable the seamless flow of data between management systems and industrial operations. Their integration has introduced new cyber threats to OT networks. For example, malicious actors can attack OT networks through IT networks by exploiting unpatched vulnerabilities, delivering malware, or conducting denial-of-service attacks to impact critical services.	歴史的に、ITとOTは別々に運用され、組織内で異なる機能をプロバイダしてきた。テクノロジーとデジタルトランスフォーメーションの進歩により、これらのネットワークの相互接続と収束が進んでいる。組織はITとOTネットワークを統合し、管理システムと産業オペレーション間のシームレスなデータの流れを可能にしている。これらの統合は、OTネットワークに新たなサイバー脅威をもたらした。例えば、悪意ある行為者はITネットワークを通じてOTネットワークを攻撃し、パッチが適用されていない脆弱性を悪用したり、マルウェアを配信したり、重要なサービスに影響を与えるサービス拒否攻撃を行ったりする。
ASD and co-authors recommend that organisations prioritise the following log sources in their OT environment:	ASDと共著者は、組織がOT環境において以下のログソースを優先することを推奨している：
1. OT devices critical to safety and service delivery, except for air-gapped systems [4]	1. 安全性とサービス提供に重要な OT デバイス（エアギャップシステムを除く）[4]。
2. internet-facing OT devices	2. インターネットに面した OT デバイス
3. OT devices accessible via network boundaries.	3. ネットワーク境界を介してアクセス可能な OT デバイス。
Note that in cases where OT devices do not support logging, device logs are not available, or are available in a non-standard format, it is good practice to ensure network traffic and communications to and from the OT devices are logged.	OT デバイスがロギングをサポートしていない、デバイスログが利用できない、または非標準形式 で利用できる場合には、OT デバイスとの間のネットワークトラフィックおよびコミュニケーションがロ ギングされることを保証することがグッドプラクティスであることに注意すること。
Logging priorities for enterprise mobility using mobile computing devices	モバイルコンピューティングデバイスを使用するエンタープライズモビリティのログの優先順位
Enterprise mobility is an important aspect of an organisation’s security posture. Mobile device management (MDM) solutions allow organisations to manage the security of their enterprise mobility, typically including logging functionality. In the context of enterprise mobility, the aim of effective event logging is to detect compromised accounts or devices; for example, due to phishing or interactions with malicious applications and websites.	エンタープライズモビリティは、組織のセキュリティ体制の重要な側面である。モバイル・デバイス管理（MDM）ソリューションにより、組織はエンタープライズ・モビリティのセキュリティを管理することができ、通常、ロギング機能を含む。エンタープライズモビリティの文脈では、効果的なイベントロギングの目的は、例えばフィッシングや悪意のあるアプリケーションやウェブサイトとの相互作用により、危険にさらされたアカウントやデバイスを検知することである。
ASD's ACSC and co-authors recommend organisations prioritise the following log sources in their enterprise mobility solution:	ASDのACSCと共著者は、エンタープライズモビリティソリューションにおいて、以下のログソースを優先することを企業に推奨している：
1. web proxies used by organisational users	1.組織ユーザーが使用するウェブプロキシ
2. organisation operated DNS services	2.組織が運営するDNSサービス
3. device security posture of organisationally managed devices	3. 組織が管理するデバイスのセキュリティ状況
4. device behaviour of organisationally managed devices	4.組織が管理するデバイスの挙動
5. user account behaviour such as sign-ins	5.サインインなどのユーザーアカウントの動作
6. VPN solutions	6. VPN ソリューション
7. MDM and Mobile Application Management (MAM) events [5].	7. MDMおよびモバイル・アプリケーション管理（MAM）イベント [5]。
Additional monitoring should be implemented in collaboration with the telecommunications network provider. Such monitoring includes:	追加のモニタリングは、通信ネットワークのプロバイダと協力して実施する必要がある。このような監視には以下が含まれる：
・signalling exploitation	・シグナリングの搾取
・binary/invisible SMS	・バイナリ/不可視 SMS
・CLI spoofing	・CLIスプーフィング
・SIM/eSIM activities such as SIM swapping	・SIMスワッピングなどのSIM/eSIM活動
・null cipher downgrade	・ヌル暗号のダウングレード
・connection downgrade (false base station)	・接続ダウングレード（偽の基地局）
・network API/query against user	・ユーザに対するネットワークAPI/クエリ
・roaming traffic protection	・ローミングトラフィックの防御
・roaming steering.	・ローミングステアリング。
Organisations should obtain legal advice about what can be logged from any personally owned mobile devices that are enrolled in an MDM solution. For example, logging GPS location may be subject to restrictions.	組織は、MDMソリューションに登録されている個人所有のモバイル・デバイスから何を記録できるかについて、法的助言を得るべきである。例えば、GPS位置情報のログは制限の対象となる場合がある。
Logging priorities for cloud computing	クラウドコンピューティングにおけるロギングの優先順位
ASD's ACSC and co-authors recommend organisations adjust event logging practices in accordance with the cloud service that is administered, whether Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or SaaS are implemented. For example, IaaS would include a significant amount of logging responsibility on the tenant, whereas SaaS would place a significant amount of the logging responsibility on the provider. Therefore, organisations should coordinate closely with their cloud service provider to understand the shared responsibility model in place, as it will influence their logging priorities. Logging priorities will also be influenced by different cloud computing service models and deployment models (i.e. public, private, hybrid, community). Where privacy and data sovereignty laws apply, logging priorities may also be influenced by the location of the cloud service provider’s infrastructure. See NSA’s Manage Cloud Logs for Effective Threat Hunting guidance for additional information.	ASDのACSCと共著者は、Infrastructure-as-a-Service (IaaS)、Platform-as-a-Service (PaaS)、SaaSのいずれが実装されているかに関わらず、管理されているクラウドサービスに応じてイベントロギングを調整することを推奨している。例えば、IaaSの場合、テナントにかなりの量のロギング責任があるのに対し、SaaSの場合、プロバイダにかなりの量のロギング責任がある。したがって、組織はクラウドサービスプロバイダと緊密に連携し、ロギングの優先順位に影響する共有責任モデルを理解する必要がある。ロギングの優先順位は、クラウドコンピューティング・サービス・モデルや展開モデル（パブリック、プライベート、ハイブリッド、コミュニティなど）の違いによっても影響を受ける。プライバシーやデータ・ソブリンに関する法律が適用される場合、ロギングの優先順位は、クラウド・サービス・プロバイダのインフラの場所によっても影響を受ける可能性がある。詳細については、NSAの「Manage Cloud Logs for Effective Threat Hunting」ガイダンスを参照のこと。
Organisations should prioritise the following log sources in their use of cloud computing services:	組織は、クラウドコンピューティング・サービスの使用において、以下のログソースを優先すべきである：
1. critical systems and data holdings likely to be targeted	1.標的とされる可能性のある重要なシステムおよびデータの保有
2. internet-facing services (including remote access) and, where applicable, their underlying server operating systems	2.インターネットに面したサービス（リモートアクセスを含む）、および該当する場合、その基盤となるサーバー・オペレーティング・システム
3. use of the tenant’s user accounts that access and administer cloud services	3. クラウドサービスにアクセスし管理するテナントのユーザーアカウントの使用状況
4. logs for administrative configuration changes	4. 管理者設定の変更履歴
5. logs for the creation, deletion and modification of all security principals, including setting and changing permissions	5. パーミッションの設定および変更を含む、すべてのセキュリティプリンシパルの作成、削除、および変更に関する履歴。
6. authentication success and/or failures to third party services (e.g. SAML/OAuth)	6. サードパーティ・サービス（SAML/OAuthなど）に対する認証の成功や失敗。
7. logs generated by the cloud services, including logs for cloud APIs, all network-related events, compliance events and billing events.	7.クラウドAPIのログ、すべてのネットワーク関連イベント、コンプライアンスイベント、課金イベントを含む、クラウドサービスによって生成的なログ。
Secure storage and event log integrity	安全な保存とイベントログの完全性
ASD's ACSC and co-authors recommend that organisations implement a centralised event logging facility such as a secured data lake to enable log aggregation and then forward select, processed logs to analytic tools, such as security information and event management (SIEM) solution and extended detection and response (XDR) solutions. Many commercially available network infrastructure devices have limited local storage. Forwarding event logs to a centralised and secure storage capability prevents the loss of logs once the local device’s storage is exhausted. This can be further mitigated by ensuring default maximum event log storage sizes are configured appropriately on local devices. In the event of a cyber security incident, an absence of historical event logs will frequently have a negative impact on incident response activities.	ASDのACSCと共著者は、組織がログの集約を可能にするセキュアなデータレイクのような集中型イベントロギング機能を実装し、選択された処理されたログをセキュリティ情報・イベント管理（SIEM）ソリューションや拡張検知・対応（XDR）ソリューションのような分析ツールに転送することを推奨している。市販のネットワーク・インフラ・デバイスの多くは、ローカル・ストレージが限られている。イベントログを一元化された安全なストレージ機能に転送することで、ローカルデバイスのストレージが使い果たされた後のログの損失を防ぐことができる。これは、デフォルトの最大イベントログストレージサイズがローカルデバイス上で適切に設定されていることを確認することによって、さらに低減することができる。サイバーセキュリティインシデントが発生した場合、過去のイベントログがないと、インシデント対応活動に悪影響を及ぼすことが多い。
Secure transport and storage of event logs	イベントログの安全な転送と保存
ASD's ACSC and co-authors recommend that organisations implement secure mechanisms such as Transport Layer Security (TLS) 1.3 and methods of cryptographic verification to ensure the integrity of event logs in-transit and at rest. Organisations should prioritise securing and restricting access to event logs that have a justified requirement to record sensitive data.	ASDのACSCと共著者は、組織がイベントログの転送中および保管中の完全性を保証するために、トランスポートレイヤーセキュリティ（TLS）1.3や暗号検証方法のような安全なメカニズムを導入することを推奨する。組織は、機密データを記録する正当な要件があるイベントログの保護とアクセス制限を優先すべきである。
Protecting event logs from unauthorised access, modification and deletion	イベントログの不正アクセス、変更、削除からの防御
It is important to perform event log aggregation as some malicious actors are known to modify or delete local system event logs to avoid detection and to delay or degrade the efficacy of incident response. Logs may contain sensitive data that is useful to a malicious actor. As a result, users should only have access to the event logs they need to do their job.	一部の悪意ある事業者は、検知を回避し、インシデントレスポンスの有効性を遅延または低下させるために、ローカルシステムのイベントログを変更または削除することが知られているため、イベントログの集約を実行することが重要である。ログには、悪意のある行為者にとって有用な機密データが含まれている可能性がある。その結果、ユーザーは自分の仕事をするために必要なイベントログにのみアクセスできるべきである。
An event logging facility should enable the protection of logs from unauthorised modification and deletion. Ensure that only personnel with a justified requirement have permission to delete or modify event logs and view the audit logs for access to the centralised logging environment. The storage of logs should be in a separate or segmented network with additional security controls to reduce the risk of logs being tampered with in the event of network or system compromise. Events logs should also be backed up and data redundancy practices should be implemented.	イベントロギング機能は、無許可の変更や削除からログを保護できるようにすべきである。正当な要件を持つ要員のみが、イベントログを削除または修正する権限を持ち、集中化されたロギング環境にアクセスするための監査ログを閲覧できるようにする。ログの保管は、ネットワークまたはシステムが侵害された場合にログが改ざんされるリスクを低減するために、追加のセキュリティ制御を備えた別個またはセグメント化されたネットワークにすべきである。イベントログはバックアップされるべきであり、データの冗長化が実施されるべきである。
Organisations are encouraged to harden and segment their SIEM solutions from general IT environments. SIEMs are attractive targets for malicious actors because they contain a wealth of information, provide an analysis function, and can be a single point of failure in an organisation’s detection capability. Organisations should consider filtering event logs before sending them to a SIEM or XDR to ensure it is receiving the most valuable logs to minimise any additional costs or capacity issues.	組織は、一般的なIT環境からSIEMソリューションを強化し、セグメント化することが推奨される。SIEMは、豊富な情報を含み、分析機能を提供し、組織の検知機能における単一障害点となり得るため、悪意のある行為者にとって魅力的な標的である。組織は、イベントログをSIEMやXDRに送信する前にフィルタリングを行い、最も価値のあるログを確実に受信し、追加コストや容量の問題を最小限に抑えることを検討すべきである。
Centralised event logging enables threat detection	イベントログの一元化が脅威検知を可能にする
The aggregation of event logs to a central logging facility that a SIEM can draw from enables the identification of:	イベントログをSIEMが利用できる中央のロギング施設に集約することで、以下を特定できるようになる：
・deviations from a baseline	・ベースラインからの逸脱
・・A baseline should include installed tools and software, user account behaviour, network traffic, system intercommunications and other items, as applicable. Particular attention should be paid to privileged accounts and critical assets such as domain controllers.	・・ベースラインには、インストールされたツールやソフトウェア、ユーザーアカウントの動作、 ネットワークトラフィック、システム間通信、その他の項目が含まれる。特に、特権アカウントやドメインコントローラなどの重要な資産に注意を払う。
・・A baseline is derived by performing an analysis of normal behaviour of some user accounts and establishing ‘always abnormal’ conditions for those same accounts.	・・ベースラインは、一部のユーザアカウントの正常な振る舞いを分析し、「常に異常」な状態を 確立することによって導き出される。
・cyber security events	・サイバーセキュリティ事象
・・For the purpose of this document, a cyber security event is an occurrence of a system, service or network state indicating a possible breach of security policy, failure of safeguards or a previously unknown situation that may be relevant to security.	・・本文書において、サイバーセキュリティイベントとは、セキュリティポリシー違反の可能性、保護措置の不履行、又はセキュリティに関連する可能性のある未知の状況を示す、システム、サービス又はネットワークの状態の発生をいう。
・cyber security incidents	・サイバーセキュリティインシデント
・・For the purpose of this document, a cyber security incident is an unwanted or unexpected cyber security event, or a series of such events, that either has compromised business operations or has a significant probability of compromising business operations.	・・この文書では、サイバーセキュリティインシデントとは、望ましくない又は予期しないサイバーセキュリティの事象、又はそのような事象の連続であって、業務運営を危険にさらすか、又は業務運営を危険にさらす可能性が大きいものをいう。
Timely ingestion	適時の取り込み
Timely ingestion of event logs is important in the early detection of cyber security events and cyber security incidents. If the generation, collection and ingestion of event logs is delayed, the organisation’s ability to identify cyber security incidents is also delayed.	イベントログを適時に検知することは、サイバーセキュリティイベントやサイバーセキュリティインシデントを早期に検知する上で重要である。イベントログの生成、収集、取り込みが遅れると、組織がサイバーセキュリティインシデントを識別する能力も遅れる。
Detection strategy for relevant threats	関連する脅威の検知戦略
Detecting living off the land techniques	現地調達技術の検知
ASD's ACSC and co-authors recommend that organisations consider implementing user and entity behavioural analytics capabilities to enable automated detection of behavioural anomalies on networks, devices, or accounts. SIEMs can detect anomalous activity by comparing event logs to a baseline of business-as-usual traffic and activity. Behavioural analytics plays a key role in detecting malicious actors employing LOTL techniques. Below is a case study that shows how threat actors leveraged LOTL to infiltrate Windows-based systems.	ASDのACSCと共著者は、ネットワーク、デバイス、アカウント上の行動異常の自動検出を可能にするユーザーと事業体の行動分析機能の導入を検討することを組織に推奨している。SIEMは、イベントログを通常業務のトラフィックやアクティビティのベースラインと比較することで、異常なアクティビティを検知することができる。行動分析は、LOTL テクニックを使用する悪意のあるアクターを検知する上で重要な役割を果たす。以下は、脅威行為者がどのように LOTL を活用して Windows ベースのシステムに侵入したかを示すケーススタディである。
Case study – Volt Typhoon	ケーススタディ - Volt Typhoon
Since mid-2021, Volt Typhoon has targeted critical infrastructure organisations by relying almost exclusively on LOTL techniques. Their campaign has been enabled by privately-owned SOHO routers, infected with the ‘KV Botnet’ malware.	2021年半ば以降、Volt Typhoon は、ほとんど LOTL テクニックだけに頼って、重要なインフラ組織を標的としてきた。彼らのキャンペーンは、「KVボットネット」マルウェアに感染した個人所有のSOHOルーターによって実現されている。
Volt Typhoon uses PowerShell, a command and scripting interpreter, to:	Volt Typhoonは、コマンドとスクリプトのインタプリタであるPowerShellを使用している：
・discover remote systems [T1059.001, T1018]	・リモートシステムを発見する [T1059.001, T1018]。
・identify associated user and computer account names using the command Get-EventLog security –instanceid 4624 [T1033]	・コマンド Get-EventLog security -instanceid 4624 [T1033]を使用して、関連するユーザーとコンピュータのアカウント名を識別する。
・enumerate event logs to search for successful logons using wevtutil.exe and the command Get-EventLog Security [T1654].	・wevtutil.exeとコマンドGet-EventLog Security [T1654]を使用して、成功したログオンを検索するためにイベントログを列挙する。
Volt Typhoon consistently obtains valid credentials by extracting the Active Directory database file NTDS.dit.[6] To do so, Volt Typhoon has been observed to:	Volt Typhoonは一貫して、Active DirectoryデータベースファイルNTDS.ditを抽出することで有効な認証情報を取得する[6]：
・execute the Windows-native vsssadmin command to create a volume shadow copy [T1006]	・Windowsネイティブのvsssadminコマンドを実行し、ボリュームシャドウコピーを作成する[T1006]。
・use Windows Management Instrumentation Console (WMIC) commands [T1047] to execute ntdsutil.exe to copy NTDS.dit and the SYSTEM registry from the volume shadow copy	・Windows Management Instrumentation Console（WMIC）コマンド［T1047］を使用してntdsutil.exeを実行し、ボリュームシャドウコピーからNTDS.ditとSYSTEMレジストリをコピーする。
・move laterally to the Microsoft Active Directory Domain Services (AD DS) domain controller via an interactive RDP session using a compromised user account with domain administrator privileges [T1021.001].	・ドメイン管理者権限を持つ侵害されたユーザーアカウントを使用して、対話型RDPセッションを介してMicrosoft Active Directory Domain Services（AD DS）ドメインコントローラに横移動する[T1021.001]。
Other LOTL techniques that Volt Typhoon has been observed to use includes:	Volt Typhoon が使用することが確認されているその他の LOTL テクニックには、以下のようなものがある：
・accessing hashed credentials from the Local Security Authority SubSystem Service (LSASS) process memory space [T1003.001]	・LSASS（Local Security Authority SubSystem Service）プロセスのメモリ空間からハッシュ化された認証情報にアクセスする [T1003.001]。
・using ntdsutil.exe to create installation media from Microsoft AD DS domain controllers, either remote or locally, which contain username and password hashes [T1003.003]	・ntdsutil.exe を使用して、リモートまたはローカルにある Microsoft AD DS ドメインコントローラから、ユーザー名とパスワードのハッシュを含むインストールメディアを作成する [T1003.003] 。
・using PowerShell, WMIC, and the ping command, to facilitate system discovery [T1018]	・PowerShell、WMIC、pingコマンドを使用して、システムの検出を容易にする [T1018] 。
・using the built-in netsh portproxy command to create proxies on compromised systems to facilitate access [T1090].	・組み込みの netsh portproxy コマンドを使用して、侵害されたシステム上にプロキシを作成し、アクセスを容易にする [T1090]。
While Volt Typhoon uses LOTL techniques to make detection more difficult, the behaviours that the malware exhibits would be considered abnormal compared to business-as-usual activity and could be used to create detection use cases.	検知 Typhoon は、検知をより困難にするために LOTL テクニックを使用しているが、マルウェアが示す動作は、通常 の動作と比較して異常であると考えられ、検知のユースケースを作成するために使用することができる。
For more information, consider visiting MITRE ATT&CK®’s Volt Typhoon page and the MITRE ATT&CK framework.	詳細については、MITRE ATT&CK® の Volt Typhoon ページおよび MITRE ATT&CK フレームワークを参照されたい。
Examples of anomalous behaviour can include:	異常な行動の例としては、以下のようなものがある：
・a user logging in during unusual hours (e.g. non-working hours, holidays, or on leave)	・通常とは異なる時間帯（勤務時間外、休日、休暇中など）にユーザがログインしている。
・an account accessing services that it does not usually access; for example, administrator or HR services	・通常アクセスしないサービスにアクセスするアカウント（例えば、管理者サービスや人事サービス）。
・a user logging in using an unusual device	・通常とは異なるデバイスを使用してログインしたユーザー
・a high volume of access attempts	・大量のアクセス試行
・instances of impossible travel [7] or concurrent sign-ins from multiple geographic locations	・不可能な出張[7]、または複数の地理的位置からの同時サインインの例
・downloading or exporting a large volume of data [8]	・大量のデータをダウンロードまたはエクスポートする [8]。
・network logins without defined computer access or physical access log validation	・定義されたコンピュータ・アクセスまたは物理的なアクセス・ログの検証を伴わないネットワーク・ログイン
・a single IP address attempting to authenticate as multiple different users	・単一の IP アドレスが複数の異なるユーザーとして認証を試みる。
・the creation of user accounts, or disabled accounts being re-enabled, especially accounts with administrative privileges	・ユーザーアカウントの作成、または無効化されたアカウント（特に管理者権限を持つアカウント）の再有効化
・netflow data indicating one device talking to other internal devices it normally does not connect to	・あるデバイスが、通常は接続しない他の内部デバイスと通信していることを示すネットフロー・データ
・unusual script execution, software installation, or use of administrative tools	・異常なスクリプトの実行、ソフトウェアのインストール、管理ツールの使用
・unexpected clearing of logs	・予期しないログの消去
・an execution of the process from an unusual or suspicious path	・通常と異なる、または疑わしいパスからプロセスが実行される
・configuration changes to security software, such as Windows Defender, and logging management software.	・Windows Defenderなどのセキュリティソフトやログ管理ソフトの設定変更履歴。
Note that the above items could be legitimate behaviour and not malicious activity. In these instances, further investigation by a network defender is required to determine if they are, in fact, evidence of a cyber security event.	上記の項目は、悪意のある行動ではなく、正当な行動である可能性があることに注意。このような場合、ネットワーク・ディフェンダーがさらに調査を行い、実際にサイバー・セキュリティ・イベントの証拠であるかどうかを判断する必要がある。
To detect threats on endpoints such as user devices, organisations should consider implementing an endpoint detection and response solution. These solutions enable an organisation to monitor malicious activity, such as malicious actors disabling security monitoring services, and process creation events with enhanced detail and fidelity.	ユーザ・デバイスなどのエンドポイント上の脅威を検知するために、組織はエンドポイント検知・対応ソリューションの導入を検討すべきである。これらのソリューションにより、組織は、悪意のある行為者がセキュリティ監視サービスを無効にするなどの悪意のある活動を監視し、作成イベントを詳細かつ忠実に処理することができる。
By following the guidance in this publication to improve the collection and centralisation of event logs, it will improve an organisation’s ability to undertake effective threat hunting to proactively investigate LOTL compromises. Organisations should consider conducting threat hunting on their networks as a proactive measure to detect cyber security incidents. This is a particularly effective activity for detecting malicious actors employing LOTL techniques.	本書のガイダンスに従ってイベントログの収集と一元化を改善することで、組織が効果的なスレットハンティングを実施し、LOTL の侵害をプロアクティブに調査する能力が向上する。組織は、サイバーセキュリティインシデントを検知するための事前対策として、ネットワーク上でスレットハンティングを実施することを検討すべきである。これは、LOTL 手法を用いる悪意ある行為者を検知するために特に効果的な活動である。
Organisations may also consider the following methods to increase the effectiveness of detecting potential LOTL techniques:	組織は、潜在的な LOTL 手法の検知の有効性を高めるために、以下の方法も検討することができる：
・Always enable detailed logging that includes process creation events and command-line auditing. This enhances log visibility and facilitates threat hunting, if needed.	・プロセス作成イベントとコマンドライン監査を含む詳細なロギングを常に有効にする。これにより、ログの可視性が向上し、必要に応じて脅威を発見しやすくなる。
・Establish a baseline for the usage of legitimate binaries within the organisation and flag any anomalous behaviour.	・組織内における正規のバイナリの使用状況のベースラインを確立し、異常な挙動があればフラグを立てる。
・Create specific SIEM detection rules based on common attack hypothesis for different operating systems. For example, powershell.exe, cmd.exe, regedit.exe for Microsoft Windows, or curl, systemctl and python for Linux, with encoded commands.	・異なるオペレーティングシステムに共通する攻撃仮説に基づいて、特定のSIEM検知ルールを作成する。例えば、Microsoft Windows の場合は powershell.exe、cmd.exe、regedit.exe、Linux の場合は curl、systemctl、python をエンコードしたコマンドを使用する。
Cloud considerations	クラウドに関する考慮事項
The joint-sealed publication Identifying and Mitigating Living Off the Land Techniques contains detailed detection guidance for cloud environments. One point states that if machine learning-powered detection capabilities are available within cloud provider security services, organisations should consider leveraging these capabilities and provide log data in real time from multiple sources to enhance log analysis. Using machine learning allows for the detection of anomalous behaviours that may indicate malicious activity. These include irregular API call patterns (especially those that involve changes to security groups, configuration of cloud resources or access to sensitive data), unusual cloud storage access and atypical network traffic.	共同で発表された出版物「現地調達手法の識別と低減」には、クラウド環境に対する詳細な検知ガイダンスが含まれている。その中で、機械学習を利用した検知機能がクラウドプロバイダのセキュリティサービス内で利用可能な場合、組織はこれらの機能を活用し、ログ分析を強化するために複数のソースからリアルタイムでログデータを提供することを検討すべきであると述べている。機械学習を利用することで、悪意のある活動を示す可能性のある異常な行動を検知することができる。これには、不規則なAPIコールのパターン（特に、セキュリティ・グループの変更、クラウド・リソースの設定、機密データへのアクセスを伴うもの）、異常なクラウド・ストレージへのアクセス、非定型なネットワーク・トラフィックなどが含まれる。
Operational technology considerations	運用技術 (OT) に関する考慮事項
Effective detection in an OT environment typically involves expertise from both IT and OT personnel; thus, an effective network security instrumentation involves collaborative efforts from both parties. This collaborative approach helps ensure that network defenders can quickly investigate relevant issues, and OT experts can raise operational concerns that may be tied to a cyber incident. Furthermore, network defenders should leverage real-time alerts to determine any abnormal activity on an OT network. These alerts can include safety data, availability data, logins, failed logins [9], configuration changes, and network access and traffic. Organisations may need to consider whether alerts for OT environments should be approached differently. For example, OT devices may be in remote or hard-to-reach locations.	OT 環境における効果的な検知には、通常、IT 部門と OT 部門の職員の専門知識が必要である。したがって、効果的なネットワーク・セキュリティ計測には、両者の協力が不可欠である。この協力的なアプローチは、ネットワーク防御担当者が関連する問題を迅速に調査し、OT の専門家がサイバー・インシデントに関連する可能性のある運用上の懸念を提起できるようにするのに役立つ。さらに、ネットワーク防御者はリアルタイムのアラートを活用して、OT ネットワーク上の異常な活動を判断する必要がある。これらのアラートには、安全性データ、可用性データ、ログイン、ログイン失敗 [9]、設定変更、ネットワーク・アクセスおよびトラフィックが含まれる。組織は、OT 環境のアラートが異なるアプローチを取るべきかどうかを検討する必要があるかもしれない。例えば、OT デバイスは遠隔地や到達しにくい場所にあるかもしれない。
For detecting anomalous behaviour in OT environments, look for:	OT 環境における異常な動作の検知については、以下を確認すること：
・unexpected use of engineering and configuration tools	・エンジニアリングツールやコンフィギュレーションツールの予期せぬ使用
・abnormal use of vendor or third-party accesses, maintenance methods, or remote monitoring	・ベンダーまたはサードパーティによるアクセス、保守方法、またはリモート監視の異常な使用
・unauthorised updates or changes to operating systems, software, firmware, configurations, or databases	・オペレーティングシステム、ソフトウェア、ファームウェア、設定、またはデータベースの無許可の更新または変更
・unexpected communication between the control system and external network or unusual communication between components that do not usually communicate	・制御システムと外部ネットワーク間の予期せぬコミュニケーション、または通常コミュニケーションしないコンポーネント間の予期せぬコミュニケーション
・execution of scripts that are not part of regular operations.	・通常業務とは異なるスクリプトの実行
Intrusion detection and intrusion prevention systems (IDS/IPS) are often designed with rules based on IT protocols; therefore, they may be more useful in OT operation systems or the OT demilitarised zone (DMZ) than in supervisory and process areas. Note: It is not recommended to deploy an IPS unless it is tailored to the OT environment, or is outside of critical process control. IPS risk interrupting critical OT devices.	侵入検知および侵入防御システム（IDS/IPS）は、多くの場合、ITプロトコルに基づいたルールで設計されている。したがって、監視およびプロセス領域よりも、OTオペレーションシステムまたはOT非武装地帯（DMZ）において、より有用である可能性がある。注：OT 環境に合わせたものでない限り、あるいは重要なプロセス制御の外側でない限り、IPS を配備することは推奨されない。IPS は重要な OT デバイスを遮断するリスクがある。
Additional guidance	その他のガイダンス
For further guidance, consider visiting:	さらなるガイダンスについては、以下を参照のこと：
・Joint-sealed Identifying and Mitigating Living Off the Land Techniques	・現地調達手法の識別と低減
・ASD ACSC’s Windows Event Logging and Forwarding	・ASD ACSC の Windows イベントログとフォワーディング
・CISA’s Guidance for Implementing M-21-31: Improving the Federal Government’s Investigative and Remediation Capabilities	・CISA の M-21-31 実施のためのガイダンス： 連邦政府の調査および修復能力の改善
・CISA’s SCuBA TRA and eVRF Guidance Documents	・CISA の SCuBA TRA および eVRF ガイダンス文書
・NSA’s Cyber Event Forwarding Guidance	・NSAのサイバー・イベント・フォワーディング・ガイダンス
・NCSC-UK’s What exactly should we be logging?	・NCSC-UKのWhat exactly should we be logging?
・NIST’s SP 800-92 Rev. 1, Cybersecurity Log Management Planning Guide	・NISTのSP 800-92 Rev.1、サイバーセキュリティ・ログ管理計画ガイド
・NIST’s Guide to Operational Technology (OT) Security	・NISTの運用技術（OT）セキュリティ・ガイド
・US White House’s M-21-31	・米国ホワイトハウスのM-21-31
・Malcolm | A powerful, easily deployable network traffic analysis tool suite	・Malcolm｜ 強力で容易に導入可能なネットワーク・トラフィック分析ツール・スイート
・MITRE ATT&CK®’s Data Sources	・MITRE ATT&CK® のデータソース
Footnotes	脚注
1. While the audience for the cited guidance is U.S. Federal Civilian Executive Branch agencies, it may provide useful guidance to all entities regarding logging best practices.	1. 引用したガイダンスの対象者は連邦文民行政機関であるが、ロギングのベストプラクティスに関して、すべての事業体に有用なガイダンスを提供する可能性がある。
2. While only binding on US federal information systems, excluding national security systems, this memorandum may provide useful guidance to all entities regarding logging best practices.	2. 国家安全保障システムを除く米国連邦情報システムのみを拘束するものではあるが、この覚書は、ロギングのベストプラクティスに関して、すべての事業体に有用なガイダンスを提供する可能性がある。
3. CISA’s “First 48”: What to Expect When a Cyber Incident Occurs	3. CISA の「最初の 48」： サイバーインシデントが発生したときに予想されること
4. The prioritised list focuses on logs that enable the detection of a malicious actor operating remotely. In this context, collecting logs from an air-gapped system is not a high priority unless malicious insiders are a concern.	4. 優先順位付けされたリストは、遠隔操作する悪意ある行為者の検知を可能にするログに焦点を当てている。この文脈では、悪意のある内部関係者が懸念されない限り、エアギャップされたシステムからログを収集することは優先順位が高くない。
5. MDM and MAM events are likely to be server-sent events, but they may also be generated by software deployed to the mobile device	5. MDM および MAM イベントは、サーバーから送信されるイベントである可能性が高いが、モ バイルデバイスに配備されたソフトウェアによって生成される場合もある。
6. NTDS.dit contains usernames, hashed passwords, and group memberships for all domain accounts, allowing for full domain compromise if the hashes can be cracked offline.	6. NTDS.ditはすべてのドメインアカウントのユーザー名、ハッシュ化されたパスワード、グルー プメンバーシップを含んでおり、ハッシュがオフラインで解読できれば、ドメインの完全な侵害 を可能にする。
7. Impossible travel occurs when a user logs in from multiple IP addresses that are a significant geographic distance apart (i.e. a person could not realistically travel between the geographic locations of the two IP addresses during the time period between the logins).	7. インポッシブル・トラベルは、ユーザーが地理的に大きく離れた複数のIPアドレスからログインした場合に発生する（つまり、ログインの間の期間に2つのIPアドレスの地理的な場所の間を人が移動することは現実的に不可能である）。
8. Large/continuous data exports should be alerted by default.	8. 大規模/連続的なデータエクスポートは、デフォルトで警告されるべきである。
9. Note that not all successful authentication events will be benign; e.g. credential theft or malicious insiders.	9. 認証に成功したすべてのイベントが良性であるとは限らないことに注意する。