From 0d768e1789ae0b00f5430df9ace5638730296502 Mon Sep 17 00:00:00 2001 From: Steve Springett Date: Mon, 5 Feb 2024 20:34:54 -0600 Subject: [PATCH] Content update --- CBOM/en/0x30-Anatomy-of-a-CBOM.md | 70 +++++++++++++++--------------- CBOM/en/0x40-Practical-Examples.md | 4 +- CBOM/en/0x41-Dependencies.md | 16 +++---- 3 files changed, 45 insertions(+), 45 deletions(-) diff --git a/CBOM/en/0x30-Anatomy-of-a-CBOM.md b/CBOM/en/0x30-Anatomy-of-a-CBOM.md index ae0b318..b9dbfe7 100644 --- a/CBOM/en/0x30-Anatomy-of-a-CBOM.md +++ b/CBOM/en/0x30-Anatomy-of-a-CBOM.md @@ -1,8 +1,8 @@ # Anatomy of a CBOM The Cryptography Bill of Materials (CBOM) presents a structured approach to inventory management of cryptographic assets, -leveraging the CycloneDX component model to represent a diverse array of cryptographic assets comprehensively. -CBOM is implemented within the CycloneDX object model, which facilitates the standardized representation of -cryptographic assets, including algorithms, keys, protocols, and certificates. The CycloneDX component model provides a +leveraging the CycloneDX component model to comprehensively represent a diverse array of cryptographic assets. +CBOM is implemented within the CycloneDX object model, facilitating the standardized representation of +cryptographic assets, including algorithms, keys, protocols, and certificates. The CycloneDX object model provides a flexible and extensible framework that accommodates the complexity and diversity of cryptographic infrastructure. ## Structure and Cryptographic Asset Types @@ -16,30 +16,30 @@ flexible and extensible framework that accommodates the complexity and diversity CycloneDX can represent the following types of cryptographic assets: -| Type | Description | -| ---- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| algorithm | Cryptographic function commonly used for data encryption, authentication, and digital signatures or other primitives. | -| certificate | An electronic document that is used to provide the identity or validate a public key. | -| protocol | A set of rules and guidelines that govern the behavior and communication with each other. | -| private-key | The confidential key of a key pair used in asymmetric cryptography. | -| public-key | The non-confidential key of a key pair used in asymmetric cryptography. | -| secret-key | A key used to encrypt and decrypt messages in symmetric cryptography. | -| key | A piece of information, usually an octet string, which, when processed through a cryptographic algorithm, process cryptographic data. | -| ciphertext | The result of encryption performed on plaintext using an algorithm (or cipher). | -| signature | A cryptographic value that is calculated from the data and a key known only by the signer. | -| digest | The output of the hash function. | -| initialization-vector | A fixed-size random or pseudo-random value used as an input parameter for cryptographic algorithms. | -| nonce | A random or pseudo-random number that can only be used once in a cryptographic communication. | -| seed | The input to a pseudorandom number generator. Different seeds generate different pseudorandom sequences. | -| salt | A non-secret value used in a cryptographic process, usually to ensure that the results of computations for one instance cannot be reused by an attacker. | -| shared-secret | A piece of data, known only to the parties involved, in a secure communication. | +| Type | Description | +| ---- |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| algorithm | Cryptographic function commonly used for data encryption, authentication, and digital signatures or other primitives. | +| certificate | An electronic document that provides the identity or validates a public key. | +| protocol | A set of rules and guidelines that govern the behavior and communication with each other. | +| private-key | The confidential key of a key pair used in asymmetric cryptography. | +| public-key | The non-confidential key of a key pair used in asymmetric cryptography. | +| secret-key | A key used to encrypt and decrypt messages in symmetric cryptography. | +| key | A piece of information, usually an octet string, which, when processed through a cryptographic algorithm, processes cryptographic data. | +| ciphertext | The result of encryption performed on plaintext using an algorithm (or cipher). | +| signature | A cryptographic value that is calculated from the data and a key known only by the signer. | +| digest | The output of the hash function. | +| initialization-vector | A fixed-size random or pseudo-random value used as an input parameter for cryptographic algorithms. | +| nonce | A random or pseudo-random number that can only be used once in a cryptographic communication. | +| seed | The input to a pseudo-random number generator. Different seeds generate different pseudo-random sequences. | +| salt | A value used in a cryptographic process, usually to ensure that the results of computations for one instance cannot be reused by an attacker. | +| shared-secret | A piece of data known only to the parties involved, in a secure communication. | | tag | A message authentication code (MAC), sometimes known as an authentication tag, is a short piece of information used for authenticating and integrity-checking a message. | -| additional-data | An unspecified collection of data with relevance to cryptographic activity. | -| password | A secret word, phrase, or sequence of characters used during authentication or authorization. | -| credential | Establishes the identity of a party to communication, usually in the form of cryptographic keys or passwords. | -| token | An object encapsulating a security identity. | -| other | Another type of cryptographic asset. | -| unknown | The type of cryptographic asset is not known. | +| additional-data | An unspecified collection of data with relevance to cryptographic activity. | +| password | A secret word, phrase, or sequence of characters used during authentication or authorization. | +| credential | Establishes the identity of a party to communication, usually in the form of cryptographic keys or passwords. | +| token | An object encapsulating a security identity. | +| other | Another type of cryptographic asset. | +| unknown | The type of cryptographic asset is not known. |
\newpage @@ -78,8 +78,8 @@ CycloneDX fully supports key states as detailed in the example below: ## Intersection of Key Management States and Lifecycle Phases As outlined in the [CycloneDX Authoritative Guide to SBOM](https://cyclonedx.org/guides/), CycloneDX supports lifecycles that encompass those in the Software Development Life Cycle (SDLC) and those commonly used in Software Asset Management -(SAM). CycloneDX lifecycle phases can be used together with the key management states defined by NIST to help in -identifying and preventing risks associated with compromised keys and operational anomalies. +(SAM). CycloneDX lifecycle phases can be used together with the key management states defined by NIST to help identify +and prevent risks associated with compromised keys and operational anomalies. CycloneDX defines the following phases: @@ -108,7 +108,7 @@ cryptographic assets and can identify potential risks more effectively.
### Manage Keys From Inception -In the CycloneDX lifecycle, the "Design" and "Pre-build" phases corresponds to the pre-activation state in key +In the CycloneDX lifecycle, the "Design" and "Pre-build" phases correspond to the pre-activation state in key management. During development, cryptographic keys are generated but not yet put into active use. By linking pre-activation with these phases, organizations can ensure that cryptographic keys are securely managed from their inception, minimizing the risk of unauthorized access or compromise before deployment. @@ -139,19 +139,19 @@ Any deviances from expected lifecycle mappings to key management states should b ![Lifecycles](../../images/Lifecycles.svg) ### Prevention of Compromised Keys During Build or Deployment -The compromised key management state, plays a crucial role in preventing software supply chain attacks when integrated +The compromised key management state is crucial in preventing software supply chain attacks when integrated into the "Build" lifecycle phase in CycloneDX. During the build phase, cryptographic keys are utilized to sign software artifacts, ensuring their authenticity and integrity. By leveraging the "compromised" state within CycloneDX, -organizations can detect compromised keys promptly and prevent their unauthorized usage during the build process. +organizations can detect compromised keys promptly and prevent unauthorized usage during the build process. For instance, if a key used for code signing is compromised, CycloneDX metadata can flag the key as compromised, triggering automated processes to revoke its access privileges and prevent its use in signing software artifacts. This proactive approach mitigates the risk of adversaries leveraging compromised keys to inject malicious code into the software supply chain, enhancing the security and trustworthiness of software builds distributed to software consumers. -By leveraging key management states within the context of the CycloneDX lifecycle phases, organizations can enhance -their risk management practices, proactively identify security vulnerabilities, and maintain the integrity of -cryptographic operations throughout the software development lifecycle. This integrated approach enables organizations -to effectively safeguard sensitive data and mitigate potential risks associated with cryptographic assets. +By leveraging key management states within the CycloneDX lifecycle phases, organizations can enhance their risk +management practices, proactively identify security vulnerabilities, and maintain the integrity of cryptographic +operations throughout the software development lifecycle. This integrated approach enables organizations to safeguard +sensitive data and mitigate potential risks associated with cryptographic assets.
diff --git a/CBOM/en/0x40-Practical-Examples.md b/CBOM/en/0x40-Practical-Examples.md index 099f3d7..c96935f 100644 --- a/CBOM/en/0x40-Practical-Examples.md +++ b/CBOM/en/0x40-Practical-Examples.md @@ -3,12 +3,12 @@ Examples of assets typically cataloged within a CBOM include algorithms, keys, p associated metadata crucial for effective management and security. Algorithms refer to the mathematical functions utilized for encryption, hashing, and digital signatures, while keys encompass cryptographic keys used for encryption, decryption, and authentication. Protocols delineate the rules and procedures governing secure communication between -entities and certificates authenticate the identities of entities within a cryptographic system. Associated CBOM metadata +entities, and certificates authenticate the identities of entities within a cryptographic system. Associated CBOM metadata includes details such as algorithm versions, key lengths, protocol configurations, and certificate attributes, providing comprehensive insights necessary for the management and security of cryptographic assets. ## Algorithm -A cryptographic algorithm is added in the components array of the BOM. The examples below lists the algorithm +A cryptographic algorithm is added in the components array of the BOM. The examples below list the algorithm AES-128-GCM and SHA512withRSA. ```json diff --git a/CBOM/en/0x41-Dependencies.md b/CBOM/en/0x41-Dependencies.md index 1e57e6c..6a9065f 100644 --- a/CBOM/en/0x41-Dependencies.md +++ b/CBOM/en/0x41-Dependencies.md @@ -8,12 +8,12 @@ A dependency graph is typically one node deep and capable of representing both d Refer to the [CycloneDX Authoritative Guide to SBOM](https://cyclonedx.org/guides/) for additional details. In the context cryptographic dependencies, CycloneDX provides some additional capabilities. -As of CycloneDX v1.6, there are two types of dependencies, dependsOn and provides. +As of CycloneDX v1.6, there are two types of dependencies: dependsOn and provides. -| Dependency Type | Description | -| --------------- |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| dependsOn | The bom-ref identifiers of the components or services that are dependencies of this dependency object. | -| provides | The bom-ref identifiers of the components or services that define a given specification or standard, which are provided or implemented by this dependency object. For example, a cryptographic library which implements a cryptographic algorithm. A component which implements another component does not imply that the implementation is in use. | +| Dependency Type | Description | +| --------------- |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| dependsOn | The bom-ref identifiers of the components or services that are dependencies of this dependency object. | +| provides | The bom-ref identifiers of the components or services that define a given specification or standard, which are provided or implemented by this dependency object. For example, a cryptographic library that implements a cryptographic algorithm. A component that implements another component does not imply that the implementation is in use. | The dependency type, dependsOn, is leveraged by classic SBOMs to define a complete graph of direct and transitive @@ -21,11 +21,11 @@ dependencies. However, for cryptographic and similar assets, "provides" allows f ![Dependencies](./images/dependencies.svg) -The example shows an application (nginx) that uses the libssl cryptographic library. This library implements the TLSv1.2 protocol. The relationship between the application, the library and the protocol can be expressed by using the depenedencies properties of the SBOM standard. +The example shows an application (nginx) that uses the libssl cryptographic library. This library implements the TLSv1.2 protocol. The relationship between the application, the library and the protocol can be expressed by using the dependencies properties of the SBOM standard. -Since a TLS protocol supports different cipher suites that include multiple algorithms, there should be a way to represent these relationships as part of the CBOM. Compared to adding the algorithms as "classic" dependencies to the protocol, we defined special property fields that allow referencing the deployment with additional meaning. The protocolProperties allow adding an array of algorithms to a cipher suite as part of the cipher suite array. By modeling and then referencing these algorithms, we can still have only one classical component at the SBOM level, but a subtree of crypto dependencies within the crypto asset components. +Since a TLS protocol supports different cipher suites that include multiple algorithms, there should be a way to represent these relationships as part of the CBOM. Compared to adding the algorithms as "classic" dependencies to the protocol, we defined special property fields that allow referencing the deployment with additional meaning. The protocolProperties allows adding an array of algorithms to a cipher suite as part of the cipher suite array. By modeling and then referencing these algorithms, we can still have only one classical component at the SBOM level but a subtree of crypto dependencies within the crypto asset components. -The following example illustrates a simple application with a dependency on a cryptographic library, which in turn, +The following example illustrates a simple application with a dependency on a cryptographic library, which, in turn, implements AES-128-GCM. The cryptographic library also has a dependency on another library. ```json