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:
- ONAP Credential Management
- ....
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
........