Child pages (Children Display)

1. Introduction

The ONAP Security Best Practices is a list of Best Practices recommended by the ONAP sub-committee.  These best practices have the following states:

...

•Basic introduction can be found here: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
•Silver/Gold criteria can be found here: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/other.md

As additional information, the The CLAMP project has been wrote about their early experiences applying the CII badging programe procedures.  Their experience is program procedures, captured here: https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/ONAP+security+Recomendation+DevelopementDevelopment?src=contextnavpagetreemode 

3. Credential Protection and Management

...

Status: Draft

Best Practice:

Recommendation to the TSC

• Use Coverity Scan https://scan.coverity.com/ to perform static code scans on all ONAP code.
• Automate scanning by enabling Jenkins to trigger weekly scans with Coverity Scan.
• Deliver scan reports to the PTLs for each project PTLs will be responsible for getting the vulnerabilities resolved (fixed or designated as false positive).
• All projects in a release must have the high vulnerabilities resolved by MS-3.
• All projects in a release must have the high and medium vulnerabilities resolved by MS-4.
• The Security Committee will host session to help projects walk through the scanning process and reports.

Next Steps

• Review the OPNFV scanning process at https://wiki.opnfv.org/display/security/Security+Scanning to see if it can be adopted as the ONAP static code scanning process.

Tools that have been assessed: Coverity Scan (LF evaluationusing the tool in OPNFV and other projects), HP Fortify (AT&T evaluation), Checkmarx (AT&T evaluation), Bandit (AT&T evaluation)

...

Languages supported: C/C++, C#, Java, Javascript, Python, Ruby (Question: what about GrooveGroovy, Erlang?)

Current Activity: In conversations with Coverity to understand the definition of “project” – does it refer to ONAP or the projects under an ONAP release to ensure that the limitation on free scans does not lead to bottlenecks in submissions and commits. (Coverity response included below)

...

• If the ONAP project can be built from source in a single command, then Coverity can to create component maps.
• If the separate components are built individually, then each component can be submitted as a separate project.
• Coverity recommends storing the projects in a hierarchical structure in Github with the ONAP parent project referring to the project (i.e. ONAP/component_name). There are a few projects already in Scan which follow this structure. (is ONAP stored this way?) Each ONAP project has it's own hierarchy in Gerrit (its own Git tree). Can they do an arbitrary a Git Pull, Git Clone on a an arbitrary git repository?

Restrictions on builds: (from https://scan.coverity.com/)

...

• Meet with Coverity (schedule call, include Tony Hansen , someone from Linux Foundation) 
  • Will Scan integrate with Gerrit? (Coverity Scan tool indicates that it does integrate with Gerrit.)
  • Can it integrate with Jenkins (use resources from Linux Foundation to assist)?
  • How long does it take to run a scan and get results?
  • Lead time with Coverity to use Scan?
  • Mass registration of all ONAP subcomponents (approximately 30 projects, 210 subprojects)?
• Identify an open source project actively using Coverity Scan to get their feedback on the integration of Scan with their code development lifecycle
• Determine whether or not the restrictions on scan frequency will cause a problem for any of the ONAP projects
• Identify an ONAP project willing to test Scan (possibly CLAMP since they are also going through CII badging)
• Integrate Scan with ONAP code development (if Scan is determined to be a viable product)

5. Security of the xNF Package and the Artifacts

Status: Priority 1 approved by TSC

Priority 1: xNF Package Verification (Committed for Dublin as part of 5G use case)

Integrity of the xNF package needs to be verified prior to, or at the time of onboarding. The purpose is to ensure that the xNF package originates from the vendor, and that the content has not been tampered with. The verification is done against the signature provided by the vendor. Reference [ETSI NFV SOL004] contains the detailed specifications on VNF package. As of March 2019 this is being implemented for Dublin release in SDC and VNF SDK (VNF SDK includes partial implementation from Casablanca).

Priority 2: Integrity Verification at Instantiation (Release TBD)

Reference [ETSI NFV SEC021] is the main specification of this feature. As of March 2019 the status is 'final draft for approval', target date of publication is July 2019.
As of March 2019, ETSI NFV plans changes in [ETSI NFV SOL004] impacting this item: creation of signature per individual artifact in the VNF package (by the package vendor) is planned to be mandatory.

Priority 3: Service Provider Ability to Sign the Artifacts (Release TBD)

Reference [ETSI NFV SEC021] is the main specification of this feature. As of March 2019 the status is 'final draft for approval', target date of publication is July 2019.

References

[ETSI NFV SOL004]
ETSI GS NFV-SOL 004 V2.3.1 (2017-07): http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf

[ETSI NFV SEC021]
The latest draft can be found in: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=53601