| Improving Security of Open Source Software in Operational Technology and Industrial Control Systems |
運用技術 (OT) および産業制御システム (ICS) におけるオープンソースソフトウェアのセキュリティ向上 |
| OVERVIEW |
概要 |
| 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. |
・不十分な文書。文書化が不十分なソフトウェアは、ユーザーが理解し、安全に使用することが難しくなる。 |
| THE IT/OT CONVERGENCE |
ITとOTの融合 |
| 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サプライチェーン・リスク管理タスクフォースを参照のこと。 |
| RECOMMENDATIONS |
推奨事項 |
| 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 vulnerability@cisa.dhs.gov with the subject line, “Requesting Cyber Hygiene Services” to get started. |
CISAは、組織が攻撃ベクトルを軽減することで脅威への露出を減らすのを支援するスキャンやテストなど、さまざまなサービスを無償で提供している。CISAのCyber Hygieneサービスは、組織のインターネットにアクセス可能な資産の追加レビューを提供するのに役立つ。Cyber Hygieneは、OSSやOTシステムを含むインターネットに接続されたソフトウェアの脆弱性を検出することができる。vulnerability@cisa.dhs.gov、件名を「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. |
・ソフトウェア資産インベントリを維持し、環境に存在するパッケージ、ソフトウェア、ファームウェア、セキュリティサービス（インシデント管理、脆弱性管理など）の特定を支援する。 |
| RESOURCES |
リソース |
| • 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: サイバー衛生 |
| • CISA: ICS |
・CISA: ICS |
| • 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 スキーマ |
| • OASIS: CSAF |
・OASIS: CSAF |
| • CISA: SBOM |
・CISA: SBOM |
| • 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: サイバーセキュリティフレームワーク |
| • CISA: CPGs |
・CISA CPG |
| • OpenSSF: Scorecard |
・OpenSSF: スコアカード |
| • OpenSSF: SLSA |
・OpenSSF: SLSA |
| • OpenSSF: Secure Supply Chain Consumption Framework |
・OpenSSF: セキュアサプライチェーン消費フレームワーク |
| • MITRE: Hipcheck |
・MITRE: ヒップチェック |
| REFERENCES |
参考文献 |
| [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] セキュリティ・チェックリスト ・実用最小限の安全な製品 |
Recent Comments