1 Introduction

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.

The main captured topics are are:

1. ONAP  Credential Management
2. static code scanning

2 ONAP Credential Management.

 Status: Draft

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

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, ... 
• (PKCS11 secure generation and storage of private key)
• (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 credentials of type user-ID and Password
• ONAP MUST support ONAP_Foreign credentials as certificates

2.3 Credential Lifecycle

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

<<<<<Comment: Remove external to ONAP and ONAP operations.  Add descriptive text that who the owning authority of the credential is (external, or onap)

ZL: Removed external to ONAP and ONAP operations 2017-12-06 . Text added (above)>>>

2.3.2 Credential States

2.3.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 to authenticate to VNFs.

2.5 Use cases

Use Cases:

 For ONAP_User Credentials

For ONAP_User Credentials, two uses cases are shown.

1. Provisioning the credentials

 The ONAP_Admin credentials are directly provisioned.  The root administrator can create the onap admininstrator user-identifier and credentials.  Intially a temporary credential is created and the ONAP operational staff can update their credentials.

The credentials are securely stored (in a hashed format???)

2. Authenticating the user

When a ONAP operational staff attempts to log in for the first time.  ONAP challenges the user (with xxxxx).  This is done by comparing the hash of the entered credentials with the stored hash of the credentials.

For  ONAP_ExtAPI credentials:

There are two cases here.  The first case is when the user credentials have to be specifically provisioned.  The second case is when an identity management scheme is used.  What do we want to describe.

For ONAP_ExtAPI credentials, 3 use cases are described

 1. Provisioning the credentials 

<< insert here >>

 2. Distributing the credentials

<< Insert here >>

3. Retrieving the credentials

<< Insert here >>

For ONAP_Component credentials:

For ONAP_Component credentials, few use cases are described here

1.Certificate Authority Instance creation : This is normally required to be only one per ONAP deployment.

Steps are given below:

• • • Administrator user creates CA instance by providing details such as following to CA Service
      • Subject name to use on self-signed CA certificate
      • PKCS11 slot ID and Key ID to use (in case PKCS11 based HW protection of CA private key)
      • Public key algorithm
      • In case of RSA, key size
      • In case of ECDSA, curve 
      • Hash algorithm and key size
      • Validity time of CA certificate
      • Whether to create token backend. If token backend is needed, life time and usage count of tokens to be supplied.
      • Returns:
        • Token request URL
        • Certificate request URL
        • CA Certificate
    • Administrator user also creates policy rules to apply on user certificate request with information such as
      • Subject name prefix, CA instance should accept.
      • Signing algorithm, key sizes or curves that are acceptable.
      • Hashing algorithm and key sizes that are acceptable.
      • MAC addresses it should accept in the subject name
      • Whether to verify MAC address in the subject name of PKCS10 request with the MAC address of the VM/Container.
      • Check for valid token (Yes/No)
      • Validity time of certificate.

2. Certificat request - Creation of credentials required for secure communication :   This normally occurs when service (e.g java application service) is started or when the certificate renewal is due

Steps are given below:

• • • Java application gets the CA URL, Token, Subject name prefix  to be used via environment variables in case of containers or via cloud-init user data in case of VM.
    • Certificate Credential Client agent is called by application during its startup to create and get the certificate signed by CA by giving CA URL, token information.
    • Certificate Credential agent does following:
      • If there is an existing certificate and private key and if it is still valid, it returns back to the application immediately. If not, it does following
      • Generate ECDSA key pair.
      • Create PKCS10 request with subject name prefix + MAC address as Common Name of the subject name.
      • Sends PKCS10 request, token to CA.
      • Gets the x.50v3 certificate from CA.
      • Stores the certificate in file system.
      • Returns back private key handle, slot ID and path to the certificate.
    • Certificate credential agent informs application on acquiring credentials
    • Application moves forward to inform TLS service with CA certificate and subject prefix to validate incoming requests.
    • If Application is making TLS connection to another service, then it uses certificate enrolled and private key handle while creating TLS endpoint.

For ONAP_Foreign credentials:

For ONAP_Foreign credentials, two use cases are described. 

1. Provisioning the credentials
   <<insert here>>
2.  Retrieving the credentials

:

NOTE to seccom: Probably should describe how this works for all lifecycle steps. 

Recommendation: ONAP should provide a reference implementation of a secrets vault service as an ONAP project.

Next Steps:

• • Find a project lead for a reference implementation.

Component 2: A process to provision ONAP instances with credentials. These credentials may be used for interprocess communication (e.g., APPC calling A&AI) or for ONAP configuring VNFs.

Automatic provisioning of certificates and credentials to ONAP components: AAF can provision certificates. ECOMP DCAE is currently using AAF to provision certificates.

Next steps:

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

Prelimary Decision: Coverity Scan https://scan.coverity.com/

<< Include a motivation >>

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

Capture the recommendation here

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/

• Evaluate how projects follow best practices using voluntary self-certification

• Three levels: Passing, Silver and Gold

• LF target level recommendation is Gold

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

4.2.2 The Questionnaire

• Edition is limited to a subset of users

• Main editor can nominate other users as editors

• Divided into clear sections
 - For each section, a set of questions is provided, addressing best practices relating to the parent section

• Each question asks if a criterion is

• Met, unmet, not applicable, or unknown

• Criteria are generally high-level as targeted to best practices, e.g.

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

• By quickly knowing what the project supports

• See what should be improved

• Self-questioning helps project stakeholders identifying strengths and weaknesses, do’s and don'ts

• Align all projects using the same ratings

• Makes projects connected together to follow the same practices

• Call for continuous improvement

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

There are two high level use cases to cover.

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:

For: Real-time communication between ONAP components:

• The solution  MUST support an approach that can be common to all onap modules.
• The solution MUST support the credential management solution and MUST NOT be tied to any particular credential management scheme.
• The solution MUST support secure communication between the ONAP components in the following sense:
  • A receiving ONAP component understands that the message is authentic
  • Any element in between the ONAP components cannot interpret or change the message.
• The solution MUST enable that a sending ONAP component does not rely on what the receiving ONAP component is, and the receiving ONAP component does not rely on what the sending ONAP component is.  (This would put unnecessary restraints on the architecture).
• The solution SHOULD be easy for the ONAP components to Adopt.
• The solution MUST be independent of the underlying communication technology (i.e. communication buss technologies).

For models and packages to be onboarded:

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

Policies can be provisioned for different types of vulnerabilities to identify them as critical, severe, moderate, etc.

A process is required to support this.  A project with a component that has a known vulnerability can do one of two things.  1. It can upgrade the component to a component version that does not have the vulnerability.  Alternatively, the project can investigate the vulnerability to and conclude that it doesn't effect the project due to the way it uses the component or the part of the component is uses.

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:

• Informing Actions that a project has to do at the release milestones.

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.

The full list of the needs can be found at:  https://wiki.onap.org/plugins/servlet/mobile?contentId=1015829#content/view/15998867 

Security:

Per project:

• Level 0: None
• Level 1: CII Passing badge
• Level 2: CII Silver badge, plus:
  • All internal/external system communications shall be able to be encrypted.
  • All internal/external service calls shall have common role-based access control and authorization.
• Level 3: CII Gold badge 

Note: When creating the CII project entry, it is recommended to use ONAP in the title to facilitate searching the onap projects.

Per Release:

• 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

6. Examples of security communiation between ONAP and other components.

7. User provisioning, and relation to access to other systems.

........