1 Introduction

1.1 Purpose

This section captures recommendations for handling certain security questions that are studied by the security sub-committee.  These recommendations, when implemented, can lead to new best practices.  The recommendation states are:

• Draft: The ONAP Security sub-committee is working on the recommendation
• Recommended: The ONAP security sub-committee agrees that this is a recommendation
• Approved: The recommendation is approved by the TSC.

1.2 Threat Analysis

Some known threats in Micro Service architectures :

...

• Host operating system (Not valid if ONAP is being installed in Hyperscale data centers) - Hardened operating system, Vulnerability scanning, Trusted computing infrastructure
• Containers images:
  
  • Only have required software packages.
  • No password, secrets, private key in the image.
  • Vulnerable scanning and ensuring only patched versions of the packages are used.
  • Trusted image repository /  Image signing by VNF vendors.
• Container image download 
  • Secure communication with repositories
  • Verifying the signature of images before they are launched.
  • Periodic check for patched container images from the repository.
• Container run time 
  
  • Secret Management 
  • Mutual TLS for network security 
  • IPSEC for network security
  • Syscall white listing, MAC (Mandatory Access Control)
  • Usage of cgroups for resource isolation for all shared resources.
  • Monitoring of system call usage
  • Immutable - No run time patches to the packages.  Always download full container image.

1.3 Main discussed topics

The main captured topics (Main focus areas):

1. ONAP  Credential Management & Secret Management
2. static code scanning
3. Known vulnerability analysis
4. Image signing/verification
5. 3SP support from security perspective (recommendation done)
   
   

2 ONAP Credential Management.

 Status: Draft

2.1 ONAP level use cases

The following are the high level onap use cases that need to be supported.

2.1.1 Package signing

A package to be onboarded is signed

...

Note:  Need to be clear on whether it is the vendor credential used for signing or the ONAP operator credential. 

2.1.2 ONAP operator signing into the manage the onap system

The operational staff that is using ONAP authenticate with the ONAP system and have authorized privilege's based on the authenticated persona. 

2.1.3 Secure communication between ONAP components

The ONAP components can securely communicate between themselves 

2.1.4 External APIs being used to access ONAPs capabilities

ONAP offers API for external systems to use the ONAP capabilities.  For this, the external system is authenticated and authorized. 

2.1.5 ONAP accessing the services from another system.

ONAP can be a consumer of services offered from other external systems.  These can include e.g. the virtulization resources, the VNFs, or other external systems.  

2.2 Credentials to be managed

Credentials may be certificates, passwords and the like.  These need to be managed through the entire lifecycle.  The types of credentials that need to be managed are:

• • Credentials for ONAP users to access ONAP.  These are referred to as ONAP_User credentials.
  • Credentials for using the APIs exposed by ONAP. These are referred to as ONAP_ExtAPI credentials.
  • Credentials for ONAP to communicate to other ONAP components.  These are referred to as ONAP_Component credentials.
    • Note: This includes credentials for VNF SDK to package the artefacts onboarded into SDC.
    • Note: Other ONAP components include VNFs that need to communicate with ONAP services such as DCAE securely.
    • Note:  ONAP components can spread across geographical locations.  For example, DCAE systems at Edge communicating with Central ONAP services.
  • Credentials for ONAP to communicate with other systems.  These are referred to as ONAP_Foreign credentials.  
    • As an example, if ONAP is to communicate to an external SDN controller or a cloud infrastructure, these credentials need to be managed.
    • A another example is the credentials to access a VNF

2.3 Credential Management Requirements

The credential management solution considers the following:

...

• ONAP MUST support ONAP_Foreign credentials of type user-ID and Password
• ONAP MUST support ONAP_Foreign credentials as certificates

2.4 Credential Lifecycle

2.4.1 Credential State Diagram

In the implementation, some types of credentials have to be provisioned into ONAP components, e.g. certificate-based credentials or (user-ID,password) have to be added to VM images or containers before deployment.  It is probably better to do this during the deployment rather than storing images with imbedded credentials.  The Secrets Vault  is used to store these credentials securely.  The transition to the Credential_Provisioned state means the credential is stored in the Secrets Vault.

...

2.4.3 Credential Operations

...

• Design Note 1 - this is intended to make explicit that digital credentials may always be re-used, even if they are expired or revoked.

2.4 ONAP Credential Management Overview

ONAP requires two components to improve the security of credentials used in orchestration.

...

Component 1: Secrets Vault - A service that can be integrated with ONAP that provides secure storage of the credentials used by ONAP to authenticate to VNFs.

2.5 Credential Management Use cases (credential perspective)

Use Cases:

 For ONAP_User Credentials

...

• • Work with the AAF team to include this functionality in Release 2. It is important to understand that the AAF solution depends on the CA supporting the SCEP protocol.
  • Enhance AAF to provision userIDs & passwords to ONAP instances and VNFs. Most VNFs only support userID/password authentication today. ETSI NFV SEC may issue a spec in the future on a more comprehensive approach to using PKI for NFV which can be visited by ONAP SEC when released. Steve is working on this right now but doesn’t know when he’ll be done.

2.6 Recommended approach

2.7 Implications to the ONAP

Describe what this means to ONAP

QUESTIONS:

3 ONAP Static Code Scans

Status: Draft

3.1 ONAP Static Code Scanning

The purpose of the ONAP static code scanning is perform static code scans of the code as it is introduced into the ONAP repositories looking for vulnerabilities.

3.2 Approaches

Tools that have been assessed: Coverity Scan (LF evaluation), HP Fortify (AT&T evaluation), Checkmarx (AT&T evaluation), Bandit (AT&T evaluation)

...

Bring in a few prposals to the TSC.

3.3 ONAP process for static code scans

Two approaches are identified.

...

In Either case, propose that MS-4 and Release criteria includes static code scan analysis. 

3.4 Recommendation

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

4. CII Badging process Learnings for ONAP.

Status: Draft

4.1 CII Badging process intro

This section captures the learning's of using the CII badging program in ONAP.

4.2 Learnings

The CLAMP project has been working as the CII badging certification.  Their feedback is found here: CII Badging Program - Feedback.  This is repeated below for simplicity:

4.2.1 CII Badging program introduction.

• Core Infrastructure Initiative Website:
-https://bestpractices.coreinfrastructure.org/

...

• ONAP Pilot Project: CLAMP
-https://bestpractices.coreinfrastructure.org/projects/1197

4.2.2 The Questionnaire

• Edition is limited to a subset of users

...

• “The project MUST have one or more mechanisms for discussion”
• “The project SHOULD provide documentation in English”

4.2.3 The Goals

• Give confidence in the project being delivered

...

• Increase self rating and reach better software quality

4.2.4 Raised Questions

• Introduce test coverage rules: how many tests should be added for each code changes
• Digital signature: use digital signature in delivered packages (already in the plan?)
• Vulnerability fixing SLA: vulnerabilities should be fixed within 60 days
• Security mechanisms
  • Which cryptographic algorithms to use to encrypt password
  • The security mechanisms within the software produced by the project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.
  • If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt).
  • 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

5 ONAP Communication Security

Status: Draft

5.1 ONAP Communication Security

Assuming the credential management is in place, ONAP needs to have a common means to support secure communication between the onap components.

...

1. Real-time communication between ONAP components
2. Support for authentication and encryption of the modules and packages to be onboarded into SDK (from VNF SDK). 

 5.2 ONAP communication security requirements

To guide the solution development for the ONAP communication security, the following requirements are identified:

...

• The solution MUST support the credential management solution and MUST NOT be tied to any particular credential management scheme.
• The soluction MUST allow Service Design and Creation to validate the package from a security perspective. 

6. ONAP known vulnerability management

Status: Draft

 Background:

Sonatype Nexus can provide a number of reports.  One report it can provide is identification of components with known vulnerabilities.

...

A process is required to support this.

Next Steps

 Decide approach with projects:

Recommended to have MS-4 criterial as not to include modules with known vulnerabilities > 60 days old.  MS-4 and Release Criteria.

7 (tmp) input to the S3P (carrier grade) discussions from a security perspective

Status: Draft

Note: This will be removed when the feedback is sent back.

...

• Level 1 70% of the projects included in the release at passing badge level
• with non-passing projects reaching 80% towards passing level.
• Non passing projects MUST pass these specific criteria:
  • The software produced by the project MUST use, by default, only cryptographic protocols and algorithms that are publicly published and reviewed by experts (if cryptographic protocols and algorithms are used).
  • 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.
  • The security mechanisms within the software produced by the project MUST use default keylengths 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 keylengths are completely       disabled.
  • 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 (e.g., 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).
  • 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 algorithm or the CBC mode in SSH).
  • If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be       stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt).
• Level 2  70% of the projects in the release passing silver
  • with non-silver projects completed passing level and 80% towards silver level
• Level 3 70% of the projects included in the release passing gold
  • with non-gold projects achieving silver level and achieving 80% towards gold level
• Level 4: 100% of the projects in the release passing gold level. 

Examples of uses cases that people may want to see solved.

5. Examples of secure communication between ONAP components

...