CII badging requirements aimed at Application Quality and Security

Tony Hansen
 

As an aid for continuing the conversation in yesterday’s SECCOM meeting, I added a sorting option for the names in the dashboard, so you can easily see which items are oriented toward which areas. The sorting lets you sort by “section” (Basics, Security, Reporting, etc) and “type” (Application Quality, FLOSS, Infrastructure, etc). Try this view of the dashboard:

 

http://tlhansen.us/onap/cii.html?turnoff=requirements,summary,projects,releasestats&sortby=bytype

 

Here are all of the CII requirements that are of the type Application Quality and in the section Security. A few are listed multiple times because they change from SHOULD to MUST in the higher level.

 

Hope this helps.

 

                Tony

 

Passing

 

crypto_call  

If the software produced by the project is an application or library, and its primary purpose is not to implement cryptography, then it SHOULD only call on software specifically designed to implement cryptographic functions; it SHOULD NOT re-implement its own.

 

crypto_keylength  

The security mechanisms within the software produced by the project MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012). It MUST be possible to configure the software so that smaller keylengths are completely disabled.

 

crypto_password_storage  

If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt).

 

crypto_pfs  

The security mechanisms within the software produced by the project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.

 

crypto_published  

The software produced by the project MUST use, by default, only cryptographic protocols and algorithms that are publicly published and reviewed by experts (if cryptographic protocols and algorithms are used).

 

crypto_random  

The security mechanisms within the software produced by the project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are cryptographically insecure.

 

crypto_weaknesses  

The default security mechanisms within the software produced by the project SHOULD NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH).

 

crypto_working 

 The default security mechanisms within the software produced by the project MUST NOT depend on broken cryptographic algorithms (e.g., MD4, MD5, single DES, RC4, Dual_EC_DRBG), or use cipher modes that are inappropriate to the context, unless they are necessary to implement an interoperable protocol (where the protocol implemented is the most recent version of that standard broadly supported by the network ecosystem, that ecosystem requires the use of such an algorithm or mode, and that ecosystem does not offer any more secure alternative). The documentation MUST describe any relevant security risks and any known mitigations if these broken algorithms or modes are necessary for an interoperable protocol.

 

vulnerabilities_critical_fixed  

Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.

 

vulnerabilities_fixed_60_days  

There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days.

 

Silver

 

assurance_case  

The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered. (URL required)

 

crypto_algorithm_agility  

The project SHOULD support multiple cryptographic algorithms, so users can quickly switch if one is broken. Common symmetric key algorithms include AES, Twofish, and Serpent. Common cryptographic hash algorithm alternatives include SHA-2 (including SHA-224, SHA-256, SHA-384 AND SHA-512) and SHA-3.

 

crypto_certificate_verification  

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

 

crypto_credential_agility  

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replace them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

 

crypto_tls12  

The software produced by the project SHOULD, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

 

crypto_used_network  

The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network communications, select 'not applicable' (N/A).

 

crypto_verification_private  

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

 

crypto_weaknesses (upgrade from Passing)

The default security mechanisms within the software produced by the project MUST NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH).

 

hardening

Hardening mechanisms SHOULD be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities.

 

implement_secure_design

The project MUST implement secure design principles (from 'know_secure_design'), where applicable. If the project is not producing software, select 'not applicable' (N/A).

 

input_validation

The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (a *whitelist*), and reject invalid inputs, if there are any restrictions on the data at all.

 

Gold

 

crypto_tls12 (upgrade from Silver)

The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

 

crypto_used_network (upgrade from Silver)

The software produced by the project MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 MUST be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network communications, select 'not applicable' (N/A).

 

hardening (upgrade from Silver)

Hardening mechanisms MUST be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities. (URL required)

 

security_review  

The project MUST have performed a security review within the last 5 years. This review MUST consider the security requirements and security boundary.

Join onap-seccom@lists.onap.org to automatically receive all group messages.