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

When onboarding the package it is validated for integrity.

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:

General Requirements

• The credential management solution MUST be able to interact with existing credential creation and validation schemes
• The following types of certificates SHOULD be supported by ONAP:
  • a, b, c, ... 
• Securing the private keys - CA private keys shall be secured using PKCS11 based HSMs (e.g secure generation and storage of private key)
• Usage of certificate identity wherever possible(binding an identity to a credential using the X.509v3 certificate)

Requirements for ONAP_USER

• • 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.2 Credential Management Requirements

The credential management solution considers the following:

General Requirements

• The credential management solution MUST be able to interact with existing credential creation and validation schemes
• The following types of certificates SHOULD be supported by ONAP:
  • a, b, c, ... 
• Securing the private keys - CA private keys shall be secured using PKCS11 based HSMs (e.g secure generation and storage of private key)
• Usage of certificate identity wherever possible(binding an identity to a credential using the X.509v3 certificate)

Requirements for ONAP_USER credentials:

• ONAP MUST support ONAP_User credentials of type user-ID and Password
• ONAP Should support ONAP_User credentials as certificates.

Requirements for ONAP_ExtAPI credentials:

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

Requirements for ONAP_Component credentials:

• ONAP MUST support ONAP_Component credentials of type user-ID and Password
• ONAP MUST support ONAP_Component credentials as certificates. 
• ONAP components SHOULD use credentials based on certificates for communication with other ONAP components.  The use of user-ID and Password is a fallback in the case of components that do not support certificates.

Requirements for ONAP_Foreign credentials:

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

...

• .

...

2.3.1 Credential State Diagram

Image Removed

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.3.2 Credential States

...

2.3.3 Credential Operations

...

Requirements for ONAP_ExtAPI credentials:

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

Requirements for ONAP_Component credentials:

• ONAP MUST support ONAP_Component credentials of type user-ID and Password
• ONAP MUST support ONAP_Component credentials as certificates. 
• ONAP components SHOULD use credentials based on certificates for communication with other ONAP components.  The use of user-ID and Password is a fallback in the case of components that do not support certificates.

Requirements for ONAP_Foreign credentials:

• 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

Image Added

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.2 Credential States

2.4.3 Credential Operations

Design Notes:

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

1. 1. a secrets vault to store credentials used by ONAP
   2. a process to instantiate credentials

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

Design Notes:

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

1. 1. a secrets vault to store credentials used by ONAP
   2. a process to instantiate credentials

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

...

Description: Coverity Scan is a service by which Synopsys provides the results of analysis on open source coding projects to open source code developers that have registered their products with Coverity Scan. Coverity Scan is powered by Coverity® Quality Advisor. Coverity Quality Advisor surfaces defects identified by the Coverity Static Analysis Verification Engine (Coverity SAVE®). Synopsys offers the results of the analysis completed by Coverity Quality Advisor on registered projects at no charge to registered open source developers.

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.

Open Source use: 4000+ open source projects use Coverity Scan

Frequency of builds:

Up to 28 builds per week, with a maximum of 4 builds per day, for projects with fewer than 100K lines of code

Up to 21 builds per week, with a maximum of 3 builds per day, for projects with 100K to 500K lines of code

Up to 14 builds per week, with a maximum of 2 build per day, for projects with 500K to 1 million lines of code

Up to 7 builds per week, with a maximum of 1 build per day, for projects with more than 1 million lines of code

Once a project reaches the maximum builds per week, additional build requests will be rejected. You will be able to re-submit the build request the following week.

Languages supported: C/C++, C#, Java, Javascript, Python, Ruby

Question: How to trigger the code scan from Jenkins?

→ Jenkis plug in?

→ what API does Coverity offer

Question: What about Go? which versions of Phython.

Comment: Add some motivation of why Coverity is a good idea.

Comment: We need to catch the commitment now. 

Comment: OPNFV also has a basic gerrit plug in for some basic scans.  This can be brought in.

Bring in a few prposals to the TSC.

3.3 Recommendation

...

. Synopsys offers the results of the analysis completed by Coverity Quality Advisor on registered projects at no charge to registered open source developers.

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.

Open Source use: 4000+ open source projects use Coverity Scan

Frequency of builds:

Up to 28 builds per week, with a maximum of 4 builds per day, for projects with fewer than 100K lines of code

Up to 21 builds per week, with a maximum of 3 builds per day, for projects with 100K to 500K lines of code

Up to 14 builds per week, with a maximum of 2 build per day, for projects with 500K to 1 million lines of code

Up to 7 builds per week, with a maximum of 1 build per day, for projects with more than 1 million lines of code

Once a project reaches the maximum builds per week, additional build requests will be rejected. You will be able to re-submit the build request the following week.

Languages supported: C/C++, C#, Java, Javascript, Python, Ruby

Question: How to trigger the code scan from Jenkins?

→ Jenkis plug in?

→ what API does Coverity offer

Question: What about Go? which versions of Phython.

Comment: Add some motivation of why Coverity is a good idea.

Comment: We need to catch the commitment now. 

Comment: OPNFV also has a basic gerrit plug in for some basic scans.  This can be brought in.

Bring in a few prposals to the TSC.

3.3 ONAP process for static code scans

Two approaches are identified.

1. Scan analysis in project

The PTL is informed of the scan analysis results on a regular basis (e.g. weekly).

• • Project has the responsibility to analysis the scans and make required changes.

Note:
•The work scales with projects
•Security competence may not be in projects to understand the results
•Have to work through the false positives.
•Requires that the scan process is incorporated into Jenkins.

2 Create a support team to support the scan analysis with the projects. 

•Under the guidance of the security sub-committee 1-2 team is created with project members (rally around timezones).
•Perform walkthrough of the static code scan results before MS-4.

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

3.4 Recommendation

The recommended tool is: xxxx

The recommendation from the security sub-committee is:

• xyz
• MS-4 and release criteria includes static code scan analysis. 

4. CII Badging process Learnings for ONAP.

...

A process is required to support this.

Next Steps

 Investigate the policies that should be applied and make a proposal.  Once agreed, anchor with LF

Propose a process.  Consider the following:

...

 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

...