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 ONAP should be CII certified to an appropriate level in order to confirm with expectation of carrier grade.

How to add multiple editors to a project report

• You need the numeric ID for the new editor you're adding to your project report.
  • If the new editor doesn't already have a login on the CII site, they need to create one by going to https://bestpractices.coreinfrastructure.org and clicking on Sign Up.
  • If you don't know the new editor's CII login ID, have them log in and click on Account -> Profile. At the bottom is a link called “JSON”. Click that and a JSON structure will be shown. We need the “id” value, which is numeric. For example, mine is 1597.
• An existing owner or editor of a project then needs to bring up the project page that they want to add another editor to. At the top is a menu item “Edit”. Click that, and search for “(Advanced) What other users have additional rights to edit this badge entry?”. In the field right below that, type in “+” and the numeric ID retrieved above. Click on one of the green “Save” buttons below.
• That new person is immediately added as an editor on the project.
• As an editor, you can quickly get a list of the projects that you have rights to by clicking on “Account -> Profile”.

Do I Report For the Entire Project or Separately For Every Single Repo? Can I Group Repos Together?

This is your choice. You can do a single report for your entire project, or you can file a separate report for each repository, or even group multiple repositories together.

• If your repositories use different languages or different testing procedures, you probably would find it easier to do it per-repository.
• You may also group multiple repositories together, if that would help. For example, you might group all of the repositories together that use Java, or all of the repos together that use Erlang.
• The key to grouping repositories together is to list all of the repo URLs in the response to the question "What is the URL for the version control repository?" question.

It's your choice as to what makes it easiest for you to manage your project.

If you do file one report for the entire project, or group multiple repos together then you need to answer each Met/Not Met question based on the lowest-common denominator answer: if ANY of the repos don’t meet the requirement, you cannot select Met. You can use the text response for each question to keep track of your reasons for picking any particular answer.

CII Badging Levels

There are 3 CII Badging levels which are as follows: 

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 ONAP projects and their level of completions refer to link https://bestpractices.coreinfrastructure.org/projects?q=onap

ONAP CII Compliance Levels

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

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

ONAP 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*

ONAP 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

ONAP 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

ONAP Level 4: 100 % passing gold. 

ONAP CII Badging Dashboard: http://tlhansen.us/onap/cii.html

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

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

R2 Beijing Requirements

For the Beijing release, the compliance requirement is ONAP Level 1 (at least 70% of the project are on passing level, and all non-passing projects at >80% towards passing).

R2 Beijing Current Status Dashboard

The dashboard gives a list of all onap projects that are undergoing the process and their % of completion.

<TODO insert a link to the dashboard table here>

Procedure to Fill Out the BestPractices.CoreInfrastructure.Org Form

First step is create a new project in bestpractices website

1. Create a account in https://bestpractices.coreinfrastructure.org/ and login
2. Click on the "Projects" icon on the top right 
   
3. This page will list all the projects certified by CII not just the onap projects. Click on Add/Add new project button to add a new project.
   
   
4. Enter the details of your project in the new screen and click "Submit URL"

Now you will be prompted with a set of questions and most of them are straightforward. The following set of Sample Questions and Answers should help you fill it out. You may also wish to refer to one of the existing projects to get an idea of what has to be filled in. You can use this link and click on any project name to see the answers used for that project.

You should go through the questions for each of the levels. Some of the questions at Silver level change a "SHOULD" into a "MUST" from the Passing level, so if you have met some suggestion at Passing level, verify that is marked as Met at Silver level as well.

This section will cover all the questions in each level and what it means and what a possible answer should be. A description of the question will be provided where needed.

This section needs to be filled in.

Sample Testing tools

 The following is a list of some of the testing tools available. These may be considered for evaluation vis-a-vis the specific project requirements

and open source license requirements.

Resources 

The following resources may be useful source of information about CII badging:

•CII Badging overview: https://bestpractices.coreinfrastructure.org/
•Basic Criteria: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
•Higher Level Criteria: CII Badging overview : https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/other.md
•Example : https://bestpractices.coreinfrastructure.org/projects/1/0
•Further reading: https://wiki.onap.org/display/DW/ONAP+Beijing+Release+Developer+Forum%2C+Dec.+11-13%2C+2017%2C+Santa+Clara%2C+CA+US?preview=/16002054/20874916/ONAP-Security%20Sub-committee-pa2.pdf
•CLAMP project CII:  https://bestpractices.coreinfrastructure.org/projects/1197
•http://tlhansen.us/onap/cii.html  [ONAP Project Status dashboard]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select "not applicable" (N/A).

Status of Security Application Quality Requirements on Nov 13, 2019

There are six Security requirements affecting Application Quality at the Passing level, and all but two projects have Met these or marked them N/A.

Below are the Security requirements affecting Application Quality for the Silver and Gold badging levels. Most projects have already answered a large percentage of these, with the majority answering Met or N/A. The project counts are given. There are three requirements that have a low answer rate, and those are shown in red.

Silver / Gold

assurance_case  (5 of 38 projects are Met or N/A)

The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered. (URL required)

hardening (9 of 38 projects are Met or N/A)

Hardening mechanisms MUST be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities.

crypto_algorithm_agility  (24 of 38 projects are Met or N/A)

The project MUST support multiple cryptographic algorithms, so users can quickly switch if one is broken. Common symmetric key algorithms include AES, Twofish, and Serpent. Common cryptographic hash algorithm alternatives include SHA-2 (including SHA-224, SHA-256, SHA-384 AND SHA-512) and SHA-3.

crypto_certificate_verification (30 of 38 projects are Met or N/A)

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

crypto_credential_agility  (20 of 38 projects are Met or N/A)

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replace them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

crypto_tls12  (27 of 38 projects are Met or N/A)

The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

crypto_used_network  (26 of 38 projects are Met or N/A)

The software produced by the project MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network communications, select 'not applicable' (N/A).

crypto_verification_private  (26 of 38 projects are Met or N/A)

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

crypto_weaknesses (35 of 38 projects are Met or N/A)

The default security mechanisms within the software produced by the project MUST 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).

implement_secure_design (22 of 38 projects are Met or N/A)

The project MUST implement secure design principles (from 'know_secure_design'), where applicable. If the project is not producing software, select 'not applicable' (N/A).

input_validation (21 of 38 projects are Met or N/A)

The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (a *whitelist*), and reject invalid inputs, if there are any restrictions on the data at all.

Gold Only

security_review  (2 of 38 projects are Met or N/A)

The project MUST have performed a security review within the last 5 years. This review MUST consider the security requirements and security boundary.