The Center for Internet Security (CIS) identifies, develops, validates, promotes, and sustains best practice solutions for cyber defense and helps communities to facilitate an environment of trust in cyberspace.

CIS employs a closed crowd sourcing model to identify and refine effective security measures, where individual recommendations are shared with the community for evaluation through a consensus decision-making process. At a national and international level, CIS plays an essential role in forming security policies and decisions by maintaining CIS Controls and CIS Benchmarks and hosting the Multi-State Information Sharing and Analysis Center (MS-ISAC).

CIS Controls

CIS Controls and CIS Benchmarks provide global standards for internet security. The CIS Benchmark is categorized as Controls, and each Control is a collection of standard security tests. The CIS Controls include the popular 20 security controls, which map to many compliance standards. The CIS Controls advocate a defense-in-depth model to prevent and detect malware. For instance, Controls 1.1 is for Filesystem Configurations, a collection of tests like 1.1.1 - Deactivate unused filesystems, which in turn comprises sub-set tests such as 1.1.1.1 - Ensure mounting of cramfs filesystems is deactivated, 1.1.1.2 - Ensure mounting of freevfs filesystems is deactivated, and others.

For more information on the relevant Controls and tests for Distributed Independent Linux Benchmark, see CIS Ubuntu Linux LTS Benchmark, available for download at https://learn.cisecurity.org/benchmarks.

The individual tests are marked at either Level 1 or Level 2.

  • Level 1 tests are part of the CIS 1.0 profile. As per CIS, the Level 1 - Server profile tests are practical and prudent and are intended to provide a clear security benefit. These tests may inhibit the utility of the technology beyond acceptable means.

  • Level 2 tests are part of the CIS 2.0 profile. This profile is an extension of the Level 1 - Server profile and includes both Level 1 and Level 2 tests. As per CIS, the tests are intended for environments or use cases where security is paramount for a deep defense mechanism. These tests may negatively inhibit the utility or performance of the technology.

Note:

The Benchmark declares a Control as failed, even if one test within the Control fails.

Enabling CIS Mode

Activate the CIS mode on NSX Advanced Load Balancer to successfully run the tests associated with specific Control. Configure the CIS mode command under system configuration as shown below:

[admin:10-1-1-1]: > configure systemconfiguration
[admin:10-1-1-1]: systemconfiguration> linux_configuration
[admin:10-1-1-1]: systemconfiguration:linux_configuration> cis_mode
Overwriting the previously entered value for cis_mode

[admin:10-1-1-1]: systemconfiguration:linux_configuration> where
Tenant: admin
+----------+-------+
| Field    | Value |
+----------+-------+
| motd     |       |
| banner   |       |
| cis_mode | True  |
+----------+-------+

Configuring CIS mode enables iptables, which cover all the 3.6.X set of Controls.

Configuring this command applies only to the Controllers and Service Engines created after that. If the CIS mode needs to be enabled for existing SEs, follow one of the following suggested steps:

  • No Downtime: Scale out all Service Engines so that the services fall onto the newly spun SEs. CIS mode will be enabled on the newly created SEs. Scale in to fall back to the former setup, but with CIS mode SEs.

  • With Downtime: Reboot the SEs. When the SEs come back online, the CIS mode will be enabled.

Non-applicable Benchmark Tests for NSX Advanced Load Balancer Service Engine

NSX Advanced Load Balancer Controller and SEs are purpose-built to provide an elastic distributed load balancing functionality and run only on services that are required to provide this functionality. Only the admin user can log in to the SE VM for troubleshooting and recovery. NSX Advanced Load Balancer conforms to the CIS Benchmark tests with a few exceptions as listed below. The text following the instance quotes the reason for the exception.

Note:

The list below only indicates the Benchmark denomination. For more information on the Benchmarks tests, see CIS Benchmarks Landing Page.

  • 1.1 File System Configurations

    • UDF File System – 1.1.1.7: Requires the UDF kernel not to load, leading to Service Engine boot-up issues and failure to connect to the Controller.

    • Separate Partitions – 1.1.2 to 1.1.17: Requires a separate partition for /tmp, /var, /var/log, /var/log/audit, and /home. This does not comply with the two separate logical partitions designed to allow NSX Advanced Load Balancer version rollback.

  • 1.3 File System Integrity Checking

    • File System Integrity Checking – 1.3.2: Requires installation of the aide tool, which is CPU intensive and leads to prolonged duration runs.

  • 1.4 Secure Boot Settings

    • 1.4.1 to 1.4.4: Requires a password-based grub bootloader menu that will interfere with the NSX Advanced Load Balancer single-click upgrade functionality.

  • 3.4 TCP Wrappers

    • 3.4.3: Requires adding default deny in /etc/hosts.deny, which would impact Service Engine connectivity with the NSX Advanced Load Balancer Controller.

  • 5.4.1 Set Shadow Password Suite Parameters

    • 5.4.1.1 to 5.4.1.4: Requires enforcing password policy at the Service Engine level.

NSX Advanced Load Balancer supports only admin users. The Controller manages the password policy, and when the admin user password is changed, it synchronizes this password across the fleet of SEs. So, no password enforcement is required at the SE level.