How SCA works

Each agent has its own local database where it stores the current state of each check. Agents only send the differences detected between scans. If there has been no change, only the scan summary event will be sent, thus avoiding unnecessary network traffic while keeping the manager up to date. The manager will then use those updates to issue alerts that will be shown in the Wazuh dashboard.

Integrity and alerting flow are depicted in the sequence diagram below:

Scan Results

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 check from policy cis_debian9.yml as an example.

- id: 2100
  title: "Ensure auditd service is enabled"
  description: "Turn on the auditd daemon to record system events."
  rationale: "The capturing of system events provides system administrators with information to allow them to determine if unauthorized access to their system is occurring."
  remediation: "Run the following command to enable auditd: # systemctl enable auditd"
  compliance:
    - cis: ["4.1.2"]
    - cis_csc: ["6.2", "6.3"]
    - pci_dss: ["10.1","10.7"]
    - tsc: [CC6.1", "CC6.2", "CC6.3", "CC7.2", "CC7.3", "CC7.4"]
  condition: all
  rules:
    - 'c:systemctl is-enabled auditd -> enabled'

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

"data": {
  "sca": {
    "scan_id": "697507169",
    "check": {
      "result": "failed",
      "remediation": "Run the following command to enable auditd: # systemctl enable auditd",
      "compliance": {
        "pci_dss": "10.1,10.7",
        "tsc": "CC6.1,CC6.2,CC6.3,CC7.2,CC7.3,CC7.4",
        "cis_csc": "6.2,6.3",
        "cis": "4.1.2"
      },
      "description": "Turn on the auditd daemon to record system events.",
      "id": "2100",
      "title": "Ensure auditd service is enabled",
      "rationale": "The capturing of system events provides system administrators with information to allow them to determine if unauthorized access to their system is occurring.",
      "command": [
        "systemctl is-enabled auditd"
      ]
    },
    "type": "check",
    "policy": "CIS Benchmark for Debian/Linux 9"
  }
},

The result is failed because the rule did not find enabled in the output of command systemctl is-enabled auditd.

Note

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

Integrity mechanisms

To ensure integrity between agent-side and manager-side states, for that particular agent, two integrity mechanisms have been included in SCA, one for policy files and the second for scan results.

Integrity of policy files

This mechanism is in charge of keeping policy files and scan results aligned. Whenever a change in a policy file is detected, SCA will invalidate the results stored in the database for that policy and request a fresh dump of them.

In a nutshell, whenever the hash of a policy file changes, the recovery steps performed are:

A message appears in the manager log file, e.g:

2022/08/04 17:58:22 wazuh-analysisd: INFO: Policy 'cis_debian9' information for agent '001' is outdated. Requested latest scan results.

The manager flushes its stored data for that policy.
The agent sends the scan results for that policy.
The manager updates its database and fires alerts for the new scan results.

Note

Alerts for every check result of the updated policy will be fired. This way, false negatives are avoided.

Integrity of the scan results

To illustrate how the integrity of scan results is kept, we will use an example in which the agent-side database and the manager-side differ. This scenario could happen due to, for instance, a network issue.

States stores in the Agent and Manager sides
Check ID	Agent-side state	Manager-side state
1000	Passed	Passed
1001	Failed	Failed
1002	Failed	Missing
1003	Passed	Passed

For those databases, the corresponding SHA256 hashes are:

Agent:   1642AB1DC478052AC3556B5E700CD82ADB69728008301882B9CBEE0696FF2C84
Manager: B43037CA28D95A69B6F9E03FCD826D2B253A6BB1B6AD28C4AE57A3A766ACE610

Given that the two hashes do not match, the manager will request the agent for its latest scan data and refresh its database with the newly received status information.