Overview

Akraino SDL Roles

Overview

Akraino SDL Roles

Security advisor/Privacy advisor

...

The following requirements of security monitoring need to be met by the solution in a virtual environment.
Akraino MUST support Real-time detection and notification of security events.
Akraino MUST support Integration functionality via API/Syslog/SNMP to other functional modules in the network (e.g., PCRF, PCEF) that enable dynamic security control by blocking the malicious traffic or malicious end users.Note: PCRF, PCEF are not good examples here à to be changed or removed
Akraino MUST support API-based monitoring to take care of the scenarios where the control interfaces are not exposed, or are optimized and proprietary in nature.
Akraino MUST support detection of malformed packets due to software misconfiguration or software vulnerability, and generate an error to the syslog console facility.
Akraino MUST support proactive monitoring to detect and report the attacks on resources so that Akraino's and associated VMs can be isolated, such as detection techniques for resource exhaustion, namely OS resource attacks, CPU attacks, consumption of kernel memory, local storage attacks.
Akraino SHOULD operate with anti-virus software which produces alarms every time a virus is detected.
Akraino MUST protect all security audit logs (including API, OS and application-generated logs), security audit software, data, and associated documentation from modification, or unauthorized viewing, by standard OS access control mechanisms, by sending to a remote system, or by encryption.
Akraino MUST log successful and unsuccessful authentication attempts, e.g., authentication associated with a transaction, authentication to create a session, authentication to assume elevated privilege.
Akraino MUST log logoffs.
Akraino MUST log starting and stopping of security logging.
Akraino MUST log success and unsuccessful creation, removal, or change to the inherent privilege level of users.
Akraino MUST log connections to the network listeners of the resource.
Akraino MUST log the field "event type" in the security audit logs.
Akraino MUST log the field "date/time" in the security audit logs.
Akraino MUST log the field "protocol" in the security audit logs.
Akraino MUST log the field "service or program used for access" in the security audit logs.
Akraino MUST log the field "success/failure" in the security audit logs.
Akraino MUST log the field "Login ID" in the security audit logs.
Akraino MUST NOT include an authentication credential, e.g., password, in the security audit logs, even if encrypted.
Akraino MUST detect when its security audit log storage medium is approaching capacity (configurable) and issue an alarm.
Akraino MUST support the capability of online storage of security audit logs.
Akraino MUST activate security alarms automatically when a configurable number of consecutive unsuccessful login attempts is reached.
Akraino MUST activate security alarms automatically when it detects the successful modification of a critical system or application file.
Akraino MUST activate security alarms automatically when it detects an unsuccessful attempt to gain permissions or assume the identity of another useranother user.
Akraino MUST include the field "date" in the Security alarms (where applicable and technically feasible).
Akraino MUST include the field "time" in the Security alarms (where applicable and technically feasible).
Akraino MUST include the field "dateservice or program used for access" in the Security alarms (where applicable and technically feasible).
Akraino MUST include the field "timesuccess/failure" in the Security alarms (where applicable and technically feasible).
Akraino MUST include the field "service or program used for accessLogin ID" in the Security alarms (where applicable and technically feasible).
Akraino MUST include the field "success/failure" in the Security alarms (where applicable and technically feasible).
Akraino MUST include the field "Login ID" in the Security alarms (where applicable and technically feasible).
Akraino MUST restrict changing the criticality level of a system security alarm to users with administrative privileges.
Akraino MUST monitor API invocation patterns to detect anomalous access patterns that may represent fraudulent access or other types of attacks, or integrate with tools that implement anomaly and abuse detection.
Akraino MUST generate security audit logs that can be sent to Security Analytics Tools for analysis.
Akraino MUST log successful and unsuccessful access to Akraino resources, including data.
Akraino MUST support the storage of security audit logs for a configurable period of time.
Akraino MUST have security logging for Akraino applications/services and their OSs be active from initialization. Audit logging includes automatic routines to maintain activity records and cleanup programs to ensure the integrity of the audit/logging systems.
Akraino MUST be implemented so that it is not vulnerable to OWASP Top 10 web application security risks.
Akraino MUST protect against all denial of service attacks, both volumetric and non-volumetric, or integrate with external denial of service protection tools.
Akraino MUST be capable of automatically synchronizing the system clock daily with the Operator's trusted time source, to assure accurate time reporting in log files. It is recommended that Coordinated Universal Time (UTC) be used where possible, so as to eliminate ambiguity owing to daylight savings time.
Akraino MUST log the Source IP address in the security audit logs.
Akraino MUST have the capability to securely transmit the security logs and security events to a remote system before they are purged from the system.
Akraino SHOULD provide the capability of maintaining the integrity of its static files using a cryptographic method.
Akraino MUST log automated remote activities performed with elevated privileges.

Data Protection

This section covers Akraino data protection requirements that are mostly applicable to security monitoring.
Akraino MUST provide the capability to restrict read and write access to data handled by Akraino.
Akraino MUST Provide the capability to encrypt data in transit on a physical or virtual network.
Akraino MUST provide the capability to encrypt data on non-volatile memory. Non-volative memory is storage that is capable of retaining data without electrical power, e.g. Complementary metal-oxide-semiconductor (CMOS) or hard drives.
Akraino SHOULD disable the paging of the data requiring encryption, if possible, where the encryption of non-transient data is required on a device for which the operating system performs paging to virtual memory. If not possible to disable the paging of the data requiring encryption, the virtual memory should be encrypted.
Akraino MUST use NIST and industry standard cryptographic algorithms and standard modes of operations when implementing cryptography.
Akraino MUST NOT use compromised encryption algorithms. For example, SHA, DSS, MD5, SHA-1 and Skipjack algorithms. Acceptable algorithms can be found in the NIST FIPS publications (https://csrc.nist.gov/publications/fips) and in the NIST Special Publications (https://csrc.nist.gov/publications/sp).
Akraino MUST use, whenever possible, standard implementations of security applications, protocols, and formats, e.g., S/MIME, TLS, SSH, IPSec, X.509 digital certificates for cryptographic implementations. These implementations must be purchased from reputable vendors or obtained from reputable open source communities and must not be developed in-house.
Akraino MUST provide the ability to migrate to newer versions of cryptographic algorithms and protocols with minimal impact.
Akraino MUST support digital certificates that comply with X.509 standards.Note: Security architecture should define all the use cases for certificates
Akraino MUST NOT use keys generated or derived from predictable functions or values, e.g., values considered predictable include user identity information, time of day, stored/transmitted data.
Akraino MUST provide the capability of using X.509 certificates issued by an external Certificate Authority.
Akraino MUST be capable of protecting the confidentiality and integrity of data at rest and in transit from unauthorized access and modification.Note: Either as part of req, or separately: specify how to protect the data; can be different approach for:- keys/secrets- DBs- configuration data- logs- …

Confidentiality

• Passwords stored on server as iterated salted hashes using bcrypt
• Remember me token: Cryptographic nonce is stored on client & bcrypt digest stored on server
• Email addresses only revealed to owner & admins
• HTTPS

Integrity

• HTTPS
• Data modification requires authorization
• Modifications to official application requires authentication

Availability

• Cloud & CDN deployment
• Timeout
• Can return to operation quickly after DDOS attack stops
• Login disabled mode
• Multiple backups

Implementation

Common types of vulnerable implementations

OWASP top 10 Vulnerabilities

• Injection (including SQL injection)
• Auth & session
• XSS (Esp. SafeBuffer)
• Insecure object references
• Security misconfiguration
• Sensitive data exposure
• Missing access control
• CSRF
• Known vulnerabilities
• Unvalidated redirect/fwd
• XXE (2017 A4)
• Insecure Deserialization (2017 A8)
• Insufficient logging and monitoring (2017 A10)

Hardening

• Force HTTPS, including via HSTS (Http strict transport security)
• Hardened outgoing HTTP headers, including restrictive CSP
• HTTP-only Cookies
• User secure cookie over HTTPS
• CSRF token hardening
• Incoming rate limits
• Address Space Layout Randomization (ASLR)
• Harden or disable XML entity resolution
• Load DLLs securely
• Reflection and authentication relay defense
• Safe redirect, online only
• Do not use the Javascript eval() or equivalent functions
• Integer overflow/underflow
• Input validation and handling
• Encrypted email addresses
• Gravatar restricted

...

• Review before use
• Get authentic version
• Use package manager

Deprecate unsafe functions

...

Verification

•Dynamic Program Analysis

•AppVerifier

•Sandbox
•Fuzz Testing
•Threat Model and Attack Surface review
•Penetration Test

...

This tool finds defects and security vulnerabilities in custom source code written in C, C++, Java, C#, JavaScript and more

Coverity Scan is a free static-analysis cloud-based service for the open source community

...

• Disassembly and intermediate-representation lifting
• Program instrumentation
• Symbolic execution
• Control-flow analysis
• Data-dependency analysis
• Value-set analysis (VSA)
• Decompilation

...

It is a fast memory error detector. It consists of a compiler instrumentation module and a run-time library. The tool can detect the following types of bugs:

• • AddressSanitizer (detects addressability issues) and LeakSanitizer (detects memory leaks)
  • ThreadSanitizer (detects data races and deadlocks) for C++ and Go
  • MemorySanitizer (detects use of uninitialized memory)

...

...

...

Root of trust. For intel & Arm @daniil Egranov

...

applicable and technically feasible).
Akraino MUST restrict changing the criticality level of a system security alarm to users with administrative privileges.
Akraino MUST monitor API invocation patterns to detect anomalous access patterns that may represent fraudulent access or other types of attacks, or integrate with tools that implement anomaly and abuse detection.
Akraino MUST generate security audit logs that can be sent to Security Analytics Tools for analysis.
Akraino MUST log successful and unsuccessful access to Akraino resources, including data.
Akraino MUST support the storage of security audit logs for a configurable period of time.
Akraino MUST have security logging for Akraino applications/services and their OSs be active from initialization. Audit logging includes automatic routines to maintain activity records and cleanup programs to ensure the integrity of the audit/logging systems.
Akraino MUST be implemented so that it is not vulnerable to OWASP Top 10 web application security risks.
Akraino MUST protect against all denial of service attacks, both volumetric and non-volumetric, or integrate with external denial of service protection tools.
Akraino MUST be capable of automatically synchronizing the system clock daily with the Operator's trusted time source, to assure accurate time reporting in log files. It is recommended that Coordinated Universal Time (UTC) be used where possible, so as to eliminate ambiguity owing to daylight savings time.
Akraino MUST log the Source IP address in the security audit logs.
Akraino MUST have the capability to securely transmit the security logs and security events to a remote system before they are purged from the system.
Akraino SHOULD provide the capability of maintaining the integrity of its static files using a cryptographic method.
Akraino MUST log automated remote activities performed with elevated privileges.

Data Protection

This section covers Akraino data protection requirements that are mostly applicable to security monitoring.
Akraino MUST provide the capability to restrict read and write access to data handled by Akraino.
Akraino MUST Provide the capability to encrypt data in transit on a physical or virtual network.
Akraino MUST provide the capability to encrypt data on non-volatile memory. Non-volative memory is storage that is capable of retaining data without electrical power, e.g. Complementary metal-oxide-semiconductor (CMOS) or hard drives.
Akraino SHOULD disable the paging of the data requiring encryption, if possible, where the encryption of non-transient data is required on a device for which the operating system performs paging to virtual memory. If not possible to disable the paging of the data requiring encryption, the virtual memory should be encrypted.
Akraino MUST use NIST and industry standard cryptographic algorithms and standard modes of operations when implementing cryptography.
Akraino MUST NOT use compromised encryption algorithms. For example, SHA, DSS, MD5, SHA-1 and Skipjack algorithms. Acceptable algorithms can be found in the NIST FIPS publications (https://csrc.nist.gov/publications/fips) and in the NIST Special Publications (https://csrc.nist.gov/publications/sp).
Akraino MUST use, whenever possible, standard implementations of security applications, protocols, and formats, e.g., S/MIME, TLS, SSH, IPSec, X.509 digital certificates for cryptographic implementations. These implementations must be purchased from reputable vendors or obtained from reputable open source communities and must not be developed in-house.
Akraino MUST provide the ability to migrate to newer versions of cryptographic algorithms and protocols with minimal impact.
Akraino MUST support digital certificates that comply with X.509 standards.Note: Security architecture should define all the use cases for certificates
Akraino MUST NOT use keys generated or derived from predictable functions or values, e.g., values considered predictable include user identity information, time of day, stored/transmitted data.
Akraino MUST provide the capability of using X.509 certificates issued by an external Certificate Authority.
Akraino MUST be capable of protecting the confidentiality and integrity of data at rest and in transit from unauthorized access and modification.Note: Either as part of req, or separately: specify how to protect the data; can be different approach for:- keys/secrets- DBs- configuration data- logs- …

Confidentiality

• Passwords stored on server as iterated salted hashes using bcrypt
• Remember me token: Cryptographic nonce is stored on client & bcrypt digest stored on server
• Email addresses only revealed to owner & admins
• HTTPS

Integrity

• HTTPS
• Data modification requires authorization
• Modifications to official application requires authentication

Availability

• Cloud & CDN deployment
• Timeout
• Can return to operation quickly after DDOS attack stops
• Login disabled mode
• Multiple backups

Implementation

Common types of vulnerable implementations

OWASP top 10 Vulnerabilities

• Injection (including SQL injection)
• Auth & session
• XSS (Esp. SafeBuffer)
• Insecure object references
• Security misconfiguration
• Sensitive data exposure
• Missing access control
• CSRF
• Known vulnerabilities
• Unvalidated redirect/fwd
• XXE (2017 A4)
• Insecure Deserialization (2017 A8)
• Insufficient logging and monitoring (2017 A10)

Hardening

• Force HTTPS, including via HSTS (Http strict transport security)
• Hardened outgoing HTTP headers, including restrictive CSP
• HTTP-only Cookies
• User secure cookie over HTTPS
• CSRF token hardening
• Incoming rate limits
• Address Space Layout Randomization (ASLR)
• Harden or disable XML entity resolution
• Load DLLs securely
• Reflection and authentication relay defense
• Safe redirect, online only
• Do not use the Javascript eval() or equivalent functions
• Integer overflow/underflow
• Input validation and handling
• Encrypted email addresses
• Gravatar restricted

Securely reuse

• Review before use
• Get authentic version
• Use package manager

Deprecate unsafe functions

Use approved tools

Static code analysis

Verification

Recommended tools:

Release

Incident Response Plan

...