Steps To Implement Security Scan Requirements
Who should perform security scan
If you are working on driver code, Vuls and Lynis are needed.
If you are developing container based application code, Vuls, Lynis and Kuber-Hunter are needed.
If you are developing VM based application code, Vuls (testing setup inside each VM) and Lynis (testing setup inside each VM) are needed.
Vuls scan usually takes around 10 to 20 mins.
Kuber-Hunter usually takes about 10 mins.
Lynis scan usually takes about 2 mins.
Incubation Inclusion in Release Review: Security Requirements Criteria
Releases typically occur every 6 months.
A release will use the last TSC approved security requirements that were approved at least 6 month prior to the release.
Exceptions must be submitted a minimum of 21 days prior to release
Note: Critical vulnerabilities/security items, as categorized by the Akraino Security Sub-Committee, must be fixed even if found inside lock out window.
Release 4 (Target Date November 30, 2020) Incubation Requirements:
Month | 6/2020 | 7/2020 | 8/2020 | 9/2020 | 10/2020 | 11/2020 | 12/2020 | 1/2021 |
|---|---|---|---|---|---|---|---|---|
Release |
|
|
|
|
| Rel. 4 |
|
|
Security Requirement Update | v. 1.0 |
|
|
|
|
|
|
|
Minimum Security Requirement |
|
|
|
|
| v. 1.0 |
|
|
Maximum Security Requirement |
|
|
|
|
| v. 1.0 |
|
|
| Release 4 Minimum Security Requirement Lock Out Window |
|
|
| ||||
Maturity Review: Security Requirements Criteria
Exception granted in cases of non-applicability.
Exception granted in cases where another security mechanism specified in the blueprint and implemented mitigates the risk.
Exceptions requested for cases above must be approved by the security sub-committee.
Exceptions require a maximum of 21 days to review.
The formal email date received, requesting a maturity review would be the Maturity Request date and this would define the set of security requirements that apply.
Note: Critical vulnerabilities/security items, as categorized by the Akraino Security Sub-Committee, must be fixed even if found inside lock out window.
Current Maturity Requirements:
Month | 6/2020 | 7/2020 | 8/2020 | 9/2020 | 10/2020 | 11/2020 | 12/2020 | 1/2021 |
|---|---|---|---|---|---|---|---|---|
Maturity Request |
|
|
|
|
|
|
|
|
Security Requirement Update | v. 1.0 |
|
|
|
|
|
|
|
Minimum Security Requirement |
| v. 1.0 | v. 1.0 | v. 1.0 | v. 1.0 | v. 1.0 | v. 1.0 |
|
Maximum Security Requirement |
| v. 1.0 | v. 1.0 | v. 1.0 | v. 1.0 | v. 1.0 | v. 1.0 |
|
| Release 4 Minimum Security Requirement Lock Out Window |
| ||||||
Vuls
Vuls will be integrated with Blueprint Validation Framework (Bluval User Guide)
Below are the list of tasks for integration.
Installation
Install Vuls containers (https://vuls.io/docs/en/install-with-docker.html). Vuls containers can be found at: https://hub.docker.com/u/vuls/
Install go-cve-dictionary, run "docker pull vuls/go-cve-dictionary"
Install goval-dictionary, run "docker pull vuls/goval-dictionary"
Install gost, run "docker pull vuls/gost"
Install vuls, run "docker pull vuls/vuls"
Set up and run
Detailed instruction can be found at https://vuls.io/docs/en/tutorial-docker.html
Prepare log dir
$ cd /path/to/working/dir
$ mkdir go-cve-dictionary-log goval-dictionary-log gost-log
Fetch NVD
$ for i in `seq 2002 $(date +"%Y")`; do \ docker run --rm -it \ -v $PWD:/vuls \ -v $PWD/go-cve-dictionary-log:/var/log/vuls \ vuls/go-cve-dictionary fetchnvd -years $i; \ done
Fetch OVAL
if you are using redhat/fedora
$ docker run --rm -it \ -v $PWD:/vuls \ -v $PWD/goval-dictionary-log:/var/log/vuls \ vuls/goval-dictionary fetch-redhat 5 6 7 8
if you are using ubuntu/debian
$ docker run --rm -it \ -v $PWD:/vuls \ -v $PWD/goval-dictionary-log:/var/log/vuls \ vuls/goval-dictionary fetch-ubuntu 16 17 18 19
Fetch gost
$ docker run --rm -i \ -v $PWD:/vuls \ -v $PWD/goval-log:/var/log/gost \ vuls/gost fetch redhat
Or
$ docker run --rm -i \ -v $PWD:/vuls \ -v $PWD/goval-log:/var/log/gost \ vuls/gost fetch ubuntu
Config the SUT, configuration will be stored in config.toml
SSH key generation & distribution: As Vuls connects to target server through SSH, and Vuls has to use SSH key-based authentication. There needs to be a way to generate SSH key pair, save the private key for Vuls container and dispatch the public key to target server. We probably don’t want to store the private key with the container image if the container image is public accessible.
[servers]
[servers.c74]
host = "54.249.93.16"
port = "22"
user = "vuls-user"
keyPath = "/root/.ssh/id_rsa" # path to ssh private key in docker
Start Vuls container to run tests
$ docker run --rm -it \ -v ~/.ssh:/root/.ssh:ro \ -v $PWD:/vuls \ -v $PWD/vuls-log:/var/log/vuls \ -v /etc/localtime:/etc/localtime:ro \ -e "TZ=Asia/Tokyo" \ vuls/vuls scan \ -config=./config.toml
To get the report:
$ docker run --rm -it -v ~/.ssh:/root/.ssh:ro -v $PWD:/vuls -v $PWD/vuls-log:/var/log/vuls -v /etc/localtime:/etc/localtime:ro -e "TZ=Asia/Tokyo" vuls/vuls report -config=./config.toml
Write Bluval configuration file for security tests
Push test results to LF Nexus
Todo: How to tell test success or fail
Todo: Sample Test result
Show test results in Bluval UI
Vuls Incubation and Maturity: PASS/FAIL Criteria, v1.0
All Critical vulnerabilities detected by Vuls must be patched/fixed. Critical vulnerabilities are defined as a CVSS score of 9.0-10.0. After patches/fixes are applied, Vuls must be run again to verify that the vulnerability is no longer detected.
The vuls.log output file and exception requests for any vulnerabilities that cannot be fixed must be sent to the security sub-committee.
Lynis
Lynis requires to run on SUT (System Under Test). The overall test framework will the similar to that of Vuls. As to the Lynis installation, there are two options:
Lynis is pre-installed on SUT by project team.
Lynis is to be installed as part of test flow from Validation Framework.
Considering the complexity of installing application on target system, it is recommended that option 1 is to be used.
For more information about Lynis, please check the link below:
https://cisofy.com/documentation/lynis/get-started/
You can download Lynis from cisofy.com. It is just over 1,000 lines of shell code.
You can use this version to check the configuration of a single server, either local or remote, as well as the configuration of a single docker file.
Just do ./lynis audit system
The output of the scan will be save in /var/log with the file name lynis-report.dat.
Then please upload these files in above folder and the report in txt or log format for the report.
Install and Execute
If you are using CentOS:
$ yum install lynis; lynis audit system
If you are using Ubuntu:
$ git clone https://github.com/CISOfy/lynis
$ cd lynis; ./lynis audit system
Report
After running, detailed test logs are stored in /var/log/lynis.log, information for each test includes:
Time of an action/event
Reason(s) why a test failed or was skipped
Output of (internal) tests
Suggestions about configuration options or how to fix/improve things
Threat/impact score
In addition to log file, Lynis also creates a report and stores it in /var/log/lynis-report.dat. The report file contains the following information:
Remarks = #<remark>
Section = [<section name>]
Option/value = <option name>=<value of option>
Lynis Incubation: PASS/FAIL Criteria, v1.0
The Lynis Program Update test MUST pass with no errors.
The following list of tests MUST complete as passing as described below.
In the lynis.log outputfile each test suite has one or more individual tests. The beginning and ending of a test suite is marked with "====". For example, the 'ID BOOT-5122' test suite should display:
020-04-08 15:36:28 ====2020-04-08 15:36:28 Performing test ID BOOT-5122 (Check for GRUB boot password)...2020-04-08 15:36:29 Hardening: assigned maximum number of hardening points for this item (3).2020-04-08 15:36:29 ===If any tests in the test suit failed, there would be the following:
2020-04-08 15:36:29 Suggestion: <Description of failed test>Also, the 'Hardening' line show above would not say 'assigned maximum number of hardening points', instead it would say 'assigned partial number of hardening points'.
1 | Test: Checking PASS_MAX_DAYS option in /etc/login.defs |
2 | Performing test ID AUTH-9328 (Default umask values) |
3 | Performing test ID SSH-7440 (Check OpenSSH option: AllowUsers and AllowGroups) |
4 | Test: checking for file /etc/network/if-up.d/ntpdate |
5 | Performing test ID KRNL-6000 (Check sysctl key pairs in scan profile) : Following sub-tests required |
5a | sysctl key fs.suid_dumpable contains equal expected and current value (0) |
5b | sysctl key kernel.dmesg_restrict contains equal expected and current value (1) |
5c | sysctl key net.ipv4.conf.default.accept_source_route contains equal expected and current value (0) |
6 | Test: Check if one or more compilers can be found on the system |
The lynis.log output file and exception requests for any of the items listed above that cannot be fixed must be sent to the security sub-committee.
Lynis Maturity: PASS/FAIL Criteria, v1.0
The Lynis Program Update test MUST pass with no errors.
The following list of tests MUST complete as passing as described below.
In the lynis.log outputfile each test suite has one or more individual tests. The beginning and ending of a test suite is marked with "====". For example, the 'ID BOOT-5122' test suite should display:
020-04-08 15:36:28 ====2020-04-08 15:36:28 Performing test ID BOOT-5122 (Check for GRUB boot password)...2020-04-08 15:36:29 Hardening: assigned maximum number of hardening points for this item (3).2020-04-08 15:36:29 ===If any tests in the test suit failed, there would be the following:
2020-04-08 15:36:29 Suggestion: <Description of failed test>Also, the 'Hardening' line show above would not say 'assigned maximum number of hardening points', instead it would say 'assigned partial number of hardening points'.
1 | Performing test ID BOOT-5122 (Check for GRUB boot password) |
2 | Performing test ID BOOT-5184 (Check permissions for boot files/scripts) |
3 | Test: Checking presence /var/run/reboot-required.pkgs |
4 | Performing test ID AUTH-9228 (Check password file consistency with pwck) |
5 | Performing test ID AUTH-9229 (Check password hashing methods) |
6 | Test: Checking SHA_CRYPT_MIN_ROUNDS option in /etc/login.defs |
7 | Test: Checking PASS_MAX_DAYS option in /etc/login.defs |
8 | Test: collecting accounts which have an expired password (last day changed + maximum change time) |
9 | Performing test ID AUTH-9328 (Default umask values) |
10 | Performing test ID FILE-6368 (Checking ACL support on root file system) |
11 | Performing test ID USB-2000 (Check USB authorizations) |
12 | Performing test ID USB-3000 (Check for presence of USBGuard) |
13 | Performing test ID PKGS-7370 (Checking for debsums utility) |
14 | Performing test ID PKGS-7388 (Check security repository in apt sources.list file) |
15 | Performing test ID SSH-7408 (Check SSH specific defined options) |
16 | Test: Checking AllowTcpForwarding in /tmp/lynis.ZotHQ7RQAj |
17 | Test: Checking ClientAliveCountMax in /tmp/lynis.ZotHQ7RQAj |
18 | Test: Checking ClientAliveInterval in /tmp/lynis.ZotHQ7RQAj |
19 | Test: Checking FingerprintHash in /tmp/lynis.ZotHQ7RQAj |
20 | Test: Checking IgnoreRhosts in /tmp/lynis.ZotHQ7RQAj |
21 | Test: Checking MaxAuthTries in /tmp/lynis.ZotHQ7RQAj |
22 | Test: Checking MaxSessions in /tmp/lynis.ZotHQ7RQAj |
23 | Test: Checking Port in /tmp/lynis.ZotHQ7RQAj |
24 | Test: Checking StrictModes in /tmp/lynis.ZotHQ7RQAj |
25 | Test: Checking TCPKeepAlive in /tmp/lynis.ZotHQ7RQAj |
26 | Performing test ID SSH-7440 (Check OpenSSH option: AllowUsers and AllowGroups) |
27 | Test: checking for file /etc/network/if-up.d/ntpdate |
28 | Performing test ID KRNL-6000 (Check sysctl key pairs in scan profile) |
29 | Test: Check if one or more compilers can be found on the system |
The lynis.log output file and exception requests for any of the items listed above that cannot be fixed must be sent to the security sub-committee.
Kuber-Hunter
Kube-Hunter Incubation and Maturity: PASS/FAIL Criteria, v1.0
The kube-hunter vulnerabilities listed as 'Yes' in the 'Critical' column MUST be resolved.
|