Akraino Security Requirements
Table of Contents
Introduction
Runtime Security
General Security
Identity and Access Management
API Security
Security Analytics
Data Protection
Cryptography
Code Security
CII Badging Program
Static Code Scans
Image Signing/Verification
| Table of Contents |
|---|
| Anchor | ||||
|---|---|---|---|---|
|
...
This section provides details on the Akraino general security requirements on various security areas such as user access control, network security, ACLs, infrastructure security, and vulnerability management. These requirements cover topics associated with compliance, security patching, logging/accounting, authentication, encryption, role-based access control, least privilege access/authorization.
Integration and operation within a robust security environment is necessary and expected. The security architecture will include one or more of the following: IDAM (Identity and Access Management) for all system and application access, network vulnerability scans, OS, Database and application patching, malware detection and cleaning, DDOS prevention, network security gateways (internal and external) operating at various layers, host and application based tools for security compliance validation, aggressive security patch application, tightly controlled software distribution and change control processes and other state of the art security solutions. Akraino is expected to function reliably within such an environment and the developer is expected to understand and accommodate such controls and can expected to supply responsive interoperability support and testing throughout the product's lifecycle.
Akraino MUST implement and enforce the principle of least privilege on all protected interfaces.
Akraino MUST provide a mechanism (e.g., access control list) to permit and/or restrict access to services on Akraino by source, destination, protocol, and/or port.
Akraino SHOULD provide a mechanism that enables the operators to perform automated system configuration auditing at configurable time intervals.Note: Probably some security architecture work needed
Akraino SHOULD provide the capability for the Operator to run security vulnerability scans of the operating system and all application layers.
Akraino MUST support network segregation on Akraino external network interfaces: separation of O&M traffic from other traffic. Also, further separation like DB traffic, traffic between VNFs and Akraino, … TBD. The separation is realized in the infra using technologies like VLAN, VXLAN, VPN.- note: probably some security architecture work needed Akraino SHOULD support network segregation on Akraino internal interfaces, between and inside the Kubernetes clusters: separation of O&M traffic from other traffic. The separation is realized eg. using network namespaces and K8s network policies.Notes:- probably some security architecture work needed- K8s network policies: the level of support depends on the chosen CNI plugin
Note: Modified the original VNF req – still a draft: Akraino SHOULD support the use of HW rooted security technologies like HSM, SGX, virtual TPM for protection of more critical data (like encryption keys, secrets).Notes:- Security architecture work needed: for which use cases in Akraino are these technologies planned/possible to be applied. One example: - The limitation with usage of TPM, vTPM and SGX: not feasible to use for a workload that can migrated between CPUs/machines (= the typical way to deploy in cloud). - HSM does not have this limitation as it is accessed over network protocol
Akraino Provider MUST have patches available for vulnerabilities in Akraino as soon as possible. Patching shall be controlled via change control process with vulnerabilities disclosed along with mitigation recommendations.
Akraino MUST support encrypted access protocols, e.g., TLS, SSH, SFTP.
Akraino MUST store Authentication Credentials used to authenticate to other systems encrypted except where there is a technical need to store the password unencrypted in which case it must be protected using other security techniques that include the use of file and directory permissions. Ideally, credentials SHOULD rely on a HW Root of Trust, such as a TPM or HSM.
For all GUI and command-line interfaces, Akraino MUST provide the ability to present a warning notice that is set by the Operator. A warning notice is a formal statement of resource intent presented to everyone who accesses the system.
Akraino MUST allow the Operator to disable or remove any security testing tools or programs included in Akraino, e.g., password cracker, port scanner.
Akraino MUST support the ability to prohibit remote access to Akraino via a host based security mechanism.
Akraino MUST log any security event required by Akraino Requirements to Syslog using LOG_AUTHPRIV for any event that would contain sensitive information and LOG_AUTH for all other relevant events.
Akraino MUST be operable without the use of Network File System (NFS).
Akraino MUST NOT contain any backdoors.
If SNMP is utilized, Akraino MUST support at least SNMPv3 with message authentication.
Akraino application processes MUST NOT run as root.
Login access (e.g., shell access) to the operating system layer, whether interactive or as part of an automated process, MUST be through an encrypted protocol such as SSH or TLS.
Akraino MUST, after a successful login at command line or a GUI, display the last valid login date and time and the number of unsuccessful attempts since then made with that user's ID. This requirement is only applicable when the user account is defined locally in Akraino.
Akraino MUST include a configuration that specifies the targeted parameters, e.g. a limited set of ports, over which Akraino will communicate (including internal, external and management communication). # Need to communicate this to the API subcommittee. #
| Anchor | ||||
|---|---|---|---|---|
|
...
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 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 levelwith 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 bemaintained as a separate FLOSS project). |
Silver | The project MUST document what the user can and cannot expect in terms of security from the software producedby the project. The project MUST identify the security requirements that the software is intended to meet and anassurance case that justifies why these requirements are met. |
Gold | The project MUST have at least 50% of all proposed modifications reviewed before release by a person other thanthe author, to determine if it is a worthwhile modification and free of known issues which would argue against itsinclusion. |
| |
|
|
|
|
|
|
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).
...
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:
| Anchor | ||||
|---|---|---|---|---|
|
...