"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
| NOTE: THIS PAGE IS UNDER CONSTRUCTION BY DCAE |
|---|
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.
| Table of Contents |
|---|
Security Knowledge
Know Secure Design
Do the committers and PTL know how to design secure software? Do the reviewers of OJSI tickets know secure design?
...
| Your Answers-Please Explain |
|---|
| Yes. Majority of DCAE committers and PTL are generally familiar with secure software development practice and experienced in vulnerability resolution. The CLM scan reports and OJSI tickets are periodically assessed by the same PTL/committers. |
Implement Secure Design
Do the committers and PTL apply secure design principles when reviewing software for merging?
...
| Your Answer-Please Explain |
|---|
| Yes, DCAE PTL/committers do review for security design principles adhrence before merging code. |
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 | TBA
|---|
No Leaked Credentials
...
| PTL/most committers do understand and make effort to mitigate these errors during reviews. A session on security/quality checkpoints will be organized for London to get all new committers up to speed. |
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 |
|---|
| Yes, all DCAE patches are verified to ensure non-test credentials/private keys are not included in the code/repositories |
Security Documentation
Documentation Architecture
Does your project have an architecture or high level design documented?
...
| Your Answer-Please Describe |
|---|
| Yes. DCAE architecture is maintained under ONAP RTD - https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/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'?)
...
| Your Answer-Please Describe |
|---|
| Yes. Documented under this wiki DCAE Security Design & Assurance |
Assurance Case
Does your project actually meet its documented security requirements?
...
| Your Answer-Please Describe |
|---|
| Yes. Documented under this wiki DCAE Security Design & Assurance |
Vulnerability Mitigation
Vulnerabilities Critical Fixed
Have you closed all issues filed against your project in sonarcloud that are CRITICAL or BLOCKERs?
...
| Your Answer-Please Explain |
|---|
| Mostly YES. Majority of the projects have no/minimal vulnerabities and blocker issues reported from SONARCLOUD for DCAE components - https://sonarcloud.io/organizations/onap/projects?search=dcaegen2&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?
...
| Your Answer-Please Explain |
|---|
| Yes. Critical vulnerabilities/issues are compiled by SECCOM periodically and DCAE project team resolves them in-time for current/prev release. |
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?
...
| Your Answer-Please Explain |
|---|
DCAE has different types of components/microservices Collectors: All DCAE collectors interface with external network element (trusted/untrusted depending on protocol/interface) however data validation is done in most cases.
EventProcessors/Analytics - These components do not accept data from external sources (i.e outside ONAP) and work through data coming via DMAAP (internal to ONAP) |
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
If your project provides a web user interface:
If your project generates email:
If your project uses a database:
[hardening] |
| Your Answer-Please Explain |
|---|
Majority of DCAE services are complaint. There are no C/C++ code in DCAE repositories hence compiler flags related questions do not apply. DL-Admin has a web (user) interface which is not complaint with all hardening requirements listed; it also stores external DB credentials (TBD if data is encryped/hashed when persisted in DB). |
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?
...
| Your Answer-Please Explain |
|---|
| DCAE does not include any internal module to implement cryptography - strictly uses AAF (currently) and OOM/ServiceMesh for supporting them. |
Crypto Random - Generic
Does your software use random information? If so, does it use a cryptographically secure random number generator?
...
| Your Answers-Please Explain |
|---|
| DCAE does not generate any cryptographic keys and/or nonces. Need to ensure DL-Admin updates planned are compliant with this requirement in future release. |
Crypto Weaknesses
Does your software depend on any cryptographic algorithms or modes that have known serious weaknesses?
...
| Your Answer-Please Explain |
|---|
No such known dependency exist currently. Need to ensure DL-Admin updates planned are compliant with this requirement in future release. |
Crypto Working
Does your software depend on any cryptographic algorithms that are known to be broken?
...
| Your Answer-Please Explain |
|---|
No such known dependency exist currently. Need to ensure DL-Admin updates planned are compliant with this requirement in future release. |
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 |
|---|
| DCAE does not generate keys |
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 |
|---|
Not currently however need to ensure ensure DL-Admin updates planned are compliant with this requirement in future release. |
Crypto Certificate Verification
Does your software use HTTPS? If so, does it do certificate verification of the host certificates by default?
| Toggle cloak |
|---|
| Cloak |
|---|
| The software produced by the project MUST, if 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. [crypto_certificate_verification] |
...
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?
...
| Cloak |
|---|
| The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are Note 2: If all of your traffic, either ingress or egress, is travelling through the ONAP mesh, then make a statement about that. |
| Your Answers-Please Explain |
|---|
As of Kohn, DCAE component default deployment is set for non-TLS (in OOM charts) however the ServiceMesh integration will ensure both inter and intra ONAP component communication is supported under TLS. To be confirmed if host certificate validation is done under Service Mesh. |
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] |
...
, and logs), and permit users to update and replace them without code recompilation. [crypto_credential_agility] |
| Your Answers-Please Explain |
|---|
In general the application credentials are stored as K8S secret and application config under K8S Configmap. For application config processing simplification, these are combined into single file within K8S pod/container (true when credentials are maintained part of microservice charts). With migration to SVC mesh, most component charts are being updated to remove independent K8S secret in Kohn, any remaining updates will be completed by London release. |
Crypto TLS1.2
Does your software support HTTPS? If so, is the minimum version allowed TLS1.2?
...
| 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 SSL. [crypto_tls12] |
...
] |
| Your Answers-Please Explain |
|---|
| Yes, all DCAE component support mininum TLSv1.2 (when enabled for HTTPS) |
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] |
...
user specifically configures it. [crypto_used_network] |
| Your Answers-Please Explain |
|---|
Yes, most DCAE components (collectors) support secure external interfaces with exception of SNMPTRap which is based on UDP protocol. FTP (DFC), HTTP (VES) are supported options but disabled by default. |
Crypto Verification Private
Does your software use outbound HTTPS connections? If so, does it perform certificate verification before sending HTTP headers with private information (such as secure cookies)
...
| Your Answers-Please Explain |
|---|
| All DCAE components uses standard libraries for HTTPS calls (java components use java11 libraries and python components uses request library). These lib's are externally managed and we believe these requirements for certificate verification before sending HTTP headers are being met. |