Table of 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?

...

• 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

...

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

Recommedations

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

...

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