Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 5 Next »

Contents

Introduction

The Akraino Security Requirements document is a list security items created by the Akraino security sub-committee.  This document includes security best practices/requirements identified by the ONAP project (also a Linux Foundation project) which are also common to the Akraino project.

Best Practices

CII Badging Program

What is the CII Badging Program?

  • CII (Core Infrastructure Initiative) Badge may be achieved by the projects which follow the Best practices criteria for Free/Libre and Open Source Software (FLOSS).
  • CII has been created by the Linux Foundation in response to previous security issues in open-source projects (e.g. Heartbleed in OpenSSL).
  • The CII Badging is associated to the areas as follows:

                                   Basics, Change Control, Reporting, Quality, Security & Analysis

  • Projects in Akraino should be CII certified to an appropriate level to confirm with expectation of carrier grade.

 

CII Badging Levels

There are 3 CII Badging levels which are as follows: 

  • Passing
  • Silver
  • Gold

When a new project starts the badging process, they will begin at 0% completeness and as they progress the % will increase.

To see a list of all Akraino projects and their level of completions refer to link:  <link to be provided>

 

Akraino CII Compliance Levels

For Akraino, 4 levels (Akraino Compliance) of compliance have been defined:

For each Akraino compliance level, all the projects in Akraino should comply to certain standards when it comes to CII badging.

Akraino Level 1: 70 % of the code in Gerrit must have an 100% completion in the CII badging towards passing level
with the non-passing projects reaching 80% completion in the CII badging towards passing level 
Non-passing projects MUST pass specific cryptography criteria outlined by the Security Subcommittee*

Akraino Level 2: 70 % of the projects in Gerrit must have an 100% completion in the CII badging for silver level 
with non-silver projects completed passing level and 80% completion towards silver level

Akraino Level 3: 70% of the projects in Gerrit must have an 100% completion in the CII badging for gold level 
with non-gold projects achieving silver level and achieving 80% completion towards gold level

Akraino Level 4: 100 % passing gold. 

 

Some of the important high level example criteria associated to the various levels are listed as follows for quick reference:

Level

Example Details/Criteria

Passing

The project website MUST succinctly describe what the software does (what problem does it solve?).
The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be
maintained as a separate FLOSS project).

Silver

The project MUST document what the user can and cannot expect in terms of security from the software produced
by the project. The project MUST identify the security requirements that the software is intended to meet and an
assurance case that justifies why these requirements are met.

The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, and evidence that common security weaknesses have been
countered

Gold

The project MUST have at least 50% of all proposed modifications reviewed before release by a person other than
the author, to determine if it is a worthwhile modification and free of known issues which would argue against its
inclusion.








 

Badge Specific Adherence requirements

Each of the Badging level is associated with compliance requirements which in turn may vary from being e.g. absolute to being as varied as recommendatory in nature.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in the Badging guideline documents are to be interpreted as below. (The terms are similar to what is described in RFC2119/RFC8174).

  • The term MUST is an absolute requirement, and MUST NOT is an absolute prohibition.
  • The term SHOULD indicates a criterion that is normally required, but there may exist valid reasons in particular circumstances to ignore it. However, the full implications must be understood and carefully weighed before choosing a different course.
  • The term SUGGESTED is used instead of SHOULD when the criterion must be considered, but valid reasons to not do so are even more common than for SHOULD.
  • Often a criterion is stated as something that SHOULD be done, or is SUGGESTED, because it may be difficult to implement or the costs to do so may be high.
  • The term MAY provides one way something can be done, e.g., to make it clear that the described implementation is acceptable.
  • To obtain a badge, all MUST and MUST NOT criteria must be met, all SHOULD criteria must be met OR the rationale for not implementing the criterion must be documented, and all SUGGESTED criteria have to be considered (rated as met or unmet). In some cases a URL may be required as part of the criterion's justification.

 

Credential & Secret Protection and Management

 

Package signing

  • In order to be onboarded a package must be signed.
  • During the onboarding process, the package is validated for integrity

Secure communication between Akraino components

  • Akraino components must be authenticated prior to establishing connections
  • The connect between components must be encrypted

External APIs used to access Akraino capabilities

  • External systems using APIs to access Akraino capabilities must be authorized and authenticated

Credentials that must be managed by security

  • Akraino user credentials which are used to access Akraino
    • Akraino MUST support user credentials of type user-id and password
    • Akraino SHOUD support user credentials as certificates
    • Credentials for using APIs exposed by Akraino
      • Akraino MUST support API credentials of type user-id and password
      • Akraino MUST support API credentials as certificates
      • Credentials used by Akraino components to communicate with other Akraino components
        • Akraino MUST support component credentials of type user-id and password
        • Akraino SHOUD support user credentials as certificates
        • Akraino components SHOULD use credentials based on certificates for communication with other Akraino components.  The use of user-id and password is a fallback in the case of components that do not support certificates.
        • Credentials for Akraino components to communicate with foreign systems
          • Akraino MUST support foreign credentials of type user-id and password
          • Akraino MUST support foreign credentials as certificates

All credentials described above MUST be securely stored.

Credential Management Requirements

  • The Akraino credential management solution MUST be able to interact with existing credential creation and validation schemes
  • Identify the types of certifications supported by Akraino
  • Secure private keys.  CA private keys MUST be secured using PKCS11 based HSMs (eg. secure generation and storage of private key)
  • Must use certificate identity if possible (eg. binding an identity to a credential using the X.509v3 certificate)

Akraino requires two components to improve the security of credentials used in orchestration.

  1. A secrets vault to store credentials used by Akraino
  2. A process to instantiate credentials

 


Components

  1. Vault for secret storage: storage of passwords, secrets, certificates or anything else that  might be used in order to access or authenticate to some system.
  2. Key Management Server: used to generate/manage crypro keys that are used by other   parts of the system (for example Vault) and perform crypto operations (in case we don’t want keys to leave the server)

High level architecture approach for both components

  1. External interface – for consumption by the system
  2. Internal implementation interface/plugin system – to enable integration with pre-existing solutions
  3. Native implementation – does everything that is required for system to be fully operational and secure out of box without any external systems to be used during testing/demoes or by people without hardware solutions at place.

Static Code Scans

 

Recommendations

  • Use Coverity Scan https://scan.coverity.com/ to perform static code scans on all Akraino code.
  • Automate scanning by enabling Jenkins to trigger weekly scans with Coverity Scan.
  • Deliver scan reports to the PTLs (Project Technical Lead) for each project PTLs will be responsible for getting the vulnerabilities resolved (fixed or designated as false positive).
  • All projects in a release must have the high vulnerabilities resolved by MS-3.
  • All projects in a release must have the high and medium vulnerabilities resolved by MS-4.
  • The Security Committee will host session to help projects walk through the scanning process and reports.

Next Steps

Tools that have been assessed: Coverity Scan (LF using the tool in OPNFV and other projects), HP Fortify (AT&T evaluation), Checkmarx (AT&T evaluation), Bandit (AT&T evaluation)

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

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.

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

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

Current Activity:

Coverity Scanning Process:

Coverity static analysis works by instrumenting through build capture. The components which make up the Akraino project can be managed a number of ways:

  • If the Akraino project can be built from source in a single command, then Coverity can to create component maps.
  • If the separate components are built individually, then each component can be submitted as a separate project.
  • Coverity recommends storing the projects in a hierarchical structure in Github with the ONAP parent project referring to the project (i.e. Akraino/component_name). There are a few projects already in Scan which follow this structure. (is Akraino stored this way?) Each Akraino project has its own hierarchy in Gerrit (its own Git tree). Can they do a Git Pull, Git Clone on an arbitrary git repository?

Restrictions on builds: (from https://scan.coverity.com/)

Maximum Lines of Code in Project

Frequency of Scans

<100K lines of code

Up to 28 builds per week, with a maximum of 4 builds per day

100K to 500K lines of code

Up to 21 builds per week, with a maximum of 3 builds per day

500K to 1 million lines of code

Up to 14 builds per week, with a maximum of 2 build per day

>1 million lines of code

Up to 7 builds per week, with a maximum of 1 build per day

 

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

Scan is self-service: Coverity provides the analysis infrastructure and results, but the submitter must provide the instrumented artifacts to analysis. Scan provides integration with TravisCI/Github.

To use Scan, the submitters will have to create an account and submit their project at https://scan.coverity.com/projects

Coverity requires a code contributor to submit a project because of their responsible disclosure process for issues the tool may identify within the code.

Next Steps: 

 

Communication Security Requirements

 

Known Vulnerability Analysis

 

Image Signing/Verification

 

 

 

 

  • No labels