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:
- ONAP Credential Management
- static code scanning
2 ONAP Credential Management.
Status: Draft
2.1 ONAP Credential Management Overview
ONAP requires two components to improve the security of credentials used in orchestration.
- a secrets vault to store credentials used by ONAP
- 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.
- OpenStack’s Barbican: specific to OpenStack, not a mature service
- Various commercial services such as LastPass
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.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)
Question:
- What about user pwd/credential
- What about the credential for interaction with other systems.
- How to the plugability to the credential management.
2.3 Recommended approach
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
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: 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
3.1 ONAP Communication Security
Investigate the means to have secure onap communication, leveraging the ONAP credential management.
6 (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
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
- <insert top 3 here>
- candidates to include are:
- The project MUST have a public website with a stable URL. (The badging application enforces this by requiring a URL to create a badge entry.)
- The project website MUST succinctly describe what the software does (what problem does it solve?).
- The software produced by the project MUST be released as FLOSS.
- The project MUST post the license(s) of its results in a standard location in their source repository. (URL required for "met".)
- The project MUST provide basic documentation for the software produced by the project.
- The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project.
- The project MUST have a version-controlled source repository that is publicly readable and has a URL.
- The project results MUST have a unique version identifier for each release intended to be used by users.
- The release notes MUST identify every publicly known vulnerability that is fixed in each new release. This is "N/A" if there are no release notes or there have been no publicly known vulnerabilities. (N/A allowed.) (Justification required for "N/A".)
- If the software produced by the project requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code.
- The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. (N/A allowed.)
- The project MUST have at least one primary developer who knows how to design secure software.
- At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them.
- 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).
- 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.
- There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days.
- Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.
- The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access.
- At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language.
- All medium and high severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed.
- It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release.
- All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. (N/A allowed.)
- 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.
........