How SCA works

Overview of an SCA check

Checks are the core of an SCA policy, as they describe the scan to be performed in the endpoint. The checks contain fields that define what actions the agent should take to scan the endpoint, and how to evaluate the scan results. Each check definition comprises:

• Metadata information including a rationale, remediation, and a description of the check.

• A logical description with the condition and rules fields.

As part of the metadata, the SCA policy can contain an optional compliance field used to specify if the check is relevant to any compliance specifications. SCA checks usually indicate standards or policies that they aim to comply with. For example, we map CIS benchmark, PCI-DSS, NIST, and TSC controls to the relevant SCA checks.

See below SCA policy ID 2651 for Debian 10 operating system as an example of a policy definition.

- id: 2651
    title: "Ensure SSH HostbasedAuthentication is disabled"
    description: "The HostbasedAuthentication parameter specifies if authentication is allowed through trusted hosts via the user of .rhosts, or /etc/hosts.equiv, along with successful public key client host authentication. This option only applies to SSH Protocol Version 2."
    rationale: "Even though the .rhosts files are ineffective if support is disabled in /etc/pam.conf, disabling the ability to use .rhosts files in SSH provides an additional layer of protection."
    remediation: "Edit the /etc/ssh/sshd_config file to set the parameter as follows: HostbasedAuthentication no"
    compliance:
       - cis: ["5.2.9"]
       - cis_csc: ["16.3"]
       - pci_dss: ["4.1"]
       - hipaa: ["164.312.a.2.IV", "164.312.e.1", "164.312.e.2.I", "164.312.e.2.II"]
       - nist_800_53: ["SC.8"]
       - tsc: ["CC6.7"]
    condition: all
    rules:
       - 'c:sshd -T -> r:HostbasedAuthentication\s+no'

Scan Results

SCA scan results appear as alerts with SCA scan data whenever a particular check changes its status between scans. Moreover, ThreatLockDown agents only send those events necessary to keep the global status of the scan updated, avoiding potential events flooding.

Any given check event has three possible results:

• Passed

• Failed

• Not applicable

This result is determined by the set of rules and the rule result aggregator of the check.

Take the following SCA check from policy cis_debian10.yml as an example. The example SCA check shown scans the Debian 10 endpoint to verify if you have implemented a “deny all” policy on your endpoint firewall:

- id: 2603
    title: "Ensure IPv6 default deny firewall policy"
    description: "A default deny all policy on connections ensures that any unconfigured network usage will be rejected."
    rationale: "With a default accept policy the firewall will accept any packet that is not configured to be denied. It is easier to white list acceptable usage than to black list unacceptable usage."
    remediation: "Run the following commands to implement a default DROP policy: # ip6tables -P INPUT DROP # ip6tables -P OUTPUT DROP # ip6tables -P FORWARD DROP. Notes: Changing firewall settings while connected over network can result in being locked out of the system. Remediation will only affect the active system firewall, be sure to configure the default policy in your firewall management to apply on boot as well."
    compliance:
      - cis: ["3.5.4.2.1"]
      - cis_csc: ["9.4"]
      - pci_dss: ["1.2.1"]
      - tsc: ["CC8.1"]
    condition: all
    rules:
      - "c:ip6tables -L -> r:^Chain INPUT && r:policy DROP"
      - "c:ip6tables -L -> r:^Chain FORWARD && r:policy DROP"
      - "c:ip6tables -L -> r:^Chain OUTPUT && r:policy DROP"

After evaluating the aforementioned check, the following event is generated:

"data": {
  "sca": {
    "scan_id": "1433689708",
    "check": {
      "result": "failed",
      "remediation": "Run the following commands to implement a default DROP policy: # ip6tables -P INPUT DROP # ip6tables -P OUTPUT DROP # ip6tables -P FORWARD DROP. Notes: Changing firewall settings while connected over network can result in being locked out of the system. Remediation will only affect the active system firewall, be sure to configure the default policy in your firewall management to apply on boot as well.",
      "compliance": {
        "pci_dss": "1.2.1",
        "tsc": "CC8.1",
        "cis_csc": "9.4",
        "cis": "3.5.4.2.1"
      },
      "description": "A default deny all policy on connections ensures that any unconfigured network usage will be rejected.",
      "id": "2603",
      "title": "Ensure IPv6 default deny firewall policy",
      "rationale": "With a default accept policy the firewall will accept any packet that is not configured to be denied. It is easier to white list acceptable usage than to black list unacceptable usage.",
      "command": [
        "ip6tables -L"
      ]
    },
    "type": "check",
    "policy": "CIS Benchmark for Debian/Linux 10"
  }
},

You can view the scan summaries on the Configuration Assessment module on the ThreatLockDown dashboard.

In addition, you can expand each result to display additional information.

The above SCA scan result is Failed because the rule did not find Chain INPUT * policy DROP, Chain FORWARD * policy DROP, and Chain OUTPUT * policy DROP in the output of the command ip6tables -L. The steps below show how we implement the remediation steps suggested by ThreatLockDown to harden the endpoint:

1. Run the following recommended commands on the monitored endpoint to apply the firewall rules:

   # ip6tables -P INPUT DROP
   # ip6tables -P OUTPUT DROP
   # ip6tables -P FORWARD DROP
   

2. Save the firewall rules and make them persist on system reboot:

   # ip6tables-save > /etc/ip6tables.conf
   # crontab -l | { cat; echo "@reboot /usr/sbin/ip6tables-restore /etc/ip6tables.conf"; } | crontab -
   

3. Restart the ThreatLockDown agent to trigger a new SCA scan:

   # systemctl restart wazuh-agent
   

The scan result for check 2603 changes to Passed as shown in the image below:

A check is marked as Not applicable in case an error occurs while performing the check. In such cases, instead of including the result field, the status and reason fields are included.

Integrity mechanisms

ThreatLockDown uses two integrity mechanisms to ensure integrity between agent-side and server-side SCA states. One of the integrity mechanisms ensures the integrity of the policy files and the second ensures the integrity of scan results.