Versions Compared

Old Version 4

changes.mady.by.user Joseph Keenan

Saved on

compared with

New Version Current

changes.mady.by.user Lee Anjella Macabuhay

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

"The project MUST have performed a security review within the last 5 years. This review MUST consider the security requirements and security boundary." – Best Practices Badging Criterion

...

Your Answers-Please ExplainSECCOM Feedback / Recommendations
Yes, the majority of the CPS team & PTL are aware of security best practices and are experienced in mitigation and vulnerability resolution.+1

Implement Secure Design

Do the committers and PTL apply secure design principles when reviewing software for merging?

...

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Yes CPS team/PTL/committers review and look for security issues and recommend fixes before merging.+1

Know Common Errors

Do the committers and PTL understand commonly found errors (and how to counter or mitigate them)? Do they apply these principles when reviewing software for merging?

...

Your Answers-Please ExplainSECCOM Feedback / Recommendations
Yes, the CPS team & PTL are aware of common security risks and how to mitigate them. There is are also security checks in our CI pipeline+1

No Leaked Credentials

Do the committers and PTL verify that there are no non-test credentials and no non-test private keys in code to be merged?

...

Your Answer-Please ExplainSECCOM Feedback / Recommendations

We do have clear text default credentials in our docker-compose files if not provided (Only used for testing). The users of CPS are expected to override credentials and strategies around these.

+1

Security Documentation

Documentation Architecture

...

If so, please provide a URL to the pages on wiki.onap.org or onap.readthedocs.io that have the architecture or high level design. If not, please describe the high level design here using one or more paragraphs.

...

Your Answer-Please DescribeSECCOM Feedback / Recommendations

Yes, CPS architecture

doc

documentation can be found @ https://docs.onap.org/projects/onap-cps/en/latest/architecture.html

 

Documentation Security

Does your project have a description of what a user of your project can and cannot expect in terms of security from the software produced by the project, (In other words, what are its 'security requirements'?)

If so, please provide a URL to the page(s) on wiki.onap.org or onap.readthedocs.io. If not, please describe the security requirements here using one or more paragraphs.

...

These are the security requirements that the software is intended to meet.

There needs to be:

...

[documentation_security S]

...

Assurance Case

Does your project actually meet its documented security requirements?

...

*Page is being updated for the next release to reflect that the architecture diagram reflects the latest release. (https://gerrit.onap.org/r/c/cps/+/133557)

The ONAP architecture diagram (London-R12 Architecture diagram) is displayed on Configuration Persistence Service Project wiki as part of explaining the project's concept

Please refer to the latest ONAP architecture diagram.

London-R12 Architecture Diagram

Documentation Security

Does your project have a description of what a user of your project can and cannot expect in terms of security from the software produced by the project, (In other words, what are its 'security requirements'?)

If so, please provide a URL to the page(s) on wiki.onap.org or onap.readthedocs.io that describe how the project meets its security goals. If . If not, please describe the security requirements here ( using one or more paragraphs) how the project meets its security goals.

Toggle cloak
 Cloak
For ONAP, somewhere in the project's description, there needs to be (as indicated above)These are the security requirements that the software is intended to meet.
There needs to be:
  • a description of how the project met the threat model,a description of how the project maintains the trust boundaries,an argument that secure design principles have been applied, andan argument that common implementation security weaknesses have been countered.
This may be combined with the "documentation security" document.
[assurance_case S]
...
  • clear identification of trust boundaries,
  • how the software expects to deal with the threat model and trust boundaries
[documentation_security S]

Your Answer-Please DescribeSECCOM Feedback / Recommendations
Vulnerability Mitigation
Vulnerabilities Critical Fixed
Have you closed all issues filed against your project in sonarcloud that are CRITICAL or BLOCKERs?
...
 Cloak
All critical vulnerabilities should be fixed rapidly after they are reported.
[vulnerabilities_critical_fixed P]
...
Yes, CPS sonarcloud reports can be found @
https://sonarcloud.io/organizations/onap/projects?search=cps&sort=-coverage
https://sonarcloud.io/organizations/onap/projects?search=ncmp-dmi-plugin&sort=-coverage
Vulnerabilities Fixed 60 Days
Are all vulnerabilities that are reported against your project, either through an OJSI ticket or publicly from CVE reports, fixed within two months of being reported?
...
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.
The vulnerability must be patched and released by the project itself (patches may be developed elsewhere). A vulnerability becomes publicly known (for this purpose) once it has a CVE with publicly released non-paywalled information (reported, for example, in the National Vulnerability Database) or when the project has been informed and the information has been released to the public (possibly by the project). A vulnerability is considered medium or higher severity if its Common Vulnerability Scoring System (CVSS) base qualitative score is medium or higher. In CVSS versions 2.0 through 3.1, this is equivalent to a CVSS score of 4.0 or higher. Projects may use the CVSS score as published in a widely-used vulnerability database (such as the National Vulnerability Database) using the most-recent version of CVSS reported in that database. Projects may instead calculate the severity themselves using the latest version of CVSS at the time of the vulnerability disclosure, if the calculation inputs are publicly revealed once the vulnerability is publicly known. Note: this means that users might be left vulnerable to all attackers worldwide for up to 60 days. This criterion is often much easier to meet than what Google recommends in Rebooting responsible disclosure, because Google recommends that the 60-day period start when the project is notified even if the report is not public. Also note that this applies to each individual project in ONAP. Once a patch is available from each individual project, others can determine how to deal with the patch (e.g., they can update to the newer version or they can apply just the patch as a cherry-picked solution).
...
None available
CPS don’t have security requirements apart from the authentication on our rest API wherein username and passwords are configurable
Configuration Persistence Service Project#CPSSECURITYREQUIREMENTS
Please refer to the latest ONAP architecture diagram.
London-R12 Architecture Diagram
Please elaborate this statement: "Usernames and passwords are configurable by the clients via configuring the application .yml file".
Expectation: passwords are not in yml file. The yml should point to user store (e.g. LDAP or K8s secrets). 
+1
Assurance Case
Does your project actually meet its documented security requirements?
If so, please provide a URL to the page(s) on wiki.onap.org or onap.readthedocs.io that describe how the project meets its security goals. If not, please describe here (using one or more paragraphs) how the project meets its security goals.
 Toggle cloak
 Cloak
For ONAP, somewhere in the project's description, there needs to be (as indicated above):
  • a description of how the project met the threat model,
  • a description of how the project maintains the trust boundaries,
  • an argument that secure design principles have been applied, and
  • an argument that common implementation security weaknesses have been countered.
This may be combined with the "documentation security" document.
[assurance_case S]

Your Answer-Please DescribeSECCOM Feedback / Recommendations
Configuration Persistence Service Project#CPSSECURITYREQUIREMENTS
CPS don’t have security requirements apart from the authentication on our rest API wherein username and passwords are configurable.
CPS has no logging of sensitive information such as usernames and passwords in plain text. The log files are only accesible withing the  authorized users of the application deployment.
CPS is in the process (as part of ONAP service mesh implementation) of migrating to service mesh, currently CPS application is fully-compatible with all the requirements, to provide encryption in transit to avoid unauthorized accesses and data breaches.
CPS does not run docker containers or services as 'root'.

Please add these statements to a new Security Assurance section just after: Configuration Persistence Service Project#CPSSECURITYREQUIREMENTS. — these statements are the same as under security requirements
Also add statements that indicate how you protect your username and password configurations. (See other questions on hashing of secrets, use of crypto and permissions on files.)
Vulnerability Mitigation
Vulnerabilities Critical Fixed
Have you closed all issues filed against your project in sonarcloud that are CRITICAL or BLOCKERs?
 Toggle cloak
 Cloak
All critical vulnerabilities should be fixed rapidly after they are reported.
[vulnerabilities_critical_fixed P]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Non-Cryptographic Software Questions
The following are a few issues regarding your project's software as delivered that are not cryptographic-related.
Input Validation
...
Yes, CPS sonarcloud reports can be found @
https://sonarcloud.io/organizations/onap/projects?search=cps&sort=-coverage
https://sonarcloud.io/organizations/onap/projects?search=ncmp-dmi-plugin&sort=-coverage
+1
Vulnerabilities Fixed 60 Days
Are all vulnerabilities that are reported against your project, either through an OJSI ticket or publicly from CVE reports, fixed within two months of being reported?
 Toggle cloak
 Cloak
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.
The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (an *allowlist*), and reject invalid inputs, if there are any restrictions on the data at all.
Note that comparing input against a list of 'bad formats' (aka a *denylist*) is normally not enough, because attackers can often work around a denylist. In particular, numbers are converted into internal formats and then checked if they are between their minimum and maximum (inclusive), and text strings are checked to ensure that they are valid text patterns (e.g., valid UTF-8, length, syntax, etc.). Some data may need to be 'anything at all' (e.g., a file uploader), but these would typically be rare.
[input_validation S]
...
Hardening
Does your project apply hardening mechanisms so that software defects are less likely to result in security vulnerabilities?
...
 Cloak
If you compile code into binary executables, do you use
  • compiler flags to mitigate attacks (such as -fstack-protector)?
  • compiler flags to eliminate undefined behavior?
  • special build features like Address Sanitizer (ASAN) (if available)?
If your project provides a web user interface:
  • Does it require the hardening headers: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as 'nosniff'), and X-Frame-Options?
  • If your web site were to be passed to a website such as <securityheaders.com>, would you get a grade of A or B?
  • Are administrative web pages shown or listed only if the logged in user is an administrator?
  • Are your JavaScript and CSS served from separate files?
  • Do you use HTTP to HTTPS redirects?
  • Do you use HSTS?
  • If appropriated, do you do rate limiting to prevent DOS attacks?
  • Do you employ measures to resist Cross Site Request Forgeries (CSRFs)?
  • Do your cookies use settings to counter Javascript-based attacks, set secure=true, and counter CSRF using a SameSite value?
  • Do you protect use of target='_blank' with rel="noopener noreferrer"?
If your project generates email:
  • Do you take measures for rate limiting?
  • Do you encrypt the email addresses that might be stored in a database?
If your project uses a database:
  • Do you encrypt values that are sensitive?
[hardening SG]
...
Cryptographic-specific Software Questions
The following questions all deal with cryptographic issues.
Crypto Call – Generic
Does your software implement any cryptographic functions, such as hash functions, instead of calling on software specifically designed to implement cryptographic functions?
...
 Cloak
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_call Pvulnerability must be patched and released by the project itself (patches may be developed elsewhere). A vulnerability becomes publicly known (for this purpose) once it has a CVE with publicly released non-paywalled information (reported, for example, in the National Vulnerability Database) or when the project has been informed and the information has been released to the public (possibly by the project). A vulnerability is considered medium or higher severity if its Common Vulnerability Scoring System (CVSS) base qualitative score is medium or higher. In CVSS versions 2.0 through 3.1, this is equivalent to a CVSS score of 4.0 or higher. Projects may use the CVSS score as published in a widely-used vulnerability database (such as the National Vulnerability Database) using the most-recent version of CVSS reported in that database. Projects may instead calculate the severity themselves using the latest version of CVSS at the time of the vulnerability disclosure, if the calculation inputs are publicly revealed once the vulnerability is publicly known. Note: this means that users might be left vulnerable to all attackers worldwide for up to 60 days. This criterion is often much easier to meet than what Google recommends in Rebooting responsible disclosure, because Google recommends that the 60-day period start when the project is notified even if the report is not public. Also note that this applies to each individual project in ONAP. Once a patch is available from each individual project, others can determine how to deal with the patch (e.g., they can update to the newer version or they can apply just the patch as a cherry-picked solution).
[vulnerabilities_fixed_60_days P]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Yes. Critical vulnerabilities/issues are compiled by SECCOM periodically and CPS project team resolves them in-time for current/prev release.
We also check sonarcloud reports on a weekly basis and if needed action is taken.
+1

Non-Cryptographic Software Questions
The following are a few issues regarding your project's software as delivered that are not cryptographic-related.
Input Validation
Does your application accept input from potentially untrusted sources? If so, do you ensure that the input is valid before processing it?
 Toggle cloak
 Cloak
The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (an *allowlist*), and reject invalid inputs, if there are any restrictions on the data at all.
Note that comparing input against a list of 'bad formats' (aka a *denylist*) is normally not enough, because attackers can often work around a denylist. In particular, numbers are converted into internal formats and then checked if they are between their minimum and maximum (inclusive), and text strings are checked to ensure that they are valid text patterns (e.g., valid UTF-8, length, syntax, etc.). Some data may need to be 'anything at all' (e.g., a file uploader), but these would typically be rare.
[input_validation S]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Our application expects (any) client to upload models and data to be stored.
These models and data are validated via the 3rd party tool - OpenDayLight Yang parser which is part of CPS and not a separate microservice. These are only stored once the parser accepts that it is valid and returns an exception for invalid models and data.
Additionally, inputs to all REST endpoints are validated, e.g. CM handle IDs, CPS paths, timestamps


+1

Hardening
Does your project apply hardening mechanisms so that software defects are less likely to result in security vulnerabilities?
 Toggle cloak
 Cloak
If you compile code into binary executables, do you use
  • compiler flags to mitigate attacks (such as -fstack-protector)?
  • compiler flags to eliminate undefined behavior?
  • special build features like Address Sanitizer (ASAN) (if available)?
If your project provides a web user interface:
  • Does it require the hardening headers: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as 'nosniff'), and X-Frame-Options?
  • If your web site were to be passed to a website such as <securityheaders.com>, would you get a grade of A or B?
  • Are administrative web pages shown or listed only if the logged in user is an administrator?
  • Are your JavaScript and CSS served from separate files?
  • Do you use HTTP to HTTPS redirects?
  • Do you use HSTS?
  • If appropriated, do you do rate limiting to prevent DOS attacks?
  • Do you employ measures to resist Cross Site Request Forgeries (CSRFs)?
  • Do your cookies use settings to counter Javascript-based attacks, set secure=true, and counter CSRF using a SameSite value?
  • Do you protect use of target='_blank' with rel="noopener noreferrer"?
If your project generates email:
  • Do you take measures for rate limiting?
  • Do you encrypt the email addresses that might be stored in a database?
If your project uses a database:
  • Do you encrypt values that are sensitive?
[hardening SG]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
CPS does not have a UI and does not use javascript
The application uses Swagger for RESTful API, wherein it is set that Authorization headers are required for accessing API documentation.
When CPS is run with docker, the services use usernames and passwords that are stored as environment variables.
While for testing purposes, all credentials are hard-coded, for deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.x
How are usernames and passwords stored?
Are passwords stored hashed where CPS acts as an authenticator?
Please refer to comment above in Documentation security.
As it is not part of the production: +1


Cryptographic-specific Software Questions
The following questions all deal with cryptographic issues.
Crypto Call – Generic
Does your software implement any cryptographic functions, such as hash functions, instead of calling on software specifically designed to implement cryptographic functions?
 Toggle cloak
 Cloak
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_call P]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
N/A
Crypto Random - Generic
Does your software use random information? If so, does it use a cryptographically secure random number generator?
 Toggle cloak
 Cloak
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.
A cryptographically secure random number generator may be a hardware random number generator (/dev/random), or it may be a cryptographically secure pseudo-random number generator (CSPRNG) using an algorithm such as Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow, or Fortuna. Examples of calls to secure random number generators include Java's java.security.SecureRandom and JavaScript's window.crypto.getRandomValues. Examples of calls to insecure random number generators include Java's java.util.Random and JavaScript's Math.random.
For additional guidance and examples about what kind of specifications to rate a random bit generator (RBG) please review: 
[crypto_random P]

Your Answers-Please ExplainSECCOM Feedback / Recommendations
CPS does generate random UUIDs for notifications. These UUIDs are generated via the built in java libraries (java.util.UUID).
+1
Crypto Weaknesses
Does your software depend on any cryptographic algorithms or modes that have known serious weaknesses?
 Toggle cloak
 Cloak
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 algorithms, or the CBC mode in SSH).
Concerns about CBC mode in SSH are discussed in CERT: SSH CBC vulnerability.
[crypto_weaknesses PS]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Crypto Random - Generic
Does your software use random information? If so, does it use a cryptographically secure random number generator?
...
 Cloak
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.
A cryptographically secure random number generator may be a hardware random number generator (/dev/random), or it may be a cryptographically secure pseudo-random number generator (CSPRNG) using an algorithm such as Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow, or Fortuna. Examples of calls to secure random number generators include Java's java.security.SecureRandom and JavaScript's window.crypto.getRandomValues. Examples of calls to insecure random number generators include Java's java.util.Random and JavaScript's Math.random.
For additional guidance and examples about what kind of specifications to rate a random bit generator (RBG) please review: 
[crypto_random P]
...
Crypto Weaknesses
Does your software depend on any cryptographic algorithms or modes that have known serious weaknesses?
...
 Cloak
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 algorithms, or the CBC mode in SSH).
Concerns about CBC mode in SSH are discussed in CERT: SSH CBC vulnerability.
[crypto_weaknesses PS]
...
Crypto Working
...
Recommendations
Usernames and passwords are configurable by the clients via passing the environment variables for use in application.yml file.
When CPS is run with docker, the services use username and passwords that are stored as environment variables.
For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.
Please refer to comment above in Documentation security.
Crypto Working
Does your software depend on any cryptographic algorithms that are known to be broken?
 Toggle cloak
 Cloak
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.
ECB mode is almost never appropriate because it reveals identical blocks within the ciphertext as demonstrated by the ECB Penguin, and CTR mode is often inappropriate because it does not perform authentication and causes duplicates if the input state is repeated. In many cases it's best to choose a block cipher algorithm mode designed to combine secrecy and authentication, e.g., Galois/Counter Mode (GCM) and EAX. Projects MAY allow users to enable broken mechanisms (e.g., during configuration) where necessary for compatibility, but then users know they're doing it.
[crypto_working P]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Usernames and passwords are configurable by the clients via passing the environment variables for use in application.yml file.
When CPS is run with docker, the services use username and passwords that are stored as environment variables.
For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.
Please refer to comment above in Documentation security.
Crypto Keylength
Does your software generate any keys? If so, do they use any default key-lengths that are considered insecure?
 Toggle cloak
 Cloak
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.
ECB mode is almost never appropriate because it reveals identical blocks within the ciphertext as demonstrated by the ECB Penguin, and CTR mode is often inappropriate because it does not perform authentication and causes duplicates if the input state is repeated. In many cases it's best to choose a block cipher algorithm mode designed to combine secrecy and authentication, e.g., Galois/Counter Mode (GCM) and EAX. Projects MAY allow users to enable broken mechanisms (e.g., during configuration) where necessary for compatibility, but then users know they're doing it.
[crypto_working P]
...
use default key-lengths 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 key-lengths are completely disabled.
These minimum bit-lengths are: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, and hash 224 (password hashing is not covered by this bit-length, more information on password hashing can be found in the Crypto Password Storage question). See <www.keylength.com> for a comparison of key-length recommendations from various organizations. The software MAY allow smaller key-lengths in some configurations (ideally it would not, since this allows downgrade attacks, but shorter key-lengths are sometimes necessary for interoperability).
[crypto_keylength P]

Your Answers-Please ExplainSECCOM Feedback / Recommendations
CPS does not generate any keys+1
Crypto Algorithm Agility
Does your software use cryptographic algorithms? If so, can a user of ONAP switch the algorithm if one is found to be broken?
 Toggle cloak
 Cloak
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_algorithm_agility S]

Your Answers-Please ExplainSECCOM Feedback / Recommendations
...
For deployments, CPS uses K8s secrets that are generated and stored as CPS is deployed.
CPS relies on java.UUID mechanism for generating unique identifiers.
+1
Crypto Certificate Verification
Does your software generate any keysuse HTTPS? If so, do they use any default key-lengths that are considered insecuredoes it do certificate verification of the host certificates by default?
 Toggle cloak
 Cloak
The security mechanisms within the software produced by the project MUST use default key-lengths 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 key-lengths are completely disabled.
These minimum bit-lengths are: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, and hash 224 (password hashing is not covered by this bit-length, more information on password hashing can be found in the Crypto Password Storage question). See <www.keylength.com> for a comparison of key-length recommendations from various organizations. The software MAY allow smaller key-lengths in some configurations (ideally it would not, since this allows downgrade attacks, but shorter key-lengths are sometimes necessary for interoperability).
[crypto_keylength P]
...
Crypto Algorithm Agility
Does your software use cryptographic algorithms? If so, can a user of ONAP switch the algorithm if one is found to be broken?
...
 Cloak
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_algorithm_agility This applies to both ingress into and egress from your project.
  • For ingress, this applies to validation of the client certificates coming into your system.
  • For egress, this applies to validation of the host certificates for external systems that your system reads from or sends to.
The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on sub-resources.
Note that incorrect TLS certificate verification is a common mistake. For more information, see The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software by Martin Georgiev et al. and Do you trust this application? by Michael Catanzaro.
Note: One aspect of this is that, if something is missing that prevents the TLS from working, the software must NOT fall back to insecure mode but must instead prevent communication. If an insecure mode is allowed, it MUST be explicitly configured.
Note 2: If all of your traffic, either ingress or egress, is travelling through the ONAP mesh, then make a statement about that.
[crypto_certificate_verification S]

Your Answers-Please ExplainSECCOM Feedback / Recommendations
Crypto Certificate Verification
Does your software use HTTPS? If so, does it do certificate verification of the host certificates by default?
...
 Cloak
This applies to both ingress into and egress from your project.
  • For ingress, this applies to validation of the client certificates coming into your system.
  • For egress, this applies to validation of the host certificates for external systems that your system reads from or sends to.
The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on sub-resources.
Note that incorrect TLS certificate verification is a common mistake. For more information, see The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software by Martin Georgiev et al. and Do you trust this application? by Michael Catanzaro.
Note: One aspect of this is that, if something is missing that prevents the TLS from working, the software must NOT fall back to insecure mode but must instead prevent communication. If an insecure mode is allowed, it MUST be explicitly configured.
Note 2: If all of your traffic, either ingress or egress, is travelling through the ONAP mesh, then make a statement about that.
[crypto_certificate_verification S]
...
Crypto Credential Agility
...
SECCOM Feedback / Recommendations
CPS is compliant and compatible with the ongoing service mesh implementation (see https://gerrit.onap.org/r/c/oom/+/124287) for ONAP. 
CPS service port names has been changed to include http in name.
+1
Crypto Credential Agility
Does your software save or process authentication credentials or private cryptographic keys? If so, is that information stored separately from other information?
 Toggle cloak
 Cloak
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.
[crypto_credential_agility S]

Your Answers-Please ExplainSECCOM Feedback / Recommendations
Usernames and passwords are configurable by the clients via passing the environment variables for use in application.yml file.
When CPS is run with docker, the services use username and passwords that are stored as environment variables.
For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.
Please refer to comment above in Documentation security.
Crypto TLS1.2
Does your software support HTTPS? If so, is the minimum version allowed TLS1.2?
 Toggle cloak
 Cloak
The software produced by 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 it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL.
[crypto_credential_agility Stls12 SG]

Your Answers-Please ExplainSECCOM Feedback / Recommendations
...
CPS is compliant and compatible with the ongoing service mesh implementation (see https://gerrit.onap.org/r/c/oom/+/124287) for ONAP. 
CPS service port names has been changed to include http in name.
+1
Crypto Used Network
Does your software support HTTPShave network communications inbound or outbound? If so, is the minimum version allowed TLS1.2do you support secure protocols for all such network communications?
 Toggle cloak
 Cloak
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 SSLsupport 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.
[crypto_tls12 used_network SG]

Your Answers-Please ExplainSECCOM Feedback / Recommendations
Crypto Used Network
Does your software have network communications inbound or outbound? If so, do you support secure protocols for all such network communications?
...
 Cloak
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.
[crypto_used_network SG]
Your Answers-Please ExplainSECCOM Feedback / Recommendations
CPS only communicates with components within ONAP.
CPS's primary communication is through HTTP.
CPS uses KAFKA, and as a listener, in KAFKA we use PLAINTEXT communication, which is also KAFKA's default for communication, at a later stage the Kafka provider ( eg. Apache, Confluent, or Strimizi Kafka [which is planned to be used] ) can enable the security by default i.e the default way of communication.
CPS components are deployed within a pod, all communications in PLAINTEXT are within the pod. Any communication outside the pods is managed via the service mesh.

+1
Crypto Verification Private
...
Your Answers-Please ExplainSECCOM Feedback / Recommendations
CPS is compliant and compatible with the ongoing service mesh implementation (see https://gerrit.onap.org/r/c/oom/+/124287) for ONAP. 
CPS service port names has been changed to include http in name.
+1