脆弱性

2025.05.20

米国 NIST サイバーセキュリティ白書 CSWP 41 悪用される可能性の高い脆弱性 - 脆弱性悪用確率の提案指標

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

NISTがセキュリティ白書 CSWP 41 悪用される可能性の高い脆弱性 - 脆弱性悪用確率の提案指標を公表していますね...


毎年公表される何万ものソフトウェアやハードウェアの脆弱性のうち、悪用されるのはごく一部である。どの脆弱性が悪用されるかを予測することは、事業体の脆弱性是正活動の効率性と費用対効果にとって重要である。


まさにその通りですよね...

何でもかんでも脆弱性を修正する必要があるかというとそうではないわけです。

それは、脆弱性の特徴をとってもそうですし、利用されている環境によっても変わってくると思います...

利用環境との関係については、各組織が個別に判断しないといけないわけですが、脆弱性の性質については、もう少し精度を上げていく余地はありそうな気がしますよね...ということでこの研究報告ということだと思います。。。

データをとってベンダーや利用者と連携して適正な効果的な手法を考えていく必要がありそうですね...

 

NIST - ITL

・2025.05.19 NIST CSWP 41 Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability

 

NIST CSWP 41 Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability NIST CSWP 41 悪用される可能性の高い脆弱性 - 脆弱性悪用確率の提案指標
Abstract 概要
This work presents a proposed security metric to determine the likelihood that a vulnerability has been observed to be exploited. Only a small fraction of the tens of thousands of software and hardware vulnerabilities that are published every year will be exploited. Predicting which ones is important for the efficiency and cost effectiveness of enterprise vulnerability remediation efforts. Currently, such remediation efforts rely on the Exploit Prediction Scoring System (EPSS), which has known inaccurate values, and Known Exploited Vulnerability (KEV) lists, which may not be comprehensive. The proposed likelihood metric may augment EPSS remediation (correcting some inaccuracies) and KEV lists (enabling measurements of comprehensiveness). However, collaboration with industry is necessary to provide necessary performance measurements. 本研究では、脆弱性が悪用される可能性を判断するためのセキュリティ指標を提案する。毎年公表される何万ものソフトウェアやハードウェアの脆弱性のうち、悪用されるのはごく一部である。どの脆弱性が悪用されるかを予測することは、事業体の脆弱性是正活動の効率性と費用対効果にとって重要である。現在のところ、このような改善努力は、不正確な値が知られている Exploit Prediction Scoring System (EPSS) や、包括的でない可能性のある Known Exploited Vulnerability (KEV) リストに依存している。提案する尤度評価指標は、EPSS の是正(不正確さの一部を修正)と KEV リストの補強(包括性の測定が可能)になるかもしれない。しかし、必要な性能測定を提供するためには、産業界との協力が必要である。

 

・[PDF]

20250520-35746

・[DOCX][PDF] 仮訳

 

目次..

1. Introduction 1. 序論
2. Background 2. 背景
2.1. Common Vulnerabilities and Exposures 2.1. 一般的な脆弱性とエクスポージャー
2.2. Exploit Prediction Scoring System 2.2. エクスプロイト予測スコアリングシステム
2.3. Known Exploited Vulnerability Lists 2.3.既知の脆弱性リスト
3. Purpose and Uses 3. 目的と用途
3.1. Measurement of the Expected Proportion of Exploited CVEs 3.1. 悪用されるCVEの予想される割合の測定
3.2. Measurement of the Comprehensiveness of KEV Lists 3.2. KEVリストの包括性の測定
3.3. Augmenting KEV-Based Remediation Prioritization 3.3. KEVに基づく修復の優先順位付けを強化する
3.4. Augmenting EPSS-Based Remediation Prioritization 3.4. EPSSに基づく改善の優先順位付けを強化する
4. Equations 4. 方程式
4.1. LEV Equation 4.1. LEV方程式
4.2. LEV2 Equation 4.2. LEV2方程式
5. Equation Derivation 5. 方程式の導出
5.1. EPSS Scores as Pre-Threat Intelligence 5.1. 脅威前のインテリジェンスとしてのEPSSスコア
5.2. EPSS Scores as Lower Bounds 5.2. 下限値としてのEPSSスコア
5.3. EPSS Scores as Conditional Probabilities 5.3. 条件付き確率としてのEPSSスコア
6. Example Output 6. 出力例
7. Empirical Results 7. 実証結果
7.1. LEV Distributions 7.1. LEV分布
7.2. Proportion of CVEs Expected to be Exploited 7.2. 悪用が予想されるCVEの割合
7.3. LEV Recall of KEV Lists 7.3. KEVリストのLEVリコール
8. KEV List Comprehensiveness Measurements and Potential Sources of Error 8. KEVリストの包括性の測定と潜在的な誤差の原因
8.1. KEV policy choice 8.1. KEVポリシーの選択
8.2. Probability error 8.2. 確率誤差
8.3. Analysis error 8.3. 分析エラー
8.4. KEV visibility error 8.4. KEV視認性エラー
8.5. Calibration error 8.5. 校正エラー
8.6. Chance 8.6. チャンス
9. Performance 9. パフォーマンス
10. Implementation and Availability 10. 実施と利用可能性
10.1. NVD Download 10.1. NVD ダウンロード
10.2. CISA KEV Download 10.2. CISA KEV ダウンロード
10.3. EPSS Download and Data 10.3. EPSSダウンロードとデータ
11. Conclusion 11. 結論
References 参考文献
Appendix A. EPSS Documentation 附属書 A.EPSS文書
Appendix B. List of Abbreviations and Acronyms 附属書B.略語と頭字語のリスト

 

 

 

| | Comments (0)

2025.05.17

「重要電子計算機に対する不正な行為による被害の防止に関する法律」とその法律の施行に伴う関係法律の整備等に関する法律が成立しましたね...そして、クリアランス制度がはじまりましたね...(2025.05.16)

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

そういえば、2025.05.16からセキュリティクリアランス制度がはじまりましたね...

 

そして、いわゆる能動的サイバー防御を認めることも含むサイバー対処能力強化法といわれる

  • 重要電子計算機に対する不正な行為による被害の防止に関する法律案
  • 重要電子計算機に対する不正な行為による被害の防止に関する法律の施行に伴う関係法律の整備等に関する法律案

が参議院で可決されましたね...

参議院の本会議は、押しボタンでの投票となりますので、個人別に賛成したかどうかがわかりますね...



個人的にはなかなか緻密に作られている法律と感じました...法案を書いた人はすごい...

 

 

参議院

まずは、サイバー対処能力強化法

・2025.05.16 議案情報

・・[PDF] 要旨

参議院で可決された法律案は

・・[PDF] 提出法案

20250517-54026

 

・・[PDF] 衆議院内閣委員会の修正案(可決)

20250517-54115

 

次に整備法案

・2025.05.16 議案情報

・・[PDF] 要旨

参議院で可決された法律案は

・・[PDF] 提出法案

 

サイバー能力対処法を理解した上でということになると思いますが、セットとなっている整備法についてもざっとその概要を

要旨...


一、警察官職務執行法を改正し、警察庁長官が指名する警察官は、サイバーセキュリティを害することその他情報技術を用いた不正な行為に用いられる電気通信等又はその疑いがある電気通信等を認めた場合であって、そのまま放置すれば人の生命、身体又は財産に対する重大な危害が発生するおそれがあるため緊急の必要があるときは、そのいとまがないと認める特段の事由がある場合を除いてサイバー通信情報監理委員会の承認を得た上で、当該電気通信等の送信元等である電子計算機の管理者その他関係者に対し、危害防止のため通常必要と認められる措置であって電気通信回線を介して行う電子計算機の動作に係るものをとることを命じ、又は自らその措置をとることができるものとする。

二、自衛隊法を改正し、内閣総理大臣は、重要電子計算機のうち一定のものに対する特定不正行為であって、本邦外にある者による特に高度に組織的かつ計画的な行為と認められるものが行われた場合において、これにより重大な支障が生ずるおそれが大きいと認められ、かつ、その発生を防止するために自衛隊が有する特別の技術又は情報が必要不可欠であること等により自衛隊が対処を行う特別の必要があると認めるときは、自衛隊の部隊等に当該特定不正行為による当該重要電子計算機への被害を防止するために必要な電子計算機の動作に係る措置であって電気通信回線を介して行うもの(通信防護措置)をとるべき旨を命ずることができるものとする。また、当該措置をとるべき旨を命ぜられた部隊等の職務の執行及び自衛隊又は日本国にあるアメリカ合衆国の軍隊が使用する一定の電子計算機をサイバーセキュリティを害することその他情報技術を用いた不正な行為から職務上警護する自衛官の職務の執行について、警察官職務執行法の必要な規定を準用するものとする。

三、サイバーセキュリティ基本法を改正し、サイバーセキュリティ戦略本部について、内閣総理大臣を本部長、全ての国務大臣を本部員とする組織に改めるとともに、その所掌事務について見直しを行う。

四、内閣法を改正し、内閣官房に内閣サイバー官一人を置く

五、この法律は、一部の規定を除き、重要電子計算機に対する不正な行為による被害の防止に関する法律の施行の日から施行する。


 

法案


第二一七回閣第五号

重要電子計算機に対する不正な行為による被害の防止に関する法律の施行に伴う関係法律の整備等に関する法律案

(国家公務員法の一部改正)

第一条 国家公務員法(昭和二十二年法律第百二十号)の一部を次のように改正する。

第二条第三項第五号の四中「及び内閣情報官」を「、内閣情報官及び内閣サイバー官」に改める。

(警察官職務執行法の一部改正)

第二条 警察官職務執行法(昭和二十三年法律第百三十六号)の一部を次のように改正する。

第六条の次に次の一条を加える。

(サイバー危害防止措置執行官による措置)

第六条の二 警察庁長官は、警察庁又は都道府県警察の警察官のうちから、次項の規定による処置を適正にとるために必要な知識及び能力を有すると認められる警察官をサイバー危害防止措置執行官として指名するものとする。

2 サイバー危害防止措置執行官は、サイバーセキュリティ(サイバーセキュリティ基本法(平成二十六年法律第百四号)第二条に規定するサイバーセキュリティをいう。)を害することその他情報技術を用いた不正な行為(以下この項において「情報技術利用不正行為」という。)に用いられる電気通信若しくはその疑いがある電気通信(以下この項及び第四項ただし書において「加害関係電気通信」という。)又は情報技術利用不正行為に用いられる電磁的記録(電子的方式、磁気的方式その他人の知覚によつては認識することができない方式で作られる記録であつて、電子計算機による情報処理の用に供されるものをいう。以下この項において同じ。)若しくはその疑いがある電磁的記録(以下この項において「加害関係電磁的記録」という。)を認めた場合であつて、そのまま放置すれば人の生命、身体又は財産に対する重大な危害が発生するおそれがあるため緊急の必要があるときは、加害関係電気通信の送信元若しくは送信先である電子計算機又は加害関係電磁的記録が記録された電子計算機(以下この条において「加害関係電子計算機」と総称する。)の管理者その他関係者に対し、加害関係電子計算機に記録されている加害関係電磁的記録の消去その他の危害防止のため通常必要と認められる措置であつて電気通信回線を介して行う加害関係電子計算機の動作に係るもの(適切に危害防止を図るために通常必要と認められる限度において、電気通信回線を介して当該加害関係電子計算機に接続して当該加害関係電子計算機に記録されたその動作に係る電磁的記録を確認することを含む。)をとることを命じ、又は自らその措置をとることができる。

3 加害関係電子計算機が国内に設置されていると認める相当な理由がない場合における当該加害関係電子計算機の動作に係る前項の規定による処置は、警察庁の警察官であるサイバー危害防止措置執行官に限り、とることができるものとする。この場合において、当該サイバー危害防止措置執行官は、あらかじめ、警察庁長官を通じて、外務大臣に協議しなければならない。

4 サイバー危害防止措置執行官は、第二項の規定による処置をとる場合には、あらかじめ、サイバー通信情報監理委員会の承認を得なければならない。ただし、当該加害関係電子計算機から重要電子計算機(重要電子計算機に対する不正な行為による被害の防止に関する法律(令和七年法律第▼▼▼号)第二条第二項に規定する重要電子計算機をいう。)に対してその機能に重大な障害を生じさせ、又は生じさせるおそれのある加害関係電気通信が現に送信されている場合その他の当該危害防止のためにはサイバー通信情報監理委員会の承認を得るいとまがないと認める特段の事由がある場合は、この限りでない。

5 第三項に規定する場合における前項の承認の求めは、第三項の規定による協議の結果を添えて行わなければならない。

6 サイバー通信情報監理委員会は、第四項の承認の求めがあつた場合において、当該求めが第二項及び第三項の規定に照らして適切であると認めるときは、当該承認をするものとする。

7 サイバー危害防止措置執行官は、第二項の規定による処置をとるに際しては、みだりに関係者の正当な業務を妨害してはならない。

8 サイバー危害防止措置執行官は、第二項の規定による処置をとつたときは、当該加害関係電子計算機の管理者に同項に規定する措置をとることを命じた場合を除き、国家公安委員会規則で定めるところにより、遅滞なく、その旨を当該管理者に通知するものとする。ただし、当該加害関係電子計算機に関係する危害の防止に支障がある場合及び当該管理者の所在が不明である場合は、この限りでない。

9 サイバー危害防止措置執行官は、第四項ただし書の規定によりサイバー通信情報監理委員会の承認を得ないで第二項の規定による処置をとつたときは、速やかに、当該処置についてサイバー通信情報監理委員会に通知しなければならない。

10 前項の規定による通知を受けたサイバー通信情報監理委員会は、当該通知に係る処置が第二項、第三項及び第四項ただし書の規定に照らして適切に行われたかどうかを確認し、第二項の規定による処置に係る事務の適正な実施を確保するため必要があると認めるときは、当該確認の結果に基づき、当該通知を行つたサイバー危害防止措置執行官が所属する警察庁又は都道府県警察の警察庁長官又は警視総監若しくは道府県警察本部長(次項において「警察庁長官等」という。)に対し、必要な措置をとるべきことを勧告するものとする。

11 サイバー危害防止措置執行官は、この条の規定による措置の実施について、警察庁長官等(第三項に規定する場合にあつては、警察庁長官)の指揮を受けなければならない。

(特別職の職員の給与に関する法律の一部改正)

第三条 特別職の職員の給与に関する法律(昭和二十四年法律第二百五十二号)の一部を次のように改正する。

第一条第八号中「及び内閣情報官」を「、内閣情報官及び内閣サイバー官」に改め、同条第十四号の三の次に次の一号を加える。

十四の四 サイバー通信情報監理委員会の委員長及び常勤の委員 第一条第四十七号の三の次に次の一号を加える。

四十七の四 サイバー通信情報監理委員会の非常勤の委員 別表第一官職名の欄中「カジノ管理委員会委員長」を

「 カジノ管理委員会委員長

サイバー通信情報監理委員会委員長 」

に、「及び内閣情報官」を「、内閣情報官及び内閣サイバー官」に、「カジノ管理委員

会の常勤の委員」を

「 カジノ管理委員会の常勤の委員

サイバー通信情報監理委員会の常勤の委員 」 に改める。

(自衛隊法の一部改正)

第四条 自衛隊法(昭和二十九年法律第百六十五号)の一部を次のように改正する。

第二十二条第一項中「又は第八十一条の二第一項」を「、第八十一条の二第一項又は第八十一条の三第一項」に改め、「出動」の下に「その他の行動」を加える。

第八十一条の二の次に次の一条を加える。 (重要電子計算機に対する通信防護措置)

第八十一条の三 内閣総理大臣は、重要電子計算機に対する特定不正行為(重要電子計算機に対する不正な行為による被害の防止に関する法律(令和七年法律第▼▼▼号)第二条第四項に規定する特定不正行為をいい、電気通信回線を介して行われるものに限る。以下この項及び第四項第一号において同じ。)であつて、本邦外にある者による特に高度に組織的かつ計画的な行為と認められるものが行われた場合において、次の各号のいずれにも該当することにより自衛隊が対処を行う特別の必要があると認めるときは、部隊等に当該特定不正行為(当該特定不正行為を行つた者による同種の特定不正行為を含む。第一号において同じ。)による当該重要電子計算機への被害を防止するために必要な電子計算機の動作に係る措置であつて電気通信回線を介して行うもの(以下この条及び第九十一条の三において「通信防護措置」という。)をとるべき旨を命ずることができる。

一 当該特定不正行為により重要電子計算機に特定重大支障(重要電子計算機の機能の停止又は低下であつて、当該機能の停止又は低下が生じた場合に、当該重要電子計算機に係る事務又は事業の安定的な遂行に容易に回復することができない支障が生じ、これによつて国家及び国民の安全を著しく損なう事態が生ずるものをいう。次号において同じ。)が生ずるおそれが大きいと認めること。

二 特定重大支障の発生を防止するために自衛隊が有する特別の技術又は情報が必要不可欠であること。

三 国家公安委員会からの要請又はその同意があること。

2 前項の「重要電子計算機」とは、重要電子計算機に対する不正な行為による被害の防止に関する法律第二条第二項に規定する重要電子計算機(同項第三号に該当するものにあつては、防衛省が調達する装備品等の開発及び生産のための基盤の強化に関する法律(令和五年法律第五十四号)第二十七条第一項に規定する契約事業者である者が次に掲げる情報を取り扱うために使用するものに限る。)をいう。

一 日米相互防衛援助協定等に伴う秘密保護法(昭和二十九年法律第百六十六号)第一条第三項に規定する特別防衛秘密である情報

二 特定秘密の保護に関する法律(平成二十五年法律第百八号)第三条第一項に規定する特定秘密(同法第五条第四項の規定により防衛大臣が保有させ、又は同法第八条第一項の規定により防衛大臣が提供したものに限る。)である情報

三 防衛省が調達する装備品等の開発及び生産のための基盤の強化に関する法律第二十七条第一項に規定する装備品等秘密である情報

四 重要経済安保情報の保護及び活用に関する法律(令和六年法律第二十七号)第三条第一項に規定する重要経済安保情報(同法第十条第一項の規定により防衛大臣が提供し、又は同条第二項の規定により防衛大臣が保有させたものに限る。)である情報

3 第一項の規定により通信防護措置をとるべき旨を命ぜられた部隊等は、警察庁又は都道府県警察(次項第四号において「警察庁等」という。)と共同して当該通信防護措置を実施するものとする。

4 内閣総理大臣は、第一項の規定により部隊等に通信防護措置をとるべき旨を命ずる場合には、あらかじめ、防衛大臣と国家公安委員会との間で協議をさせた上で、次に掲げる事項を指定しなければならない。

一 通信防護措置により対処を行う特定不正行為及び防護の対象となる第二項に規定する重要電子計算機

二 通信防護措置として実施すべき措置に関する事項

三 通信防護措置の期間

四 警察庁等と共同して通信防護措置を実施する要領その他の警察庁等との連携に関する事項

五 その他必要な事項

5 内閣総理大臣は、前項第三号の期間内であつても、通信防護措置の必要がなくなつたと認める場合には、速やかに、部隊等に通信防護措置の終了を命じなければならない。

第八十六条中「第八十一条の二第一項」の下に「、第八十一条の三第一項」を加える。 第八十九条第一項中「)の規定は、」を「。第六条の二を除く。)の規定は」に改め、「ついて」の下に「、同法第六条の二第二項から第十一項までの規定は当該自衛官のうちこの項において準用する同条第二項の規定による処置を適正にとるために必要な能力を有する部隊等として防衛大臣が指定する部隊等に属するものの職務の執行について、それぞれ」を加え、「あるのは、」を「あるのは」に改め、「者」と」の下に「、同法第六条の二第三項中「処置は、警察庁の警察官であるサイバー危害防止措置執行官に限り、とることができるものとする。この場合において、当該」とあるのは「処置をとる」と、「警察庁長官」とあるのは「防衛大臣」と、同条第四項中「あらかじめ」とあるのは「あらかじめ、防衛大臣を通じて」と、同条第八項中「国家公安委員会規則」とあるのは「防衛省令」と、「その旨を」とあるのは「その旨を部隊等の長を通じて」と、同条第九項中「サイバー通信情報監理委員会に」とあるのは「防衛大臣を通じてサイバー通信情報監理委員会に」と、同条第十項中「当該通知を行つたサイバー危害防止措置執行官が所属する警察庁又は都道府県警察の警察庁長官又は警視総監若しくは道府県警察本部長(次項において「警察庁長官等」という。)」とあり、及び同条第十一項中「警察庁長官等(第三項に規定する場合にあつては、警察庁長官)」とあるのは「防衛大臣」と」を加える。

第九十一条の二の次に次の一条を加える。

(重要電子計算機に対する通信防護措置の際の権限)

第九十一条の三 警察官職務執行法第六条の二第二項から第十一項までの規定は、第八十一条の三第一項の規定により通信防護措置をとるべき旨を命ぜられた部隊等の自衛官の職務の執行について準用する。この場合において、同法第六条の二第二項中「サイバーセキュリティ(サイバーセキュリティ基本法(平成二十六年法律第百四号)第二条に規定するサイバーセキュリティをいう。)を害することその他情報技術を用いた不正な行為(以下この項において「情報技術利用不正行為」という。)」とあるのは「重要電子計算機(自衛隊法(昭和二十九年法律第百六十五号)第八十一条の三第二項に規定する重要電子計算機をいう。第四項において同じ。)に対する特定不正行為(同条第一項に規定する特定不正行為をいう。以下この項において同じ。)」と、「情報技術利用不正行為に」とあるのは「当該特定不正行為に」と、同条第三項中「処置は、警察庁の警察官であるサイバー危害防止措置執行官に限り、とることができるものとする。この場合において、当該」とあるのは「処置をとる」と、「警察庁長官」とあるのは「防衛大臣」と、同条第四項中「あらかじめ」とあるのは「あらかじめ、防衛大臣を通じて」と、同項ただし書中「重要電子計算機(重要電子計算機に対する不正な行為による被害の防止に関する法律(令和七年法律第▼▼▼号)第二条第二項に規定する重要電子計算機をいう。)」とあるのは「重要電子計算機」と、同条第八項中「国家公安委員会規則」とあるのは「防衛省令」と、「その旨を」とあるのは「その旨を部隊等の長を通じて」と、同条第九項中「サイバー通信情報監理委員会に」とあるのは「防衛大臣を通じてサイバー通信情報監理委員会に」と、同条第十項中「当該通知を行つたサイバー危害防止措置執行官が所属する警察庁又は都道府県警察の警察庁長官又は警視総監若しくは道府県警察本部長(次項において「警察庁長官等」という。)」とあり、及び同条第十一項中「警察庁長官等(第三項に規定する場合にあつては、警察庁長官)」とあるのは「防衛大臣」と読み替えるものとする。

第九十二条第二項中「及び第九十条第一項」を「(第六条の二を除く。)及び第九十条第一項」に、「規定は、」を「規定は」に、「海上保安庁法第十六条」を「同法第六条の二第二項から第十一項までの規定は当該自衛官のうちこの項において準用する同条第二項の規定による処置を適正にとるために必要な能力を有する部隊等として防衛大臣が指定する部隊等に属するものが前項の規定により公共の秩序の維持のため行う職務の執行について、海上保安庁法第十六条」に、「準用する。」を「、それぞれ準用する。」に改め、「者」と」の下に「、同法第六条の二第三項中「処置は、警察庁の警察官であるサイバー危害防止措置執行官に限り、とることができるものとする。この場合において、当該」とあるのは「処置をとる」と、「警察庁長官」とあるのは「防衛大臣」と、同条第四項中「あらかじめ」とあるのは「あらかじめ、防衛大臣を通じて」と、同条第八項中「国家公安委員会規則」とあるのは「防衛省令」と、「その旨を」とあるのは「その旨を部隊等の長を通じて」と、同条第九項中「サイバー通信情報監理委員会に」とあるのは「防衛大臣を通じてサイバー通信情報監理委員会に」と、同条第十項中「当該通知を行つたサイバー危害防止措置執行官が所属する警察庁又は都道府県警察の警察庁長官又は警視総監若しくは道府県警察本部長(次項において「警察庁長官等」という。)」とあり、及び同条第十一項中「警察庁長官等(第三項に規定する場合にあつては、警察庁長官)」とあるのは「防衛大臣」と」を加え、「この項において準用する警察官職務執行法第七条及びこの法律」を「自衛隊法(昭和二十九年法律第百六十五号)第九十二条第二項において準用する警察官職務執行法第七条及び自衛隊法」に、「この項において準用する海上保安庁法」を「同法第九十二条第二項において準用する」に改め、「、「海上保安官又は海上保安官補の職務」とあるのは「第七十六条第一項(第一号に係る部分に限る。)の規定により出動を命ぜられた自衛隊の自衛官が公共の秩序の維持のため行う職務」と」を削る。

第九十五条の四を第九十五条の五とし、第九十五条の三の次に次の一条を加える。

(自衛隊等が使用する特定電子計算機の警護のための権限)

第九十五条の四 警察官職務執行法第六条の二第二項から第十一項までの規定は、次に掲げる特定電子計算機(不正アクセス行為の禁止等に関する法律(平成十一年法律第百二十八号)第二条第一項に規定する特定電子計算機をいう。)をサイバーセキュリティ(サイバーセキュリティ基本法(平成二十六年法律第百四号)第二条に規定するサイバーセキュリティをいう。)を害することその他情報技術を用いた不正な行為から職務上警護する自衛官の職務の執行について準用する。この場合において、警察官職務執行法第六条の二第二項中「、サイバーセキュリティ」とあるのは「、自衛隊法(昭和二十九年法律第百六十五号)第九十五条の四第一項各号に掲げる特定電子計算機(第四項ただし書において「特定電子計算機」という。)に対するサイバーセキュリティ」と、「情報技術利用不正行為に」とあるのは「当該情報技術利用不正行為に」と、同条第三項中「処置は、警察庁の警察官であるサイバー危害防止措置執行官に限り、とることができるものとする。この場合において、当該」とあるのは「処置をとる」と、「警察庁長官」とあるのは「防衛大臣」と、同条第四項中「あらかじめ」とあるのは「あらかじめ、防衛大臣を通じて」と、同項ただし書中「に対し」とあるのは「である特定電子計算機に対し」と、同条第八項中「国家公安委員会規則」とあるのは「防衛省令」と、「その旨を」とあるのは「その旨を部隊等の長を通じて」と、同条第九項中「サイバー通信情報監理委員会に」とあるのは「防衛大臣を通じてサイバー通信情報監理委員会に」と、同条第十項中「当該通知を行つたサイバー危害防止措置執行官が所属する警察庁又は都道府県警察の警察庁長官又は警視総監若しくは道府県警察本部長(次項において「警察庁長官等」という。)」とあり、及び同条第十一項中「警察庁長官等(第三項に規定する場合にあつては、警察庁長官)」とあるのは「防衛大臣」と読み替えるものとする。

一 自衛隊が使用する特定電子計算機

二 日本国とアメリカ合衆国との間の相互協力及び安全保障条約に基づき日本国にあるアメリカ合衆国の軍隊が使用する特定電子計算機

2 前項第二号に掲げる特定電子計算機に対する同項の警護は、アメリカ合衆国の軍隊から要請があつた場合であつて、防衛大臣が必要と認めるときに限り、自衛官が行うものとする。

(情報処理の促進に関する法律の一部改正)

第五条 情報処理の促進に関する法律(昭和四十五年法律第九十号)の一部を次のように改正する。

第五十一条第二項中「第一号」の下に「又は第二号」を加える。

第六条 情報処理の促進に関する法律の一部を次のように改正する。

第五十一条第二項中「(第一号又は第二号に係る部分に限る。)」を「若しくは重要電子計算機に対する不正な行為による被害の防止に関する法律(令和七年法律第▼▼▼ 号)第七十二条第一項若しくは第二項」に改める。

(国立研究開発法人情報通信研究機構法の一部改正)

第七条 国立研究開発法人情報通信研究機構法(平成十一年法律第百六十二号)の一部を次のように改正する。

第十四条に次の一項を加える。

3 機構は、前二項の業務のほか、サイバーセキュリティ基本法第三十一条第一項(第二号に係る部分に限る。)の規定による事務を行う。 (行政機関が行う政策の評価に関する法律の一部改正)

第八条 行政機関が行う政策の評価に関する法律(平成十三年法律第八十六号)の一部を次のように改正する。

第六条第一項中「カジノ管理委員会」の下に「、サイバー通信情報監理委員会」を加える。

(情報通信技術を活用した行政の推進等に関する法律の一部改正)

第九条 情報通信技術を活用した行政の推進等に関する法律(平成十四年法律第百五十一号)の一部を次のように改正する。

第二十七条本文中「カジノ管理委員会規則」の下に「、サイバー通信情報監理委員会規則」を加え、同条ただし書中「カジノ管理委員会、」の下に「サイバー通信情報監理委員会、」を、「カジノ管理委員会規則」の下に「、サイバー通信情報監理委員会規則」を加える。

(民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律の一部改正)

第十条 民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律(平成十六年法律第百四十九号)の一部を次のように改正する。

第九条本文中「カジノ管理委員会規則」の下に「、サイバー通信情報監理委員会規則」を加え、同条ただし書中「カジノ管理委員会、」の下に「サイバー通信情報監理委員会、」を、「カジノ管理委員会規則」の下に「、サイバー通信情報監理委員会規則」を加える。

(産業競争力強化法の一部改正)

第十一条 産業競争力強化法(平成二十五年法律第九十八号)の一部を次のように改正する。

第百四十七条第三項本文中「カジノ管理委員会規則」の下に「、サイバー通信情報監理委員会規則」を加え、同項ただし書中「カジノ管理委員会、」の下に「サイバー通信情報監理委員会、」を、「カジノ管理委員会規則」の下に「、サイバー通信情報監理委員会規則」を加える。

(サイバーセキュリティ基本法の一部改正)

第十二条 サイバーセキュリティ基本法(平成二十六年法律第百四号)の一部を次のように改正する。

第七条に次の一項を加える。

2 情報システム若しくはその一部を構成する電子計算機若しくはプログラム、情報通信ネットワーク又は電磁的記録媒体(以下この項において「情報システム等」という。)の供給者は、サイバーセキュリティに対する脅威により自らが供給した情報システム等に被害が生ずることを防ぐため、情報システム等の利用者がその安全性及び信頼性の確保のために講ずる措置に配慮した設計及び開発、適切な維持管理に必要な情報の継続的な提供その他の情報システム等の利用者がサイバーセキュリティの確保のために講ずる措置を支援する取組を行うよう努めるものとする。

第十七条第五項中「命を受けて内閣官房副長官補」を「内閣サイバー官」に改める。

第二十六条第一項中第五号を第六号とし、第四号を第五号とし、同項第三号中「又は」を「及び」に、「で発生した」を「におけるサイバーセキュリティの確保の状況の評価(情報システムに対する不正な活動であって情報通信ネットワーク又は電磁的記録媒体を通じて行われるものの監視及び分析並びに」に改め、「を含む。)」の下に「を含む。)」を加え、同号を同項第四号とし、同項第二号の次に次の一号を加える。

三 重要社会基盤事業者等におけるサイバーセキュリティの確保に関して国の行政機関が実施する施策の基準の作成(当該基準の作成のための重要社会基盤事業者等におけるサイバーセキュリティの確保の状況の調査を含む。)及び当該基準に基づく施策の評価その他の当該基準に基づく施策の実施の推進に関すること。

第二十六条中第三項を第四項とし、第二項の次に次の一項を加える。

3 本部は、次に掲げる場合には、あらかじめ、サイバーセキュリティ推進専門家会議の意見を聴かなければならない。

一 サイバーセキュリティ戦略の案を作成しようとするとき。

二 第一項第二号又は第三号の基準を作成しようとするとき。

三 第一項第二号又は第三号の評価について、その結果の取りまとめを行おうとするとき。

第二十八条第一項中「内閣官房長官」を「内閣総理大臣」に改め、同条第三項中「、第三号及び第五号」を「から第四号まで及び第六号」に改め、同条第五項を削る。

第三十条第二項中「次に掲げる者(第一号から第六号までに掲げる者にあっては、副本部長に充てられたものを除く。)」を「本部長及び副本部長以外の全ての国務大臣」に改め、同項各号を削り、同条の次に次の一条を加える。

(サイバーセキュリティ推進専門家会議)

第三十条の二 本部に、サイバーセキュリティ推進専門家会議(以下この条において「専門家会議」という。)を置く。

2 専門家会議は、次に掲げる事務をつかさどる。

一 第二十六条第三項の規定により本部長に意見を述べること。

二 前号に掲げるもののほか、サイバーセキュリティに関する施策で重要なものについて調査審議し、必要があると認めるときは、本部長に意見を述べること。

3 専門家会議の委員は、サイバーセキュリティに関し優れた識見を有する者のうちから、内閣総理大臣が任命する。

第三十一条第一項第一号中「独立行政法人及び指定法人におけるサイバーセキュリティに関する対策の基準に基づく監査」を「同号に規定する監査(独立行政法人及び指定法人に係るものに限る。)」に、「又は同項第三号」を「、同項第三号に掲げる事務(同号に規定する調査に係るものに限る。)又は同項第四号」に、「独立行政法人又は指定法人で発生したサイバーセキュリティに関する重大な事象の原因究明のための調査」を「同号に規定する調査(独立行政法人及び指定法人に係るものに限る。)」に改め、同項第二号中「第二十六条第一項第四号」を「第二十六条第一項第五号」に改め、同号を同項第三号とし、同項第一号の次に次の一号を加える。

二 第二十六条第一項第四号に掲げる事務(同号に規定する活動の監視及び分析に係るものに限る。) 国立研究開発法人情報通信研究機構、独立行政法人情報処理推進機構その他当該活動の監視及び分析について十分な技術的能力及び専門的な知識経験を有するとともに、当該事務を確実に実施することができるものとして政令で定める法人

第三十三条第二項中「前項」を「前二項」に、「同項」を「第一項」に改め、同項を同条第三項とし、同条第一項の次に次の一項を加える。

2 本部は、その所掌事務を遂行するため必要があると認めるときは、重要社会基盤事業者及びその組織する団体の代表者に対して、前項の協力を求めることができる。この場合において、当該求めを受けた者は、その求めに応じるよう努めるものとする。

第三十五条中「命を受けて内閣官房副長官補」を「内閣サイバー官」に改める。

第三十六条中「内閣法」の下に「(昭和二十二年法律第五号)」を加える。

第十三条 サイバーセキュリティ基本法の一部を次のように改正する。

目次中「第二十四条」を「第二十三条」に、「第二十五条」を「第二十四条」に改める。

第十二条第二項第三号中「の促進」を削る。

第十四条の見出し中「の促進」を削り、同条中「関し」の下に「、重要な設備に係る電子計算機の被害の防止のための情報の整理及び分析を行うとともに」を加える。

第十七条を削り、第十八条を第十七条とし、第十九条から第二十四条までを一条ずつ繰り上げ、第四章中第二十五条を第二十四条とする。

第二十六条第一項中第五号を削り、第六号を第五号とし、同条を第二十五条とし、第二十七条を第二十六条とする。

第二十八条第三項中「第二十六条第一項第二号から第四号まで及び第六号」を「第二十五条第一項第二号から第五号まで」に改め、同条を第二十七条とし、第二十九条を第二十八条とし、第三十条を第二十九条とする。

第三十条の二第二項第一号中「第二十六条第三項」を「第二十五条第三項」に改め、同条を第三十条とする。

第三十一条第一項第一号中「第二十六条第一項第二号」を「第二十五条第一項第二号」に改め、同項第二号中「第二十六条第一項第四号」を「第二十五条第一項第四号」に改め、同項第三号を削る。

第三十八条中「第十七条第四項又は」を削る。

(情報通信技術を利用する方法による国の歳入等の納付に関する法律の一部改正)

第十四条 情報通信技術を利用する方法による国の歳入等の納付に関する法律(令和四年法律第三十九号)の一部を次のように改正する。

第十四条本文中「カジノ管理委員会規則」の下に「、サイバー通信情報監理委員会規則」を加え、同条ただし書中「カジノ管理委員会、」の下に「サイバー通信情報監理委員会、」を、「カジノ管理委員会規則」の下に「、サイバー通信情報監理委員会規則」を加える。

(内閣法の一部改正)

第十五条 内閣法(昭和二十二年法律第五号)の一部を次のように改正する。

第十五条の二第二項第四号中「及び内閣情報官」を「、内閣情報官及び内閣サイバー官」に改める。

第十六条第六項中「二人」を「三人」に改め、同条第七項中「者」の下に「及び内閣サイバー官」を加える。

第十七条第二項中「内閣情報官」の下に「、内閣サイバー官」を加える。

第十九条の次に次の一条を加える。

第十九条の二 内閣官房に、内閣サイバー官一人を置く。

内閣サイバー官は、内閣官房長官、内閣官房副長官及び内閣危機管理監を助け、次に掲げる事務を掌理する。

第十二条第二項第二号から第五号までに掲げる事務のうちサイバーセキュリティ(サイバーセキュリティ基本法(平成二十六年法律第百四号)第二条に規定するサイバーセキュリティをいう。)の確保に関するもの(国家安全保障局、内閣広報官及び内閣情報官の所掌に属するものを除く。)

サイバーセキュリティ基本法第十七条第五項の規定により内閣官房において処理することとされたサイバーセキュリティ協議会の庶務

サイバーセキュリティ基本法第三十五条の規定により内閣官房において処理することとされたサイバーセキュリティ戦略本部に関する事務

第十五条第四項から第六項までの規定は、内閣サイバー官について準用する。

第十六条 内閣法の一部を次のように改正する。

第十九条の二第二項中第二号を削り、第三号を第二号とする。

(内閣府設置法の一部改正)

第十七条 内閣府設置法(平成十一年法律第八十九号)の一部を次のように改正する。

第三条第二項中「安全の確保」の下に「、国等の重要な電子計算機等に対する不正な行為による被害の防止のための措置の適正な実施を確保するための審査及び検査の遂行」を加える。

第四条第一項に次の一号を加える。

三十七 重要電子計算機(重要電子計算機に対する不正な行為による被害の防止に関する法律(令和七年法律第▼▼▼号)第二条第二項に規定するものをいう。第三項第二十七号の七において同じ。)に対する特定不正行為(同条第四項に規定するものをいう。同号において同じ。)による被害の防止のための基本的な政策に関する事項 第四条第三項第二十七号の六の次に次の一号を加える。

二十七の七 重要電子計算機に対する不正な行為による被害の防止に関する法律に基づく重要電子計算機に対する特定不正行為による被害の防止に関する事務に関すること(他省及び金融庁の所掌に属するものを除く。)。

第四条第三項第五十九号の三の次に次の一号を加える。

五十九の四 重要電子計算機に対する不正な行為による被害の防止に関する法律第四十八条に規定する事務

第十六条第二項中「カジノ管理委員会」の下に「、サイバー通信情報監理委員会」を加える。

第六十四条の表カジノ管理委員会の項の次に次のように加える。


サイバー通信情報監理委員会


重要電子計算機に対する不正な行為による被害の防止に関する法律

 

附 則

(施行期日)

第一条 この法律は、重要電子計算機に対する不正な行為による被害の防止に関する法律(令和七年法律第▼▼▼号)の施行の日から施行する。ただし、次の各号に掲げる規定は、当該各号に定める日から施行する。

一 附則第四条の規定 公布の日

二 第一条の規定、第三条中特別職の職員の給与に関する法律第一条第八号の改正規定及び同法別表第一の改正規定(「及び内閣情報官」を「、内閣情報官及び内閣サイバー官」に改める部分に限る。)、第五条、第七条、第十二条及び第十五条の規定並びに第十七条中内閣府設置法第四条第一項に一号を加える改正規定及び同条第三項第二十七号の六の次に一号を加える改正規定 重要電子計算機に対する不正な行為による被害の防止に関する法律附則第一条第二号に掲げる規定の施行の日

三 第三条の規定(前号に掲げる改正規定を除く。)、第八条から第十一条まで及び第十四条の規定並びに第十七条の規定(同号に掲げる改正規定を除く。) 重要電子計算機に対する不正な行為による被害の防止に関する法律附則第一条第三号に掲げる規定の施行の日

(サイバーセキュリティ基本法の一部改正に伴う経過措置)

第二条 この法律の施行の日(以下この条及び次条において「施行日」という。)前に第十三条の規定による改正前のサイバーセキュリティ基本法第十七条第一項のサイバーセキュリティ協議会の事務に従事していた者に係る当該事務に関して知り得た秘密を漏らし、又は盗用してはならない義務及び施行日前に同法第三十一条第一項第三号に掲げる事務の委託を受けた法人の役員又は職員であった者に係る当該委託に係る事務に関して知り得た秘密を漏らし、又は盗用してはならない義務については、施行日以後も、なお従前の例による。

(罰則の適用に関する経過措置)

第三条 施行日前にした行為及び前条の規定によりなお従前の例によることとされる場合における施行日以後にした行為に対する罰則の適用については、なお従前の例による。

(政令への委任)

第四条 前二条に定めるもののほか、この法律の施行に関し必要な経過措置(罰則に関する経過措置を含む。)は、政令で定める。

(デジタル庁設置法の一部改正)

第五条 デジタル庁設置法(令和三年法律第三十六号)の一部を次のように改正する。

第四条第一項第二号中「第二十六条第一項」を「第二十五条第一項」に改める。  

 

理 由

重要電子計算機に対する不正な行為による被害の防止に関する法律の施行に伴い、重大な危害を防止するための一定の警察官又は自衛官による電子計算機の動作に係る措置に関する規定を整備するとともに、サイバーセキュリティ基本法その他の関係法律について所要の規定の整備等を行う必要がある。これが、この法律案を提出する理由である。

 


 

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

 

能動的サイバー防御・サイバー対処能力強化法関係...

・2025.02.08 内閣官房 サイバー対処能力強化法案及び同整備法案 (2025.02.07)

・2025.01.29 自民党 能動的サイバー防御の導入へ 関係会議が法案概要を了承 (2025.01.24)

 

・2024.12.28 内閣官房 内閣サイバー官(特別職、次官級)・国家サイバー統括室の新設と【内閣府】防災監(次官級)の新設(政府の災害対応の司令塔機能の抜本的強化)(2024.12.27)

 

・2024.12.02 内閣官房 サイバー安全保障分野での対応能力の向上に向けた提言 (2024.11.29)

 

・2024.10.22 参議院常任委員会調査室・特別調査室 「能動的サイバー防御に係る制度構築の方向性と課題」

 

・2024.09.13 自民党 サイバー安全保障分野での対応能力向上に向けた提言 (2024.09.11)

 

・2024.08.29 内閣官房 サイバー安全保障分野での対応能力の向上に向けた有識者会議 これまでの議論の整理 (2024.08.07)

・2024.07.13 防衛白書(2024年)

・2024.03.23 国立国会図書館 調査及び立法考査局 サイバーセキュリティの確保と通信の秘密の保護―この 20年の議論と能動的サイバー防御導入等に向けた課題―

・2023.09.23 サイバー領域への軍事的適応の課題:オランダの事例研究 (2023.07.13)

・2023.07.28 防衛白書(2023年) (+ 能動的サイバー防衛...)

・2023.07.17 英国 NCSC アクティブ・サイバーディフェンス第6次報告書 (2023.07.06) そういえばNCSCは「アクティブ・サイバーディフェンスは防御であって攻撃ではない」と言ってました...

・2023.06.17 経団連 サイバー安全保障に関する意見交換会を開催

・2023.05.24 米国 国防総合大学 「統合抑止力とサイバー空間 - 国益追求のためのサイバー作戦の役割を探る論文選集」(2023.05.15)

・2023.04.03 米国 米サイバー軍がアルバニアでイランからのサイバー攻撃に対する防衛的ハント作戦を実施 (2023.03.23)

・2022.12.18 国家安全保障戦略が閣議決定されましたね。。。(2022.12.16) 対英訳付き...

・2022.08.23 米国 サイバー司令部:クロアチアと米国のサイバー防衛隊が悪質な行為者をハントする

・2021.04.07 ハックバックを認めるべき?民間企業による積極的サイバー防衛についての記事 ... Oxford Academic, Journal of Cybersecurity: Private active cyber defense and (international) cyber security—pushing the line?

・2021.02.21 U.K. NSCS 2019年能動的サイバー防御についての実績報告書 (Active Cyber Defence (ACD) - The Third Year)

 

 

クリアランス制度(経済安保情報活用及び保護法)

・2025.02.25 特定秘密の保護に関する法律と重要経済安保情報の保護及び活用に関する法律の比較...

・2025.02.06 内閣府 重要経済安保情報の指定及びその解除、適性評価の実施並びに適合事業者の認定に関し、統一的な運用を図るための基準 (2025.01.31)

・2024.05.11 日本でもセキュリティクリアランス制度が本格的に導入されることになりましたね...

・2024.02.28 内閣 重要経済安保情報の保護及び活用に関する法律案が閣議決定

・2024.02.20 経団連 経済安全保障分野におけるセキュリティ・クリアランス制度等に関する提言 (2024.02.15)

・2024.01.30 内閣官房 経済安全保障分野におけるセキュリティ・クリアランス制度等に関する有識者会議 最終取りまとめ (2024.01.19)

・2023.12.22 内閣官房 経済安全保障分野におけるセキュリティ・クリアランス制度等に関する有識者会議(第9回)

・2023.10.12 内閣官房 経済安全保障分野におけるセキュリティ・クリアランス制度等に関する有識者会議(第7回)

・2023.08.27 参議院常任委員会調査室・特別調査室:セキュリティ・クリアランス制度導入の方向性と主な論点 ~技術流出の防止等による国力向上を目指した制度構築に向けて~

・2023.06.08 経済安全保障分野におけるセキュリティ・クリアランス制度等に関する有識者会議 中間論点整理

・2023.04.08 自民党 セキュリティ・クリアランスで法整備を経済安保推進本部・安全保障調査会・サイバーセキュリティ対策本部・デジタル社会推進本部が提言

・2023.02.27 内閣官房 経済安全保障分野におけるセキュリティ・クリアランス制度等に関する有識者会議

・2022.12.18 国家安全保障戦略が閣議決定されましたね。。。(2022.12.16) 対英訳付き...

・2022.10.19 自民党 わが国が目指すべき 経済安全保障の全体像について~新たな国家安全保障戦略策定に向けて~ (2022.10.04)

 

 

米国...

・2024.02.26 米国 GAO 国防総省インテリジェンス:プログラムの監督を強化しリスクを管理するために必要な行動

・2023.12.11 米国 国防総省 内部監察官室 請負業者ネットワーク上の国防総省管理対象非機密情報保護に関するサイバーセキュリティの共通の不備 (2023.12.04)

・2023.11.20 NIST 意見募集 IR8496 NIST IR 8496(初公開ドラフト) データ収集改善のためのデータ格付の概念と考察

・2023.11.05 RAND研究所 多様で信頼される労働力 - 国家安全保障担当者の審査における偏見の可能性と不公平の原因となりうる要素の検証

・2023.07.24 Rand研究所 セキュリティ・クリアランス・プロセスに関するネット上の誤解を評価する(+米国セキュリティクリアランス関連リンク)

・2022.08.18 米国 国土安全保障省 内部監察官室 2015年サイバーセキュリティ情報共有法の下、情報共有の改善に向けてさらなる進展が必要

・2021.09.21 国務省OIG 国務省のセキュリティ・クリアランス・データを国家情報長官室に報告するプロセスには改善が必要

 

その他...

・2024.08.08 英国 政府のセキュリティ格付

・2024.07.30 オーストラリア会計検査院 (ANAO) 国防省によるマイクリアランス・システムの調達と導入 (2024.07.11)

 

 

| | Comments (0)

2025.05.11

米国 FBI サポートが終了したルータを悪用したサイバー犯罪について警告

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

サポートが終了したルータを悪用したサイバー犯罪についてFBIが警告をだしていますね...

サポートが終了したルータは脆弱性があっても通常は対応されないないので、それを狙った侵入し、サイバー犯罪等に利用することができるわけですが、侵入し成功したルーターを他の人に利用してもらうということも可能となりますよね...

ボットネットの一部になってしまうと...

そういえば、家庭用ルーター等のCyber Trust Markの運用がFCC(連邦取引委員会)で始まっているように思うのですが、それはどうなっているのでしょうかね...2025年の後半、クリスマスプレゼントの購入の前(11月かあ12月前半?)に開始される可能性が高いようなかんじですかね...

 

FBI

・2025.05.07 Cyber Criminal Proxy Services Exploiting End of Life Routers

Alert Number: I-050725-PSA

Cyber Criminal Proxy Services Exploiting End of Life Routers サポートが終了したルータを悪用したサイバー犯罪プロキシサービス
The Federal Bureau of Investigation (FBI) is issuing this announcement to inform individuals and businesses about proxy services taking advantage of end of life routers that are susceptible to vulnerabilities. When a hardware device is end of life, the manufacturer no longer sells the product and is not actively supporting the hardware, which also means they are no longer releasing software updates or security patches for the device. Routers dated 2010 or earlier likely no longer receive software updates issued by the manufacturer and could be compromised by cyber actors exploiting known vulnerabilities. 連邦捜査局(FBI)は、脆弱性の影響を受けやすいサポートが終了したルータを悪用したプロキシサービスについて、個人および企業に周知するため、本アナウンスを発表する。ハードウェア・デバイスの製造が終了した場合、製造事業者はその製品の販売を終了し、ハードウェアのサポートも終了する。2010年以前のルーターは、製造事業者が発行するソフトウェア・アップデートを受け取らない可能性が高く、既知の脆弱性を悪用したサイバー行為によって侵害される可能性がある。
End of life routers were breached by cyber actors using variants of TheMoon malware botnet. Recently, some routers at end of life, with remote administration turned on, were identified as compromised by a new variant of TheMoon malware. This malware allows cyber actors to install proxies on unsuspecting victim routers and conduct cyber crimes anonymously. サポートが終了したルーターは、TheMoonマルウェア・ボットネットの亜種を使用したサイバー行為者によって侵入された。最近、リモート管理がオンになっているサポートが終了したルーターの一部が、TheMoonマルウェアの新しい亜種によって侵害されていることが確認された。このマルウェアにより、サイバー・アクターは疑うことを知らない被害者のルーターにプロキシをインストールし、匿名でサイバー犯罪を行うことができる。
Proxies and Router Vulnerabilities プロキシとルーターの脆弱性
A proxy server is a system or router that provides a gateway between users and the Internet. It is an intermediary between end-users and the web pages they visit online. A proxy is a service that relays users' Internet traffic while hiding the link between users and their activity. プロキシサーバーは、ユーザーとインターネットの間にゲートウェイを提供するシステムまたはルーターである。エンドユーザーと彼らがオンラインで閲覧するウェブページとの仲介役である。プロキシは、ユーザーのインターネット・トラフィックを中継し、ユーザーとその活動の間のリンクを隠すサービスである。
Cyber actors use proxy services to hide their identities and location. When actors use a proxy service to visit a website to conduct criminal activity, like stealing cryptocurrency or contracting illegal services, the website does not register their real IP address and instead registers the proxy IP. サイバー・アクターは、プロキシ・サービスを利用して、自分の身元や居場所を隠す。行為者がプロキシ・サービスを利用してウェブサイトを訪問し、暗号通貨の窃盗や違法サービスの契約などの犯罪行為を行う場合、ウェブサイトは実際のIPアドレスを登録せず、代わりにプロキシIPを登録する。
TheMoon Malware TheMoon マルウェア
TheMoon malware was first discovered on compromised routers in 2014 and has since gone through several campaigns. TheMoon does not require a password to infect routers; it scans for open ports and sends a command to a vulnerable script. The malware contacts the command and control (C2) server and the C2 server responds with instructions, which may include instructing the infected machine to scan for other vulnerable routers to spread the infection and expand the network. TheMoon マルウェアは2014年に侵害されたルーターで初めて発見され、その後いくつかのキャンペーンを経ている。TheMoonはルーターを感染させるのにパスワードを必要とせず、開いているポートをスキャンし、脆弱性のあるスクリプトにコマンドを送信する。マルウェアはコマンド・アンド・コントロール(C2)サーバーに連絡し、C2サーバーは感染したマシンに他の脆弱性ルーターをスキャンして感染を広げ、ネットワークを拡大するよう指示するなどの対応をとる。
Tips to Protect Yourself 防御のための識別
Commonly identified signs of malware infections on routers include overheating devices, problems with connectivity, and changes to settings the administrator does not recognize. ルーターにおけるマルウェア感染の兆候としてよく確認されるのは、デバイスの過熱、接続性の問題、管理者が認識していない設定の変更などである。
The FBI recommends individuals and companies take the following precautions: FBIは、個人および企業に対し、以下の予防策を講じることを推奨している:
・If the router is at end of life, replace the device with an updated model if possible. ・ルーターの寿命が来ている場合は、可能であれば最新のモデルに交換する。
・Immediately apply any available security patches and/or firmware updates for your devices. ・利用可能なセキュリティ・パッチやファームウェア・アップデートを直ちに適用する。
・Login online to the router settings and disable remote management/remote administration, save the change, and reboot the router. ・ルータの設定にオンラインでログインし、リモート管理/遠隔管理を無効にし、変更を保存して、ルータを再起動する。
・Use strong passwords that are unique and random and contain at least 16 but no more than 64 characters. Avoid reusing passwords and disable password hints. ・ユニークでランダムな、16 文字以上 64 文字以下の強力なパスワードを使用する。パスワードの再利用を避け、パスワードヒントを無効にする。
・If you believe there is suspicious activity on any device, apply any necessary security and firmware updates, change your password, and reboot the router. ・デバイスに不審な動きがあると思われる場合、必要なセキュリティとファームウェアのアップデートを適用し、パスワードを変更し、ルーターを再起動する。
Victim Reporting and Additional Information 被害者の報告および追加情報
If you suspect you are a victim of a proxy service or your personal information has been compromised: プロキシサービスの被害者であると思われる場合、または個人情報が漏洩していると思われる場合:
・File a complaint with the FBI Internet Crime Complaint Center (IC3), www.ic3.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting organization; designated point of contact. ・FBIインターネット犯罪苦情センター(IC3)www.ic3.gov。その際、インシデントに関する以下の情報を含めること:インシデントの発生日時、場所、アクティビティの種類、影響を受けた人数、アクティビティに使用された機器の種類、提出組織の名前、指定された連絡先。
・Contact your account provider immediately to regain control of your accounts, change passwords, and place alerts on your accounts for suspicious login attempts and/or transactions. ・アカウントの制御を回復し、パスワードを変更し、不審なログイン試行および/またはトランザクションのためのアラートをアカウントに配置するために、アカウントプロバイダに直ちに連絡する。

 

1_20250428102201

 


 

CyberTrust Markについてはこのブログをみれば、リンク先を含めてある程度の情報が入手できるように思います...

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

・2025.01.10 米国 ホワイトハウス サイバートラストマークを開始...

 

 

 

| | Comments (0)

2025.04.29

Google Mandiantのレポート (M-Trends 2025 Report) (2025.04.24)

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

Mandiantが2025年の脅威インテリジェンスレポートを公表していますね...ダウンロードをするためには、会社関係の登録が必要となります...

レポートは92ページあります。

 

・組織への侵入経路は

  • 最も多いのは脆弱性の悪用で33%。攻撃者は特にセキュリティデバイスやネットワークエッジデバイスを標的にしている。
  • 次に多いのは盗み出した認証情報(16%)とフィッシング(14%)。認証情報の窃取やソーシャルエンジニアリングの巧妙化が脅威を増大させている。認証情報の盗難は、地下フォーラムでの購入やインフォスティーラーによる収集を通じて増加している。多要素認証(MFA)の導入が急務。

・攻撃を受けている割合

  • 金融セクター 全体の約18%。同期は価値高いデータの入手や金銭的利益。
  • 続いて、専門職、ハイテク企業、政府、ヘルスケア

・攻撃者の滞在時間(検知するまでの時間)

  • 11日
  • 攻撃者による通知(14%)、内部検知(43%)、外部の検知(43%)

・新たな脅威

  • 北朝鮮のITワーカーによる内部脅威。金融、通信、ハイテク業界で確認されている。初期侵入の5%
  • Web3を標的した攻撃の増加

 

Google

・2025.04.24 M-Trends 2025 Report is now available

M-Trends 2025 Report is now available M-Trends 2025 レポートを発表
Stay ahead of the latest cyber threats with frontline insights from our incident response investigations. インシデント対応調査から得た最前線の知見で、最新のサイバー脅威を先取りしよう。
In this 16th edition of M-Trends, we share our observations and analysis of the dynamic threat landscape, and aim to provide security professionals with actionable guidance to enhance their security posture. M-Trendsの第16版である本レポートでは、ダイナミックな脅威の状況についての見解と分析を共有し、セキュリティ担当者にセキュリティ体制を強化するための実用的なガイダンスを提供することを目的としている。
Key trends explored in the report: 本レポートの主なトレンド
・Incident response metrics, including top detection sources and initial infection vectors ・インシデント対応の指標(上位の検知ソースや初期感染ベクトルなど
・Growing risk posed by infostealer malware ・情報窃取マルウェアがもたらすリスクの増大
・The Democratic People’s Republic of Korea IT worker threat ・朝鮮民主主義人民共和国のIT労働者の脅威
・The danger of unsecured data repositories ・安全でないデータ保管庫の危険性
・The Iranian threat landscape in 2024 ・2024年におけるイランの脅威状況
・The evolution of data theft in cloud and software as a service environments ・クラウドおよびSaaS環境におけるデータ盗難の進化
・Common themes in cloud compromise investigations ・クラウド侵害の調査に共通するテーマ
・Threats to Web3 and cryptocurrency ・Web3と暗号通貨への脅威

 

 

登録するとファイルがダウンロードできます...

20250429-52258

 

目次...

Introduction 序文
By the Numbers 数字で見る
Campaigns and Global Events キャンペーンと世界的な出来事
Targeted Attacks 標的型攻撃
Ransomware ランサムウェア
Cloud Compromises クラウド侵害
Threat Techniques 脅威の手口
Regional Reports 地域別レポート
 Americas  米州
 EMEA  欧州・中東・アフリカ
 JAPAC  日本
Articles 記事
Infostealer Malware Continues to Create a Threat to Enterprise Systems エンタープライズシステムへの脅威を生み続けるインフォステアマルウェア
Democratic People’s Republic of Korea Insider Threats 朝鮮民主主義人民共和国 インサイダーの脅威
The 2024 Iranian Threat Landscape 2024年イランの脅威情勢
Evolution of Data Theft in Cloud and Software-as-a-Service Environments クラウドおよびソフトウェア・アズ・ア・サービス環境におけるデータ盗難の進化 クラウドとSaaS環境におけるデータ盗難の進化
Common Themes in Cloud Compromise Investigations クラウド侵害の調査における共通のテーマ
Security Recommendations for Diverse Cloud and Hybrid Environments 多様なクラウドおよびハイブリッド環境に対するセキュリティの推奨
Threats to Web3 and Cryptocurrency Web3と暗号通貨への脅威
Unsecured Data Repositories 安全でないデータリポジトリ
Conclusion 結論
MITRE ATT&CK MITRE ATT&CK
Bibliography 参考文献

 

 

 

 

| | Comments (0)

2025.03.21

英国 NSCS 耐量子暗号への移行スケジュールを発表 (2025.03.20)

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

英国のNCSC長官が耐量子暗号への移行スケジュールを発表していますね...

2028年までに移行計画を決め、重要なものについては2031年までに、それ以外も2035年までに移行を完了するというスケジュールのようです...

米国と同様のスケジュールですね...

EU各国も2026年までには移行計画を発表し、概ね同じスケジュール感で公表してくるのだろうと思います。日本から正式な移行計画が出されるのかはわかりませんが、このスケジュール感で移行を計画すれば問題ないのでしょうかね...

 

U.K. National Cyber Security Centre: NCSC

1_20250209050301

アナウンス...

・2025.03.20 Cyber chiefs unveil new roadmap for post-quantum cryptography migration

Cyber chiefs unveil new roadmap for post-quantum cryptography migration サイバーセキュリティ責任者が、耐量子暗号への移行に向けた新たなロードマップを発表
New guidance from the NCSC outlines a three-phase timeline for organisations to transition to quantum-resistant encryption methods by 2035. NCSCが新たに発表した指針では、2035年までに量子耐性暗号方式への移行を目指す組織向けの3段階のタイムラインが概説されている。
・NCSC issues new guidance to help protect against future quantum computing threats.  ・NCSCは、将来の量子コンピューティングの脅威に対する防御を支援する新たな指針を発表した。
・Advice outlines a three-phase timeline for key sectors and organisations to transition to quantum-resistant encryption methods by 2035.  ・この指針では、2035年までに量子耐性暗号方式への移行を目指す主要部門および組織向けの3段階のタイムラインが概説されている。
・Adoption of post-quantum cryptography (PQC) is encouraged, as current encryption standards – used to protect banking, secure communications and other sensitive data – are vulnerable to power of quantum computers.  ・現在の暗号化標準は、銀行業務や安全な通信、その他の機密データの保護に使用されているが、量子コンピュータの能力に対して脆弱性があるため、耐量子暗号(PQC)の採用が推奨されている。
The UK's cyber security agency has today issued new guidance to help the nation prepare for and protect against threats posed by future developments in quantum computing 英国のサイバーセキュリティ機関は本日、量子コンピュータの将来的な発展による脅威への備えと防御を支援するための新たな指針を発表した。
The guidance, published by the National Cyber Security Centre (NCSC) – part of GCHQ – emphasises the importance of post-quantum cryptography (PQC), which is a new type of encryption designed to safeguard sensitive information from the future risks posed by quantum computers.  GCHQの一部である国家サイバーセキュリティセンター(NCSC)が発表したこのガイドラインでは、量子コンピュータが将来的にもたらすリスクから機密情報を保護するために設計された新しい暗号化方式である耐量子暗号(PQC)の重要性が強調されている。
While today’s encryption methods – used to protect everything from banking to secure communications – rely on mathematical problems that current-generation computers struggle to solve, quantum computers have the potential to solve them much faster, making current encryption methods insecure.  今日の暗号化手法(銀行業務から安全なコミュニケーションまで、あらゆるものを防御するために使用されている)は、現行のコンピューターでは解決が困難な数学的問題に依存しているが、量子コンピューターはそれらをはるかに高速に解決できる可能性があり、現在の暗号化手法は安全ではなくなる。
Migrating to PQC will help organisations stay ahead of this threat by deploying quantum-resistant algorithms before would-be attackers have the chance to exploit vulnerabilities.    PQCへの移行は、攻撃者が脆弱性を悪用する前に量子耐性アルゴリズムを展開することで、組織がこの脅威に先手を打つのに役立つ。  
The new guidance encourages organisations to begin preparing for the transition now to allow for a smoother, more controlled migration that will reduce the risk of rushed implementations and related security gaps. It outlines three phases for migration:  この新しい指針では、組織が移行の準備を今から始めることを推奨しており、よりスムーズで管理された移行を実現することで、性急な実装や関連するセキュリティギャップのリスクを軽減できる。 移行には3つのフェーズがある。
To 2028 – identify cryptographic services needing upgrades and build a migration plan.  2028年まで – 移行が必要な暗号化サービスを識別し、移行計画を策定する。
From 2028 to 2031 – execute high-priority upgrades and refine plans as PQC evolves.  2028年から2031年 – 優先度の高い移行を実施し、PQCの進化に合わせて計画を修正する。
From 2031 to 2035 – complete migration to PQC for all systems, services and products.  2031年から2035年 – すべてのシステム、サービス、製品についてPQCへの移行を完了する。
NCSC Chief Technical Officer Ollie Whitehouse said:   NCSCの最高技術責任者であるオリー・ホワイトハウス氏は次のように述べた。
“Quantum computing is set to revolutionise technology, but it also poses significant risks to current encryption methods.  「量子コンピューティングはテクノロジーに革命をもたらすものだが、同時に現在の暗号化方式に重大なリスクをもたらす。
“Our new guidance on post-quantum cryptography provides a clear roadmap for organisations to safeguard their data against these future threats, helping to ensure that today's confidential information remains secure in years to come.  「私たちの新しい耐量子暗号化に関するガイダンスは、将来の脅威からデータを保護するための明確なロードマップを組織に提供し、今日の機密情報が将来も安全に保たれることを保証するのに役立つ。
“As quantum technology advances, upgrading our collective security is not just important – it’s essential.”  「量子技術が進歩するにつれ、私たちのセキュリティを向上させることは重要であるだけでなく、不可欠である。」 
For many small and medium-sized businesses and organisations, migration to PQC will be routine, as service and technology providers will deliver it as part of their normal upgrades. However, for some larger organisations, PQC will require planning and significant investment.  多くの中小企業や組織にとって、PQCへの移行は日常的なものとなるだろう。なぜなら、サービスプロバイダやテクノロジープロバイダが通常のアップグレードの一環として提供するからだ。しかし、一部の大規模な組織にとっては、PQCには計画と多額の投資が必要となる。
By taking proactive steps now, the UK can ensure its digital infrastructure remains robust and secure in the face of quantum advancements.  英国は今から積極的な対策を講じることで、量子技術の進歩にも耐えうる強固で安全なデジタルインフラを確保することができる。 

 

 

移行スケジュール...

Timelines for migration to post-quantum cryptography

 

Timelines for migration to post-quantum cryptography 耐量子暗号への移行スケジュール
Activities which organisations must carry out to migrate safely to post-quantum cryptography in the coming years. 今後数年間にわたって、組織が耐量子暗号化への安全な移行を行うために実施すべき活動。
in this guidance 本ガイダンスにおける
Executive summary エグゼクティブサマリー
Background 背景
Planning your PQC migration PQC移行の計画
PQC migration across different sectors さまざまな分野におけるPQC移行
Maturity of PQC technology PQC技術の成熟
Timelines for PQC migration PQC移行のスケジュール
Next steps 次のステップ
Executive summary エグゼクティブサマリー
The national migration to post-quantum cryptography (PQC), mitigating the threat from future quantum computers, is a mass technology change that will take a number of years. 将来の量子コンピュータの脅威を緩和する耐量子暗号(PQC)への国家的な移行は、数年にわたる大規模な技術的変化である。
The NCSC recognises the need both to offer guidance on some of the early-stage migration activities, and to set some indicative timelines that UK industry, government and regulators can follow. In this guidance, the NCSC sets out some key target dates for migration activities.  NCSCは、初期段階の移行活動に関する指針を提供する必要性と、英国の産業、政府、規制当局が従うべき指針となるスケジュールを設定する必要性を認識している。本ガイドラインでは、NCSCは移行活動に関するいくつかの重要な目標日を設定している。
Although the core timelines are relevant to all organisations, this guidance is primarily aimed at technical decision-makers and risk owners of large organisations, operators of critical national infrastructure systems including industrial control systems, and companies that have bespoke IT. Different sectors will have different current states of cryptographic maturity, and so the weight of activities might vary across the three periods, but a focus on those headline dates is important for investment decisions and broader cyber security planning. 中核となるスケジュールはすべての組織に関連するものであるが、このガイダンスは主に、大規模な組織の技術的決定者およびリスク管理者、産業用制御システムを含む重要な国家インフラシステムの運用者、および特注のITを導入している企業を対象としている。 暗号化の成熟度は各セクターによって異なるため、3つの期間における活動の比重は異なる可能性があるが、これらの主要な日付に焦点を当てることは、投資の決定やより広範なサイバーセキュリティ計画にとって重要である。
The key milestones are: 主なマイルストーンは以下の通りである。
By 2028 2028年までに
・Define your migration goals ・移行目標を定義する
・Carry out a full discovery exercise (assessing your estate to understand which services and infrastructure that depend on cryptography need to be upgraded to PQC) ・完全な調査を実施する(暗号化に依存するサービスやインフラを把握し、PQCへのアップグレードが必要かどうかをアセスメントする
・Build an initial plan for migration ・移行の初期計画を策定する
By 2031 2031年までに
Carry out your early, highest-priority PQC migration activities 優先度の高いPQC移行活動を早期に実施する
Refine your plan so that you have a thorough roadmap for completing migration 移行完了までの詳細なロードマップを作成するために計画を修正する
By 2035 2035年までに
・Complete migration to PQC of all your systems, services and products ・すべてのシステム、サービス、製品をPQCに移行する
There will be a small set of more rarely used technologies for which migration by 2035 may be more difficult. This may impact some sectors more than others, but all organisations should work towards these key dates
.
2035年までに移行が難しいと思われる、使用頻度の低いテクノロジーのセットも存在する。これは、一部のセクターにより大きな影響を与える可能性があるが、すべての組織はこれらの期限に向けて取り組むべきである。
Note: Most of the work needed to prepare for and deliver a successful migration involves activities that are central to good cyber security practice. Organisations should use migration as an opportunity to build broader cyber resilience into their systems. 注:移行を成功させるために必要な準備作業のほとんどは、優れたサイバーセキュリティ対策の実践に不可欠な活動である。組織は、移行を機に、より広範なサイバーレジリエンスをシステムに組み込むべきである。

 

 

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

NISTの耐量子暗号

・2025.03.14 米国 NIST 第5の耐量子暗号化のアルゴリズムとしてHQCを選択 (2025.03.11)

・2025.03.14 米国 NIST IR 8545 NISTの耐量子暗号標準化プロセスの第4ラウンドに関する現状報告書

・2025.03.11 米国 NIST CSWP 39(初期公開ドラフト) 暗号化の機敏性を実現するための考慮事項:戦略と実践

・2025.01.10 米国 NIST SP 800-227(初期公開ドラフト) キーカプセル化メカニズムに関する推奨事項

・2024.11.16 米国 NIST IR 8547(初期公開ドラフト) 耐量子暗号標準への移行について

・2024.11.03 米国 NIST IR 8528 耐量子暗号標準化プロセスにおける追加デジタル署名スキームの第一ラウンドに関する状況報告書

 

・2024.08.14 米国 NIST 耐量子暗号化標準の最初の3つ (FIPS 203, 204, 205) を確定

 

・2023.12.22 NIST SP 1800-38(初期ドラフト)耐量子暗号への移行: 量子安全暗号の実装と採用を検討するための準備

・2023.08.22 米国 CISA NSA NIST 量子対応:耐量子暗号への移行

・2022.10.02 NISTIR 8413 NIST耐量子暗号標準化プロセス第3ラウンドの現状報告(参考文献の追加)

・2022.07.07 NISTIR 8413 NIST耐量子暗号標準化プロセス第3ラウンドの現状報告

 

英国

・2025.03.21 英国 NSCS 耐量子暗号への移行スケジュールを発表 (2025.03.20)

 

ENISA

・2022.10.21 ENISA ポスト量子暗号 - 統合研究

 

日本...

・2024.10.25 政府認証基盤 (GPKI) 政府認証基盤相互運用性仕様書(移行期間編)と移行完了編)  (2024.10.11)

・2024.09.16 金融庁 「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会」(第1回)議事要旨 (会議は2024.07.18)

・2023.09.29 日本銀行金融研究所 量子コンピュータが暗号に及ぼす影響にどう対処するか:海外における取組み

 

 

| | Comments (0)

2025.03.14

シンガポール オープンソースソフトウェアとサードパーティ依存のSBOMとリアルタイム脆弱性監視に関するアドバイザリー (2025.02.20)

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

シンガポールのサイバーセキュリティ庁が、OWASPと協力してソフトウェア開発者に対し、脆弱性管理に対する持続可能で自動化されたアプローチを実装する方法についてのガイダンスを公表していましたね...

SBOMの必要性は理解はされているが、実装はなかなか難しいというのは、どこでも同じかもです。でも、必要ですよね...

 

⚫︎ Cyber Security Authority: CSA

・2025.02.20 Advisory on Software Bill of Materials and Real-time Vulnerability Monitoring for Open-Source Software and Third-Party Dependencies

 

・[PDF

20250314-42217

 

Advisory on Software Bill of Materials and Real-time Vulnerability Monitoring for Open-Source Software and Third Party Dependencies オープンソースソフトウェアとサードパーティ依存関係のソフトウェア部品表とリアルタイム脆弱性モニ タリングに関する助言
Introduction 序文
1. The integration of Open-Source Software (OSS) in software development introduces significant cybersecurity challenges, particularly regarding vulnerabilities in third-party dependencies. Notable incidents, such as Log4j and Heartbleed, underscore these risks. On Log4j, many organisations struggled to assess system compromises due to a lack of visibility into their software components and dependencies, with delayed responses to discovered vulnerabilities. On Heartbleed, it affected the widely used OpenSSL cryptography library, leading to the theft of 4.5 million medical records from a major overseas hospital chain. 1. ソフトウェア開発におけるオープンソースソフトウェア(OSS)の統合は、特にサードパーティ依存の脆弱性に関して、重大なサイバーセキュリティ上の課題をもたらす。Log4jやHeartbleedのような注目すべきインシデントが、こうしたリスクを浮き彫りにしている。Log4jでは、ソフトウェア・コンポーネントや依存関係の可視化が不十分であったため、多くの組織がシステム侵害のアセスメントに苦慮し、脆弱性の発見に対する対応が遅れた。Heartbleedについては、広く使われているOpenSSL暗号ライブラリに影響を及ぼし、海外の大手病院チェーンから450万件の医療記録が盗まれることになった。
2. These dependency threats are exacerbated by extent of third-party dependencies and critical vulnerabilities found in software development projects. According to studies, there are on average 68.8[1] dependencies per project and 5.1[2] critical vulnerabilities in an application. If developers are unaware of the full composition of their applications, the risks of cybersecurity breaches are significant. In the light of such trends, there is an impetus for developers to easily identify and address OSS dependencies to mitigate cybersecurity risks. 2. このような依存関係の脅威は、サードパーティーの依存性の広さと、ソフトウェア開発プロジェクトで発見された重大な脆弱性によって悪化している。調査によると、1つのプロジェクトあたり平均68.8[1]の依存性と5.1[2]の重大な脆弱性がアプリケーションに存在する。開発者が自分のアプリケーションの完全な構成を知らない場合、サイバーセキュリティ侵害のリスクは大きい。このような傾向を踏まえ、サイバーセキュリティリスクを緩和するために、開発者は OSS の依存関係を容易に識別し、対処することが求められている。
Intended audience of advisory 助言の対象読者
3. The advisory is intended for all software developers, especially those who incorporate OSS and third-party dependencies into their projects. While many developers are aware of cybersecurity risks, they may not have the resources and guidance to enforce cybersecurity during software development and implementation. To aid developers, the advisory offers guidance on a sustainable and automated approach to vulnerability management through Software Bill of Materials (SBOM) and real-time vulnerability monitoring. 3. この勧告は、すべてのソフトウェア開発者、特に OSS やサードパーティとの依存関係をプロジェクトに組み込んでい る開発者を対象としている。多くの開発者はサイバーセキュリティリスクを認識しているが、ソフトウ ェアの開発・実装時にサイバーセキュリティを実施するためのリソースやガイダンスを持っていない可能性がある。開発者を支援するために、この勧告では、ソフトウェア部品表(SBOM)とリアルタイムの脆弱性監視を通じた脆弱性管理の持続可能で自動化されたアプローチに関するガイダンスを提供している。
Value proposition of SBOM and real-time monitoring of vulnerabilities SBOMと脆弱性のリアルタイム・モニタリングの価値提案
4. The traditional way of manually managing OSS dependencies is inefficient and prone to errors. Furthermore, developers must sift through complex codebases to identify and fix vulnerable software components. 4. OSSの依存関係を手作業で管理する従来の方法は、非効率的でエラーが発生しやすい。さらに、開発者は脆弱性のあるソフトウェア・コンポーネントを特定し、修正するために、複雑なコードベースをふるいにかけなくてはならない。
5. Generating Software Bill of Materials (SBOM) ensures developers are not using known vulnerable dependencies and provide them full visibility into software components. SBOM provides a structured and formal record of components used to build software. It equips organisations with a clear view of their software environment, ensuring that vulnerabilities can be managed more effectively. Through the integration of SBOM tools into software development workflows, developers can automatically track each component from the start, reducing manual effort and human error. It enables them to significantly reduce technical debt by identifying outdated or vulnerable components much earlier, in turn decreasing future remediation workloads. 5. ソフトウェア部品表(SBOM)を生成することで、開発者が既知の脆弱な依存関係を使用していないことを保証し、ソフトウェア部品に対する完全な可視性を提供する。SBOMは、ソフトウェア構築に使用されるコンポーネントの構造化された正式な記録を提供する。これにより、組織はソフトウェア環境を明確に把握できるようになり、脆弱性をより効果的に管理できるようになる。SBOMツールをソフトウェア開発ワークフローに統合することで、開発者は各コンポーネントを最初から自動的に追跡できるようになり、手作業や人的ミスを減らすことができる。これにより、開発者は、古くなったコンポーネントや脆弱性のあるコンポーネントをより早い段階で特定し、技術的負債を大幅に削減することができる。
6. SBOM also improves response times by allowing developers to quickly identify and fix vulnerable components and collaborate across the organisation for holistic vulnerability management. This streamlined process not only minimises complexity but also fosters collaboration among developers and cybersecurity professionals, allowing cybersecurity risks to be addressed proactively without stifling innovation. If SBOM is integrated into CI/CD pipelines, it allows real-time monitoring of new vulnerabilities through automation of SBOM generation, signing and alerts. The SBOM can also be used to foster collaboration across teams, including SecOps, Incident Response (IR) and development teams for holistic vulnerability management and improved response times. 6. SBOMはまた、開発者が脆弱性コンポーネントを迅速に特定して修正し、組織全体で協力して全体的な脆弱性管理を行えるようにすることで、対応時間を改善する。この合理化されたプロセスは、複雑さを最小限に抑えるだけでなく、開発者とサイバーセキュリティ専門家のコラボレーションを促進し、イノベーションを阻害することなく、サイバーセキュリティリスクにプロアクティブに対処することを可能にする。SBOMをCI/CDパイプラインに統合すれば、SBOMの生成、署名、アラートの自動化を通じて、新しい脆弱性をリアルタイムで監視できる。SBOMはまた、SecOps、インシデントレスポンス(IR)、開発チームを含むチーム間のコラボレーションを促進し、全体的な脆弱性管理とレスポンスタイムの改善に利用できる。
Three step approach to managing vulnerabilities through SBOMs SBOMによる脆弱性管理の3ステップアプローチ
20250314-50930
Figure 1. Three step approach to managing vulnerabilities through SBOMs 図1. SBOMによる脆弱性管理の3ステップアプローチ
7. The three-step approach is as follows[3] : 7. 3段階のアプローチは以下のとおりである[3]:
• Select tool: The chosen tool should accurately identify and list components as well as direct[4] and indirect[5] dependencies of the software. The tool should also integrate seamlessly with continuous integration/continuous deployment (CI/CD)[6] pipelines such as GitHub Actions, GitLab CI/CD or equivalent software. - ツールを選択する: 選択したツールは、ソフトウェアの直接[4]および間接的[5]な依存関係だけでなく、コンポーネントを正確に識別してリスト化する必要がある。また、ツールは、GitHub Actions、GitLab CI/CD、または同等のソフトウェアなどの継続的インテグレーション/継続的展開(CI/CD)[6]パイプラインとシームレスに統合する必要がある。
• Generate and sign the SBOM: The tool should be used to generate an SBOM that complies with industry standards such as CycloneDX or SPDX[7] . Signing the SBOM after its generation ensures authenticity and provides assurance that it originates from a trusted source. Developers should leverage on available tools[8] to publish signed records into transparency logs, enhancing trust and verifiability through immutable records of signing events. - SBOM の生成と署名:ツールは、CycloneDX や SPDX[7]などの業界標準に準拠した SBOM を生成するために使用されるべきである。生成後に SBOM に署名することで、認証が保証され、信頼できるソースから生成されたことが保証される。開発者は利用可能なツール[8]を活用して、署名されたレコードを透明性ログに公開し、署名イベントの不変の記録を通じて信頼性と検証可能性を高めるべきである。
• Proactive vulnerability management: The generated SBOM should be published to a secure repository and automatically ingested by tools like OWASP Dependency-Track[9] for continuous vulnerability monitoring and Nday vulnerability identification. - プロアクティブな脆弱性管理: 生成された SBOM を安全なリポジトリに公開し、OWASP Dependency-Track[9]のようなツールに自動的に取り込ませて、脆弱性の継続的なモニタリングと Nday 脆弱性の特定を行う。
8. As the software development environment varies for each system, developers should also take note of the following practical considerations: 8. ソフトウェア開発環境はシステムごとに異なるため、開発者は以下の実用的な考慮事項にも留意すべきである:
• The SBOM is only as comprehensive as the manifest files generated. If the codebase includes obscure or less common programming languages, some dependencies may not be detected; - SBOM は、生成的なマニフェストファイルと同程度に包括的である。コードベースに不明瞭なプログラミング言語や一般的でないプログラミング言語が含まれている場合、一部の依存関係が検知されない可能性がある。
• For SaaS and closed-source software, developers should request the SBOMs from their third-party providers as these SBOMs provide the most comprehensive coverage of the software components and dependencies. If developers are unable to obtain SBOMs from their third-party providers, the selected SBOM generation tool need to be able to perform supplementary checks in the respective environments. In particular, SaaS software could use runtime SBOMs[10] , capturing dynamically loaded or run-time injected components during execution. For closed-source software, binary-based SBOM tools[11] could be used to create an inventory of the software components used. Such tools inspect the compiled binary code, which is the final product of the software. Once developers discover vulnerabilities through the SBOMs, they need to inform their third-party providers to remediate them; - SaaS およびクローズドソースソフトウェアの場合、開発者はサードパーティプロバイダに SBOM を要求すべきである。これらの SBOM はソフトウェアコンポーネントと依存関係を最も包括的にカバーしているからである。開発者がサードパーティプロバイダからSBOMを入手できない場合、選択したSBOM生成ツールは、それぞれの環境で補足的なチェックを実行できる必要がある。特にSaaSソフトウェアでは、実行時に動的にロードされるコンポーネントや実行時に注入されるコンポーネントをキャプチャする、ランタイムSBOM[10]を使用することができる。クローズドソースソフトウェアの場合、バイナリベースのSBOMツール[11]を使用して、使用されているソフトウェアコンポーネントのインベントリを作成することができる。このようなツールは、ソフトウェアの最終成果物であるコンパイル済みバイナリコードを検査する。開発者は、SBOMを通じて脆弱性を発見したら、その脆弱性を修正するようにサードパーティ・プロバイダに通知する必要がある。
• Developers need to verify identified vulnerabilities for exploitability as the vulnerabilities may not be relevant in their software development environments. Without appropriate verification, there could be a high volume of vulnerabilities surfaced through the SBOM and developers risk being overwhelmed with false positives and time spent on subsequent remediation. Developers should start the verification process by using industry filters such as CISA’s Known Exploited Vulnerabilities (KEV)[12] that only alerts on CVEs that are actively exploited. Once the vulnerabilities are filtered, vulnerabilities can be assessed for the likelihood of being exploited through the Exploit Prediction Scoring System (EPSS)[13] . After identifying vulnerabilities that are likely to be exploited, they can be prioritised for remediation using Common Vulnerability Scoring Systems (CVSS), which rates the severity of vulnerabilities. - 開発者は、特定された脆弱性の悪用可能性を検証する必要がある。脆弱性は、開発者のソフトウェア開発環境では関連性がない可能性があるからである。適切な検証を行わなければ、SBOMを通じて大量の脆弱性が表面化する可能性があり、開発者は誤検知に圧倒され、その後の修正に時間を費やすリスクがある。開発者は、CISAのKnown Exploited Vulnerabilities(KEV)[12]のような、活発に悪用されているCVEのみに警告を発する業界フィルタを使用して検証プロセスを開始すべきである。脆弱性のフィルタリングが完了したら、エクスプロイト予測スコアリングシステム(Exploit Prediction Scoring System:EPSS)[13]を用いて脆弱性が悪用される可能性を評価することができる。悪用される可能性の高い脆弱性を特定した後は、脆弱性の深刻度を評価する共通脆弱性スコアリングシステム(CVSS)を用いて、脆弱性を改善するための優先順位をつけることができる。
Automating capabilities in code repositories platforms to manage OSS vulnerabilities OSSの脆弱性を管理するために、コードリポジトリプラットフォームの機能を自動化する
9. Both commercial and Open-Source Software projects commonly rely on opensource dependencies, typically hosted on code repository platforms such as GitHub and GitLab. As central hubs for OSS development, GitHub and GitLab are used by developers who collaborate on projects of varying scope and complexity. Given the widespread use of such code repository platforms, managing vulnerabilities are even more critical for maintaining a secure software ecosystem. Such environments provide automated workflow functionalities on managing vulnerabilities, with automation enabling a seamless integration of security practices into the development process. 9. 商業プロジェクトもオープンソースソフトウェアプロジェクトも、一般的にオープンソースの依存関係に依存しており、GitHub や GitLab のようなコードリポジトリプラットフォームにホストされている。OSS開発の中心的なハブとして、GitHubとGitLabは、様々な範囲と複雑さのプロジェクトで共同作業する開発者によって使用されている。このようなコード・リポジトリ・プラットフォームが広く使用されていることを考えると、脆弱性の管理は、安全なソフトウェア・エコシステムを維持するためにさらに重要になっている。このような環境は、脆弱性の管理に関する自動化されたワークフロー機能を提供し、自動化によって、開発プロセスにセキュリティ対策をシームレスに統合することを可能にする。
10. Developers should use tools such as GitHub Actions and GitLab CI/CD that allow for the automated creation and vulnerability checking of SBOMs. While SBOM signing is not a native feature, external tools[14] can be integrated into the workflow. Refer to Annex A for the full script that automates these actions for GitHub Actions and a similar workflow can be implemented for GitLab CI/CD (Annex B). 10. 開発者は、GitHub Actions や GitLab CI/CD のような、SBOM の自動作成と脆弱性チェックを可能にするツールを使用すべきである。SBOM署名はネイティブな機能ではないが、外部ツール[14]をワークフローに統合することができる。GitHub Actionsのこれらのアクションを自動化するスクリプトの完全版については附属書Aを参照のこと。GitLab CI/CDについても同様のワークフローを実装することができる(附属書B)。
11. Developers should either remove vulnerable components if the functionalities provided through these components are not crucial or update these components to non-vulnerable versions. Developers should thoroughly test their applications to verify the application works as intended and update the SBOM documentation to record which components were removed and updated. This approach enhances the cybersecurity of the software and protects users from known exploits. 11. 開発者は、脆弱性のあるコンポーネントを通じて提供される機能が重要でない場合は、脆弱性のあるコンポーネントを削除するか、脆弱性のないバージョンに更新する。開発者は、アプリケーションが意図したとおりに動作することを検証するためにアプリケーションを徹底的にテストし、どのコンポーネントが削除され更新されたかを記録するために SBOM ドキュメントを更新するべきである。このアプローチは、ソフトウェアのサイバーセキュリティを強化し、既知の悪用からユーザを保護する。
12. Developers should publish SBOM, its signature and certificate alongside the digital files. This allows downstream users in the software development ecosystem to easily access and verify the SBOM, ensuring that they are working with a secure and authentic version of the software. Users can also leverage the SBOM to continuously monitor for new vulnerabilities. 12. 開発者は、SBOM、その署名、および証明書をデジタルファイルと一緒に公開する。これにより、ソフトウェア開発エコシステムの下流のユーザーは、SBOM に簡単にアクセスして検証することができ、安全で認証されたバージョンのソフトウェアを使用していることを確認できる。ユーザーはまた、SBOM を活用して、新しい脆弱性を継続的に監視することもできる。
Real-time monitoring of vulnerabilities through OWASP Dependency Track OWASP Dependency Track による脆弱性のリアルタイム監視
13. OWASP Dependency Track (DT) provides real-time vulnerability monitoring capabilities through SBOM ingestion and continual checking against current threat intelligence. OWASP Dependency Track (DT) goes beyond basic scanning by incorporating the Exploit Prediction Scoring System (EPSS), allowing developers to prioritise vulnerabilities based on their likelihood of exploitation. Refer to Annex C for more details on the deployment of OWASP DT. 13. OWASP Dependency Track(DT)は、SBOM の取り込みと、最新の脅威インテリジェンスとの継続的なチェッ クを通じて、リアルタイムの脆弱性監視機能を提供する。OWASP Dependency Track(DT)は、Exploit Prediction Scoring System(EPSS)を組み込むことで、基本的なスキャンを超え、開発者が悪用の可能性に基づいて脆弱性に優先順位をつけることを可能にする。OWASP DT の展開の詳細については、附属書 C を参照されたい。
14. Developers should integrate the OWASP DT tool into CI/CD pipelines for realtime monitoring, consistent automation of SBOM generation and signing, and alerts for new vulnerabilities. Developers should securely store signed SBOM into centralised repositories to support collaboration across teams, including SecOps, Incident Response (IR) and development teams. In addition, developers need to establish governance policies for SBOM storage, access control and lifecycle management in collaboration with their Chief Information Security Officers (CISOs). 14. 開発者は、リアルタイムの監視、SBOM 生成と署名の一貫した自動化、および新たな脆弱性に対する警告のために、OWASP DT ツールを CI/CD パイプラインに統合すること。開発者は、SecOps、インシデントレスポンス(IR)、開発チームを含むチーム間のコラボレーションをサポートするために、署名された SBOM を一元化されたリポジトリに安全に保管すべきである。さらに、開発者は、最高情報セキュリティ責任者(CISO)と協力して、SBOMの保管、アクセス管理、ライフサイクル管理に関するガバナンスポリシーを確立する必要がある。
Conclusion 結論
15. SBOMs and real-time monitoring of vulnerabilities provide developers a sustainable and automated approach to address risks posed by Open-Source Software (OSS) and third-party software components, in turn enhancing the cybersecurity posture of the software supply chain. Such an approach allows developers and system owners to have visibility on software components and dependencies and improve response times to address vulnerabilities. 15. SBOMと脆弱性のリアルタイムモニタリングは、オープンソースソフトウェア(OSS)とサードパーティ製ソフトウェアコンポーネントがもたらすリスクに対処するための持続可能で自動化されたアプローチを開発者に提供し、ひいてはソフトウェアサプライチェーンのサイバーセキュリティ態勢を強化する。このようなアプローチにより、開発者とシステムオーナーは、ソフトウェアコンポーネントと依存関係を可視化し、脆弱性に対処するためのレスポンスタイムを改善することができる。
Acknowledgement 謝辞
16. This advisory was jointly developed by the Cyber Security Agency of Singapore and OWASP Foundation. 16. この勧告は、シンガポールのサイバーセキュリティ庁と OWASP 財団が共同で作成した。
Disclaimer 免責事項
17. The information and advice contained in this document is provided "as is" without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by the Cyber Security Agency of Singapore, OWASP Foundation or GitHub. This document shall not be used for advertising or product endorsement purposes. 17. 本文書に含まれる情報および助言は、いかなる保証もなく「現状のまま」プロバイダとして提供される。商号、商標、製造事業者、その他による特定の商用製品、プロセス、サービスへの言及は、Cyber Security Agency of Singapore、OWASP Foundation、GitHub による推奨、推薦、支持を意味するものではない。本文書は、広告や製品の推奨を目的として使用してはならない。
List of References 参考文献一覧
S/N Document Source Year of Publication S/N 文書出典 発行年
1 The Minimum Elements for a Software Bill of Materials (SBOM) NTIA 2021 1 The Minimum Elements for a Software Bill of Materials (SBOM) NTIA 2021
2 Addressing Cybersecurity Challenges in OpenSource Software OpenSSF 2022 2 Addressing Cybersecurity Challenges in OpenSource Software OpenSSF 2022
3 Guidance on Introduction of Software Bill of Materials (SBOM) for Software Management METI 2023 3 Guidance on Introduction of Software Bill of Materials (SBOM) for Software Management METI 2023
4 Recommendations for Software Bill of Materials (SBOM) Management NSA 2024 4 Recommendations for Software Bill of Materials (SBOM) Management NSA 2024
5 Documentation on OWASP Dependency-Track OWASP 2024, v4.11 5 Documentation on OWASP Dependency-Track OWASP 2024, v4. 
6 CycloneDX Authoritative Guide to SBOM OWASP 2024, 2nd edition 6 CycloneDX Authoritative Guide to SBOM OWASP 2024, 2nd edition
Annex A – Sample workflow. yaml script for GitHub Actions 附属書 A - サンプルワークフロー。GitHub Actions 用 yaml スクリプト
Annex B – Sample workflow. yaml script for GitLab CI/CD 附属書 B - サンプルワークフロー。GitLab CI/CD 用 yaml スクリプト
Annex C – Deploying and using Dependency-Track 附属書 C - Dependency-Track の展開と使用。

 

[1] PDF  
[2] [web]  
[3] The approach is adapted from existing best practices found in sources 1,3 to 6 of bibliography.  [3] このアプローチは、参考文献のソース1,3から6にある既存のベストプラクティスから採用されている。
[4] Direct refers to software components that are explicitly required by the code.  [4] 直接とは、コードによって明示的に必要とされるソフトウェアコンポーネントを指す。
[5] Indirect refers to software components required by the direct dependencies.  [5] 間接的とは、直接的な依存関係によって必要とされるソフトウェア・コンポーネントを指す。
[6] GitHub Actions and GitLab CI/CD are CI/CD tools to automate workflows like building, testing, and deploying code.  [6] GitHub ActionsとGitLab CI/CDは、コードのビルド、テスト、展開のようなワークフローを自動化するためのCI/CDツールである。
[7] These are industry standards for SBOM creation, distribution, and consumption, enabling interoperability and integration into existing workflows.  [7] これらはSBOMの作成、配布、消費のための業界標準であり、相互運用性と既存のワークフローへの統合を可能にしている。
[8] An example of such a tool is Sigstore, which provides signing, verification, and provenance checks to secure Open-Source Software distribution.  [8] このようなツールの例として、オープンソースソフトウェアの安全な配布のために、署名、検証、出所チェックを提供するSigstoreがある。
[9] OWASP Dependency-Track tracks and identify software vulnerabilities through SBOM analysis.  [9] OWASP Dependency-Trackは、SBOM分析を通じてソフトウェアの脆弱性を追跡し、特定する。
[10] Runtime SBOMs requires the system to be analysed when running. Some detailed information may be available only after the system has been run for a period of time until the complete functionality has been exercised. Example of runtime SBOM tools are Anchor Syft and Slim.AI.  [10] ランタイムSBOMは、実行時にシステムを分析することを要求する。一部の詳細情報は、完全な機能が発揮されるまで、システムが一定期間実行された後にのみ利用可能となる場合がある。実行時SBOMツールの例としては、Anchor SyftとSlim.AIがある。
[11] Example of binary-based SBOM tools are Black Duck Binary Analysis and Tern.  [11] バイナリベースの SBOM ツールの例としては、Black Duck Binary Analysis と Tern がある。
[12] CISA’s Known Exploited Vulnerabilities (KEV) is a catalogue of actively exploited vulnerabilities to help prioritise security remediation.  [12] CISAの既知の脆弱性(KEV:Known Exploited Vulnerabilities)は、積極的に悪用されている脆弱性のカタログであり、セキュリティ改善の優先順位付けに役立つ。
[13] Exploit Prediction Scoring System (EPSS) is a predictive model that scores the probability of a software vulnerability being exploited, aiding in prioritising security responses.  [13] Exploit Prediction Scoring System(EPSS)は、ソフトウェアの脆弱性が悪用される確率をスコア化する予測モデルであり、セキュリティ対応の優先順位付けに役立つ。
[14] An example is Cosign, which is a tool to sign, verify and attest software artifacts securely.  [14] Cosign は、ソフトウェア成果物に安全に署名、検証、証明するツールである。

 

 

| | Comments (0)

2025.03.13

FIRST 戦略計画2025-2028と戦略を作るためのフレームワークを公表... (2025.03.03)

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

サイバーセキュリティに関わっている方であれば、FIRSTという団体の名前を聞いたことがあると思います。2023年の第36回のAnnual Conferenceは福岡で開催されましたね。。。

 Red, Amber, GreenのTrafic Light Protocol: TLP (Ver2.0日本語版) を定めている団体というと親近感がわくかもです...

FIRSTは、Forum of Incident Response and Security Teams [wikipdeia] の略で、サイバーインシデント対応のためにお互いが協力し合えるような信頼できるメンバーによる団体という感じでしょうかね...

1990年に米国で始まった団体ですが、今では111カ国、165のリエゾン、762のチームが参加する団体です...1995年に法人化した時の本社はカリフォルニア州でしたが、2014年にノースカロライナ州に移転しています。

日本では山口英先生のおかげてJPCERT/CCが早期に加盟しています。それを足がかりに日本の主要な企業の多くもFIRSTに参加し、インシデントレスポンスの対応に協力していますね...そして、FIRSTには、Suguru Yamaguchi Fellowship Programがあります。FIRSTに入りたいけど十分な経験がないという国のメンバーを支えるための4年間のプログラムです。すでに終了したのは、15CERT、現在のフェローシップは、南アフリカ、セルビア、ペナン、フィリピン、モザンビーク、トリニダード・トバゴ、モーリタニア、ナミビア等16のCERTです。

JPCERT/CCの理事もしていた山口先生がFIRSTの設立時からの関与があったので、山口先生がFIRSTの理事もしていましたが、その後もJPCERT/CCから小宮山さん、そして現在では内田さんがFIRSTの理事として就任しています。

今回FIRSTの戦略が公開されたわけですが、その前にFIRSTのVisionとMissionsのおさらいからです...

1995年に初版ができて、2020年に改訂されたものです。

・2020.07 FIRST Vision and Mission Statement

Vision ビジョン
FIRST aspires to bring together incident response and security teams from every country across the world to ensure a safe internet for all. FIRSTは、すべての人にとって安全なインターネットを確保するために、世界各国のインシデント対応チームとセキュリティ・チームを結集することを目指している。
Effective response is a global task, mirroring the global nature of the internet. Based on a peer to peer network governance model, Computer Security Incident Response Teams (CSIRTs), Product Security Incident Response Teams (PSIRTs) and independent security researchers work together to limit the damage of security incidents. This requires a high level of trust; the fuel our members run on. FIRST fosters trust building among members through a variety of activities. Incidents are not confined to one cultural or political corner of the internet, nor do they respect borders or boundaries. FIRST thus promotes inclusiveness, inviting membership from all geographic and cultural regions. 効果的な対応は、インターネットのグローバルな性質を反映したグローバルなタスクである。ピア・ツー・ピアのネットワーク・ガバナンス・モデルに基づき、コンピュータ・セキュリティ・インシデント対応チーム(CSIRT)、製品セキュリティ・インシデント対応チーム(PSIRT)、独立系セキュリティ研究者が協力して、セキュリティ・インシデントの被害を抑える。そのためには、FIRSTのメンバーが燃料としている高いレベルの信頼が必要である。FIRSTは、さまざまな活動を通じて、メンバー間の信頼構築を促進する。インシデントは、インターネットの文化的、政治的な一角に限定されるものではなく、国境や境界を尊重するものでもない。そのためFIRSTは、あらゆる地理的・文化的地域から会員を募り、包括性を推進している。
Missions 任務(ミッション)
Global Coordination - You can always find the team and information you need. グローバル・コーディネーション - 必要なチームや情報をいつでも見つけることができる。
FIRST provides platforms, means and tools for incident responders to always find the right partner and to collaborate efficiently. This implies that FIRST’s reach is global. We aspire to have members from every country and culture. FIRSTは、インシデント対応者が常に適切なパートナーを見つけ、効率的に協力できるプラットフォーム、手段、ツールを提供する。このことは、FIRSTの活動範囲がグローバルであることを意味する。FIRSTは、あらゆる国や文化圏からメンバーが集まることを目指している。
Global Language - Incident responders around the world speak the same language and understand each other’s intents and methods. グローバル言語 - 世界中のインシデント対応者は同じ言語を話し、お互いの意図と方法を理解する。
During an incident it is important that people have a common understanding and enough maturity to react in a fast and efficient manner. FIRST supports teams through training opportunities to grow and mature. FIRST also supports initiatives to develop common means of data transfer to enable machine to machine communication. インシデント発生時には、人々が共通の理解を持ち、迅速かつ効率的に対応できるだけの成熟度を備えていることが重要である。FIRSTは、成長し成熟するためのトレーニングの機会を通じてチームをサポートする。FIRSTはまた、マシン・ツー・マシンのコミュニケーションを可能にする共通のデータ転送手段を開発する取り組みも支援している。
Policy and Governance - Make sure others understand what we do, and enable us rather than limit us. 方針とガバナンス - FIRSTの活動を理解し、制限するのではなく、可能にする。
FIRST members do not work in isolation, but are part of a larger system. FIRST engages with relevant stakeholders, in technical and non-technical communities, to ensure teams can work in an environment that is conducive to their goals. FIRSTのメンバーは孤立して活動するのではなく、より大きなシステムの一部である。FIRSTは、技術的および非技術的なコミュニティの関係者と連携し、チームが目標に適した環境で活動できるようにする。

 

さて、このVisionとMissionsを具体的な行動に移すためのFIRSTの戦略計画2025-2028ですが、こちらとなっています...

 

⚫︎ Forum of Incident Response and Security Teams: FIRST

・2025.03.03 FIRST Strategic Plan 2025-2028

 

この戦略は5つの戦略目標(objectives)10の戦略領域(area)、それぞれの戦略目標に紐づく3から7の戦略的目標(goals)期待される成果(outcome)リスクが設定されています。

人数も増えたので、組織だった活動ができるようにということでしょうね...

 

まずは、2025-2028の3年間にかかる、5つの戦略目標(objectives)

1. Global Recognition and Trust: This objective aims to solidify FIRST's position as the leading advocate for the incident response and security community worldwide by enhancing global visibility and building partnerships with key industry stakeholders and organizations and, most importantly, delivering value beyond its constituencies. This aligns with FIRST's vision to be globally recognized and trusted. 1. 世界的な認知と信頼:この目標は、世界的な認知度を高め、業界の主要なステークホルダーや組織とのパートナーシップを構築し、最も重要なこととして、その構成員を超えた価値を提供することにより、世界のインシデントレスポンスとセキュリティコミュニティの主要な支持者としてのFIRSTの地位を確固たるものにすることを目指す。これは、世界的に認知され、信頼されるというFIRSTのビジョンに沿ったものである。
2. Member Value Creation: This objective focuses on providing exceptional value to FIRST members, empowering them to excel in their incident response and cybersecurity endeavors by expanding and enhancing member services and benefits as well as strengthening member engagement and support. This aligns with FIRST's mission to support and empower the incident response community. 2. 会員価値の創造: この目標は、FIRST会員に卓越した価値を提供することに重点を置き、会員サービスと特典を拡大・強化するとともに、会員の参加とサポートを強化することによって、会員がインシデント対応とサイバーセキュリティの取り組みにおいて優れた力を発揮できるようにする。これは、インシデント対応コミュニティを支援し、力を与えるという FIRST の使命に沿うものである。
3. Development and Education: This objective aims to establish FIRST as the premier platform for industry newcomers and experienced professionals seeking to enhance their skills and knowledge in incident response and cybersecurity. This can be achieved by, for example, creating comprehensive training programs for new members, developing advanced modules and certification programs, and promoting continuous learning and professional development. 3. 開発と教育: この目的は、FIRST を、インシデントレスポンスとサイバーセキュリティのスキルと知識を高めようとする業界の新人や経験豊富な専門家のための最高のプラットフォームとして確立することである。これは、例えば、新メンバーのための包括的なトレーニング・プログラムの作成、高度なモジュールや認定プログラムの開発、継続的な学習と専門能力開発の促進によって達成することができる。
4. Trusted Venue for Standards and Information Sharing: This objective aims to position FIRST as the most trusted venue where its members define standards and best practices, as well as share insights and timely information on cybersecurity threats and trends. FIRST plans to achieve this by, for example, seeking enhanced information sharing from its members in its MISP instance, or increased member participation in discussions around standards development. 4. 標準と情報共有のための信頼される場: この目標は、FIRST を、会員が標準とベストプラクティスを定義し、サイバーセキュリティの 脅威と動向に関する洞察とタイムリーな情報を共有する、最も信頼される場として位置付けること を目指す。FIRST は、例えば、MISP のインスタンスにおいて会員からの情報共有の強化を求めたり、標準 策定に関する議論への会員の参加を増やしたりすることで、これを達成する計画である。
5. Effective Governance and Financial Resilience: This objective focuses on the long term strategy towards strengthening FIRST's governance structure, ensuring financial sustainability, and fostering organizational resilience to navigate evolving challenges effectively. This involves reviewing and updating governance policies, enhancing board and member engagement, diversifying funding sources, and maintaining rigorous financial management practices. 5. 効果的なガバナンスと財務レジリエンス: この目標は、FIRSTのガバナンス構造を強化し、財務の持続可能性を確保し、変化する課題に効果的に対処するための組織のレジリエンスを育成するための長期戦略に焦点を当てる。これには、ガバナンス方針の見直しと更新、理事会と会員の関与の強化、資金源の多様化、厳格な財務管理の維持が含まれる。

 

そして、10の戦略領域 (area)

1 - Chairship of the Board of Directors. 1 - 理事会の議長職
2 - Finance. 2 - 財務
3 - Membership. 3 - 会員(メンバーシップ)
4 - Events. 4 - イベント
5 - Education & Training. 5 - 教育・研修
6 - Community Engagement. 6 - 地域社会との関わり
7 - Governance. 7 - ガバナンス
8 - Policy. 8 - 政策
 9 - Community Capacity Building (CCB). 9 - コミュニティ能力開発(CCB)
10 - Communications and Brand Management. 10 - コミュニケーションとブランド管理

 

それぞれの戦略目標、期待される成果、リスクについてはウェブページを...

 

・[PDF

20250313-52835

 

 

FIRSTはこの政策の中でも言われているように、中立的な(neutral)オピニオンリーダーという地位を獲得しようとしています。しかし、地政学的な課題の中で、米国に本社を置くFIRSTというグローバル団体は影響を受けますよね...

日本においても、いわゆるサイバー対処能力強化法案が国会に提出され議論が始まります。そこで、基幹インフラ事業者と政府間での協議会(第45条)が設置され、脅威情報、脆弱性情報、インシデント情報が分析・共有される予定になっていますね...

もちろん、米国、英国等でも同様のことは長年やってきているので、新しい話ではないのですが、いろいろと工夫が必要となってくるところだろうと思います。

 

で、もう一つのテーマである、この戦略をつくるためのフレームワーク。。。

・2025.03.03 FIRST Strategy Framework

立案、更新...

FIRSTにおける戦略的計画    
  期間 更新頻度
戦略的計画 3年 3年
3カ年運営・財務計画 3年 1年
予算・運営計画 1年 1年
達成・進捗報告書 1年 1年

 

 

 


 

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

・2024.11.12 FIRST デジタル初動対応者:発展途上国におけるコンピュータセキュリティ・インシデント対応チーム(CSIRT)の役割に関する実務者ノート (2024.06)

・2024.08.10 FIRST Conference 2024 @福岡 YouTube

・2022.09.16 FIRST The Traffic Light Protocol (TLP)  Version 2.0 の日本語版を公表

・2022.03.29 FIRST ロシアとベラルーシを拠点とする会員組織を一時的に停止 (2022.03.25)

 

 

| | Comments (0)

2025.02.25

特定秘密の保護に関する法律と重要経済安保情報の保護及び活用に関する法律の比較...

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

単なる興味本位ですが、重要経済安保情報の保護及び活用に関する法律と特定秘密の保護に関する法律の比較をしてみました。

民間企業は特定秘密情報を原則取り扱うことはないので、あまり意味はないです...(^^;;

 

e-Gov

・重要経済安保情報の保護及び活用に関する法律 特定秘密の保護に関する法律
・重要経済安保情報の保護及び活用に関する法律施行令 特定秘密の保護に関する法律施行令

 

・特定秘密の保護に関する法律を基に重要経済安保情報の保護及び活用に関する法律を比較したもの...

・[DOCX][PDF] 比較

 

1_20250225052901

本当は赤色にしないとなんですが...

 

対比表的...

↓↓↓↓↓↓↓↓↓↓↓

Continue reading "特定秘密の保護に関する法律と重要経済安保情報の保護及び活用に関する法律の比較..."

| | Comments (0)

2025.01.29

米国 CISA FBI 注意喚起:Ivantiクラウドサービス・アプリケーションにおける脅威アクター連鎖型脆弱性 (2025.01.22)

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

CISAとFBIがIvantiクラウドサービス・アプリケーションにおける脅威アクター連鎖型脆弱性について、バージョンアップを薦める警告を出していましたね。。。

中国のアクターが関与している可能性もあり、実害が生じていることから少し警戒モードが上がっている感じですかね...

 

CISA - ITL

・2025.01.22 Threat Actors Chained Vulnerabilities in Ivanti Cloud Service Applications

Alert Code AA25-022A

管理バイパスに関する脆弱性 (CVE-2024-8963)、SQLインジェクションに関する脆弱性 (CVE-2024-9379)、リモートコード実行に関する脆弱性 (CVE-2024-8190, CVE-2024-9380) を組み合わせて、システムに侵入し、認証情報を取得し、ネットワーク内のシステムにWEBシェルを埋め込んでいたようです。

脅威アクターの主な侵入経路は、

のようです...

 

1_20250129040801

 

 

| | Comments (0)

2025.01.21

中国 CNCERT 米国が企業秘密を盗むために中国の大手テクノロジー企業や機関にサイバー攻撃を行った事案についての報告書 (2025.01.17)

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

中国のCNCERTが、米国が企業秘密を盗むために中国の大手テクノロジー企業や機関にサイバー攻撃を行った事案を2件公表していますね...

一つは、2024年8月から先端材料設計研究部門が、おそらく米国諜報機関に電子文書セキュリティ管理システムの脆弱性を利用して、ソフトウェア更新管理サーバーに侵入し、更新サービスを通じて270台以上にトロイの木馬を配信し、機密情報、知財を盗んだということのようです。

もう一つは、2023年5月から、スマートウェンルギーとデジタル情報の大手ハイテク企業が、おそらく米国諜報機関により、海外の複数の踏み台を利用してマイクロソフト・エクスチェンジの脆弱性を利用し、メールサーバに侵入し、バックドアを埋め込んで電子メールデータを搾取していたようです。その上、メールサーバを踏み台にして、30台以上の端末から機密情報を盗んだようです。

本当かどうかはわかりませんが、被害をうけたことと同じような攻撃をしていますよね。。。そして、マイクロソフト製品の脆弱性を利用して攻撃。。。

 

国家计算机网络应急技术处理协调中心 (CNCERT/CC)

1_20250121053601

・2024.12.18 CNCERT发现处置两起美对我大型科技企业机构网络攻击事件

CNCERT发现处置两起美对我大型科技企业机构网络攻击事件 CNCERTは、米国による中国大手テクノロジー企業の機関ネットワークに対するサイバー攻撃2件を発見し、対処した
国家互联网应急中心发现处置两起美对我大型科技企业机构进行网络攻击窃取商业秘密事件。 国家インターネット緊急対応センターは、米国の大手テクノロジー企業2社が、当社機関の企業秘密を盗むために攻撃を行っていることを発見し、対応した。
2024年8月起,我国某先进材料设计研究单位遭疑似美国情报机构网络攻击。经分析,攻击者利用我境内某电子文档安全管理系统漏洞,入侵该公司部署的软件升级管理服务器,通过软件升级服务向该公司的270余台主机投递控制木马,窃取该公司大量商业秘密信息和知识产权。 2024年8月より、中国の高度材料設計研究部門が、米国の諜報機関と疑われる組織による攻撃を受けた。分析の結果、攻撃者は中国の電子文書セキュリティ管理システムの脆弱性を悪用し、当社が配備したソフトウェアアップグレード管理サーバーに侵入した。攻撃者はソフトウェアアップグレードサービスを利用して、当社の270以上のホストに制御用トロイの木馬を送り込み、当社の大量の企業秘密情報および知的財産を盗んだ。
2023年5月起,我国某智慧能源和数字信息大型高科技企业遭疑似美国情报机构网络攻击。经分析,攻击者使用多个境外跳板,利用微软Exchange漏洞,入侵控制该公司邮件服务器并植入后门程序,持续窃取邮件数据。同时,攻击者又以该邮件服务器为跳板,攻击控制该公司及其下属企业30余台设备,窃取该公司大量商业秘密信息。 2023年5月より、スマートエネルギーとデジタル情報に特化した中国のある大手ハイテク企業が、米国情報機関によるものと見られるサイバー攻撃の標的となった。分析の結果、攻撃者は複数の海外中継サーバーを使用してMicrosoft Exchangeの脆弱性を悪用し、同社のメールサーバーに侵入し、バックドアプログラムを仕掛けて電子メールデータを継続的に盗み出していたことが判明した。同時に、攻撃者はメールサーバーを足がかりとして、同社および子会社の30以上のデバイスを攻撃・制御し、同社の大量の企業秘密情報を盗み出していた。

 

報告書

・2025.01.17 美网络攻击我国某先进材料设计研究院事件调查报告

美网络攻击我国某先进材料设计研究院事件调查报告 米国による中国先進材料設計・研究機関へのサイバー攻撃事件に関する調査報告
2024年12月18日,国家互联网应急中心 CNCERT发布公告 ([web]
),发现处置两起美对我大型科技企业机构网络攻击事件。本报告将公布对其中我国某先进材料设计研究院的网络攻击详情,为全球相关国家,单位有效发现和防范美网络攻击行为提供借鉴。
2024年12月18日、中国国家コンピュータネットワーク緊急対応技術チーム/調整センター(CNCERT)は、発表([web] )によると、中国政府による米国大手テクノロジー企業へのサイバー攻撃2件が処理されたことが判明した。本報告では、中国先進材料設計研究院に対するサイバー攻撃の詳細を公表し、世界各国の関連国および関連部門が米国のサイバー攻撃を効果的に検知・防止するための参考情報を提供する。
一、网络攻击流程 I. サイバー攻撃のプロセス
(一)利用漏洞进行攻击入侵 (1) 脆弱性を利用した攻撃
2024年8月19日,攻击者利用该单位电子文件系统注入漏洞入侵该系统,并窃取了该系统管理员账号/密码信息。2024年8月21日,攻击者利用窃取的管理员账号/密码登录被攻击系统的管理后台。 2024年8月19日、攻撃者は当該機関の電子文書システムの脆弱性を利用してシステムに侵入し、システムの管理者アカウント/パスワード情報を盗んだ。2024年8月21日、攻撃者は盗んだ管理者アカウント/パスワードを利用して、攻撃対象システムの管理バックグラウンドにログインした。
(二)软件升级管理服务器被植入后门和木马程序 (2) ソフトウェアアップグレード管理サーバーにバックドアとトロイの木馬が仕掛けられた
2024年8月21日12时,攻击者在该电子文件系统中部署了后门程序和接收被窃数据的定制化木马程序。为逃避检测,这些恶意程序仅存在于内存中,不在硬盘上存储。木马程序用于接收从涉事单位被控个人计算机上窃取的敏感文件,访问路径为/sxx/xxxx?nag=syn_user_policy。后门程序用于将窃取的敏感文件聚合后传输到镜外,访问路径是/xxx/xxxStats. 2024年8月21日12時、攻撃者は電子文書システムに盗難データを受信するバックドアプログラムとカスタマイズされたトロイの木馬プログラムを展開した。 検知を回避するため、これらの悪意のあるプログラムはメモリ内にのみ存在し、ハードディスクには保存されていない。 トロイの木馬は、関係部門の被疑者のパソコンから盗まれた機密ファイルを受信するために使用され、アクセスパスは/sxx/xxxx?nag=syn_user_policyであった。バックドアは、盗まれた機密ファイルをミラーの外に集約して送信するために使用され、アクセスパスは/xxx/xxxStatsであった。
(三)大范图个人主机电脑被植入木马 (3)トロイの木馬は、大ファンのパソコンに埋め込まれた
2024年11月6日、2024年11月8日和2024年11月16日,攻击者利用电子文档服务器的某软件升级功能将特种木马程序植入到该单位276 台主机中。木马程序的主要功能一是扫描被植入主机的敏感文件进行窃取。二是窃取受攻击者的登录账密等其他个人信息。木马程序即用即删。
2024年11月6日、11月8日、11月16日、攻撃者は電子文書サーバーのソフトウェアアップグレード機能を利用して、単位内の276台のホストコンピューターに特殊なトロイの木馬プログラムを植え付けた。トロイの木馬プログラムの主な機能は、植え付けられたホストコンピューター上の機密ファイルをスキャンして盗むことである。もう一つは、攻撃対象者のログインアカウントやパスワードなどのその他の個人情報を盗むことである。トロイの木馬プログラムは使用後すぐに削除される。
二、窃取大量商业秘密信息 II. 企業秘密を大量に窃取
(一)全盘扫描受害单位主机 (1) 被害者のホストをフルスキャン
攻击者多次用中国境内 IP 跳板登录到软件升级管理服务器,并利用该服务器入侵受害单位内网主机,并对该单位内网主机硬盘反复进行全盘扫描,发现潜在攻击目标,掌握该单位工作内容。 攻撃者は、中国国内のIPジャンプ台を繰り返し利用してソフトウェアアップグレード管理サーバーにログインし、このサーバーを利用して被害者の内部ネットワークホストに侵入し、被害者の内部ネットワークホストのハードディスクを繰り返しフルスキャンし、潜在的な攻撃対象を発見し、当該部門の業務内容を把握した。
(二)日的明确地针对性窃取 (2) 特定の日に明確に窃取
2024年11月6日至11月16日,攻击者利用3个不同的跳板 IP 三次入侵该软件升级管理服务器,向个人主机植入木马,这些木马已内置与受害单位工作内容高度相关的特定关键词,搜索到包含特定关键词的文件后即将相应文件窃取并传输至境外。这三次窃密活动使用的关键词均不相同,显示出攻击者每次攻击前均作了精心准备,具有很强的针对性。三次窃密行为共窃取重要商业信息、知识产权文件共4.98GB。 2024年11月6日から11月16日にかけて、攻撃者は3つの異なるジャンプオフポイントIPを使用してソフトウェアアップグレード管理サーバーを3回攻撃し、個人用ホストにトロイの木馬を埋め込んだ。これらのトロイの木馬には、すでに被害者部門の業務内容と極めて関連性の高い特定のキーワードが組み込まれていた。特定のキーワードを含むファイルを検索した後、対応するファイルが盗まれ、海外に送信された。 これら3回の盗難で使用されたキーワードはすべて異なっており、攻撃者は各攻撃の前に周到な準備を行い、標的を絞っていたことがわかる。3回の機密盗難により、合計4.98GBの重要な商業情報および知的財産文書が盗まれた。
三、攻击行为特点 III.攻撃の特徴
(一)攻击时间 (1)攻撃時間
分析发现,此次攻击时间主要栗中在北京时间 22时至次日8时,相对于美国东部时间为白天时间10时至20时,攻击时间主要分布在美国时间的星期一至星期五,在美国主要节假日未出现攻击行为。 分析によると、攻撃時間は主に北京時間22:00から翌日8:00の間であり、これは米国東部時間では10:00から20:00までの昼間である。攻撃時間は主に米国時間の月曜日から金曜日までであり、米国の大型連休には攻撃は発生していない。
(二)攻毒資源 (2) 攻撃リソース
攻击者使用的5个跳板IP 完全不童复,位于德国和罗马尼亚等地,反映出其高度的反溯源意识和丰富的攻击资源储各。 攻撃者が使用した5つのジャンプオフIPは完全に異なり、ドイツ、ルーマニアなどにあることから、追跡防止に対する高い意識と豊富な攻撃リソースの蓄積がうかがえる。
(三)攻击式器 (3) 攻撃ツール
一是善于利用开源或通用工具伪装避溯源,此次在涉事单位服务器中发现的后门程序为开源通用后门工具。攻击者为了避免被溯源,大量使用开源或通用攻击工具。 第一に、オープンソースや汎用ツールを駆使して、偽装や追跡回避を得意としている。今回事件に関与した部門のサーバーに発見されたバックドアプログラムは、オープンソースの汎用バックドアツールである。攻撃者は、追跡を避けるために、大量のオープンソースや汎用攻撃ツールを使用している。
二是重要后门和木马程序仅在内存中运行,不在硬盘中存储,大大提升了其攻击行为被我分析发现的难度。 第二に、重要なバックドアやトロイの木馬プログラムはメモリ上でしか実行されず、ハードディスクには保存されないため、攻撃の分析や発見の難易度が大幅に高まる。
(四)攻击手法 (4) 攻撃方法
攻击者攻击该单位电子文件系统服务器后,篡改了该系统的客户端分发程序,通过软件客户端升级功能,向276台个人主机投递木马程序,快速、精准攻击重要用户,大肆进行信息搜集和窃取。以上攻击手法充分显示出该攻击组织的强大攻击能力。 攻撃者は、当該単位の電子ファイルシステムサーバーを攻撃した後、当該システムのクライアント配布プログラムを改ざんし、ソフトウェアクライアントのアップグレード機能を利用して、276台の個人用ホストにトロイの木馬を送り込み、重要なユーザーを迅速かつ正確に攻撃し、大規模な情報収集と窃取を行った。以上の攻撃方法は、攻撃組織の強力な攻撃能力を十分に示している。
四、部分跳板IP列表 IV. 踏み台IPアドレス(一部)一覧

20250121-54033

 

 

・2025.01.17 美网络攻击我国某智慧能源和数字信息大型高科技企业事件调查报告

美网络攻击我国某智慧能源和数字信息大型高科技企业事件调查报告 米国サイバー攻撃 中国のスマートエネルギーおよびデジタル情報分野における大手ハイテク企業への攻撃に関する調査報告書
2024年12月18日,国家互联网应急中心 CNCERT发布公告 ([web] ),发现处置两起美对我大型科技企业机构网络攻击事件。本报告将公布对其中我国某智慧能源和数字信息大型高科技企业的网络攻击详情,为全球相关国家、单位有效发现和防范美网络攻击行为提供借鉴。 2024年12月18日、中国国家コンピュータネットワーク緊急対応技術チーム/調整センター(CNCERT)は、発表([web] )によると、中国による米国大手テクノロジー企業へのサイバー攻撃2件が処理されたことが判明した。この報告書では、スマートエネルギーおよびデジタル情報分野における中国大手ハイテク企業へのサイバー攻撃の詳細を公表し、世界各国の関連国および関連部門が米国のサイバー攻撃を効果的に検知・防止するための参考情報を提供する。
一、网络攻击流程 I. サイバー攻撃のプロセス
(一)利用邮件服务器漏洞进行入侵 (1) メールサーバーの脆弱性を利用し、侵入した
公司郎件服券使用微Exchange 件統。攻市者利用2个微软 Exchange 洞选行攻击,首先利用某任意用户伪造漏洞针对特定账户进行攻击,然后利用某反序列化漏洞再次进行攻击,达到执行任意代码的目标。 当該企業の文書管理システムはMicrosoft Exchangeを使用している。攻撃者は2つのMicrosoft Exchangeの脆弱性を利用して攻撃を行った。まず、ある任意のユーザー偽装の脆弱性を利用して特定のアカウントを攻撃し、その後、あるアンチシリアライゼーションの脆弱性を利用して再度攻撃を行い、任意のコードを実行するという目的を達成した。
(二)在邮件服务器植入高度隐蔽的内存木马 (2) 高度に隠蔽されたメモリ型トロイの木馬がメールサーバーに埋め込まれた
为避免被发现,攻击者在邮件服务器中植入了2个攻击武器,仅在内存中运行,不在硬盘存储。其利用了虚拟化技术,虛拟的访问路径为fowa/auth/xxx/xx.aspx 和 lowalauth/xxx/yy.aspx,攻武器主要功能包括敏感宿息窃取、命令执行以及内网穿透等。内网穿透程序通过混淆来逃避安全软件检测,将攻击者流量转发给其他目标设备,达到攻击内网其他设备的目的。

検知を回避するために、攻撃者はメールサーバーに2つの攻撃用武器を仕込んだ。これらはメモリ上でのみ実行され、ハードディスクには保存されない。 仮想化技術を使用しており、仮想アクセスパスはfowa/auth/xxx/xx.aspxおよびlowalauth/xxx/yy.aspxである。攻撃用武器の主な機能には、機密データ盗難、コマンド実行、イントラネット侵入などがある。イントラネット侵入プログラムは、難読化によりセキュリティソフトウェアによる検出を回避し、攻撃者のトラフィックを他の標的デバイスに転送し、イントラネット上の他のデバイスを攻撃する。
(三)对内网30余台重要设备发起攻击 (3) 内部ネットワーク上の30以上の重要デバイスに対する攻撃
攻击者以邮件服务器为跳板,利用内网扫描和渗透手段,在内网中建立隐蔽的加密传输隧道,通过 SSH.SMB等方式登录控制该公司的30余台重要设备并窃取数据。包括个人计算机、服务器和网络设备等;被控服务器包括,邮件服务器、办公系统服务器、代码管理服务器、测试服务器、开发管理服务器和文件管理服务器等。为实现持久控制,攻击者在相关服务器以及网络管理员计算机中植入了能够建立 websocket+SSH 隧適的攻击窃密武器,实现了对攻击者指的隠蔽義友和数取。避免被岌現,咳攻法 密程序装成微信相程序 WeChatxxxxxxxx.exe. 攻法者坯在受害服多器中植入了2个利用PIPE 管道迸行程同通信的模決化恶意程序,实现了通信管道的搭建。 攻撃者はメールサーバーを足がかりとし、内部ネットワークのスキャンと侵入方法を使用して内部ネットワーク上に隠された暗号化通信トンネルを確立し、SSH.SMBなどの方法で30以上の重要デバイスにログインしてデータを窃取した。 これには、パソコン、サーバー、ネットワーク機器などが含まれる。攻撃を受けた疑いのあるサーバーには、メールサーバー、オフィスシステムサーバー、コード管理サーバー、テストサーバー、開発管理サーバー、ファイル管理サーバーなどが含まれる。持続的な制御を実現するために、攻撃者は、関連サーバーおよびネットワーク管理者のコンピュータにウェブソケット+SSHトンネルを確立できる攻撃およびスパイ用の武器を仕込み、攻撃者の意図する隠蔽とデータ収集を実現した。 発見を回避するために、攻撃者は悪意のあるプログラムを「WeChatxxxxxxxx.exe」というWeChatアプレットに偽装した。その後、攻撃者は、PIPEプロトコルを使用して被害者のサーバーで同時通信用のパイプを確立する2つのモジュール型悪意のあるプログラムを仕込み、通信チャネルを確立した。
二、窃取大量商业秘密信息 II. 企業秘密情報の大量窃取
(一)窃取大量敏感邮件数据 (1) 機密性の高い大量のメールデータの窃取
攻击者利用邮件服务器管理员账号执行了邮件导出操作,窃密目标主要是该公司高层管理人员以及童要部门人员。攻击者执行导出命令时设置了导出邮件的时间区间,有些账号邮件全部导出,邮件很多的账号按指定时间区间导出,以减少窃密数据传输量,降低被发现风险。 攻撃者は、メールサーバの管理者アカウントを利用して、同社の経営層や主要部門の担当者を対象に、メールのエクスポート操作を行った。エクスポートコマンドを実行する際、攻撃者はメールのエクスポート時間間隔を設定した。一部のアカウントはすべてエクスポートされ、メール件数の多いアカウントは、送信データ量と発覚リスクを低減するために、時間間隔に従ってエクスポートされた。
(二)窃取核心网络设备账号及配置信息 (2) 基幹ネットワーク機器のアカウントおよび設定情報の窃取
攻击者通过攻击控制该公司3名网络管理员计算机,频繁窃取该公司核心网络设备账号及配暨信息。例如,2023年5月2日、攻法者以手徳国的代理服器(95.179.XX.XX)为跳板,入了该公司邮件服务累后,以邮件服务器为跳板,攻击了该公司网络管理员计算机,并窃取了“网络核心设备配置表”、“核心网络设备配置备份及巡检”、“网络拓扑”、“机房交换机(核心+汇聚〕”、“运营商IP 地址统计”、“关于采购互联网控制网关的请示”等敏悠文件。 攻撃者は、同社のネットワーク管理者の3台のコンピュータを攻撃することで、同社のコアネットワーク機器のアカウントと設定情報を頻繁に盗んでいた。例えば、2023年5月2日、攻撃者はドイツのプロキシサーバー(95.179.XX.XX)を踏み台にして同社のメールサービスに侵入し、その後、メールサーバーを踏み台にして同社のネットワーク管理者のコンピュータを攻撃し コンピュータに侵入し、「ネットワークコア機器構成表」、「コアネットワーク機器構成バックアップ・点検」、「ネットワークトポロジー」、「コンピュータ室スイッチ(コア+アグリゲーション)」、「キャリアIPアドレス統計」、「インターネットコントロールゲートウェイ購入依頼書」などの機密ファイルを盗んだ。
(三)窃取项目管理文件 (3) プロジェクト管理文書の窃取
攻击者通过对该公司的代码服务累、开发服务器等进行攻法,頻繁窃取公司相袋項目数担。例如。2023年7月26日、攻市者以的代理服器(65.21.XX.XX)为跳板,攻击控制该公司的邮件服务器后,又以此为跳板,频繁访问在该公司代码服务累中已植入的后门攻击武器,窃取数据达1.03GiB。为避免被发现,该后门程序伪装成开源项目“禅道”中的文件 “lip4XXXXXXXX.php”。 攻撃者は、頻繁に会社のコードサービスプラットフォームと開発サーバーを攻撃して、会社のプロジェクトデータを窃取していた。例えば、2023年7月26日、攻撃者はプロキシサーバー(65.21.XX.XX)を踏み台として、会社のメールサーバーを攻撃し、その後、踏み台として頻繁にアクセスしていた 会社のコードサービスに仕込まれたバックドア攻撃兵器に頻繁にアクセスし、1.03 GiBに達するデータを盗んだ。 バックドアプログラムは、検知を回避するために、オープンソースプロジェクト「ZenTao」の「lip4XXXXXXXX.php」というファイルを装っていた。
(四)清除攻击痕迹并进行反取证分析 (4) 攻撃の痕跡を消去し、フォレンジック対抗分析を行う
为避免被发现,攻击者每次攻击后,都会清除计算机日志中攻击痕班,并删除攻击窗密过程中产生的临时打包文件。攻击者还会查看系统审计日志、历史命令记录,SSH相关配置等,意图分析机器祓取证情况,对抗网络安全检测。 検知を回避するために、攻撃者は攻撃のたびに、コンピュータログから攻撃の痕跡を消去し、攻撃ウィンドウ中に生成された一時的なパッケージングファイルを削除していた。 また、攻撃者はシステム監査ログ、過去の命令記録、SSH関連の設定などを確認し、マシンを分析して証拠を捜し、ネットワークセキュリティの検出を回避しようとした。
三、攻击行为特点 III. 攻撃の特徴
(一)攻击时间 (1) 攻撃時間
分析发现,此次攻击活动主要条中在北京时间22时至次日8时,相对于美国东部时间为白天10时至20时,攻击时间主要分布在美国时间的星期一至星期五,在美国主要节假日未出现攻击行为。 分析によると、攻撃活動は主に北京時間22:00から翌日8:00までの間に集中しており、これは東部時間では10:00から20:00までの日中である。攻撃時間は主に米国時間の月曜日から金曜日にかけて分布しており、米国の主要な祝日には攻撃は検出されていない。
(二)攻击资源 (2) 攻撃リソース
2023年5月至2023年10月,攻击者发起了30余次网络攻击,攻击者使用的境外跳板 IP 基本不重复,反映出其高度的反溯源意识和丰富的攻击资源储备。 2023年5月から10月にかけて、攻撃者は30回以上のサイバー攻撃を仕掛けた。攻撃者の海外ジャンププラットフォームのIPは基本的に繰り返し使用されておらず、追跡防止に対する高い意識と豊富な攻撃リソースの蓄えを反映している。
(三)攻击武器 (3) 攻撃武器
攻击者植入的2个用于PIPE 管道进程通信的模化恶意程序位于 “c:liwindowslisystem32W” 下,使用了.net 框架,编译时间均被抹除,大小为数十KB,以TLS 加密为主。邮件服务器内存中植入的攻击武器主耍功能包括敏感信总窃取、命令执行以及内网穿透等。在相关服务器以及网络管理员计算机中植入的攻击窃密武器,使用https 协议,可以建立websocket+SSH 隧道,会回连攻击者控制的某域名。 攻撃者がPIPEパイプラインプロセス通信に埋め込んだ2つのモジュール型悪意あるプログラムは、「c:liwindowslisystem32W」に位置し、.netフレームワークを使用し、コンパイル時間は消去されている。サイズは数十KBで、主にTLS暗号化を使用している。 メールサーバーのメモリに埋め込まれた攻撃用武器の主な機能には、機密文書窃取、コマンド実行、イントラネット侵入などがある。関連サーバーおよびネットワーク管理者のコンピュータに埋め込まれた攻撃・スパイ用武器は、httpsプロトコルを使用し、websocket+SSHトンネルを確立し、攻撃者が管理するドメイン名に接続する。
四、部分跳板 IP列表 IV. 踏み台IPアドレス(一部)一覧

20250121-53926

 

ちなみに国。。。

荷兰 オランダ
罗马尼亚 ルーマニア
德国 ドイツ
芬兰 フィンランド
墨西哥 メキシコ

 

ドイツが多いですね...

 

 


こちらも参考に...

 

WeChat(テンセント)

微信公众平台(WeChat公式アカウント)

・2025.01.18 CNCERT:美网络攻击我国某智慧能源和数字信息大型高科技企业事件调查报告

(中国のインテリジェント・エネルギーおよびデジタル情報の大規模ハイテク企業に対する米国のサイバー攻撃に関する調査報告)

 

・2025.01.18 CNCERT:美网络攻击我国某先进材料设计研究院事件调查报告

(中国の先端材料設計研究所に対する米国のサイバー攻撃に関する調査報告)

 

・2025.01.18 AI大模型对CNCERT有关美国对我机构实施网络攻击两份调查报告的分析与评价

(米国のサイバー攻撃に関するCNCERTの2つの調査報告書に対するAIビッグモデルの分析と評価)

 

 

| | Comments (0)

より以前の記事一覧