"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 Criteria
...
Criterion
Please fill in the survey questions for each of the following sections. In all cases, answer the questions from the point of view for YOUR application within ONAP.
For each one, additional information on the question is available to be read by clicking the arrow following the question.
Most items in this questionnaire are related to specific Best Practices Badging Criteria. The name of the associated criterion is listed at the end of the toggled "additional information" section, along with an indication of the badging level of the question, P=passing, S=silver and G=gold.
Once the security review is completed, the application owner can update the gold level badging question "security-review" as having been accomplished.
| Table of Contents |
|---|
Security Knowledge
...
| Your Answers-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Implement Secure Design
Do the committers and PTL apply secure design principles when reviewing software for merging?
...
| Cloak |
|---|
The project must implement secure design principles (from 'know secure design'). For example, the project results should have fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default). They should also have complete mediation (every access that might be limited must be checked for authority and be non-bypassable). Note that in some cases principles will conflict, in which case a choice must be made (e.g., many mechanisms can make things more complex, contravening 'economy of mechanism' / keep it simple). Implement secure design builds on the question above of "know secure design". For ONAP, the committers must all know the secure design principles and reviewing the code must always includes looking at it from the point of review of the security principles. It's crucial to document the secure design practices and software design/coding standards and code review. This NIST SSDF document provides additional details: [implement_secure_design S] |
| Your Answer-Please ExplainExplain | SECCOM Feedback / Recommendations |
|---|---|
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 Explain | SECCOM Feedback / Recommendations |
|---|---|
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 Explain | SECCOM Feedback / Recommendations |
|---|---|
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 Describe | SECCOM Feedback / Recommendations |
|---|---|
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.
...
| Your Answer-Please Describe | SECCOM Feedback / Recommendations |
|---|---|
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.
...
| Your Answer-Please Describe | SECCOM Feedback / Recommendations |
|---|---|
Vulnerability Mitigation
Vulnerabilities Critical Fixed
...
| Your Answer-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Vulnerabilities Fixed 60 Days
...
| Your Answer-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Non-Cryptographic Software Questions
...
| Your Answer-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Hardening
Does your project apply hardening mechanisms so that software defects are less likely to result in security vulnerabilities?
...
| Your Answer-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Cryptographic-specific Software Questions
...
| Your Answer-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Crypto Random - Generic
Does your software use random information? If so, does it use a cryptographically secure random number generator?
...
| Your Answers-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Crypto Weaknesses
Does your software depend on any cryptographic algorithms or modes that have known serious weaknesses?
...
| Your Answer-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Crypto Working
Does your software depend on any cryptographic algorithms that are known to be broken?
...
| 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. [crypto_working P] |
| Your Answer-Please ExplainExplain | SECCOM Feedback / Recommendations |
|---|---|
Crypto Keylength
Does your software generate any keys? If so, do they use any default key-lengths that are considered insecure?
...
| Your Answers-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
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?
...
| Your Answers-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Crypto Certificate Verification
Does your software use HTTPS? If so, does it do certificate verification of the host certificates by default?Toggle cloak
...
| Toggle cloak |
|---|
| Cloak |
|---|
This applies to both ingress into and egress from your project.
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: 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 Explain | SECCOM Feedback / Recommendations |
|---|---|
Crypto Credential Agility
...
| Your Answers-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Crypto TLS1.2
Does your software support HTTPS? If so, is the minimum version allowed TLS1.2?
...
| Your Answers-Please Explain | SECCOM 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?
...
| Your Answers-Please Explain | SECCOM Feedback / Recommendations |
|---|---|
Crypto Verification Private
...
| Your Answers-Please Explain | SECCOM Feedback / Recommendations |
|---|---|