European Commission

・2023.12.01 Commission welcomes political agreement on Cyber Resilience Act

Commission welcomes political agreement on Cyber Resilience Act 欧州委員会、サイバー・レジリエンス法に関する政治合意を歓迎する
The Commission welcomes the political agreement reached last night between the European Parliament and the Council on the Cyber Resilience Act, proposed by the Commission in September 2022. 欧州委員会は、欧州委員会が2022年9月に提案した「サイバー・レジリエンス法」に関する欧州議会と理事会の政治的合意が昨夜成立したことを歓迎する。
The Cyber Resilience Act is the first legislation of its kind in the world. It will improve the level of cybersecurity of digital products to the benefit of consumers and businesses across the EU, as it introduces proportionate mandatory cybersecurity requirements for all hardware and software, ranging from baby monitors, smart watches and computer games to firewalls and routers.  Products with different levels of risk associated will have different security requirements. Less than 10% of products will be subject to third-party assessments. サイバー・レジリエンス法は、この種の法律としては世界初のものである。ベビーモニター、スマートウォッチ、コンピューターゲームからファイアウォールやルーターに至るまで、すべてのハードウェアとソフトウェアに比例した義務的サイバーセキュリティ要件が導入される。 関連するリスクのレベルが異なる製品は、セキュリティ要件も異なる。サードパーティ評価の対象となる製品は全体の10%未満である。
With this new Regulation, all products put on the EU market will need to be cyber secure. This is a crucial step in the fight against the growing threat from cyber criminals and other malicious actors. この新規制により、EU市場に投入されるすべての製品はサイバーセキュアである必要がある。これは、サイバー犯罪者やその他の悪意ある行為者から増大する脅威との戦いにおける重要なステップである。
Once the Cyber Resilience Act is in place, manufacturers of hardware and software will have to implement cybersecurity measures across the entire lifecycle of the product, from the design and development, to after the product is placed on the market. Software and hardware products will bear the CE marking to indicate that they comply with the Regulation's requirements and therefore can be sold in the EU. サイバー・レジリエンス法が施行されると、ハードウェアとソフトウェアのメーカーは、設計・開発から製品が市場に投入された後まで、製品のライフサイクル全体にわたってサイバーセキュリティ対策を実施しなければならなくなる。ソフトウェアおよびハードウェア製品には、同規則の要件に適合していることを示すCEマーキングが付され、EU域内で販売できるようになる。
The Act will also introduce a legal obligation for manufacturers to provide consumers with timely security updates during several years after the purchase. This period has to reflect the time products are expected to be used. 同法はまた、購入後数年間、消費者にタイムリーなセキュリティアップデートを提供する製造業者の法的義務を導入する。この期間は、製品が使用されると予想される期間を反映したものでなければならない。
Through these measures, the new Act will empower users to make better informed and more secure choices, as manufacturers will have to become more transparent and responsible about the security of their products. これらの措置により、新法は、メーカーが自社製品のセキュリティについてより透明性を高め、責任を持たなければならなくなるため、ユーザーがより十分な情報を得た上で、より安全な選択をすることができるようになる。
Next Steps 次のステップ
The agreement reached is now subject to formal approval by both the European Parliament and the Council. Once adopted, the Cyber Resilience Act will enter into force on the 20th day following its publication in the Official Journal. 今回の合意は、欧州議会と欧州理事会の正式な承認が必要となる。採択されれば、サイバー・レジリエンス法は官報に掲載されてから20日目に発効する。
Upon entry into force, manufacturers, importers and distributors of hardware and software products will have 36 months to adapt to the new requirements, with the exception of a more limited 21-month grace period in relation to the reporting obligation of manufacturers for incidents and vulnerabilities. 発効後、ハードウェアおよびソフトウェア製品の製造業者、輸入業者、販売業者は、インシデントや脆弱性に関する製造業者の報告義務に関する21ヶ月という限定的な猶予期間を除き、新しい要件に適応するために36ヶ月の猶予期間が与えられる。
Background 背景
Cybersecurity is one of the top priorities of the European Commission. We must take strong action to secure our digital products, both software and hardware. サイバーセキュリティは欧州委員会の最優先課題のひとつである。われわれは、ソフトウェア、ハードウェアを問わず、デジタル製品の安全性を確保するために強力な行動を起こさなければならない。
The Cyber Resilience Act builds on the 2020 EU Cybersecurity Strategy and the 2020 EU Security Union Strategy, and was announced in the 2021 State of the European Union address as part of the plan to build a Europe fit for the Digital age. It will complement existing legislation, specifically the NIS2 Framework, adopted in 2022. サイバー・レジリエンス法は、2020年EUサイバーセキュリティ戦略と2020年EU安全保障連合戦略に基づくもので、デジタル時代に適合した欧州を構築する計画の一環として、2021年の欧州連合演説で発表された。これは既存の法律、特に2022年に採択されたNIS2フレームワークを補完するものである。
In the last year, the number of software supply chain attacks have tripled, and every day, small businesses and critical institutions like hospitals are targeted by cyber criminals. Every 11 seconds, an organisation is hit by a ransomware attack, to the cost of an estimated €20 billion annually. And, in 2021 alone, cyber criminals were able to hack devices and launch around 10 million distributed denial of service (DDoS) attacks worldwide, making websites and online services  inaccessible to their users. 昨年、ソフトウェアサプライチェーン攻撃の件数は3倍に増加し、毎日、中小企業や病院のような重要機構がサイバー犯罪者に狙われている。11秒に1つの組織がランサムウェア攻撃を受けており、その被害額は年間200億ユーロに上ると推定されている。また、2021年だけでも、サイバー犯罪者はデバイスをハッキングし、世界中で約1,000万件の分散型サービス妨害(DDoS)攻撃を仕掛け、ウェブサイトやオンライン・サービスを利用できなくすることができた。
For More Information 詳細はこちら
Cyber Resilience Act サイバー・レジリエンス法
Proposal for a Cyber Resilience Act サイバー・レジリエンス法の提案
Cyber Resilience Act - Questions and Answers (updated) サイバー・レジリエンス法 - 質問と回答(更新版)
Factsheet: Cyber Resilience Act ファクトシート サイバー・レジリエンス法
Impact assessment: Cyber Resilience Act 影響評価 サイバー・レジリエンス法
Quote(s) 引用
Consumers need to feel safe with the products available on the EU market. The Cyber Resilience Act agreed today will ensure the digital products we use at home and at work comply with strong cybersecurity standards. Those that place these products on the market must be held responsible for their safety. 消費者は、EU市場で入手可能な製品を安心して使用する必要がある。本日合意されたサイバー・レジリエンス法は、我々が家庭や職場で使用するデジタル製品が強力なサイバーセキュリティ標準に準拠することを保証するものである。これらの製品を市場に出す者は、その安全性について責任を負わなければならない。
Věra Jourová, Vice-President for Values and Transparency - 01/12/2023 ヴィエラ・ジュロヴァー副会長(価値・透明性担当) - 01/12/2023
The safety of all products circulating in the EU has always been a priority and a success story. With the Cyber Resilience Act, we are filling a gap by completing the safety rules so that security by design applies to all products that reach EU consumers and users. The new rules require every interconnected product sold in the EU to be cybersecure and make sure that our businesses and homes become more secure. EUで流通するすべての製品の安全性は、常に優先事項であり、成功事例である。サイバー・レジリエンス法では、EUの消費者やユーザーの手に渡るすべての製品にデザインによるセキュリティが適用されるよう、安全規則を完成させることでギャップを埋めようとしている。この新しい規則は、EU域内で販売されるすべての相互接続製品にサイバーセキュリティを要求するものであり、私たちのビジネスと家庭がより安全になることを確実にするものである。
Margaritis Schinas, Vice-President for Promoting our European Way of Life - 01/12/2023 マルガリーテス・シナス副委員長(欧州生活促進担当) - 01/12/2023
I welcome the agreement reached by the Parliament and the Council on this important regulation my services tabled. This Act guarantees that digital devices within the EU embody robust cybersecurity from their conception throughout their lifecycle. This cybersecurity by design is essential for the security of both consumers and society at large. 私が提出したこの重要な規則について、議会と理事会が合意に達したことを歓迎する。この法律は、EU域内のデジタル機器が、その構想段階からライフサイクルを通じて強固なサイバーセキュリティを具現化することを保証するものである。このサイバーセキュリティ・バイ・デザインは、消費者と社会全体の安全にとって不可欠である。
Thierry Breton, Commissioner for Internal Market - 01/12/2023 ティエリー・ブルトン域内市場担当委員 - 2023年12月1日




European Parliament

・2023.12.01 Cyber Resilience Act: agreement with Council to boost digital products’ security

Cyber Resilience Act: agreement with Council to boost digital products’ security サイバー・レジリエンス法:デジタル製品のセキュリティ強化に向けた理事会との合意
・More robust cybersecurity for all products with digital elements ・デジタル要素を含むすべての製品に対して、より強固なサイバーセキュリティを提供する。
・Covers everyday products, such as connected doorbells, baby monitors and Wi-Fi routers ・コネクテッド・ドアベル、ベビーモニター、Wi-Fiルーターなど、日常的に使用される製品を対象とする。
・Security updates to be applied automatically when technically feasible ・技術的に可能な場合、セキュリティアップデートを自動的に適用する。
On Thursday night, MEPs reached a deal with the Presidency of the Council on new cyber resilience rules to protect all digital products in the EU from cyber threats. 木曜日夜、欧州議会議員は、EU域内のすべてのデジタル製品をサイバー脅威から保護するための新しいサイバー・レジリエンス規則について、理事会議長国と合意に達した。
Parliament and Council negotiators reached an informal agreement on the Cyber Resilience Act, which aims to ensure that products with digital features are secure to use, resilient against cyber threats and provide enough information about their security properties. 欧州議会と理事会の交渉担当者は、サイバーレジリエンシー法について非公式合意に達した。この法律は、デジタル機能を備えた製品が安全に使用され、サイバー脅威に対してレジリエンス(回復力)を持ち、セキュリティ特性について十分な情報を提供することを保証することを目的としている。
The rules will put important and critical products into different lists based on their criticality and the level of cybersecurity risk they pose. Two lists will be proposed and updated by the European Commission. During negotiations, MEPs secured an expansion of the list of covered devices with products such as identity management systems software, password managers, biometric readers, smart home assistants and private security cameras. Products should also have security updates installed automatically and separately from functionality ones. この規則では、重要かつクリティカルな製品を、その重要性とサイバーセキュリティリスクのレベルに応じて異なるリストに分類する。つのリストが欧州委員会によって提案され、更新される。交渉中、欧州議会議員らは、ID管理システムソフトウェア、パスワード管理者、生体認証リーダー、スマートホームアシスタント、個人用セキュリティカメラなどの製品を対象とする対象機器リストの拡大を確保した。また、機能とは別にセキュリティアップデートが自動的にインストールされるようにすべきである。
MEPs also pushed for the European Union Agency for Cybersecurity (ENISA) to be more closely involved when vulnerabilities and incidents occur. The agency will be notified by the member state concerned and receive information so it can assess the situation and, if it estimates that the risk is systemic, will inform other member states so they are able to take the necessary steps. 欧州議会議員はまた、脆弱性やインシデントが発生した場合、欧州連合サイバーセキュリティ機関(ENISA)がより密接に関与するよう求めた。ENISAは関係加盟国から通知を受け、情報を受け取ることで状況を評価し、リスクがシステミックであると判断した場合には、他の加盟国に通知し、必要な措置を講じることができるようにする。
To emphasise the importance of professional skills in the cybersecurity field, MEPs also managed to introduce education and training programmes, collaboration initiatives, and strategies to enhance workforce mobility. また、サイバーセキュリティ分野における専門スキルの重要性を強調するため、欧州議会議員は、教育・訓練プログラム、協力イニシアティブ、労働力の流動性を高める戦略の導入にも取り組んだ。
Quote 引用
Lead MEP Nicola Danti (Renew, IT) said: “The Cyber Resilience Act will strengthen the cybersecurity of connected products, tackling vulnerabilities in hardware and software alike, making the EU a safer and more resilient continent. Parliament has protected supply chains ensuring that key products such as routers and antiviruses are identified as a priority for cybersecurity. We have ensured support for micro and small enterprises and better involvement of stakeholders, and addressed the concerns of the open-source community, while keeping an ambitious European dimension. Only together will we be able to tackle successfully the cybersecurity emergency that awaits us in the coming years.” ニコラ・ダンチ欧州議会議員(刷新、IT)は次のように述べた: 「サイバー・レジリエンス法は、コネクテッド製品のサイバーセキュリティを強化し、ハードウェアとソフトウェアの脆弱性に取り組むことで、EUをより安全でレジリエンスに優れた大陸にする。議会は、ルーターやアンチウイルスなどの主要製品がサイバーセキュリティの優先事項として特定されるよう、サプライチェーンを保護してきた。また、欧州という野心的な次元を保ちつつ、零細・小規模エンタープライズへの支援と利害関係者のより良い参加を確保し、オープンソースコミュニティの懸念に対処してきた。今後数年間に待ち受けるサイバーセキュリティの緊急事態に成功裏に取り組むことができるのは、われわれの協力があってこそである」。
Next steps 次のステップ
The agreed text will now have to be formally adopted by both Parliament and Council in order to come into law. The Industry, Research and Energy Committee will hold a vote on the file in a forthcoming meeting. 合意された文書は今後、国会と理事会の双方で正式に採択され、法制化される必要がある。産業・研究・エネルギー委員会は、近々開催される会議でこの法案に関する採決を行う予定である。
Background 背景
New technologies come with new risks, and the impact of cyber-attacks through digital products has increased dramatically in recent years. Consumers have fallen victim to security flaws linked to digital products such as baby monitors, robot-vacuum cleaners, Wi-Fi routers and alarm systems. For businesses, the importance of ensuring that digital products in the supply chain are secure has become pivotal, considering three in five vendors have already lost money due to product security gaps. 新しい技術には新しいリスクがつきものであり、デジタル製品を介したサイバー攻撃の影響は近年劇的に増加している。消費者は、ベビーモニター、ロボット掃除機、Wi-Fiルーター、警報システムなどのデジタル製品に関連したセキュリティ欠陥の犠牲になっている。企業にとっても、サプライチェーンにおけるデジタル製品の安全性を確保することの重要性は、製品のセキュリティ・ギャップのためにすでに5社に3社が損失を被っていることを考えると、極めて重要になっている。




European Council

・2023.11.30 Cyber resilience act: Council and Parliament strike a deal on security requirements for digital products

Cyber resilience act: Council and Parliament strike a deal on security requirements for digital products サイバー・レジリエンス法: 欧州理事会と欧州議会がデジタル製品のセキュリティ要件で合意
The Council presidency and the European Parliament’s negotiators have reached a provisional agreement on the proposed legislation regarding cybersecurity requirements for products with digital elements, which aims to ensure that products such as connected home cameras, fridges, TVs and toys are safe before they are placed on the market (cyber resilience act).   欧州理事会議長国と欧州議会の交渉担当者は、コネクテッドホームカメラ、冷蔵庫、テレビ、玩具などの製品が市場に出回る前に安全であることを保証することを目的とした、デジタル要素を含む製品のサイバーセキュリティ要件に関する法律案(サイバー・レジリエンス法)について暫定合意に達した。 
Today’s agreement is a milestone towards a safe and secure digital single market in Europe. Connected devices need a basic level of cybersecurity when sold in the EU, ensuring that businesses and consumers are properly protected against cyber threats. This is exactly what the cyber resilience act will achieve once it enters into force. 「本日の合意は、欧州における安全でセキュアなデジタル単一市場に向けた一里塚である。コネクテッドデバイスがEUで販売される際には、基本的なレベルのサイバーセキュリティが必要であり、企業や消費者がサイバー脅威から適切に保護されることが保証される。サイバー・レジリエンス法が発効されれば、まさにこれが実現されることになる」。
José Luis Escrivá, Spanish minister of digital transformation ホセ・ルイス・エスクリバ、スペインのデジタル変革担当大臣
Main objectives of the new regulation 新規則の主な目的
The new law introduces EU-wide cybersecurity requirements for the design, development, production and making available on the market of hardware and software products, to avoid overlapping requirements stemming from different pieces of legislation in EU member states. 新法は、EU加盟国の異なる法律に由来する要件の重複を避けるため、ハードウェアおよびソフトウェア製品の設計、開発、生産、市場投入に関するEU全体のサイバーセキュリティ要件を導入する。
The regulation will apply to all products that are connected either directly or indirectly to another device or to a network. There are some exceptions for products for which cybersecurity requirements are already set out in existing EU rules, for example medical devices, aeronautical products and cars. この規制は、他の機器やネットワークに直接または間接的に接続されるすべての製品に適用される。ただし、医療機器、航空製品、自動車など、既存のEU規則でサイバーセキュリティ要件がすでに定められている製品については例外がある。
The proposal aims to fill the gaps, clarify the links, and make the existing cybersecurity legislation more coherent, ensuring that products with digital components, for example ‘Internet of Things’ (IoT) products, are made secure throughout the supply chain and throughout their lifecycle. この提案は、ギャップを埋め、つながりを明確にし、既存のサイバーセキュリティ法制をより首尾一貫したものにすることで、例えば「モノのインターネット」(IoT)製品のようなデジタルコンポーネントを持つ製品が、サプライチェーン全体およびライフサイクル全体を通じて安全であることを保証することを目的としている。
Finally, the regulation will allow consumers to take cybersecurity into account when selecting and using products that contain digital elements, making it easier for them to identify hardware and software products with the proper cybersecurity features. 最後に、同規制は、消費者がデジタル要素を含む製品を選択・使用する際にサイバーセキュリティを考慮できるようにし、適切なサイバーセキュリティ機能を備えたハードウェア製品やソフトウェア製品を特定しやすくする。
Main thrust of the Commission proposal retained 欧州委員会提案の主な内容は維持される
The provisionally agreed text maintains the general thrust of the Commission’s proposal, namely as regards: 暫定的に合意された文書は、欧州委員会の提案の一般的な主旨、すなわち、以下の点を維持している:
・rules to rebalance responsibility for compliance towards manufacturers, who must meet certain obligations such as providing cybersecurity risk assessments, issuing declarations of conformity, and cooperating with the competent authorities ・製造業者は、サイバーセキュリティのリスクアセスメントのプロバイダ、適合宣言書の発行、所轄当局との協力といった一定の義務を果たさなければならない。
・vulnerability handling processes for manufacturers to ensure the cybersecurity of digital products, and obligations for economic operators, such as importers or distributors, in relation to those processes ・製造業者がデジタル製品のサイバーセキュリティを確保するための脆弱性対応プロセス、およびそれらのプロセスに関連する輸入業者や販売業者などの経済事業者の義務
・measures to improve transparency on the security of hardware and software products for consumers and business users ・消費者および企業ユーザー向けに、ハードウェアおよびソフトウェア製品のセキュリティに関する透明性を改善するための措置
・a market surveillance framework to enforce the rules. ・規則を実施するための市場監視の枠組み
Co-legislators’ main amendments 共同議員の主な修正案
However, the co-legislators propose various adjustments to parts of the Commission’s proposal, mainly with regard to: しかし、共同議員団は、欧州委員会の提案の一部について、主に以下の点でさまざまな修正を提案している:
・the scope of the proposed legislation, with a simpler methodology for the classification of digital products to be covered by the new regulation ・新規制の対象となるデジタル製品の分類をより単純化した方法論とする。
・the determination of the expected product lifetime by manufacturers: while the principle remains that the support period for a digital product corresponds to its expected lifetime, a support period of at least five years is indicated, except for products which are expected to be in use for a shorter period of time ・製造者による製品の予想耐用年数の決定: デジタル製品のサポート期間は、その製品の予想耐用年数に対応するという原則は変わらないが、より短い期間しか使用されないと予想される製品を除き、少なくとも5年間のサポート期間が示される。
・the reporting obligations regarding actively exploited vulnerabilities and incidents: the competent national authorities will be the initial recipients of such reports but the role of the EU agency for cybersecurity (ENISA) is strengthened ・積極的に悪用された脆弱性やインシデントに関する報告義務:管轄の国家当局がそのような報告の最初の取得者となるが、EUのサイバーセキュリティ機関(ENISA)の役割は強化される。
・the new rules will apply three years after the law enters into force, which should give manufacturers sufficient time to adapt to the new requirements ・新規則は法律発効から3年後に適用されるため、製造業者は新しい要件に適応するための十分な時間を確保できるはずである。
・additional support measures for small and micro enterprises have been agreed, including specific awareness-raising and training activities, as well as support for testing and conformity assessment procedures. ・特定の意識向上およびトレーニング活動、試験および適合性評価手続きへの支援など、小規模・零細企業に対する追加支援措置が合意された。
Next steps 次のステップ
Following today’s provisional agreement, work will continue at technical level in the coming weeks to finalise the details of the new regulation. The Spanish presidency will submit the compromise text to the member states’ representatives (Coreper) for endorsement once this work has been concluded. 本日の暫定合意を受けて、今後数週間、技術レベルで新規則の詳細を詰める作業が続けられる。スペインの議長国は、この作業が終了次第、妥協案を加盟国代表者(Coreper)に提出し、承認を求める。
The entire text will need to be confirmed by both institutions and undergo legal-linguistic revision before formal adoption by the co-legislators. 共同立法者による正式な採択に先立ち、全文が両機構によって確認され、法文上の修正を受ける必要がある。
Background 背景
In its conclusions of 2 December 2020 on the cybersecurity of connected devices, the Council underlined the importance of assessing the need for horizontal legislation in the long term to address all relevant aspects of cybersecurity of connected devices, such as availability, integrity and confidentiality, including specifying conditions for placement on the market. 欧州理事会は、2020年12月2日に発表したコネクテッドデバイスのサイバーセキュリティに関する結論の中で、市場投入の条件を規定することを含め、可用性、完全性、機密性など、コネクテッドデバイスのサイバーセキュリティに関連するあらゆる側面に対応するため、長期的に水平的な法律の必要性を評価することの重要性を強調した。
First announced by Commission President von der Leyen in her State of the Union address in September 2021, the cyber resilience act was mentioned in the Council conclusions of 23 May 2022 on the development of the European Union’s cyber posture, which called upon the Commission to submit its proposal by the end of 2022. フォン・デル・ライエン欧州委員会委員長が2021年9月の一般教書演説で初めて発表したサイバー・レジリエンス法は、EUのサイバー態勢の整備に関する2022年5月23日の理事会結論で言及され、欧州委員会に対し2022年末までに提案書を提出するよう求めた。
On 15 September 2022, the Commission submitted the proposal for a cyber resilience act, which will complement the existing EU cybersecurity framework: the directive on the security of network and information systems (NIS directive), the directive on measures for a high level of cybersecurity across the Union (NIS 2 directive) and the EU cybersecurity act. 2022年9月15日、欧州委員会は、ネットワークと情報システムのセキュリティに関する指令(NIS指令)、EU全域における高水準のサイバーセキュリティ対策に関する指令(NIS 2指令)、EUサイバーセキュリティ法といった既存のEUサイバーセキュリティの枠組みを補完するサイバー・レジリエンス法の提案を提出した。
Cyber resilience act, Council’s negotiating mandate, 19 July 2023 ・サイバー・レジリエンス法、理事会の交渉委任、2023年7月19日
Regulation on harmonized cybersecurity requirements for products with digital elements (cyber resilience act), Commission proposal, 15 September 2022 ・デジタル要素を含む製品のサイバーセキュリティ要件の調和に関する規則(サイバー・レジリエンス法)、欧州委員会提案、2022年9月15日
Your life online: how the EU is making it easier and safer for you (feature story) ・あなたのオンライン生活:EUはどのようにしてより簡単で安全なものにしようとしているのか(特集記事)



| | Comments (0)


IPA サイバーセキュリティ経営ガイドライン Ver 3.0実践のためのプラクティス集 (2023.10.31)





・2023.10.31 サイバーセキュリティ経営ガイドライン Ver 3.0実践のためのプラクティス集


[PDF] プラクティス集第4版


[PDF] 第4版 変更履歴









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


・2023.06.27 英国 NSCS (サイバーセキュリティ向け)リスクマネジメントガイドの改訂 (2023.06.23) + 取締役会向けサイバーセキュリティ・ツールキット (2023.03.30)



・2023.03.26 経済産業省 サイバーセキュリティ経営ガイドラインVer 3.0

・2023.03.09 総務省 経済産業省 警察庁、内閣官房 「サイバー攻撃被害に係る情報の共有・公表ガイダンス」を公表

・2022.12.10 経団連 「サイバーセキュリティ経営ガイドライン Ver3.0 (案) 」に対する意見

・2022.06.16 経済産業省 「サイバーセキュリティ体制構築・人材確保の手引き」(第2.0版)

・2022.03.30 IPA サイバーセキュリティ経営ガイドライン Ver 2.0実践のためのプラクティス集

・2021.08.18 経済産業省 / IPA サイバーセキュリティ経営可視化ツールWeb版(V1.0版)

・2021.04.27 経済産業省 「サイバーセキュリティ体制構築・人材確保の手引き」(第1.1版)

・2021.04.06 IPA 「2020年度サイバーセキュリティ経営ガイドライン実践のためのプラクティスの在り方に関する調査」報告書

・2020.09.30 経済産業省からサイバーセキュリティ経営ガイドラインVer2.0の付録として「サイバーセキュリティ体制構築・人材確保の手引き」が公開されていますね。。。

・2020.06.04 IPA サイバーセキュリティ経営ガイドライン Ver 2.0実践のためのプラクティス集

・2020.03.26 IPA サイバーセキュリティ経営ガイドライン実践状況の可視化ツールβ版



| | Comments (0)


欧州 EASA 航空安全に関する情報セキュリティ規則 (2023.10.31)


欧州連合航空安全機関  (European Union Aviation Safety Agency: EASA) が情報セキュリティ規則への簡単アクセスツール (Easy Access Rules (EAR) for Information Security ) を公表していますね。。。欧州連合航空安全機関は、米国の連邦航空局 (Federal Aviation Administration: FAA) に相当する欧州の機関。。。

規則、委任規則、許容される遵守手段 (acceptable means of compliance: AMC) 、ガイダンス資料 (guidance material: GM) と複層的にルールが作られるので、それらを分かりやすく統合した資料という感じですね。。。



European Union Aviation Safety Agency: EASA


・2023.10.31 EASA published first Easy Access Rules for Information Security


・2023.10.31 First Easy Access Rules for Information Security (Regulations (EU) 2023/203 and 2022/1645)









Commission Implementing Regulation (EU) 2023/203 欧州委員会 規則(EU)2023/203 欧州委員会規則(EU)No 1178/2011の対象となる組織および管轄当局のための、航空安全に影響を及ぼす可能性のある情報セキュリティリスク管理の要件に関する規則(EU)2018/1139の適用規則を定め、同規則を改正する規則。
設計組織承認 (Design Organisations Approvals: DOA)、生産組織承認 (Production Organisations: POA)、エプロン管理者 (Apron Management)、飛行場運営者 (Aerodrome Operators) 向け
Commission Delegated Regulation (EU) 2022/1645  欧州委員会委任規則(EU)第2022/1645号 第748/2012号および(EU)第139/2014号の対象となる組織に対する航空安全に影響を及ぼす可能性のある情報セキュリティリスクの管理に関する要求事項に関して、規則(EU)2018/1139号の適用に関する規則を定め、同規則を改正する欧州委員会委任規則(EU)第2022/1645号
ED Decision 2023/008/R ‘Management of information security risks’  ED決定2023/008/R「情報セキュリティリスクの管理」 規則(EU)2022/1645および規則(EU)2023/203の条文に対するAMCおよびGMを規定する;
ED Decision 2023/009/R ‘Management of information security risks’  ED決定2023/009/R「情報セキュリティリスクの管理」 AMC&GMがPart-IS規制パッケー ジ(Part-IS.D.ORとPart-IS.I.OR)の実施を支援することを規定する。
ED Decision 2023/010/R ‘Management of information security risks’ ED決定2023/010/R「情報セキュリティリスクの管理」 AMCとGMがPart-IS規制パッケージ(Part-IS.AR)の実施を支援することを規定する。



Continue reading "欧州 EASA 航空安全に関する情報セキュリティ規則 (2023.10.31)"

| | Comments (0)


NATO CCDCOE 国際サイバー法の実践;インタラクティブ・ツールキットの新規募集 (2023.10.23)


NATO CCDCOEでは、国際サイバー法の実践;インタラクティブ・ツールキットとして、28の仮想シナリオを公開していますが、新規のシナリオの募集をしていますね。。。



NATO CCECOE - International Cyber Law in Practice: Interactive Toolkit


S01 Election interference 選挙妨害
S02 Political espionage 政治スパイ
S03 Power grid 送電網
S04 International organization 国際機関
S05 Criminal investigation 犯罪捜査
S06 Enabling State 国家を動かす
S07 Hacking tools ハッキング・ツール
S08 Certificate authority 認可機関
S09 Economic espionage 経済スパイ
S10 Cyber weapons サイバー兵器
S11 Surveillance tools 監視ツール
S12 Computer data コンピューター・データ
S13 Armed conflict 武力紛争
S14 Ransomware campaign ランサムウェアキャンペーン
S15 Cyber deception サイバー詐欺
S16 High seas 公海
S17 Collective responses 集団的対応
S18 Cyber operators サイバー工作員
S19 Hate speech ヘイトスピーチ
S20 Medical facilities 医療施設
S21 Misattribution  誤爆 
S22 Methods of warfare 戦争の方法
S23 Vaccine research ワクチン研究
S24 Internet blockage インターネット遮断
S25 Humanitarian assistance 人道支援
S26 Export licensing 輸出許可
S27 Redirecting attacks リダイレクト攻撃
S28 Incidental harm 偶発的被害





・2023.10.23 Cyber Law Toolkit 2024


・[PDF] Cyber Law Toolkit: Call for Submissions for the 2024 Annual Update

| | Comments (0)


NIST SP 1800-36 (初期ドラフト第2版) 信頼できるIoT機器のネットワーク層の実装とライフサイクル管理:インターネットプロトコルベースのIoT機器とネットワークのセキュリティ強化 (B,C,E)



昨年12月にA(エグゼクティブサマリー)が、今年の5月にBからEが、そして、9月末はAとDの改訂ドラフト、今回は残りのB, C, Eの改訂ドラフトですね。。。



・2023.10.31 NCCoE Releases Drafts for NIST SP 1800-36, Trusted IoT Onboarding (Vols. B, C, and E)



・2023.10.31 NIST SP 1800-36 (2nd Preliminary Draft) Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management: Enhancing Internet Protocol-Based IoT Device and Network Security

・[PDF] NIST SP 1800-36B 2prd Approach, Architecture, and Security Characteristics




1 Summary 1 概要
1.1 Challenge 1.1 課題
1.2 Solution. 1.2 解決策
1.3 Benefits  1.3 メリット 
2 How to Use This Guide  2 このガイドの使い方 
2.1 Typographic Conventions 2.1 タイポグラフィの規則
3 Approach  3 アプローチ 
3.1 Audience 3.1 想定読者
3.2 Scope 3.2 適用範囲
3.3 Assumptions and Definitions. 3.3 前提条件と定義
3.3.1 Credential Types  3.3.1 クレデンシャルタイプ 
3.3.2 Integrating Security Enhancements  3.3.2 セキュリティ強化の統合 
3.3.3 Device Limitations 3.3.3 機器の制限事項
3.3.4 Specifications Are Still Improving  3.3.4 仕様はまだ改善中
3.4 Collaborators and Their Contributions  3.4 協力者とその貢献 
3.4.1 Aruba, a Hewlett Packard Enterprise Company  3.4.1 ヒューレット・パッカード・エンタープライズ:アルーバ
3.4.2 CableLabs  3.4.2 ケーブルラボ 
3.4.3 Cisco  3.4.3 シスコ 
3.4.4 3.4.4
3.4.5 Kudelski IoT 3.4.5 クデルスキーIoT
3.4.6 NquiringMinds 3.4.6 NquiringMinds
3.4.7 NXP Semiconductors 3.4.7 NXPセミコンダクターズ
3.4.8 Open Connectivity Foundation (OCF)  3.4.8 オープン・コネクティビティ・ファンデーション(OCF) 
3.4.9 Sandelman Software Works  3.4.9 サンデルマンソフトウェアワークス 
3.4.10 SEALSQ, a subsidiary of WISeKey  3.4.10 SEALSQ:WISeKeyの子会社 
3.4.11 VaultIC405 3.4.11 VaultIC405
3.4.12 Silicon Labs. 3.4.12 シリコンラボ
4 Reference Architecture 4 リファレンス・アーキテクチャ
4.1 Device Manufacture and Factory Provisioning Process 4.1 機器の製造と工場での準備プロセス
4.2 Device Ownership and Bootstrapping Information Transfer Process  4.2 機器の所有権とブートストラップ情報転送プロセス 
4.3 Trusted Network-Layer Onboarding Process  4.3 信頼されたネットワーク層の実装プロセス 
4.4 Trusted Application-Layer Onboarding Process  4.4 信頼されたアプリケーション層の実装プロセス 
4.5 Continuous Verification  4.5 継続的検証 
5 Laboratory Physical Architecture 5 ラボ物理アーキテクチャ
5.1 Shared Environment  5.1 共有環境 
5.1.1 Domain Controller 5.1.1 ドメインコントローラ
5.1.2 Jumpbox 5.1.2 ジャンプボックス
5.2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) Physical Architecture  5.2 ビルド1(Wi-Fi Easy Connect、アルーバ/HPE)物理アーキテクチャ 
5.3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) Physical Architecture 5.3 ビルド2(Wi-Fi Easy Connect、ケーブルラボ、OCF)物理アーキテクチャ
5.4 Build 3 (BRSKI, Sandelman Software Works) Physical Architecture 5.4 ビルド3(BRSKI、Sandelman Software Works)物理アーキテクチャ
5.5 Build 4 (Thread, Silicon Labs, Kudelski IoT) Physical Architecture  5.5 ビルド4 (Thread、Silicon Labs、Kudelski IoT) 物理アーキテクチャ 
5.6 Build 5 (BRSKI, NquiringMinds) Physical Architecture 5.6 ビルド5(BRSKI、NquiringMinds) 物理アーキテクチャ
5.7 BRSKI Factory Provisioning Build Physical Architecture  5.7 BRSKI Factory 準備 ビルド 物理アーキテクチャ 
5.8 Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture 5.8 Wi-Fi Easy Connect Factory Provisioning ビルド 物理アーキテクチャ
6 General Findings  6 一般的な知見
6.1 Wi-Fi Easy Connect  6.1 Wi-Fi Easy Connect 
6.1.1 Mutual Authentication  6.1.1 相互認証 
6.1.2 Mutual Authorization  6.1.2 相互認可
6.1.3 Secure Storage 6.1.3 安全なストレージ
6.2 BRSKI  6.2 BRSKI 
6.2.1 Reliance on the Device Manufacturer 6.2.1 機器・メーカーへの依存
6.2.2 Mutual Authentication  6.2.2 相互認証 
6.2.3 Mutual Authorization  6.2.3 相互認証 
7 Future Build Considerations 7 将来の構築に関する考慮事項
7.1 Network Authentication  7.1 ネットワーク認証 
7.2 Device Intent  7.2 機器の意図 
7.3 Integration with a Lifecycle Management Service 7.3 ライフサイクル管理サービスとの統合
7.4 Network Credential Renewal  7.4 ネットワーク・クレデンシャルの更新 
7.5 Integration with Supply Chain Management Tools 7.5 サプライチェーン管理ツールとの統合
7.6 Attestation  7.6 認証 
7.7 Mutual Attestation  7.7 相互認証 
7.8 Behavioral Analysis 7.8 行動分析
7.9 Device Trustworthiness Scale 7.9 機器信頼性尺度
7.10 Resource Constrained Systems  7.10 資源制約のあるシステム 
Appendix A List of Acronyms 附属書A 略語一覧
Appendix B Glossary  附属書B 用語集 
Appendix C Build 1 (Wi-Fi Easy Connect, Aruba/HPE) 附属書C 構築1(Wi-Fi Easy Connect、アルーバ/HPE)
C.1 Technologies C.1 技術
C.2 Build 1 Architecture  C.2 ビルド 1 アーキテクチャ 
C.2.1 Build 1 Logical Architecture  C.2.1 ビルド1 論理アーキテクチャ 
C.2.2 Build 1 Physical Architecture  C.2.2 ビルド1 物理アーキテクチャ 
Appendix D Build 2 (Wi-Fi Easy Connect, CableLabs, OCF)  附属書D ビルド2(Wi-Fi Easy Connect、ケーブルラボ、OCF) 
D.1 Technologies D.1 技術
D.2 Build 2 Architecture  D.2 ビルド2 アーキテクチャ 
D.2.1 Build 2 Logical Architecture  D.2.1 ビルド2 論理アーキテクチャ 
D.2.2 Build 2 Physical Architecture  D.2.2 ビルド2 物理アーキテクチャ 
Appendix E Build 3 (BRSKI, Sandelman Software Works)  附属書E ビルド3(BRSKI、Sandelman Software Works) 
E.1 Technologies E.1 技術
E.2 Build 3 Architecture  E.2 ビルド3 アーキテクチャ 
E.2.1 Build 3 Logical Architecture  E.2.1 ビルド3 論理アーキテクチャ 
E.2.2 Build 3 Physical Architecture  E.2.2 ビルド3 物理アーキテクチャ 
Appendix F References  附属書F 参考文献 


・[PDF] NIST SP 1800-36C 2prd How-To Guides




1  Introduction 1 序文
1.1  How to Use This Guide 1.1 このガイドの使い方
1.2  Build Overview 1.2 ビルドの概要
1.2.1  Reference Architecture Summary 1.2.1 リファレンスアーキテクチャの概要
1.2.2 Physical Architecture Summary 1.2.2 物理アーキテクチャの概要
1.3 Typographic Conventions 1.3 タイポグラフィの規則
2  Build 1 (Wi-Fi Easy Connect, Aruba/HPE) 2 ビルド 1(Wi-Fi Easy Connect、アルーバ/HPE)
2.1  Aruba Central/Hewlett Packard Enterprise (HPE) Cloud 2.1 アルーバ Central/Hewlett Packard Enterprise(HPE)クラウド
2.2  Aruba Wireless Access Point 2.2 アルーバワイヤレス・アクセス・ポイント
2.2.1  Wi-Fi Network Setup/Configuration 2.2.1 Wi-Fi ネットワークの設定/構成
2.2.2  Wi-Fi Easy Connect Configuration 2.2.2 Wi-Fi Easy Connectの設定
2.3  Cisco Catalyst 3850-S Switch 2.3 Cisco Catalyst 3850-Sスイッチ
2.3.1  Configuration 2.3.1 設定
2.4  Aruba User Experience Insight (UXI) Sensor 2.4 アルーバ User Experience Insight (UXI) センサー
2.4.1  Configuration 2.4.1 構成
2.5  Raspberry Pi 2.5 Raspberry Pi
2.5.1  Configuration 2.5.1 構成
2.5.2  DPP Onboarding 2.5.2 DPP 実装
2.6  Certificate Authority 2.6 認証局
2.6.1  Private Certificate Authority 2.6.1 プライベート認証局
2.7 UXI Cloud 2.7 UXIクラウド
3  Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) 3 ビルド 2 (Wi-Fi Easy Connect、ケーブルラボ、OCF)
3.1  CableLabs Platform Controller 3.1 ケーブルラボプラットフォームコントローラ
3.1.1  Operation/Demonstration 3.1.1 操作/デモンストレーション
3.2  CableLabs Custom Connectivity Gateway 3.2 ケーブルラボカスタム接続ゲートウェイ
3.2.1  Installation/Configuration 3.2.1 インストール/設定
3.2.2  Integration with CableLabs Platform Controller 3.2.2 ケーブルラボプラットフォームコントローラーとの統合
3.2.3  Operation/Demonstration 3.2.3 操作/デモンストレーション
3.3  Reference Clients/IoT Devices 3.3 リファレンスクライアント/IoT機器
3.3.1  Installation/Configuration 3.3.1 インストール/設定
3.3.2  Operation/Demonstration 3.3.2 操作/デモンストレーション
4  Build 3 (BRSKI, Sandelman Software Works) 4 ビルド3(BRSKI、サンデルマンソフトウェアワークス)
4.1  Onboarding Router/Join Proxy 4.1 オンボード・ルーター/ジョイン・プロキシ
4.1.1  Setup and Configuration 4.1.1 セットアップと設定
4.2  Minerva Join Registrar Coordinator 4.2 Minerva Joinレジストラコーディネータ
4.2.1  Setup and Configuration 4.2.1 セットアップと設定
4.3  Reach Pledge Simulator 4.3 リーチ誓約シミュレーター
4.3.1  Setup and Configuration 4.3.1 セットアップと設定
4.4  Serial Console Server 4.4 シリアルコンソールサーバー
4.5  Minerva Highway MASA Server 4.5 Minerva Highway MASAサーバー
4.5.1  Setup and Configuration 4.5.1 セットアップと設定
4.6  IoT Devices 4.6 IoT機器
4.6.1 Setup/Installation 4.6.1 セットアップ/インストール
4.7 SEALSQ Certificate Authority 4.7 SEALSQ認証局
5  Build 4 (Thread, Silicon Labs, Kudelski IoT) 5 ビルド4(Thread、Silicon Labs、Kudelski IoT)
6  Build 5 (BRSKI, NquiringMinds) 6 ビルド 5(BRSKI、NquiringMinds)
7  Factory Provisioning Builds 7 ファクトリー・準備ビルド
Appendix A List of Acronyms 附属書 A 頭字語リスト
Appendix B References 附属書 B 参考文献



・[PDF] NIST SP 1800-36E 2prd Risk and Compliance Management




1  Introduction 1 序文
1.1  How to Use This Guide 1.1 本ガイドの使用方法
2 Risks Addressed by Trusted Network-Layer Onboarding and Lifecycle Management 2 信頼されるネットワーク層の実装とライフサイクル管理で対処されるリスク 
2.1  Risks to the Network 2.1 ネットワークに対するリスク
2.1.1  Risks to the Network Due to Device Limitations 2.1.1 機器の制限によるネットワークへのリスク
2.1.2  Risks to the Network Due to Use of Shared Network Credentials 2.1.2 共有ネットワーククレデンシャルの使用によるネットワークへのリスク
2.1.3  Risks to the Network Due to Insecure Network Credential Provisioning 2.1.3 安全でないネットワーククレデンシャルプロビジョニングによるネットワークへのリスク
2.1.4  Risks to the Network Due to Supply Chain Attacks 2.1.4 サプライチェーン攻撃によるネットワークへのリスク
2.2  Risks to the Device 2.2 機器へのリスク
2.3  Risks to Secure Lifecycle Management 2.3 安全なライフサイクルマネジメントに対するリスク
2.4  Limitations and Dependencies of Trusted Onboarding 2.4 信頼された実装の限界と依存関係
3  Mapping Use Cases, Approach, and Terminology 3 ユースケース、アプローチ、用語のマッピング
3.1  Use Cases 3.1 ユースケース
3.2  Mapping Producers 3.2 生産者のマッピング
3.3  Mapping Approach 3.3 マッピングのアプローチ
3.3.1 Mapping Terminology 3.3.1 マッピング用語
3.3.2 Mapping Process 3.3.2 マッピングプロセス
4  Mappings 4 マッピング
4.1  NIST CSF Subcategory Mappings 4.1 NIST CSF サブカテゴリーのマッピング
4.1.1  Mappings Between Reference Design Functions and NIST CSF Subcategories 4.1.1 参照設計機能と NIST CSF サブカテゴリーとの間のマッピング
4.1.2  Mappings Between Specific Onboarding Protocols and NIST CSF Subcategories 4.1.2 特定の実装・プロトコルと NIST CSF サブカテゴリーとの間のマッピング
4.1.3  Mappings Between Specific Builds and NIST CSF Subcategories 4.1.3 特定のビルドと NIST CSF サブカテゴリーとの間のマッピング
4.2  NIST SP 800-53 Control Mappings 4.2 NIST SP 800-53 コントロールマッピング
4.2.1  Mappings Between Reference Design Functions and NIST SP 800-53 Controls 4.2.1 参照設計機能と NIST SP 800-53 コントロールとの間のマッピング
4.2.2 Mappings Between Specific Onboarding Protocols and NIST SP 800-53 Controls 4.2.2 特定の実装・プロトコルと NIST SP 800-53 コントロールとの間のマッピング
4.2.3 Mappings Between Specific Builds and NIST SP 800-53 Controls 4.2.3 特定のビルドと NIST SP 800-53 コントロールとの間のマッピング
Appendix A References 附属書 A 参考文献






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

・2023.09.30 NIST SP 1800-36 (初期ドラフト第2版) 信頼できるIoTデバイスのネットワーク層オンボーディングとライフサイクル管理:インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化 (A,D)

・2023.05.07 米国 NIST SP 1800-36 (ドラフト) 信頼できるIoTデバイスのネットワーク層オンボーディングとライフサイクル管理:インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化(初期ドラフト)(2023.05.03)

・2022.12.13 NIST SP 1800-36 (ドラフト) 信頼できるIoTデバイスのネットワーク層オンボーディングとライフサイクル管理:インターネットプロトコルベースのIoTデバイスとネットワークのセキュリティ強化(初期ドラフト)(2022.12.05)


SP 800-213, NIST IR 8259関係

・2022.05.19 NIST IoTセキュリティ関連の文書についてNISTのブログで簡単に説明されていますね。。。

・2021.11.30 NIST SP 800-213 連邦政府のためのIoTデバイスサイバーセキュリティ・ガイダンス:IoTデバイスのサイバーセキュリティ要件の確立、SP 800-213A 連邦政府のためのIoTデバイスサイバーセキュリティ・ガイダンス:IoTデバイス・サイバーセキュリティ要件カタログ

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

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

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

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



・2022.01.21 NISTIR 8349(ドラフト)IoTデバイスのネットワーク動作を特徴づける方法論 at 2022.01.11



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

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

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

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

・2021.05.15 NIST White Paper ドラフト IoTデバイスセキュリティの信頼を確立するために:どうすればいいのか?

・2021.03.31 NISTIR 8333 「消費者向け家庭用IoT製品におけるサイバーセキュリティ・リスク」に関するオンラインワークショップの要旨



・2020.11.19 米国 2020年IoTサイバーセキュリティ改善法が上院を通過

・2020.10.01 米国連邦政府がIoT製品を調達するためのガイドラインの法制化が近づいている?




| | Comments (0)


米国 NSA CSI: デバイス・ピラーを通じたゼロトラスト成熟度の推進


米国の国家安全保障局 (National Security Agency: NSA) が、デバイス・ピラーを通じたゼロトラスト成熟度の推進という文書を公表していますね。。。


User ユーザー
Device デバイス
Network & Environment ネットワークと環境
Application & Workload アプリケーションとワークロード
Data データ
Automation & Orchestration 自動化とオーケストレーション
Visibility & Analytics 可視化と分析




National Security Agency: NSA


・2023.10.19 [PDF] CSI: Advancing Zero Trust Maturity Throughout the Device Pillar


・[DOCX] 仮訳



Contents  内容 
Executive summary 要旨
Introduction はじめに
Audience 想定読者
Background 背景
Device pillar デバイス・ピラー
Device inventory デバイス・インベントリ
Device detection and compliance デバイスの検出とコンプライアンス
Device authorization with real time inspection リアルタイム検査によるデバイス認証
Remote access protection リモートアクセスの保護
Automated vulnerability and patch management 自動化された脆弱性とパッチ管理
Centralized device management デバイスの集中管理
Endpoint threat detection and response エンドポイント脅威の検知と対応
Summary of guidance ガイダンスの概要
Further guidance さらなるガイダンス
Works cited 引用文献



Executive summary   要旨  
Continued cyber incidents have called attention to the immense challenges of ensuring effective cybersecurity across the federal government, as with many large enterprises, and demonstrate that “business as usual” approaches are no longer sufficient to defend the nation from cyber threats. The government can no longer depend only on traditional strategies and defenses to protect critical systems and data. [1]   継続的なサイバー事件は、多くの大企業と同様に、連邦政府全体で効果的なサイバーセキュリティを確保するための膨大な課題に注意を喚起し、サイバー脅威から国家を守るためには、もはや「通常通り」のアプローチでは不十分であることを示している。政府はもはや、重要なシステムやデータを守るための従来の戦略や防御策だけに頼ることはできない。[1]  
A modernized cybersecurity framework—Zero Trust—integrates visibility from multiple vantage points, makes risk-aware access decisions, and automates detection and response. Implementing this framework places network defenders in a better position to secure sensitive data, systems, applications, and services. [2]   最新のサイバーセキュリティ・フレームワーク「Zero Trust」は、複数の視点からの可視性を統合し、リスクを考慮したアクセス決定を行い、検知と対応を自動化する。このフレームワークを実装することで、ネットワーク防御者は、機密データ、システム、アプリケーション、およびサービスを保護するためのより良いポジションに立つことができます。[2]  
This cybersecurity information sheet (CSI) provides recommendations for maturing devices—the Zero Trust device pillar—to effectively ensure all devices seeking access earn trust based on device metadata and continual checks to determine if the device meets the organization’s minimum bar for access. The primary capabilities of the device pillar are:  このサイバーセキュリティ・インフォメーション・シート(CSI)は、アクセスを求めるすべてのデバイスが、デバイス・メタデータに基づいて信頼を獲得し、デバイスがアクセスに関する組織の最低基準を満たすかどうかを継続的にチェックすることを効果的に保証するために、デバイスを成熟させるための推奨事項(ゼロトラスト・デバイス・ピラー)を提供する。デバイス・ピラーの主な機能は以下のとおり: 
•       identification, inventory, and authentication   •         識別、在庫、認証  
•       detection of unknown devices and configuration compliance checks of known ones   •         未知のデバイスの検出と既知のデバイスの設定コンプライアンスチェック  
•       device authorization using real time inspections   •         リアルタイム検査による機器認証  
•       remote access protections   •         リモートアクセス保護  
•       hardware updates and software patches  •         ハードウェア・アップデートとソフトウェア・パッチ 
•       device management capabilities   •         デバイス管理機能  
•       endpoint detection and response for threat detection and mitigation   •         脅威の検出と緩和のためのエンドポイント検出と応答  
This CSI further discusses how these capabilities integrate into a comprehensive Zero Trust (ZT) framework, as described in Embracing a Zero Trust Security Model. [2] National Security System (NSS), Department of Defense (DoD), and Defense Industrial Base (DIB) owners and operators should use this and complementary guidance to understand how to take concrete steps for maturing device security by implementing the outlined capabilities.  この CSI は、これらの機能が、「ゼロトラスト・セキュリティ・モデルの採用」で説明されているように、包括的なゼロトラスト(Zero Trust:ZT)フレームワークにどのように統合されるかについてさらに説明する。[2] 国家安全保障システム(NSS)、国防総省(DoD)、国防産業基盤(DIB)の所有者と運用者は、このガイダンスと補完的なガイダンスを使用して、概説された機能を実装することで、デバイスのセキュリティを成熟させるための具体的な手順をどのように取るかを理解する必要がある。 




・2023.04.03 [PDF] CSI: Advancing Zero Trust Maturity throughout the User Pillar (April 2023 Update)




| | Comments (0)


経済産業省 「インド太平洋地域向け日米EU産業制御システムサイバーセキュリティウィーク」を実施 (2023.10.16)


経済産業省と、(独)情報処理推進機構(IPA)産業サイバーセキュリティセンター(ICSCoE) が、米国政府(CISA、国務省)及びEU政府(通信ネットワーク・コンテンツ・技術総局)と連携して、2023.10.09-13で、日米EUの専門家による制御システムのサイバーセキュリティに関するイベントを東京で開催したようですね。。。インド太平洋地域から招聘した35名の政府機関・産業界の実務者がハンズオン演習及び専門家によるサイバーセキュリティセミナーに参加したようです。




・2023.10.16 インド太平洋地域向け日米EU産業制御システムサイバーセキュリティウィーク」を実施しました

| | Comments (0)

NIST IR 8473 電気自動車の超高速充電インフラ向けサイバーセキュリティフレームワークプロファイル


NISTが電気自動車の超高速充電インフラに対してサイバーセキュリティフレームワークを適用する場合のガイダンスを公表していますね。。 。7月にパブコメに出してからわりと早めの公開ですね。。。。




・2023.10.16 NIST IR 8473 Cybersecurity Framework Profile for Electric Vehicle Extreme Fast Charging Infrastructure

NIST IR 8473 Cybersecurity Framework Profile for Electric Vehicle Extreme Fast Charging Infrastructure NIST IR 8473 電気自動車の急速充電インフラ向けサイバーセキュリティフレームワークプロファイル
Abstract 概要
This document is the Cybersecurity Framework Profile (Profile) developed for the Electric Vehicle Extreme Fast Charging (EV/XFC) ecosystem and the subsidiary functions that support each of the four domains: (i) Electric Vehicles (EV); (ii) Extreme Fast Charging (XFC); (iii) XFC Cloud or Third-Party Operations; (iv) and Utility and Building Networks. This Profile provides a foundational profile that relevant parties may use to develop profiles specific to their organization to assess their cybersecurity posture as a part of their risk management process. The profile is intended to supplement, not replace, an existing risk management program or the current cybersecurity standards, regulations, and industry guidelines that are in current use by the EV/XFC industry. 本書は、電気自動車(EV/XFC)エコシステムと、(i)電気自動車(EV)、(ii)超高速充電(XFC)、(iii)XFC クラウドまたはサードパーティの運用、(iv)ユーティリティと建物のネットワークという 4 つのドメインのそれぞれをサポートする補助的な機能のために開発されたサイバーセキュリティ・フレームワーク・プロファイル(プロファイル)である。このプロファイルは、リスク管理プロセスの一環としてサイバーセキュリティ態勢を評価するために、関係者が各組織固有のプロファイルを作成するために使用できる基礎的なプロファイルを提供するものである。本プロファイルは、既存のリスク管理プログラムや、EV/XFC 業界で現在使用されているサイバーセキュリティ基準、規制、業界ガイドラインを補完するものであり、置き換えるものではない。


・[PDF] NIST.IR.8473






1. Introduction 1. 序文
1.1. Purpose 1.1. 目的
1.2. Scope 1.2. 適用範囲
1.3. Audience 1.3. 想定読者
2. Intended Use 2. 使用目的
3. EV/XFC Cybersecurity Mission Objectives 3. EV/XFC サイバーセキュリティのミッション目標
3.1. Mission Objective 1: Deliver Reliable Performance through Secure Communications 3.1. ミッション目標1:セキュアなコミュニケーションを通じて信頼できるパフォーマンスを提供する。
3.2. Mission Objective 2: Maintain Resilience of the XFC Infrastructure 3.2. ミッション目標2:XFCインフラのレジリエンスを維持する
3.3. Mission Objective 3: Build and Maintain Trustworthy Relationships with Partners and Customers 3.3. ミッション目標3:パートナーおよび顧客との信頼関係の構築と維持
3.4. Mission Objective 4: Maintain Continuity of Operations 3.4. ミッション目標4:業務の継続性を維持する
4. Overview of the Cybersecurity Framework 4. サイバーセキュリティフレームワークの概要
4.1. The Framework Core 4.1. フレームワークの中核
4.2. Sector-Level Profiles 4.2. セクター・レベルのプロファイル
5. XFC Baseline Profile 5. XFCベースラインプロファイル
5.1. Identify Function 5.1. 機能の識別
5.1.1. Asset Management Category 5.1.1. 資産管理カテゴリー
5.1.2. Business Environment Category 5.1.2. ビジネス環境カテゴリー
5.1.3. Governance Category 5.1.3. ガバナンス・カテゴリー
5.1.4. Risk Assessment Category 5.1.4. リスクアセスメント カテゴリー
5.1.5. Risk Management Category 5.1.5. リスクマネジメントカテゴリー
5.1.6. Supply Chain Risk Management Category 5.1.6. サプライチェーンリスクマネジメントカテゴリー
5.2. Protect Function Considerations Across the EV/XFC Domains 5.2. EV/XFC領域にわたる防御機能の考慮事項
5.2.1. Identity Management, Authentication and Access Control Category 5.2.1. アイデンティティ管理、認証/アクセス制御カテゴリー
5.2.2. Awareness and Training Category 5.2.2. 意識向上およびトレーニングカテゴリー
5.2.3. Data Security Category 5.2.3. データセキュリティカテゴリー
5.2.4. Information Protection and Processes Category 5.2.4. 情報防御とプロセスカテゴリー
5.2.5. Maintenance Category 5.2.5. 保守カテゴリー
5.2.6. Protective Technology Category 5.2.6. 保護技術カテゴリー
5.3. Detect Function Considerations Across the EV/XFC Domains 5.3. EV/XFC領域にわたる検知機能の検討
5.3.1. Anomalies and Events 5.3.1. 異常とイベント
5.3.2. Security Continuous Monitoring 5.3.2. セキュリティの継続的なモニタリング
5.3.3. Detection Processes 5.3.3. 検知プロセス
5.4. Respond Function Considerations Across the EV/XFC Domains 5.4. EV/XFCドメイン間での対応機能の考慮事項
5.4.1. Analysis 5.4.1. 分析
5.4.2. Communications 5.4.2. コミュニケーション
5.4.3. Improvements Category 5.4.3. 改善カテゴリー
5.4.4. Mitigation 5.4.4. 低減
5.4.5. Response Planning 5.4.5. 対応計画
5.5. Recover Function Considerations Across the EV/XFC Domains 5.5. EV/XFCドメイン間での機能回復に関する考慮事項
5.5.1. Communications 5.5.1. コミュニケーション
5.5.2. Improvements 5.5.2. 改善
5.5.3. Recovery Planning 5.5.3. 復旧計画
References 参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms 附属書A. 記号、略語、頭字語のリスト




・2023.10.16 Final NIST Internal Report (NIST IR) 8473, Cybersecurity Framework Profile for Electric Vehicle Extreme Fast Charging Infrastructure

Final NIST Internal Report (NIST IR) 8473, Cybersecurity Framework Profile for Electric Vehicle Extreme Fast Charging Infrastructure 最終NIST内部報告書(NIST IR)8473「電気自動車超高速充電インフラ向けサイバーセキュリティ・フレームワーク・プロファイル
Overview 概要
This Profile is designed to be part of an enterprise risk management program to aid organizations in managing threats to systems, networks, and assets within the Electric Vehicle Extreme Fast Charging Infrastructure (EV/XFC) ecosystem (it is not intended to serve as a solution or compliance checklist). このプロファイルは、電気自動車(EV/XFC)エコシステム内のシステム、ネットワーク、資産に対する脅威を管理する組織を支援するための企業リスク管理プログラムの一部として設計されている(ソリューションやコンプライアンスチェックリストとして機能することを意図していない)。
The Profile is an application of the Framework Categories and Subcategories in the context of the EV/XFC cybersecurity ecosystem, as provided by the Department of Energy and Electric Power Research Institute. It is a non-regulatory, voluntary profile intended to supplement—not replace—an existing risk management program or the current cybersecurity standards, regulations, and industry guidelines that are in current use by the EV/XFC industry. このプロファイルは、エネルギー省と電力研究所(Electric Power Research Institute)が提供するフレームワークのカテゴリーとサブカテゴリーをEV/XFCのサイバーセキュリティエコシステムに適用したものである。このプロファイルは、既存のリスク管理プログラムや、EV/XFC 業界で現在使用されているサイバーセキュリティ基準、規制、業界ガイドラインを代替するのではなく、補完することを目的とした、規制のない自主的なプロファイルである。
The Profile also provides ecosystem-relevant parties with a means to assess and communicate their cybersecurity posture in a manner consistent with the Framework. It also offers users with an industry level risk-based approach for managing cybersecurity activities and facilitates cross-collaboration between industry parties, vendors, and end users. また、このプロファイルは、エコシステムに関連する当事者に対して、フレームワークと整合的な方法でサイバーセキュリティ態勢を評価し、伝達する手段を提供する。また、サイバーセキュリティ活動を管理するための業界レベルのリスクベースのアプローチをユーザーに提供し、業界関係者、ベンダー、エンドユーザー間の相互協力を促進する。
Use of the Profile will help organizations: このプロファイルを利用することで、組織は以下のようなことが可能になる:
・Identify key assets and interfaces in each of the ecosystem domains.< ・エコシステムの各ドメインにおける主要な資産とインタフェースを特定する。
・Address cybersecurity risk in the management and use of EV/XFC services.< ・EV/XFCサービスの管理と利用におけるサイバーセキュリティリスクに対処する。
・Identify the threats, vulnerabilities, and associated risks to EV/XFC services, equipment, and data. ・EV/XFCサービス、機器、データに対する脅威、脆弱性、関連リスクを特定する。
・Apply protection mechanisms to reduce risk to manageable levels. ・管理可能なレベルまでリスクを低減するための保護メカニズムを適用する。
・Detect disruptions and manipulation of EV/XFC services. ・EV/XFCサービスの中断や操作を検知する。
・Respond to and recover from EV/XFC service anomalies in a timely, effective, and resilient manner. ・EV/XFCサービスの異常に対して、タイムリーかつ効果的で回復力のある方法で対応し、回復する。
What changed from the draft to final Profile? ドラフトから最終版へ何が変わったのか?
We received over 220 public comments on the draft Profile. Based on the input received, a few major changes from the draft to final Profile include: プロファイル草案に対して220件を超えるパブリックコメントが寄せられた。寄せられた意見に基づき、草案から最終版への主な変更点は以下の通りである:
・Added additional informative references for applicable subcategories, including: NIST Special Publication (SP) 800-207 Zero Trust Architecture, International Organization for Standardization (ISO) ISO/SAE 21434, and International Organization for Standardization (ISO) 24089. ・該当するサブカテゴリの参考文献を追加した: NIST Special Publication (SP) 800-207 Zero Trust Architecture、International Organization for Standardization (ISO) ISO/SAE 21434、International Organization for Standardization (ISO) 24089 を含む。
・Added acknowledgements for individual contributors from the COI and public comment period. ・COIおよびパブリックコメント期間からの個々の貢献者に対する謝辞を追加した。
・Updated content in the subcategories to better articulate relevancy to specific domains within the EV/XFC ecosystem. ・EV/XFCエコシステム内の特定領域との関連性をより明確にするため、サブカテゴリの内容を更新した。
・Updated front matter language to represent the rapid growth of EV vehicles globally. ・世界的なEV車の急成長を表現するために、フロントマターの文言を更新した。




Series Number Title Status Release Date
NISTIR 8473 Cybersecurity Framework Profile for Electric Vehicle Extreme Fast Charging Infrastructure Final 10/16/2023
Download: NISTIR 8473 (DOI)Local DownloadProject homepage
NISTIR 8467 Cybersecurity Framework Profile for Genomic Data Draft 06/15/2023
DDownload: NISTIR 8467 (Draft) (DOI)Local DownloadComment templateProject homepage
NISTIR 8406 Cybersecurity Framework Profile for Liquefied Natural Gas Final 10/10/2023
Download: NISTIR 8406 (DOI)Local DownloadProject homepage
NISTIR 8441 Cybersecurity Framework Profile for Hybrid Satellite Networks (HSN) Final 09/25/2023
Download: NISTIR 8441 (DOI)Local DownloadProject homepage
NISTIR 8323 Rev. 1 Foundational PNT Profile: Applying the Cybersecurity Framework for the Responsible Use of Positioning, Navigation, and Timing (PNT) Services Final 1/31/2023
Download: NISTIR 8323 Rev. 1 (DOI); Local Download; Comments received on public draft; PNT homepage
White Paper NIST CSWP 27 Cybersecurity Framework Profile for Hybrid Satellite Networks (HSN): Final Annotated Outline Final 11/03/2022
Download: White Paper (DOI)NIST CSWP 27Project homepage
NISTIR 8323 Foundational PNT Profile: Applying the Cybersecurity Framework for the Responsible Use of Positioning, Navigation, and Timing (PNT) Services Final 02/11/2021
Download: NISTIR 8323 (DOI)Local DownloadPNT Profile Quick GuideNIST news articlePNT homepage




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

・2023.10.16 NIST NISTIR 8406 液化天然ガス向けサイバーセキュリティフレームワークプロファイル(更新)

・2023.09.26 NIST IR 8441 ハイブリッド衛星ネットワーク(HSN)のサイバーセキュリティ・フレームワーク・プロファイル

・2023.07.19 NIST NISTIR 8473(ドラフト)電気自動車の超高速充電インフラのためのサイバーセキュリティフレームワークプロファイル

・2023.06.24 NIST NISTIR 8467(ドラフト)ゲノムデータのサイバーセキュリティフレームワーク・プロファイル

・2023.06.11 NIST NISTIR 8406 液化天然ガス向けサイバーセキュリティフレームワークプロファイル

・2023.06.10 NIST NISTIR 8441(ドラフト)ハイブリッド衛星ネットワークのためのサイバーセキュリティフレームワークプロファイル (2023.06.06)

・2023.03.05 NISTIR 8432(ドラフト) ゲノムデータのサイバーセキュリティ

・2022.11.06 NIST ホワイトペーパー NIST CSWP 27:ハイブリッド衛星ネットワーク (HSN) 用サイバーセキュリティ・フレームワーク・プロファイル:注釈付きアウトライン最終版

・2022.10.25 NIST NISTIR 8406 (ドラフト) 液化天然ガス向けサイバーセキュリティフレームワークプロファイル (2022.10.17)

・2021.09.10 NISTIR 8374 (Draft) ランサムウェア・リスク管理のためのサイバーセキュリティ・フレームワーク・プロファイル

・2021.06.11 NISTIR 8374 (Draft) ランサムウェア・リスク管理のためのサイバーセキュリティ・フレームワーク・プロファイル(初期ドラフト)



| | Comments (0)


NIST NISTIR 8406 液化天然ガス向けサイバーセキュリティフレームワークプロファイル(更新)


NISTが、NISTIR 8406 液化天然ガス向けサイバーセキュリティフレームワークプロファイルの一部※を更新していますね。。。


※ 更新箇所

「7.1. サイバーセキュリティフレームワークサブカテゴリーの優先順位表」の情報を表25として再統合した。この表の情報は、本報告書の最初の公開草案の表13に掲載されていたが、最終版では省略されていた。




・2023.10.10 NISTIR 8406 Cybersecurity Framework Profile for Liquefied Natural Gas

NISTIR 8406 Cybersecurity Framework Profile for Liquefied Natural Gas NISTIR 8406 液化天然ガス向けサイバーセキュリティフレームワークプロファイル
Abstract 概要
This document is the Cybersecurity Framework Profile developed for the Liquefied Natural Gas (LNG) industry and the subsidiary functions that support the overarching liquefaction process, transport, and distribution of LNG. The LNG Cybersecurity Framework Profile can be used by liquefaction facilities, LNG vessels, and other supporting entities of the LNG lifecycle so that cybersecurity risks associated with these critical processes and systems can be minimized. The LNG Profile provides a voluntary, risk-based approach for managing cybersecurity activities and reducing cyber risk to the overall LNG process. The Cybersecurity Framework LNG Profile is meant to supplement but not replace current cybersecurity standards, regulations, and industry guidelines that are already being used by the Liquefied Natural Gas industry. 本書は、液化天然ガス(LNG)産業と、LNGの液化プロセス、輸送、流通を包括的に支援する補助的な機能のために開発されたサイバーセキュリティフレームワークプロファイルである。LNGサイバーセキュリティフレームワークプロファイルは、液化施設、LNG船、およびLNGライフサイクルを支える他の事業体が使用することができ、これらの重要なプロセスやシステムに関連するサイバーセキュリティリスクを最小化することができるようにする。LNGプロファイルは、サイバーセキュリティ活動をマネジメントし、LNGプロセス全体に対するサイバーリスクを低減するための自主的でリスクベースのアプローチを提供する。サイバーセキュリティフレームワーク LNG プロファイルは、液化天然ガス業界で既に使用されている現行のサイバーセキュリティ基準、規制、および業界ガイドラインを補完することを意図しているが、それに代わるものではない。


・[PDF] NISTIR 8406 upd1




1. Introduction 1. 序文
1.1.  Purpose and Scope 1.1. 目的及び範囲
1.1.Audience 1.1. 想定読者
1.2. Document Structure 1.2. 文書構成
2. The Liquefied Natural Gas Industry 2. 液化天然ガス産業
2.1.  Liquefied Natural Gas 2.1.  液化天然ガス
2.2.  Components of the Liquefied Natural Gas Industry 2.2.  液化天然ガス産業の構成要素
 2.2.1. Liquefaction Facilities  2.2.1. 液化設備
 2.2.2. Liquefied Natural Gas Vessels and the Marine Transportation System  2.2.2. 液化天然ガス船と海上輸送システム
 2.2.3. Liquefied Natural Gas LNG Export and Import Terminals  2.2.3. 液化天然ガスLNG輸出入ターミナル
2.3.  Liquefied Natural Gas Safety 2.3.  液化天然ガスの安全性
3. Overview of the Cybersecurity Framework 3. サイバーセキュリティフレームワークの概要
3.1. The Cybersecurity Framework Core 3.1. サイバーセキュリティフレームワークの中核
3.2. Cybersecurity Framework Profiles 3.2. サイバーセキュリティフレームワーク・プロファイル
4. Cybersecurity Profile Development Methodology 4. サイバーセキュリティプロファイル開発手法
4.1. Stakeholder Workshops 4.1. ステークホルダーワークショップ
 4.1.1. Workshop 1: Establishing Mission Objectives  4.1.1. ワークショップ 1:ミッション目標の設定
 4.1.2. Workshop 2: Prioritizing Mission Objectives  4.1.2. ワークショップ 2:ミッション目標の優先順位付け
 4.1.3. Workshop 3: Prioritizing CSF Categories for Mission Objectives  4.1.3. ワークショップ 3: ミッション目標のCSF分類の優先順位付け
4.2. Subcategory Scoring 4.2. サブカテゴリのスコアリング
5. Marine Transportation System Liquefied Natural Gas Mission Objectives 5. 海上輸送システム液化天然ガスミッション目標
5.1. Mission Objective-1: Maintain Safe and Secure Operations 5.1. ミッション目標-1: 安全・安心な操業の維持
5.2. Mission Objective-2: Ensure Operational Integrity of Plant Systems and Processes 5.2. ミッション目標-2: プラントのシステム及びプロセスの操作上の完全性を確保すること
5.3. Mission Objective-3: Control Operational and Enterprise Security and Access 5.3. ミッション目標-3: 運用上及びエンタープライズ上のセキュリティとアクセスを管理する。
5.4. Mission Objective-4: Monitor, Detect, and Respond to Anomalous Behavior 5.4. ミッション目標-4: 異常な動作の監視、検出、及び対応
5.5. Mission Objective-5: Safeguard the Environment 5.5. ミッション目標-5: 環境の保護
5.6. Mission Objective-6: Define Policy and Governance Actions that Capture/Protect the Mission 5.6. ミッション目標-6: ミッション目標を達成し、保護するための方針とガバナンスの明確化
5.7. Mission Objective-7: Maintain Regulatory Compliance 5.7. ミッション目標-7: 法規制の遵守の維持
5.8. Mission Objective-8: Continuously Optimize and Maintain Current Operational State by Establishing Baselines and Measures 5.8. ミッション目標-8: ベースライン及び手段を確立することによる、現在の運用状態の継続的な最適化及び維持
5.9. Mission Objective-9: Validate and Optimize the Supply Chain 5.9. ミッション目標-9: サプライチェーンの検証と最適化
6. Category Prioritization Summary 6. カテゴリーの優先順位付けの概要
6.1. Prioritized Cybersecurity Framework Categories by Mission Objective 6.1. サイバーセキュリティフレームワークのミッション目標別優先順位付けカテゴリー
6.2. Summary Table 6.2. 総括表
7. Priority Cybersecurity Framework Subcategories by Mission Objective 7. ミッション目的別優先順位付けされたサイバーセキュリティフレームワークのサブカテゴリー
7.1. Cybersecurity Framework Subcategory Priority Chart 7.1. サイバーセキュリティフレームワークサブカテゴリーの優先順位表
7.2. Subcategory Implementation Considerations 7.2. サブカテゴリの実装に関する検討事項
References 参考文献
Appendix A.  List of Symbols, Abbreviations, and Acronyms 附属書A. 記号、略語、および頭字語のリスト
Appendix B.  Glossary 附属書B. 用語集
Appendix C. Change Log 附属書C. 変更履歴








・2023.06.11 NIST NISTIR 8406 液化天然ガス向けサイバーセキュリティフレームワークプロファイル

・2022.10.25 NIST NISTIR 8406 (ドラフト) 液化天然ガス向けサイバーセキュリティフレームワークプロファイル (2022.10.17)



| | Comments (0)


米国 CISA FBI NSA DOT 運用技術 (OT) および産業制御システム (ICS) におけるオープンソースソフトウェアのセキュリティ向上


米国のサイバーセキュリティ・インフラ・セキュリティ局(CISA)、連邦捜査局(FBI)、国家安全保障局(NSA)、米国財務省 (DOT) が、運用技術(OT)ベンダーや重要インフラ施設の上級指導者や運用担当者向けに、運用技術 (OT) および産業制御システム (ICS) におけるオープンソースソフトウェアのセキュリティ向上についてのファクトシートを公表していますね。。。


・2023.10.10 CISA, FBI, NSA, and Treasury Release Guidance on OSS in IT/ICS Environments

CISA, FBI, NSA, and Treasury Release Guidance on OSS in IT/ICS Environments CISA、FBI、NSA、財務省がIT/ICS環境におけるOSSに関するガイダンスを発表
Today, CISA, the Federal Bureau of Investigation, the National Security Agency, and the U.S. Department of the Treasury released guidance on improving the security of open source software (OSS) in operational technology (OT) and industrial control systems (ICS). In alignment with CISA’s recently released Open Source Security Roadmap, the guidance provides recommendations to OT/ICS organizations on: 本日、CISA、連邦捜査局(FBI)、国家安全保障局(NSA)、米国財務省は、運用技術(OT)および産業制御システム(ICS)におけるオープンソースソフトウェア(OSS)のセキュリティ向上に関するガイダンスを発表した。CISAが最近発表したオープンソース・セキュリティ・ロードマップに沿って、このガイダンスはOT/ICS組織に対し、以下の事項を推奨している:
・Supporting OSS development and maintenance, ・OSSの開発・保守の支援
・Managing and patching vulnerabilities in OT/ICS environments, and ・OT/ICS環境における脆弱性管理とパッチ適用
・Using the Cross-Sector Cybersecurity Performance Goals (CPGs) as a common framework for adopting key cybersecurity best practices in relation to OSS. ・OSSに関連する主要なサイバーセキュリティのベストプラクティスを採用するための共通フレームワークとして、クロスセクター・サイバーセキュリティ・パフォーマンス・ゴール(CPG)を使用する。
Alongside the guidance, CISA published the Securing OSS in OT web page, which details the Joint Cyber Defense Collaborative (JCDC) OSS planning initiative, a priority within the JCDC 2023 Planning Agenda. The initiative will support collaboration between the public and private sectors—including the OSS community—to better understand and secure OSS use in OT/ICS, which will strengthen defense against OT/ICS cyber threats.    このガイダンスと並行して、CISAはJoint Cyber Defense Collaborative (JCDC) OSS planning initiativeの詳細を記したSecuring OSS in OTのウェブページを公開した。このイニシアチブは、OT/ICSにおけるOSSの利用をよりよく理解し、安全性を確保するために、OSSコミュニティを含む官民セクター間の協力を支援するもので、OT/ICSのサイバー脅威に対する防御を強化する。  
CISA encourages OT/ICS organizations to review this guidance and implement its recommendations. CISAは、OT/ICS組織がこのガイダンスを検討し、その勧告を実施することを奨励する。





Improving Security of Open Source Software in Operational Technology and Industrial Control Systems 運用技術 (OT) および産業制御システム (ICS) におけるオープンソースソフトウェアのセキュリティ向上
The Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI), National Security Agency (NSA), and U.S. Department of the Treasury are releasing this fact sheet for senior leadership and operations personnel at operational technology (OT) vendors and critical infrastructure facilities. This fact sheet will assist with better management of risk from OSS use in OT products and increase resilience using available resources. While several resources and recommendations within this fact sheet are best suited for execution by the vendor or the critical infrastructure owner, collaboration across parties will result in less friction for operator workflows and promote a safer, more reliable system and provision of National Critical Functions.  サイバーセキュリティ・インフラ・セキュリティ局(CISA)、連邦捜査局(FBI)、国家安全保障局(NSA)、米国財務省は、運用技術(OT)ベンダーや重要インフラ施設の上級指導者や運用担当者向けに、このファクトシートを公表する。このファクトシートは、OT製品におけるOSSの利用によるリスクをより適切に管理し、利用可能なリソースを利用してレジリエンスを高めることを支援するものである。このファクトシート内のいくつかのリソースと推奨事項は、ベンダーまたは重要インフラ所有者による実行に最適であるが、関係者間の協力により、オペレータのワークフローに対する摩擦が少なくなり、より安全で信頼性の高いシステムと国家重要機能の提供が促進される。
This fact sheet aims to:  このファクトシートの目的は以下のとおりである: 
• Promote the understanding of open source software (OSS) and its implementation in OT and industrial control systems (ICS) environments (hereinafter referred to as “OT”).  ・オープンソースソフトウェア(OSS)の理解と、OTおよび産業制御システム(ICS)環境(以下「OT」という。)におけるその実装を促進する。
• Highlight best practices and considerations for the secure use of OSS in OT.  ・OT における OSS の安全な使用のためのベスト・プラクティスと考慮事項を強調する。
CISA’s OSS Initiative  CISAのOSSイニシアチブ 
In 2023, CISA’s Joint Cyber Defense Collaborative (JCDC) initiated a collaborative planning effort to support the awareness, security, and cyber resiliency of OSS in critical infrastructure OT. This effort is one of the priority initiatives within the JCDC 2023 Planning Agenda, which consists of contributions from JCDC participants, including industry partners and representatives from OSS foundations. Consistent with JCDC’s approach to bringing together public and private partners in development of joint cyber defense plans, this fact sheet benefitted from input by industry contributors, including Accenture, Claroty, Dragos, Fortinet, Google, Honeywell, Microsoft, Nozomi Networks, NumFOCUS, OpenSSF / Linux Foundation, Rockwell Automation, Rust Foundation, Schneider Electric, Schweitzer Engineering Laboratories, Siemens, and Xylem. Organizations can reference the Securing Open Source Software in Operational Technology web page for an overview of the OSS planning initiative, goals, and additional deliverables.  2023年、CISAのサイバー防衛共同体(JCDC)は、重要インフラOTにおけるOSSの認識、セキュリティ、サイバー回復力を支援するための共同計画作業を開始した。この取り組みは、JCDC 2023計画アジェンダの中の優先課題の一つであり、業界パートナーやOSS財団の代表者を含むJCDC参加者からの貢献で構成されている。共同サイバー防衛計画の策定において官民のパートナーを結集するという JCDC のアプローチに基づき、このファクトシートは、アクセンチュア、クラロティ、ドラゴス、フォーティネット、グーグル、ハネウェル、マイクロソフト、のぞみネットワークス、NumFOCUS、OpenSSF / Linux Foundation、ロックウェル・オートメーション、ラスト・ファウンデーション、シュナイダーエレクトリック、シュバイツァー・エンジニアリング研究所、シーメンス、ザイレムを含む産業界の貢献者の意見を参考にした。各組織は、OSS計画イニシアチブの概要、目標、およびその他の成果物について、運用技術におけるオープンソースソフトウェアの安全確保に関するウェブページを参照することができる。
CISA recognizes the benefits of open source software in enabling software developers to work at an accelerated pace and fostering significant innovation and collaboration. With these benefits in mind, this planning effort complements the CISA Open Source Software Security Roadmap, which defines how CISA will work to enable the secure use and development of open source software, both within and outside of the federal government.  CISAは、ソフトウェア開発者が加速度的に作業できるようにし、重要なイノベーションとコラボレーションを促進するオープンソースソフトウェアの利点を認識している。こうした利点を念頭に、この計画策定作業は、連邦政府内外でオープン・ソース・ソフトウェアの安全な使用と開発を可能にするためにCISAがどのように取り組むかを定義したCISAオープン・ソース・ソフトウェア・セキュリティ・ロードマップを補完するものである。
SAFETY AS A PRIORITY  優先事項としての安全性 
In OT, both cybersecurity and safety concerns are heightened due to the potentially far-reaching impacts of incidents and associated life safety implications, specifically to connected infrastructure. Widely accepted cyber hygiene practices, such as updating software in IT systems when a patch for a vulnerability is available, may be challenging when an underlying OSS library needs to be updated. Updating software in OT may be additionally challenging because of the potential adverse effects on other (dependent) software and potential operational risks. Implementing “secure-by-design” and “default” approaches can help decrease these cybersecurity and safety risks in OT. OT において、サイバーセキュリティと安全性の両方に対する懸念は、特に接続されたインフラに対するインシデントと関連する生活安全への影響が広範囲に及ぶ可能性があるため、高まっている。脆弱性に対するパッチが利用可能になったときに IT システムのソフトウェアを更新するような、広く受け入れられているサイバー衛生慣行は、基礎となる OSS ライブラリを更新する必要がある場合には困難な場合がある。OTのソフトウェアの更新は、他の(依存する)ソフトウェアへの潜在的な悪影響や潜在的な運用リスクのために、さらに困難な場合がある。セキュア・バイ・デザイン」と「デフォルト」のアプローチを導入することで、OTにおけるこれらのサイバーセキュリティと安全のリスクを低減することができる。
Open Source Software in Operational Technology  運用技術におけるオープンソースソフトウェア 
Open source software[1]—often referred to as OSS—is software with an open license for anyone to view, use, study, or modify, and is distributed with its source code. Source code is the human-readable formal language that software developers use to specify the actions a computer will take. OSS serves as an example of open collaboration among many parties and is available for use, modification, and distribution. Among other benefits, OSS allows organizations with similar software needs to share progress, reduce overhead, and scale innovation. In contrast to OSS, closed source (proprietary) software refers to software that is developed, tested, and managed close hold. Proprietary software will also include valid, authenticated licenses for users using the software, which often come with restrictions. It is common for closed source software and security tools to make use of OSS. Much of the infrastructure and tools used to develop, build, and install a closed source software project contain OSS as well.  オープン・ソース・ソフトウェア[1]-しばしばOSSと呼ばれる-は、誰でも閲覧、使用、研究、修正できるオープン・ライセンスのソフトウェアであり、ソース・コードとともに配布される。ソースコードとは、ソフトウェア開発者がコンピュータが実行する動作を指定するために使用する、人間が読める形式言語のことである。OSSは、多くの関係者によるオープンなコラボレーションの例として機能し、使用、変更、配布が可能である。他の利点の中でも、OSSは、同じようなソフトウェア・ニーズを持つ組織が進捗を共有し、オーバーヘッドを削減し、イノベーションを拡大することを可能にする。OSSとは対照的に、クローズドソース(プロプライエタリ)ソフトウェアとは、開発、テスト、管理が密に行われたソフトウェアを指す。プロプライエタリ・ソフトウェアには、そのソフトウェアを使用するユーザーに対して有効で認証されたライセンスも含まれるが、これには制約が伴うことが多い。クローズドソースソフトウェアやセキュリティツールは、OSSを利用するのが一般的である。クローズドソースソフトウェアプロジェクトの開発、ビルド、インストールに使われるインフラやツールの多くもOSSを含んでいる。
OT[2] is defined as the hardware, software, and firmware components of a system used to detect or cause changes in physical processes through the direct control and monitoring of industrial equipment, assets, processes, and events. While often interchangeable with OT, ICS[3] are a subset of OT where networks are comprised of information systems that control industrial processes, such as manufacturing, product handling, production, and distribution. The diverse way OSS can be integrated into OT products can make it difficult to know whether certain software modules, and their associated vulnerabilities, are present and/or exploitable. Additional challenges include an overall minimized opportunity to patch and increased aversion to new variables added into production environments because of the often stringent uptime requirements for OT environments.  OT[2]は、産業機器、資産、プロセス、およびイベントの直接的な制御と監視を通じて、物理的なプロセスの変化を検出または引き起こすために使用されるシステムのハードウェア、ソフトウェア、およびファームウェアのコンポーネントとして定義される。OTとしばしば互換性があるが、ICS[3]はOTのサブセットであり、ネットワークは、製造、製品ハンドリング、生産、流通などの産業プロセスを制御する情報システムで構成されている。OSSがOT製品に統合される方法は多様であるため、特定のソフトウェアモジュールとそれに関連する脆弱性が存在するかどうか、および/または悪用可能かどうかを知ることは困難である。さらに、OT環境には厳しい稼働時間が要求されることが多いため、パッチを当てる機会が全体的に少なくなり、生産環境に追加される新たな変数に対する嫌悪感が高まるという課題もある。
Software Security Challenges  ソフトウェア・セキュリティの課題 
Security is a critical step at every phase of lifecycle management for both OSS and OT software on all systems. Some considerations are especially relevant or challenging due to features existing at the intersection of managing OSS and OT software. Examples of security concerns that OSS and OT share with all software systems include:  セキュリティは、あらゆるシステムのOSSとOTソフトウェアのライフサイクル管理のあらゆる段階で重要なステップである。OSSとOTソフトウェアを管理する交差点に存在する機能により、特に関連性が高く、困難な考慮事項もある。OSS と OT がすべてのソフトウェアシステムと共有するセキュリティ上の懸念の例には、以下が含まれる: 
• Dependency vulnerabilities. Software often relies on other libraries and components. If these dependencies have vulnerabilities, they can introduce (cyber) risks into the software.  ・依存関係の脆弱性。ソフトウェアは、しばしば他のライブラリやコンポーネントに依存する。これらの依存関係に脆弱性がある場合、ソフトウェアに(サイバー)リスクをもたらす可能性がある。
• Lack of commercial support. Many software packages come with limited or no service agreements to actively monitor components and manage vulnerabilities, or the expected useful lifetime of products is longer than the software service agreement. Being outside of a support window makes patching vulnerabilities extremely challenging. Open source software licenses typically provide the software without any warranty and disclaim all responsibility; commercial organizations often provide support for a fee.  ・商用サポートの欠如。多くのソフトウェアパッケージには、コンポーネントを積極的に監視し、脆弱性を管理するためのサービス契約が限定的であるか、全くない。サポート期間外であるため、脆弱性へのパッチ適用が極めて困難となる。オープンソースソフトウェアのライセンスは、通常、保証なしでソフトウェアを提供し、すべての責任を放棄する。商用組織は、有償でサポートを提供することが多い。
• Inadequate documentation. Insufficiently documented software can be difficult for users to understand and use securely.  ・不十分な文書。文書化が不十分なソフトウェアは、ユーザーが理解し、安全に使用することが難しくなる。
OT may theoretically be considered mutable infrastructure—capable of being updated following deployment—but in practice is often treated as immutable infrastructure and rarely maintained or upgraded. Some hardware or controllers may be immutable, but the software and data on them, including OSS, is mutable. Ideally governed by good change management, software can be entirely replaced, changed, or upgraded at any time. However, in practice this is not always feasible due to the change management policies and safety regulations surrounding the introduction of new, updated code to a product.  OTは、理論的には、配備後に更新可能な、変更可能なインフラとみなされるかもしれないが、実際には、不変のインフラとして扱われることが多く、保守やアップグレードが行われることはほとんどない。一部のハードウェアやコントローラは不変かもしれないが、OSSを含め、その上のソフトウェアやデータは変更可能である。理想的には、優れた変更管理によって管理され、ソフトウェアはいつでも完全に交換、変更、アップグレードできる。しかし実際には、製品への新しい更新コードの導入を取り巻く変更管理ポリシーや安全規制のために、これは必ずしも実現可能ではない。
OT components are often connected to IT networks. Consequently, malicious actors can pivot from IT to OT networks to affect or interrupt system, device, and process operations. This highlights the need for securing systems at the IT level to reduce the likelihood of a threat actor pivoting to OT systems connected to IT infrastructure. As identified in the 2015 Ukrainian power grid compromise, [4] threat actors sent phishing emails targeting IT networks before pivoting to the ICS environment and deploying BlackEnergy malware.  OTコンポーネントは多くの場合、ITネットワークに接続されている。その結果、悪意のある行為者は、ITからOTネットワークに軸足を移し、システム、デバイス、プロセスのオペレーションに影響を与えたり、中断させたりすることができる。このことは、脅威行為者がITインフラに接続されたOTシステムにピボットする可能性を減らすために、ITレベルでシステムを保護する必要性を強調している。2015年のウクライナの送電網の侵害で確認されたように[4]、脅威者はICS環境にピボットしてBlackEnergyマルウェアを展開する前に、ITネットワークをターゲットにしたフィッシングメールを送信していた。
The security of systems in both IT and OT environments should improve in tandem. Many aspects of Security-by-Design and -Default apply to both IT and OT. Some considerations are specific to either OSS, OT, or the conjunction of both. Conversely, some considerations are not specific to OSS but have OSS-specific implementations, such as Sigstore. Sigstore serves as an OSS-specific implementation of the broader security control of code signing; it enables developers to validate that the software in use is exactly what it claims to be by using cryptographic digital signatures and transparency log technologies. A desired security control with OT-specific considerations is multifactor authentication (MFA). It is considered an important best practice in both IT and OT environments; however, MFA implementation (such as using long, complex passwords paired with a second or multiple sources of validation) may be prohibitive in high-intensity safety scenarios. With OT devices, MFA should use technology compatible with OT operational modalities.  ITとOTの両環境におけるシステムのセキュリティは、連動して改善されるべきである。セキュリティ・バイ・デザイン(Security-by-Design)とデフォルト(Security-by-Default)の多くの側面は、ITとOTの両方に当てはまる。いくつかの考慮事項は、OSS、OTのいずれか、あるいは両方の組み合わせに特有のものである。逆に、OSSに特有ではないが、SigstoreのようなOSSに特化した実装を持つ考慮事項もある。Sigstoreは、コード署名という広範なセキュリティ管理のOSS固有の実装として機能する。Sigstoreは、開発者が、暗号デジタル署名と透明性ログ技術を使用することで、使用中のソフトウェアが主張するとおりのものであることを検証することを可能にする。OT に特化したセキュリティ管理として望まれるのは、多要素認証(MFA)である。MFA は、IT と OT 環境の両方で重要なベストプラクティスと考えられている。しかし、MFA の実装(長くて複 雑なパスワードと 2 つ目または複数の検証ソースのペア使用など)は、強度の高い安全シナリオでは禁止される可能性がある。OT 機器では、MFA は OT の運用モダリティと互換性のある技術を使用すべきである。
Supply Chain Risks  サプライチェーンリスク 
As a result of the connections between OT and IT networks, OT systems are too often exposed to cyber threat actors targeting control systems and the critical infrastructure they operate. To counter these threats, the cybersecurity community recommends that defenders and operators keep all OT and IT systems up to date with patches and security updates to address known exploited vulnerabilities. However, patching and security updates create opportunities for threat actors to affect the OT supply chain—malicious threat actors can compromise the supply chain by embedding malware in a patch or by compromising the website that hosts the patch, such as replacing the patch itself with malware (known as a ‘watering hole’). This is particularly problematic since most OT operators inherently trust the legitimacy of these sites. For example, Havex malware used legitimate system update installers to deploy and execute the malware along with the normal software update process. The compromised OT platform was left fully functional, but with a malicious backdoor installed.[5]  OT ネットワークと IT ネットワークが接続されている結果、OT システムは、制御システムとそれらが運用する重要インフラを標的にするサイバー脅威要因にさらされることがあまりにも多い。このような脅威に対抗するため、サイバーセキュリティ・コミュニティは、防御者とオペレータが、悪用される既知の脆弱性に対処するため、すべてのOTとITシステムをパッチとセキュリティ・アップデートで最新の状態に保つことを推奨している。悪意のある脅威者は、パッチにマルウェアを埋め込んだり、パッチ自体をマルウェアに置き換えたり(「ウォータリングホール」として知られる)、パッチをホストするウェブサイトを侵害することによって、サプライチェーンを侵害することができる。ほとんどのOTオペレータは、これらのサイトの正当性を本質的に信頼しているため、これは特に問題となる。例えば、Havexマルウェアは、正規のシステム・アップデート・インストーラーを使用して、通常のソフトウェア・アップデート・プロセスとともにマルウェアを展開・実行した。侵害されたOTプラットフォームは、完全に機能するものの、悪意のあるバックドアがインストールされた状態になった[5]。
Supply Chain Risk Management  サプライチェーン・リスクマネジメント
The software supply chain is a complex issue for systems and poses specific risks when accounting for the intersection of OT and OSS, necessitating a thoughtful strategy for risk management. A reliable software supply chain for an OT system with OSS components provides assurance the system will behave as intended at the time of acquisition and that all OSS components have been appropriately vetted prior to use. This is also true for software supply chain information in general. The phrases “as intended,” “at time of acquisition,” and “prior to use” reference business or organizational expectations that will be specific to each individual enterprise and require definition of a particular component’s use in the operational environment—components defined as either a commercial product or open source software. Two examples of supply chain risk management aspects that are relevant to OSS in OT are transparency and verifiability.  ソフトウェアのサプライチェーンは、システムにとって複雑な問題であり、OTとOSSの交差を考慮する際に特有のリスクをもたらすため、リスク管理のための思慮深い戦略が必要となる。OSSコンポーネントを含むOTシステムのための信頼できるソフトウェアサプライチェーンは、システムが取得時に意図されたとおりに動作し、すべてのOSSコンポーネントが使用前に適切に吟味されたことを保証する。これはソフトウェアサプライチェーン情報全般についても言えることである。意図した通り」、「取得時」、「使用前」という表現は、個々の企業に特有のビジネスや組織の期待に言及するものであり、運用環境における特定のコンポーネントの使用について定義する必要がある。OTにおけるOSSに関連するサプライチェーン・リスク管理の側面の2つの例は、透明性と検証可能性である。
Transparency includes:  透明性には以下が含まれる: 
• What assets it owns and operates, e.g., asset management transparency.  ・例えば,資産管理の透明性である。
• What software each software asset is composed of—a Software Bill of Materials (SBOM) can assist with this.  ・各ソフトウェア資産がどのようなソフトウェアで構成されているか-ソフトウェア部品表(SBOM)はこれを支援することができる。
• The supplier’s process by which, for example, an OT device’s firmware will be updated.  ・例えば,OT デバイスのファームウェアが更新される,サプライヤーのプロセス。
• The software the assets are running is the software that the developer wrote, and that the developer who wrote the software is the intended developer.  ・資産が実行しているソフトウエアは,開発者が書いたソフトウエアであり,そのソフトウエアを書いた開発者が意図した開発者である。
Verifiability—or the ability to confirm the authenticity of information and data related to systems—includes:  検証可能性、すなわちシステムに関連する情報やデータの真正性を確認する能力には、以下が含まれる: 
• The identity of users and their access restrictions.  ・ユーザーの身元とそのアクセス制限。
• Data integrity—the accuracy and validity of data throughout its lifecycle.  ・データの完全性-データのライフサイクル全体を通しての正確性と妥当性。
• Software is functioning as specified.  ・ソフトウェアが仕様どおりに機能している。
• Overall system security.  ・システム全体のセキュリティ。
Each variation of verifiability contains independent means of achieving it, often with an overlapping and interrelated set of controls. In this sense, OT and OSS are similar to other software. By ensuring these components can be verified, confidence in a system's defense and its ability to mitigate malicious cyber activity is heightened. For additional resources on assessing IT supply chain risk management, see CISA’s ICT Supply Chain Risk Management Task Force.  検証可能性のそれぞれのバリエーションには、それを達成するための独立した手段が含まれており、多くの場合、重複し、相互に関連する管理セットを伴う。この意味で、OTとOSSは他のソフトウェアに似ている。これらのコンポーネントを確実に検証できるようにすることで、システムの防御と悪意のあるサイバー活動を軽減する能力に対する信頼が高まる。ITサプライチェーン・リスク管理の評価に関するその他のリソースについては、CISAのICTサプライチェーン・リスク管理タスクフォースを参照のこと。
This fact sheet provides recommendations for improving security of OSS in OT/ICS, starting at the senior leadership level of an organization. Best practice resources are also provided as considerations when addressing cybersecurity concerns pertaining to OSS in OT devices and ICS environments. CISA, FBI, NSA, and U.S. Department of the Treasury encourage organizations to review the National Institute of Standards and Technology (NIST) Guide to ICS Security for further guidance. The OT/ICS industry is encouraged to apply the below tools and best practices to address general problems surrounding the use of OSS, as well as to actively participate in instances where there are unique needs for these solutions.  このファクトシートは、OT/ICS における OSS のセキュリティを改善するための推奨事項を、組織のシニア・リー ダーシップ・レベルから提供する。また、OT 機器や ICS 環境における OSS に関連するサイバーセキュリティの懸念に対処する際の考慮事項として、ベストプラクティ ス・リソースも提供している。CISA、FBI、NSA、米国財務省は、さらなる指針として、米国標準技術局(National Institute of Standards and Technology:NIST)の「ICSセキュリティガイド(Guide to ICS Security)」を検討することを組織に推奨している。OT/ICS業界は、OSSの使用を取り巻く一般的な問題に対処するために、以下のツールとベストプラクティスを適用するだけでなく、これらのソリューションに固有のニーズがある場合に積極的に参加することが推奨される。
Vendor Support of OSS Development and Maintenance  ベンダによるOSS開発とメンテナンスのサポート 
Open source software is often developed and maintained by volunteers. Providing support to individuals and groups that develop and maintain key open source projects helps elevate the security baseline and provides more assurance in the integrity of key libraries. Every organization using OSS should support the OSS ecosystem, including by:  オープンソースソフトウェアは、ボランティアによって開発・保守されることが多い。主要なオープンソースプロジェクトを開発・保守する個人やグループに支援を提供することは、セキュリティの基本水準を高め、主要なライブラリの完全性をより確実にするのに役立つ。OSSを使用するすべての組織は、以下を含むOSSエコシステムを支援すべきである: 
Learning about and considering participation in OSS and grant programs. The following resources can help support the development and maintenance of critical OSS projects that are used in OT/ICS systems. These can include security audits, efforts to fix identified problems, and/or improve processes of OSS used in OT.  OSS および助成金プログラムについて学び、参加を検討する。以下のリソースは、OT/ICS システムで使用される重要な OSS プロジェクトの開発と保守を支援するのに役立つ。これらには、セキュリティ監査、特定された問題の修正、および/または OT で使用される OSS のプロセス改善への取り組みが含まれる。
o DigitalOcean Hacktoberfest: An annual, worldwide event held during the month of October that encourages open source developers to contribute to repositories.  o DigitalOceanハクトーバーフェスト: 毎年 10 月に開催される世界的なイベントで、オープンソース開発者にリポジトリへの貢献を奨励する。
o Open Source Security Foundation (OpenSSF) Alpha-Omega Program: Program that partners with OSS project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code (and get them fixed) to improve global software supply chain security.  o Open Source Security Foundation (OpenSSF) Alpha-Omega プログラム: OSSプロジェクトのメンテナと提携し、オープンソース・コードのまだ発見されていない新しい脆弱性を体系的に発見し(そして修正させ)、グローバルなソフトウェア・サプライチェーン・セキュリティを向上させるプログラム。
o Free and Open Source Software (FOSS) Contributor Fund: Framework for selecting open source projects that a company supports financially. This initiative is designed to encourage open source participation and help companies take an active role in sustaining the projects they depend on.  o フリー・オープンソースソフトウェア(FOSS)貢献者基金: 企業が財政的に支援するオープンソースプロジェクトを選択するための枠組み。このイニシアチブは、オープンソースへの参加を奨励し、企業が依存するプロジェクトの維持に積極的な役割を果たせるよう支援することを目的としている。
o NumFOCUS Small Development Grants Program: Program that helps fund projects’ usability, community growth, and speeding up the time to major releases.  o NumFOCUS 小規模開発助成金プログラム: プロジェクトのユーザビリティ、コミュニティの成長、メジャーリリースまでの期間の短縮に資金を援助するプログラム。
Partnering with existing OSS Foundations and pursuing collaborative efforts to leverage the ecosystem knowledge for more effective, direct funding and support to key projects critical to OT/ICS security.  既存のOSS財団と提携し、エコシステムの知識を活用して、OT/ICSセキュリティにとって重要なプロジェクトにより効果的で直接的な資金提供や支援を行うための協力的な取り組みを追求する。
Supporting the adoption of security tools and best practices in the software development lifecycle. Integrating security at the early stage of the software development lifecycle is critical to producing software that is Secure-byDesign. Organizations contributing to OSS should invest development time and resources towards the adoption of critical security tools as part of a project’s development lifecycle.  ソフトウェア開発ライフサイクルにおけるセキュリティツールとベストプラクティスの採用を支援する。セキュアバイデザイン(Secure-by-Design)のソフトウエアを製造するには、ソフトウエア開発ライフサイクルの初期段階でセキュリティを統合することが重要である。OSS に貢献する組織は、プロジェクトの開発ライフサイクルの一環として、重要なセキュリ ティ・ツールの採用に向けて開発時間とリソースを投資すべきである。
o Google’s Open Source Security Upstream Team effort is one example advocating for the adoption of these principles.  o Googleのオープンソース・セキュリティ・アップストリーム・チームの取り組みは、これらの原則の採用を提唱する一例である。
o The GitHub Action for OpenSSF Scorecard serves as a check that a project is using current best practices to test for security vulnerabilities before production releases, as well as export provenance metadata to support end-to-end trust in the project’s supply chain.  o GitHub Action for OpenSSF スコアカードは、プロジェクトが本番リリース前にセキュリティの脆弱性をテストするための最新のベストプラクティスを使用しているかどうかをチェックするのに役立つ。
o See additional recommendations in the OpenSSF Best Practices Working Group’s Concise Guide for Developing More Secure Software.  o OpenSSF ベストプラクティスワーキンググループ(OpenSSF Best Practices Working Group)の「Concise Guide for Developing More Secure Software(よりセキュアなソフトウェア開発のための簡潔なガイド)」のその他の推奨事項を参照すること。
Manage Vulnerabilities  脆弱性の管理 
Vulnerability management is important for all software, though OSS and OT have unique characteristics that require further consideration. Vulnerability management includes[6] processes for organizations to communicate and accomplish vulnerability discovery, analysis, and handling, as well as report intake, coordination, disclosure, and response. In each of these phases, using common vulnerability identifiers, including the production and consumption of vulnerability information in existing formats, can reduce confusion and simplify vulnerability management. Existing formats include Common Vulnerabilities and Exposures (CVE), Common Security Advisory Framework (CSAF), and Open Source Vulnerability (OSV). This section highlights resources for vulnerable device detection, response, and vulnerability coordination.  脆弱性管理は、すべてのソフトウェアにとって重要であるが、OSS と OT には、さらに考慮が必要な固有の特性がある。脆弱性管理には[6]、組織が脆弱性の発見、分析、対処、および報告書の取り込み、調整、開示、対応を伝達し、達成するためのプロセスが含まれる。これらの各段階において、既存のフォーマットによる脆弱性情報の作成と消費を含め、共通の脆弱性識別子を使用することで、混乱を減らし、脆弱性管理を簡素化することができる。既存のフォーマットには、CVE(Common Vulnerabilities and Exposures)、CSAF(Common Security Advisory Framework)、OSV(Open Source Vulnerability)などがある。このセクションでは、脆弱性デバイスの検出、対応、脆弱性の調整に関するリソースを紹介する。
Risk Exposure Reduction  リスク・エクスポージャーの削減 
CISA offers a range of services at no cost, including scanning and testing to help organizations reduce exposure to threats via mitigating attack vectors. CISA Cyber Hygiene services can help provide additional review of organizations’ internetaccessible assets. Cyber Hygiene can detect vulnerabilities in internet-connected software, including in OSS and OT systems. Email with the subject line, “Requesting Cyber Hygiene Services” to get started.  CISAは、組織が攻撃ベクトルを軽減することで脅威への露出を減らすのを支援するスキャンやテストなど、さまざまなサービスを無償で提供している。CISAのCyber Hygieneサービスは、組織のインターネットにアクセス可能な資産の追加レビューを提供するのに役立つ。Cyber Hygieneは、OSSやOTシステムを含むインターネットに接続されたソフトウェアの脆弱性を検出することができる。、件名を「Requesting Cyber Hygiene Services(サイバー・ハイジーン・サービスの依頼)」として電子メールを送信する。
Vulnerability Coordination  脆弱性の調整 
Advancing the security and resilience of ICS is one of CISA’s top priorities. As part of CISA’s mission to help critical infrastructure partners manage ICS security risk, CISA is committed to equipping the community with practices that address ICS risk and operational resilience. For example, CISA helps ensure ICS vendors can assign CVE IDs by assisting organizations to become a root CVE Numbering Authority (CNA). If there is no identifier for coordinating a new ICS vulnerability, CISA will assign one as the root CNA for ICS. Additional vulnerability coordination guidance and supporting resources include:  ICSのセキュリティと回復力の向上は、CISAの最優先事項の1つである。重要インフラパートナーがICSセキュリティリスクを管理するのを支援するというCISAの使命の一環として、CISAは、ICSリスクと運用回復力に対処するプラクティスをコミュニティに提供することに尽力している。例えば、CISAは、組織がルートCVE番号付与機関(CNA)になるのを支援することで、ICSベンダーが確実にCVE IDを割り当てられるように支援している。新しいICS脆弱性を調整するための識別子がない場合、CISAはICSのルートCNAとして識別子を割り当てる。その他の脆弱性調整ガイダンスと支援リソースには以下のものがある: 
• Organizations developing software, including OSS, should establish a Coordinated Vulnerability Disclosure (CVD) program. The Software Engineering Institute’s (SEI) CERT Guide to CVD provides an introduction to the key concepts, principles, and roles necessary to establish a successful process.  ・OSSを含むソフトウェアを開発する組織は、調整された脆弱性開示(CVD)プログラムを確立すべきである。ソフトウェア工学研究所(SEI)の CVD への CERT ガイドは、成功するプロセスを確立するために必要な主要概念、原則、および役割の紹介を提供する。
• Individuals and organizations who discover vulnerabilties should report to the relevant developer. For example, vulnerability finders might report to product owners, vendors, or project maintainers. In cases where contact with the developer cannot be made, the bug finder may report via CISA.  ・脆弱性を発見した個人や組織は,関連する開発者に報告すべきである。例えば,脆弱性発見者は,製品所有者,ベンダ,あるいはプロジェクトメンテナに報告するかもしれない。開発者に連絡できない場合,バグ発見者は CISA を通じて報告してもよい。
• Organizations participating in CVD should identify key OSS used to assist in improving CVD programs where needed. See OpenSSF’s Guide to Implementing a Coordinated Vulnerability Disclosure Process for Open Source Projects, which is intended to help open source project maintainers create and maintain a coordinated vulnerability response process.  ・CVD に参加する組織は、必要に応じて CVD プログラムの改善を支援するために使用される主要な OSS を特定すべきである。OpenSSF の「Guide to Implementing a Coordinated Vulnerability Disclosure Process for Open Source Projects」(オープンソースプロジェクトメンテナが協調的な脆弱性対応プロセスを作成・維持するのを支援するためのガイド)を参照のこと。
• Contribute effort to support and encourage vulnerability research. Improve the security of OSS projects by discovering, reporting, and helping to remediate vulnerabilities. Consider the following incentives:  ・脆弱性研究を支援し、奨励するための努力に貢献する。脆弱性を発見し、報告し、是正を支援することによって、OSS プロジェクトのセキュリティを向上させる。以下のインセンティブを検討する: 
o Google’s Open Source Software Vulnerability Rewards Program  o Googleのオープンソースソフトウェア脆弱性報奨プログラム 
o HackerOne’s Internet Bug Bounty and Community Edition  o HackerOneのインターネットバグバウンティとコミュニティ版 
• Utilize Stakeholder-Specific Vulnerability Categorization (SSVC) methodologies to inform response activities. CISA and SEI have partnered to develop the SSVC system, which presents a systematic, decision tree-based approach to analyze and prioritize vulnerability response activities based on exploitation status, impacts to safety, and prevalence.  ・ステークホルダー固有の脆弱性分類(SSVC)手法を活用し、対応活動に反映させる。CISA と SEI は提携して SSVC システムを開発した。SSVC システムは、悪用の状況、安全性への影響、および普及率に基づいて脆弱性対応活動を分析し、優先順位をつけるための体系的な決定ツリーベースのアプローチを提示する。
o CISA’s SSVC Guide  o CISAのSSVCガイド 
o SEI’s Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization  o SEIの脆弱性対応の優先順位付け: 利害関係者固有の脆弱性分類 
Patch Management  パッチ管理 
Patch management is a process at the intersection of vulnerability management and change management. Patching is just one option for vulnerability remediation,[7] which occurs when a vulnerability is eliminated or removed. Mitigation, on the other hand, occurs when the impact of a vulnerability decreases without reducing or eliminating the vulnerability. Patching is a complex decision when considering and working with OT. Other forms of remediation (upgrading or removing the system) or mitigation (increasing network controls) can reduce the functionality of the affected device and alter alignment to organizational risk tolerances and priorities.  パッチ管理は、脆弱性管理と変更管理の交差点にあるプロセスである。パッチは、脆弱性の修復[7]のための一つの選択肢に過ぎず、脆弱性が除去されたり除去されたりするときに発生する。一方、緩和は、脆弱性を低減または除去することなく、脆弱性の影響を減少させる場合に発生する。パッチを適用することは、OTを考慮し作業する際に複雑な決定を伴う。他の形態の修復(システムのアップグレードまたは削除)または緩和(ネットワーク制御の強化)は、影響を受けるデバイスの機能を低下させ、組織のリスク許容度や優先順位との整合性を変化させる可能性がある。
In some industries[8],[9],[10] patches may require regulatory approval for certain devices. For example, in some instances patches can move OT systems out of a state that has been previously certified and/or approved under certain regulatory or compliance frameworks. North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) is a set of standards that requires covered entities to weigh a variety of risk factors when making individual patching determinations, including the reliability of the patched system.[11] Amidst possible overlap with regulatory concerns, restarting an OT system to apply a patch may have large business or operational costs. In these situations, mitigations should be applied immediately after the vulnerability is identified until a remediation, such as a patch, is approved.  業界によっては[8]、[9]、[10]、パッチの適用に特定の機器に対する規制上の承認が必要な場合がある。例えば、パッチを適用することで、OT システムを、特定の規制やコンプライアンスフレームワークの下で以前に認証及び/又は承認された状態から移動させることができる場合がある。NERC CIP(North American Electric Reliability Corporation Critical Infrastructure Protection:北米電気信頼性公社重要インフラ保護)は、対象事業体に対して、パッチを適用するシステムの信頼性を含め、個々のパッチを決定する際に様々なリスク要因を考慮することを要求する一連の基準である[11]。このような状況では、脆弱性が特定された直後から、パッチなどの改善策が承認されるまで、緩和策を適用すべきである。
While the OSS ecosystem is diverse, vulnerabilities are collectively aggregated in the National Vulnerability Database (NVD) and driven by organizations that serve as CVE numbering authorities. The procedure of CVE assignment and tracking is common practice in U.S. government policies and standards. Some open source organizations also use the OpenSSF OSV Schema as an aggregation tool for vulnerabilities in language ecosystems, while others have not yet adopted a community vulnerability naming and tracking benchmark. To support community application of securityrelevant patches, all projects and organizations should use a community-recognized vulnerability naming method. These methods are further supported by structured formats for security alerts such as the OASIS CSAF.  OSSのエコシステムは多様であるが、脆弱性はNational Vulnerability Database (NVD)に集約され、CVE番号付与機関として機能する組織によって管理されている。CVEの割り当てと追跡の手順は、米国政府の政策と標準では一般的な慣行である。いくつかのオープンソース組織も、言語エコシステムにおける脆弱性の集約ツールとして OpenSSF OSV スキーマを使用している。セキュリティ関連パッチのコミュニティによる適用を支援するために、すべてのプロジェクトと組織は、コミュニティが認める脆弱性の命名方法を使用すべきである。これらの方法は、OASIS CSAF のようなセキュリティ警告の構造化されたフォーマットによって、さらにサポートされる。
Vendors and consumers are further encouraged to:  ベンダとコンシューマには、さらに次のことが推奨される: 
• Promote the unique understanding of patch deployment processes for OT/ICS environments. Communication for OT/ICS-specific patch implementation should include:  ・OT/ICS 環境のパッチ展開プロセスに関する独自の理解を促進する。OT/ICS 特有のパッチ実施に関するコミュニケーションには、以下を含めるべきである: 
o Safety and security of the customers as a core business requirement, not just a technical feature.  o 技術的な機能だけでなく、中核的なビジネス要件としての顧客の安全性とセキュリティ。
o The assessment of what mitigations are immediately needed.  o どのような緩和策が直ちに必要であるかの評価。
o How decisions are made for balancing the risk due to a cybersecurity vulnerability, as well as risk due to changing the OT environment.  o サイバーセキュリティの脆弱性に起因するリスクと OT 環境の変更に起因するリスクのバランスをどのように決定するか。
o The turnaround time, for example, for how long a patch should take to deploy and what the confidence level is for correct implementation.  o 例えば、パッチの展開にどれくらいの時間がかかるか、また、正しい実装の信頼度はどの程度か、といったターンアラウンドタイム。
o How to streamline software development processes with ICS vendors, that is, when vendors ship patch updates and consumers apply periodically without the added complexity of scheduling maintenance windows.  o ICSベンダーとのソフトウェア開発プロセスを合理化する方法、つまり、ベンダーがパッチのアップデートを出荷し、コンシューマがメンテナンスウィンドウのスケジューリングという複雑な作業を追加することなく定期的に適用する方法。
o How software is being tested for compability issues before a patch is deployed.  o パッチを導入する前に、ソフトウェアの互換性に問題がないか、どのようにテストしているか。
• Maintain a comprehensive updated asset inventory to best identify software and hardware products, as well as open source components in both IT and OT environments. Identify vulnerabilities that need to be patched based on the asset inventory and automated correlation with vulnerability databases such as the NVD.  ・IT および OT 環境の両方におけるソフトウェアおよびハードウェア製品,ならびにオープンソースコンポーネントを最適に識別するために,包括的な最新の資産インベントリを維持する。資産目録と NVD のような脆弱性データベースとの自動相関に基づいて,パッチを適用する必要のある脆弱性を特定する。
o For OT/ICS systems, SBOMs can provide an inventory of what is in use, making it easier to determine whether a device is affected by a vulnerability due to use of an out-of-date OSS dependency. Organizations are encouraged to hold vendors and suppliers accountable for maintaining provenance data, for example, by requesting SBOMs prior to purchasing products. A SBOM can also help identify OSS projects that are widely used by or otherwise critical to ICS. Organizations are encouraged to request or require SBOMs from upstream suppliers at the time of procurement, as well as for products that are already owned.  o OT/ICS システムの場合、SBOM は、使用中のもののインベントリを提供することができ、デバイスが古い OSS 依存の使用により脆弱性の影響を受けるかどうかを容易に判断することができる。組織は、製品を購入する前にSBOMを要求するなどして、ベンダーやサプライヤーに出所データの維持について責任を持たせることが推奨される。SBOM は、ICS で広く使用されている、または ICS にとって重要な OSS プロジェクトを特定するのにも役立つ。組織は、すでに所有している製品だけでなく、調達時に上流サプライヤに SBOM を要求または要求することが推奨される。
o Vulnerability Exploitability eXchange (VEX) provides additional information on whether a product is impacted by a specific vulnerability and, if affected, whether there are actions recommended to remediate. VEX is machine-readable, which enables automation and supports integration into broader tooling and processes; organizations can integrate component data from SBOMs with vulnerability status information from VEXes to provide an up-to-date view of the status of vulnerabilities.  o Vulnerability Exploitability eXchange (VEX)は、製品が特定の脆弱性の影響を受けているかどうか、また影響を受けている場合、是正するために推奨される措置があるかどうかに関する追加情報を提供する。組織は、SBOMからのコンポーネントデータとVEXからの脆弱性ステータス情報とを統合することで、脆弱性ステータスの最新ビューを提供することができる。
• Establish “emergency patching procedures” that expedite patches for critical vulnerabilities without sacrificing safety and working outside of accepted standards.  ・重要な脆弱性に対するパッチを,安全性を犠牲にすることなく,また許容される標準の範囲外で作業することなく,迅速に適用する「緊急パッチ適用手順」を確立する。
See the following additional resources for best practice guidance that addresses the management of vulnerabilities:  脆弱性の管理に対応するベストプラクティスのガイダンスについては、以下の追加リソースを参照のこと: 
• Global Cybersecurity Alliance (GCA): Manage Vulnerabilities in ICS Open Source Software  ・グローバルサイバーセキュリティアライアンス(GCA): ICS オープンソースソフトウェアにおける脆弱性の管理
• Forum of Incident Response and Security Teams (FIRST): Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure  ・グローバル・サイバーセキュリティ・アライアンス(GCA):ICS オープンソースソフトウェアにおける脆弱性の管理: 複数当事者による脆弱性の調整と開示のためのガイドラインと実務
Improve Authentication and Authorization Policies  認証・認可ポリシーの改善 
While not unique to OSS, effective implementation of authentication[12] and authorization[13] represent powerful protective controls that can be deployed in any networked computing environment and can significantly enhance the security and consumption of commercial products and OSS projects. Authentication—verifying identity—and authoritization—ensuring appropriate access permissions—work in tandem to prevent unauthorized and malicious changes to IT and OT infrastructure.  OSS に限ったことではないが、認証[12]と認可[13]の効果的な実装は、あらゆるネットワーク化されたコンピューティング環境に展開できる強力な保護制御であり、商用製品と OSS プロジェクトのセキュリティと消費を大幅に強化することができる。認証-身元を確認すること-と認可-適切なアクセス許可を確保すること-は、IT および OT インフラストラクチャへの不正で悪意のある変更を防止するために連動する。
However, these controls can be difficult to correctly implement and are especially important in OT environments, which are less likely to maintain defense-in-depth security controls once a threat actor breaches the network boundary and obtains initial access to the environment. Considering OT devices are often deployed in production environments for longer periods of time and are less likely to receive updates compared to enterprise devices, they may also be less likely to support the latest cryptographic technologies that facilitate highly secure authentication. Furthermore, although many OT communication protocols utilized by these devices have extensions or revisions that support modern authentication and authorization schemes, the actual uptake of “more secure” protocols is mixed. The shortage of experienced OT professionals required to maintain and administer a granular authentication and authorization program in OT environments can also prove especially challenging.  しかし、これらのコントロールを正しく実装することは困難であり、OT環境では特に重要である。OT環境では、脅威行為者がネットワーク境界を突破し、環境への最初のアクセスを取得すると、徹底的なセキュリティ防御コントロールを維持する可能性が低くなる。OT デバイスは、本番環境に長期間配置されることが多く、エンタープライズ・デバイスと比較してアップデートを受ける可能性が低いことを考慮すると、高度に安全な認証を促進する最新の暗号技術に対応していない可能性もある。さらに、これらのデバイスで利用される多くの OT 通信プロトコルは、最新の認証および認可スキームをサポートする拡張または改訂が施されているが、「より安全な」プロトコルの実際の導入状況はまちまちである。OT 環境におけるきめ細かな認証・認可プログラムの維持・管理に必要な経験豊富な OT 専門家が不足していることも、特に困難であることを示している。
Within ICS, authentication and authoritization practices can improve by:  ICS 内では、認証および認可の慣行は、次のようにして改善することができる: 
• Using accounts that uniquely and verifiably identify individual users. For example, OT products that leverage service accounts should use role-based access control (RBAC) or a similar approach.  ・個々のユーザを一意にかつ検証可能に識別するアカウントを使用する。例えば、サービス・アカウントを利用する OT 製品は、役割ベースのアクセス制御(RBAC)または類似のアプローチを使用する。
• Avoiding use of hard-coded credentials, default passwords, and weak configurations.  ・ハードコードされた認証情報,デフォルトパスワード,および脆弱な設定の使用を避ける。
• Implementing MFA (when applicable).  ・MFA を実装する(該当する場合)。
• Using centralized user management solutions (e.g., Lightweight Directory Access Protocol [LDAP], Active Directory [AD]), which can streamline account management and improve traceability. This should be weighted against availability requirements.  ・集中型ユーザー管理ソリューション(LDAP、Active Directoryなど)を使用し、アカウント管理を合理化し、追跡可能性を向上させる。これは、可用性要件との兼ね合いを考慮する必要がある。
Combining Secure-by-Default practices with least privilege—or users only having access to what they need to perform their responsibilities—is an important consideration for addressing the authorization process. Increasing the resilience against exploitation via end-user compromise reduces the prevalence of successful incidents impacting OT.  セキュア・バイ・デフォルト(Secure-by-Default)の実践と、最小権限(ユーザが責任を果たすために必要なものだけにアクセスすること)を組み合わせることは、権限付与プロセスに対処するための重要な検討事項である。エンドユーザーの侵害による悪用に対する回復力を高めることで、OT に影響を及ぼすインシデントの成功率を下げることができる。
Establish Common Framework  共通のフレームワークを確立する 
Improving the awareness and adoption of key cybersecurity best practices and infrastructure as they relate to both IT and OT environments can establish a common framework for using OSS. CISA has developed a performance-based checklist of key organizational cybersecurity goals, which are applicable to mixed IT/ICS network environments. Developed from NIST’s Cybersecurity Framework (CSF), the CISA Cross-Sector Cybersecurity Performance Goals (CPGs) describe network segmentation, vulnerability patching, and software assurance goals organizations should strive to meet, irrespective of OSS involvement in a given system. Additionally, the following recommendations should be considered to ensure vendors provide components that meet industry standards for security compatibility with existing OSS tools, and a culture is established that addresses safety and cybersecurity concerns for critical systems:  IT 環境と OT 環境の両方に関連する主要なサイバーセキュリティのベストプラクティスとインフラストラクチャーの認識と採用を改善することで、OSS を使用するための共通のフレームワークを確立することができる。CISA は、IT/ICS が混在するネットワーク環境に適用可能な、組織のサイバーセキュリティに関する主要な目標を示すパフォーマンスベースのチェックリストを開発した。NIST のサイバーセキュリティフレームワーク(CSF)を基に開発された CISA Cross-Sector Cybersecurity Performance Goals(CPGs)は、特定のシステムへの OSS の関与に関係なく、組織が満たすよう努力すべきネットワークセグメンテーション、脆弱性パッチ適用、ソフトウェア保証の目標を記述している。さらに、ベンダーが既存の OSS ツールとのセキュリティ互換性に関する業界標準を満たすコン ポーネントを提供し、重要システムの安全性とサイバーセキュリティの懸念に対処する文化が 確立されるように、以下の推奨事項を検討する: 
• Develop and support an Open Source Program Office (OSPO). Organizations that heavily interact with or utilize OSS should consider a dedicated office for coordinating these tasks. An OSPO serves as the center of competency for an organization's open source operations and structure and is responsible for defining and implementing strategies and policies to guide these efforts.[14]  ・オープンソースプログラムオフィス(OSPO)を開発し、支援する。OSS と密接に関わり、あるいは OSS を利用する組織は、これらのタスクを調整するための専用オフィスの設置を検討すべきである。OSPO は、組織のオープンソースの運用と構造に関するコンピテンシーの中心的な役割を果たし、こ れらの取り組みを導くための戦略とポリシーを定義し、実施する責任を負う[14]。
• Support safe and secure open source consumption practices. The following tools can assist: o  The OpenSSF Scorecard serves as an automated tool to assess risks that dependencies introduce.  ・安全でセキュアなオープンソースの利用方法を支援する。o OpenSSF スコアカードは,依存関係がもたらすリスクを評価するための自動化ツールとして機能する。
o Supply-chain Levels for Software Artifacts (SLSA)’s framework serves as an actionable checklist to improve software security, assess upstream dependencies, and evaluate the trustworthiness of the artifacts consumed.  o SLSA(Supply-chain Levels for Software Artifacts)のフレームワークは、ソフトウエアのセキュリ ティを改善し、上流での依存関係を評価し、消費される成果物の信頼性を評価するための実行可能な チェックリストとして機能する。
o The Secure Supply Chain Consumption Framework (S2C2F) provides a guideline for any organization that is directly utilizing open source components (e.g., open source that is not a component within a commercial product) to do so in a secure manner.  o セキュアサプライチェーン消費フレームワーク(S2C2F)は、オープンソースコンポーネント(例えば、商用製品内のコンポーネントではないオープンソース)を直接利用する組織が、安全な方法で利用するためのガイドラインを提供する。
o MITRE’s Hipcheck can be used within the secure consumption process to assess the risk of an OSS component before use.  o MITRE の Hipcheck は、使用前に OSS コンポーネントのリスクを評価するために、安全な利用プロセスの中で使用することができる。
• Build a targeted list of OT/ICS-specific requirements. A collection of industry partners have created a generic security checklist[15] that constitutes what makes a product minimally and viably secure. This checklist is not specific to OT/ICS systems; hence, a more targeted list of security requirements specific to vendors supplying these systems is needed. This targeted list should include tools that are aligned with the common themes of transparency and verifiability.  ・OT/ICS 固有の要件のターゲットリストを構築する。業界パートナーの集まりが、製品を最低限かつ実行可能な安全性にするものを構成する汎用的なセ キュリティチェックリスト[15] を作成した。このチェックリストは、OT/ICS システムに特化したものではない。したがって、これらのシステムを供給するベンダに特化した、より的を絞ったセキュリティ要件のリストが必要である。この対象リストには、透明性と検証可能性という共通テーマに沿ったツールを含めるべきである。
• Support the adoption of software signing techniques. Software signing ensures the integrity of updates, network communications, and software distribution across environments. In conjunction, using access transparency logs and identity-based signing can provide auditable and tamper-resistant logging, allowing OT/ICS systems to verify the authenticity of software updates and patches.  ・ソフトウェア署名技術の採用を支援する。ソフトウェア署名は,アップデート,ネットワーク通信,環境間でのソフトウェア配布の完全性を保証する。併せて,アクセス透明性ログと ID ベースの署名を使用することで,監査可能で改ざん耐性のあるロギングを提供し,OT/ICS システムがソフトウェア更新とパッチの真正性を検証できるようにする。
• Support the adoption of provenance generation. Provenance for OT/ICS software can provide knowledge about where software came from and how it was built—in a verifiable manner. Provenance may assist ICS systems in tracking the source of software components, as well as verify they were created in accordance with established organizational policies.  ・実績生成の採用をサポートする。OT/ICS ソフトウェアのプ ロベナン スは,ソフトウェアがどこから来て,どのように検証可能な方法で組み込まれたかという知識を提供 することができる。プロベナン スは,ソフトウェア・コンポーネントの出所を追跡し,それらが確立された組織方針に従って作成 されたことを検証する上で,ICS システムを支援する可能性がある。
• Maintain a software asset inventory to support the identification of what packages, software, firmware, and security services (e.g., incident and vulnerability management) exist in your environment.  ・ソフトウェア資産インベントリを維持し、環境に存在するパッケージ、ソフトウェア、ファームウェア、セキュリティサービス(インシデント管理、脆弱性管理など)の特定を支援する。
• CISA: JCDC 2023 Planning Agenda  ・CISA JCDC 2023 計画アジェンダ 
• CISA: JCDC Planning - Securing Open Source Software in Operational Technology  ・CISA: JCDC計画 ・運用技術におけるオープンソースソフトウェアのセキュリティ確保
• CISA: Open Source Software Security Roadmap  ・CISA: オープンソース・ソフトウェアのセキュリティ・ロードマップ
• CISA: Security-by-Design and -Default  ・CISA: セキュリティ・バイ・デザインとデフォルト
• Sigstore  ・シグストア
• CISA: ICT Supply Chain Risk Management Task Force  ・CISA: ICTサプライチェーンリスク管理タスクフォース
• NIST: Guide to ICS Security  ・NIST: ICSセキュリティガイド
• DigitalOcean: Hacktoberfest  ・DigitalOcean: ハクトーバーフェスト
• OpenSSF: Alpha-Omega Program  ・OpenSSF: アルファ-オメガプログラム
• FOSS Contributor Fund  ・FOSS コントリビューター基金
• NumFOCUS: Small Development Grants Program  ・NumFOCUS: 小規模開発助成プログラム
• Google: Open Source Security Upstream Team  ・グーグル オープンソースセキュリティ上流チーム
• OpenSSF: GitHub Action for Scorecard  ・OpenSSF: スコアカードのためのGitHubアクション
• OpenSSF Best Practices Working Group: Concise Guide for Developing More Secure Software •  CISA: Cyber Hygiene  ・OpenSSF ベストプラクティスワーキンググループ: より安全なソフトウェアを開発するための簡潔なガイド ・CISA: サイバー衛生
• CVE: Numbering Authorities  ・CVE: 番号付与機関
• CVE: Partner Details - CISA  ・CVE: パートナーの詳細 ・CISA
• SEI: CERT Guide to CVD  ・SEI CVD への CERT ガイド
• Report to CISA  ・CISA への報告
• OpenSSF: Guide to Implementing a Coordinated Vulnerability Disclosure Process for Open Source Projects  ・OpenSSF: オープンソースプロジェクトのための調整された脆弱性開示プロセスの実装ガイド
• Google: Open Source Software Vulnerability Rewards Program  ・グーグル オープンソースソフトウェア脆弱性報奨金プログラム
• HackerOne: The Internet Bug Bounty  ・HackerOne: インターネット・バグバウンティ
• HackerOne: Community Edition  ・HackerOne: コミュニティ版
• CISA: SSVC Guide  ・CISA: SSVC ガイド
• SEI: Prioritizing Vulnerability Response - A Stakeholder-Specific Vulnerability Categorization  ・SEI: 脆弱性対応の優先順位付け ・ステークホルダー別の脆弱性分類
• NIST: National Vulnerability Database  ・NIST 国家脆弱性データベース
• OpenSSF: OSV Schema  ・OpenSSF: OSV スキーマ
• CISA: Minimum Requirements for VEX  ・CISA: SBOM VEX の最低要件
• GCA: Manage Vulnerabilities in ICS Open Source Software  ・GCA: ICS オープンソースソフトウェアの脆弱性管理
• FIRST: Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure •  NIST: Cybersecurity Framework  ・FIRST: 複数当事者による脆弱性の調整と開示のためのガイドラインと実践 ・NIST: サイバーセキュリティフレームワーク
• OpenSSF: Scorecard  ・OpenSSF: スコアカード
• OpenSSF: Secure Supply Chain Consumption Framework  ・OpenSSF: セキュアサプライチェーン消費フレームワーク
• MITRE: Hipcheck  ・MITRE: ヒップチェック
[1] Open Source Initiative: The Open Source Definition  [1] オープンソースイニシアティブ: オープンソースの定義 
[2] NIST Glossary: Operational Technology  [2] NIST 用語集: 運用技術 
[3] NIST Glossary: Industrial Control System  [3] NIST 用語集: 産業制御システム 
[4] Trend Micro: BlackEnergy  [4] トレンドマイクロ ブラックエナジー 
[5] CISA ICS Advisory: ICS Focused Malware  [5] CISA ICSアドバイザリ: ICSにフォーカスしたマルウェア 
[6] FIRST CSIRT Services Framework: Vulnerability Management  [6] FIRST CSIRT サービスフレームワーク: 脆弱性管理 
[7] DoD: Instruction 8531.01 Vulnerability Management  [7] DoD: Instruction 8531.01 脆弱性管理 
[8] FDA: Deciding When to Submit a 510(k) for a Software Change to an Existing Device  [8] FDA: 既存のデバイスに対するソフトウェア変更の 510(k)をいつ提出するかの決定 
[9] TÜV SÜD: UN Regulation 156 - Automotive Software  [9] TÜV SÜD: 国連規則 156 ・自動車用ソフトウェア 
[10] Department of Commerce: Securing the Information and Communications Technology and Services Supply Chain; Connected Software Applications  [10] 商務省 情報通信技術及びサービスのサプライチェーンの安全確保、コネクテッド・ソフトウェア・アプリケーション [11] NERC CIP 
[11] NERC CIP: Cyber Security - System Security Management  [11] NERC CIP: サイバーセキュリティ ・システムセキュリティ管理 
[12] NIST Glossary: Authentication  [12] NIST 用語集: 認証 
[13] NIST Glossary: Authorization  [13] NIST 用語集:認証 認証 
[14] TODO Group: OSPO Definition and Guide  [14] TODO グループ: OSPO の定義とガイド 
[15] Security Checklist - Minimum Viable Secure Product  [15] セキュリティ・チェックリスト ・実用最小限の安全な製品 

| | Comments (0)