You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

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 captured Security Recommendations are:

  1. ONAP  Credential Management
  2. ....


2 ONAP Credential Management.

 Status: Draft

2.1 ONAP Credential Management Overview

 In order to support secure communication between the ONAP modules and also external to ONAP, then a form of credentials is required. The options for these credentials are:

  • List here

The recommended approach is....

2.2 Credential Lifecycle

The lifecycle of the credentials are:

  • Provisioning Credentials
    • Provisioning the credentials involves putting the credentials into the ONAP system, ensuring that they are securily stored.
  • Updateing Credentials
  • Validating Credentials
  • Distributing Credentials
  • Removing Credentials

(Note:  A description of the above is required)

2.3 Recommended approach

Describe recommended approach here for all steps of the lifecycle.

Architecture put (abstract)


2.4 Implications to the ONAP

Describe what this means to ONAP



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

The ONAP sub-committee is converging on that coverity is a suitable choice for the static code scans.

The discussion now is how to include this in the git/gerrit code contribution process.

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


........




  • No labels