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.

Runtime Security

General Security

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

Identity and Access Management

Akraino MUST, if not integrated with the Operator's Identity and Access Management system, support the creation of multiple IDs so that individual accountability can be supported.
Akraino MUST allow the Operator to restrict access based on the assigned permissions associated with an ID in order to support Least Privilege (no more privilege than required to perform job functions).
Each architectural layer of Akraino (eg. operating system, network, application) MUST support access restriction independently of all other layers so that Segregation of Duties can be implemented.
Akraino MUST NOT allow the assumption of the permissions of another account to mask individual accountability. For example, use SUDO when a user requires elevated permissions such as root or admin.
Akraino MUST set the default settings for user access to deny authorization, except for a super user type of account. When Akraino is installed, nothing should be able to use it until the super user configures Akraino to allow other users (human and application) have access.
Akraino MUST support strong authentication, also known as multifactor authentication, on all protected interfaces exposed by Akraino for use by human users. Strong authentication uses at least two of the three different types of authentication factors in order to prove the claimed identity of a user. # Look at making this MUST for infrastructure and SHOULD for other areas #
Akraino MUST disable unnecessary or vulnerable cgi-bin programs. # Completely disallow cgi-bin #
Akraino MUST provide access controls that allow the Operator to restrict access to Akraino functions and data to authori

zed entities. # Least privilege #
Akraino SHOULD support OAuth 2.0 authorization using an external Authorization Server.
Akraino MUST, if not integrated with the Operator's Identity and Access Management system, support configurable length and password expiration.
Akraino MUST, if not integrated with the Operator's Identity and Access Management system, support Role-Based Access Control to enforce least privilege.
Akraino MUST, if not integrated with the Operator's Identity and Access Management system, comply with "password complexity" policy. When passwords are used, they shall be complex and shall at least meet the following password construction requirements: (1) be a minimum configurable number of characters in length, (2) include 3 of the 4 following types of characters: upper-case alphabetic, lower-case alphabetic, numeric, and special, (3) not be the same as the UserID with which they are associated or other common strings as specified by the environment, (4) not contain repeating or sequential characters or numbers, (5) not to use special characters that may have command functions, and (6) new passwords must not contain sequences of three or more characters from the previous password.
Akraino MUST not store authentication credentials to itself in clear text or any reversible form and must use salting.
Akraino MUST, if not integrated with the Operator's Identity and Access Management system, support the ability to disable the userID after a configurable number of consecutive unsuccessful authentication attempts using the same userID.
Akraino MUST, if not integrated with the Operator's identity and access management system, authenticate all access to protected GUIs, CLIs, and APIs.Note: I (could) read this like: "if I integrate with operator's IdAM then I don't need to do anything on authentication". Maybe improve wording…
Akraino MUST integrate with standard identity and access management protocols such as LDAP, TACACS+, Windows Integrated Authentication (Kerberos), SAML federation, or OAuth 2.0.
Akraino MUST have the capability of allowing the Operator to create, manage, and automatically provision user accounts using an Operator approved identity lifecycle management tool using a standard protocol.
Akraino MUST support account names that contain at least A-Z, a-z, 0-9 character sets and be at least 6 characters in length.
A failed authentication attempt MUST NOT identify the reason for the failure to the user, only that the authentication failed.
Akraino MUST NOT display "Welcome" notices or messages that could be misinterpreted as extending an invitation to unauthorized users.
Akraino MUST provide a means for the user to explicitly logout, thus ending that session for that authenticated user.
Akraino MUST, if not integrated with the Operator's Identity and Access Management system, or enforce a configurable "terminate idle sessions" policy by terminating the session after a configurable period of inactivity.

API Security

This section covers API security requirements when these are used by the Akraino. Key security areas covered in API security are Access Control, Authentication, Passwords, PKI Authentication Alarming, Anomaly Detection, Lawful Intercept, Monitoring and Logging, Input Validation, Cryptography, Business continuity, Biometric Authentication, Identification, Confidentiality and Integrity, and Denial of Service.
The solution in a virtual environment needs to meet the following API security requirements:
Akraino SHOULD integrate with the Operator's authentication and authorization services (e.g., IDAM).Note: Should specify explicitly what has to be supported.
Akraino MUST implement the following input validation control: Check the size (length) of all input. Do not permit an amount of input so great that it would cause Akraino to fail. Where the input may be a file, Akraino API must enforce a size limit.
Akraino MUST implement the following input validation controls: Do not permit input that contains content or characters inappropriate to the input expected by the design. Inappropriate input, such as SQL expressions, may cause the system to execute undesirable and unauthorized transactions against the database or allow other inappropriate access to the internal network (injection attacks).
Akraino MUST implement the following input validation control on APIs: Validate that any input file has a correct and valid Multipurpose Internet Mail Extensions (MIME) type. Input files should be tested for spoofed MIME types.

Security Analytics

This section covers Akraino security analytics requirements that are mostly applicable to security monitoring. The Akraino Security Analytics cover the collection and analysis of data following key areas of security monitoring:

• Anti-virus software

• Logging

• Data capture

• Tasking

• DPI

• API based monitoring

• Detection and notification

• Resource exhaustion detection

• Proactive and scalable monitoring

• Closed loop monitoring

• Interfaces to management and orchestration

• Malformed packet detections

• Service chaining

• Dynamic security control

• Dynamic load balancing

• Connection attempts to inactive ports (malicious port scanning)