DCAE - ONAP Security Review Questionnaire

"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 [security-review G]


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.

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 ExplainSECCOM Feedback / Recommendations
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. (Based on managerial assessment of the committers' knowledge.)

<Muddasar>Are there any efforts/means within DCAE team to ensure all contributors and committers are familiar with Sec-SDLC practices?

CLM Scans and OJSI tickets are scanned, what is the efficacy of such reviews?  Is it reducing downstream discoveries of issues?

Implement Secure Design

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

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Yes, DCAE PTL/committers do review for security design principles adherence before merging code. (There is a checklist that committers should be following that includes looking at secure design issues.)<Muddasar>. Is this done based on memory or based on a checklist/helper app?

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
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. 

<Muddasar>. Could we use this opportunity to record and save the session?  this may be helpful for new team members.

Amy Zwarico the findings and recommendations from SonarCloud will help educate the developers

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
Yes, all DCAE patches are verified to ensure non-test credentials/private keys are not included in the code/repositories

<Muddasar> can this be associated with a scan report to reduce human errors?  SCAN for credentials be part of testing.

Amy Zwarico  use SonarCloud to find any embedded credentials

Security Documentation

Documentation Architecture

Does your project have an architecture or high level design documented?

If so, please provide a URL to the pages on wiki.onap.org or onap.readthedocs.io  or docs.onap.org 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. 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'?)

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 DescribeSECCOM Feedback / Recommendations
Yes. Documented under this wiki DCAE Security Design & Assurance <Muddasar>. description is clear on the link provided. It is a good effort.  Wondering if this information is added to DCAE user documentation.  Also, CONSUL app protection and data protections should be considered some where, it is not in scope for DCAE, is it inscape somewhere else?

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 DescribeSECCOM Feedback / Recommendations
Yes. Documented under this wiki DCAE Security Design & Assurance 

<Muddasar> wiki does not constitute documented security requirements.  it merely tells what DCAE team usually do.  This area can be improved to describe Security requirements and aligned with how these are met.

Amy Zwarico SECCOM developed security requirements years ago.

Vulnerability Mitigation

Vulnerabilities Critical Fixed

Have you closed all issues filed against your project in sonarcloud that are CRITICAL or BLOCKERs?

Your Answer-Please ExplainSECCOM Feedback / Recommendations
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

<Muddasar>. this can be termed as a quality matrix.  days open/TTR etc  should be tracked.  self-induced vs external, or code, review, test escape/

Amy Zwarico Agreed. That data is available in SonarCloud, but at the moment we cannot get the API working. (sad)

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 ExplainSECCOM Feedback / Recommendations
Yes. Critical vulnerabilities/issues are compiled by SECCOM periodically and DCAE project team resolves them in-time for current/prev release.

<Muddasar>. this can be termed as a quality matrix.  days open/TTR etc  should be tracked.  self-induced vs external, or code, review, test escape/

Amy Zwarico  there is a small vulnerability team that manages this. It is very rare to get a vuln reported against the ONAP platform. 99% are reported against LF tools such. Agreed that ONAP should track.


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 ExplainSECCOM Feedback / Recommendations

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.

VESCollector/HV-VES - Data validation done on event receipt and rejected if non-conforming to the expected spec. Both collectors are expected to recieve data from any xNF.

  • DFC/RESTConf/SNMPTrap - Data validation done during post processing of the events in the northbound flow. DFC and RESTConf accepts events only from configured xNF, SNMPTrap collector is listener services accepts any traps sent to it.

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)

<Muddasar>. shouldn't collectors validate data source/sender?  known vs unknown sender and degree of trust?

Amy Zwarico There should be tests for all external interfaces that include fuzzing, etc.

Hardening

Does your project apply hardening mechanisms so that software defects are less likely to result in security vulnerabilities?

Your Answer-Please ExplainSECCOM Feedback / Recommendations

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 encrypted/hashed when persisted in DB).

<Muddasar> How should we measure security vulnerability stemming from unharden code?  vulnerabilities discovered after integration stage, release stage may be?


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 ExplainSECCOM Feedback / Recommendations
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 ExplainSECCOM Feedback / Recommendations
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 ExplainSECCOM Feedback / Recommendations

No such known dependency exists 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 ExplainSECCOM Feedback / Recommendations

No such known dependency exists currently.

Need to ensure DL-Admin updates planned are compliant with this requirement in future release.

Amy Zwarico SonarCloud finds broken algos in TLS and other crypto in the code

Crypto Keylength

Does your software generate any keys? If so, do they use any default key-lengths that are considered insecure?

Your Answers-Please ExplainSECCOM Feedback / Recommendations
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 ExplainSECCOM Feedback / Recommendations

Not currently however need to ensure DL-Admin updates planned are compliant with this requirement in future release.

Amy Zwarico standard configurations of TLS generally support multiple ciphers


Crypto Certificate Verification

Does your software use HTTPS? If so, does it do certificate verification of the host certificates by default?

Your Answers-Please ExplainSECCOM Feedback / Recommendations

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.

<Muddasar> can a user change the default behavior? if default is non-TLS, does documentation clearly indicate how to change the default behavior?  

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?

Your Answers-Please ExplainSECCOM Feedback / Recommendations

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?

Your Answers-Please ExplainSECCOM Feedback / Recommendations
Yes, all DCAE component support mininum TLSv1.2 (when enabled for HTTPS)

Amy Zwarico there is an integration test that checks for TLS and I think for the version.


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 ExplainSECCOM Feedback / Recommendations

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. 

<Muddasar> SNMP ver?


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 ExplainSECCOM Feedback / Recommendations
All DCAE components uses standard libraries for HTTPS calls (java components use java11 libraries and python components uses request library). These libs are externally managed, and we believe these requirements for certificate verification before sending HTTP headers are being met.  

<Muddasar>. Use of standard libraries does not mean certification verification being applied.  Can someone confirm Java11 behavior?