Instructions here.

 https://wiki.onap.org/display/DW/CII+Badging+Program

Targeted CII Security Requirements

Silver / Gold

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

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

*DETAILS ON ASSURANCE CASE*

The description of assurance case is:

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)

Here is the extended description. Scroll down for HOW TO ANSWER.

"An assurance case is 'a documented body of evidence that provides a convincing and valid argument that a specified set of critical claims regarding a system’s properties are adequately justified for a given application in a given environment' ('Software Assurance Using Structured Assurance Case Models', Thomas Rhodes et al, NIST Interagency Report 7608). Trust boundaries are boundaries where data or execution changes its level of trust, e.g., a server's boundaries in a typical web application. It's common to list secure design principles (such as Saltzer and Schroeer) and common implementation security weaknesses (such as the OWASP top 10 or CWE/SANS top 25), and show how each are countered. The [BadgeApp assurance case|https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/security.md] may be a useful example. This is related to documentation_security, documentation_architecture, and implement_secure_design."

implement_secure_design in turns builds on the bronze level requirement of "know_secure_design".

documentation_security:

The project MUST document what the user can and cannot expect in terms of security from the software produced by the project (its 'security requirements'). 

These are the security requirements that the software is intended to meet.

documentation_architecture:

The project MUST include documentation of the architecture (aka high-level design) of the software produced by the project. If the project does not produce software, select 'not applicable' (N/A).

A software architecture explains a program's fundamental structures, i.e., the program's major components, the relationships among them, and the key properties of these components and relationships.

implement_secure_design:

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

For example, the project results should have fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default). They should also have complete mediation (every access that might be limited must be checked for authority and be non-bypassable). Note that in some cases principles will conflict, in which case a choice must be made (e.g., many mechanisms can make things more complex, contravening 'economy of mechanism' / keep it simple).

know_secure_design:

The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.)
This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder:

• economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications)
• fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default)
• complete mediation (every access that might be limited must be checked for authority and be non-bypassable)
• open design (security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords)
• separation of privilege (ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication)
• least privilege (processes should operate with the least privilege necessary)
• least common mechanism (the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files)
• psychological acceptability (the human interface must be designed for ease of use - designing for 'least astonishment' can help)
• limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited)
• input validation with whitelists (inputs should typically be checked to determine if they are valid before they are accepted; this validation should use whitelists (which only accept known-good values), not blacklists (which attempt to list known-bad values)).

A 'primary developer' in a project is anyone who is familiar with the project's code base, is comfortable making changes to it, and is acknowledged as such by most other participants in the project. A primary developer would typically make a number of contributions over the past year (via code, documentation, or answering questions). Developers would typically be considered primary developers if they initiated the project (and have not left the project more than three years ago), have the option of receiving information on a private vulnerability reporting channel (if there is one), can accept commits on behalf of the project, or perform final releases of the project software. If there is only one developer, that individual is the primary developer.

HOW TO ANSWER

This is a documentation issue. Somewhere in your project's description, either on wiki.onap.org or onap.readthedocs.io, there needs to be (as indicated above):

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

This would most likely be based on what you documented for your "documentation_security" answer, and may be combined with the same document.

If you have such documentation, then answer Met and provide the URL pointing at that page.

If you DO NOT have such documenttion, then answer Unmet and file a JIRA ticket that says:

• add an assurance case to the documentation, and
• after adding the assurance case, change the Unmet to Met in CII badging

(See the comments below for examples of good assurance cases.)

DETAILS ON HARDENING

The description of hardening is:

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

Here is the extended description.

"Hardening mechanisms may include HTTP headers like Content Security Policy (CSP), compiler flags to mitigate attacks (such as -fstack-protector), or compiler flags to eliminate undefined behavior. For our purposes least privilege is not considered a hardening mechanism (least privilege is important, but separate)."

Wikipedia has this to say in its article [Hardening (computing)|https://en.wikipedia.org/wiki/Hardening_(computing)]:

"...hardening is usually the process of securing a system by reducing its surface of vulnerability, which is larger when a system performs more functions; in principle a single-function system is more secure than a multipurpose one. Reducing available ways of attack typically includes changing default passwords, the removal of unnecessary software, unnecessary usernames or logins, and the disabling or removal of unnecessary services."

 

HOW TO ANSWER HARDENING

The answers for this question will be very application-specific.

IF YOUR APPLICATION IS WEB-BASED:

The information from the question "hardened_site" provides additional guidance on how to harden applications that are web-based:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as 'nosniff'), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."

Some interesting reading on hardening at github can be found at github's Post-CSP journey.

IF YOUR APPLICATION IS NOT WEB-BASED:

The use of compiler flags as listed in the extended description would be appropriate for applications that are compiled. Other methods of hardening will be dependent on your application.

ANSWERING

If you have attempted to reduce your attack surface, then you have hardened your application. Click Met and provide some details on how you've hardened the application.

If you have NOT done this exercise on your code, then answer Unmet and file a JIRA ticket that says:

• work on hardening the application, and
• after hardening the application, change the Unmet to Met in CII badging