Wazuh and TSC (SOC 2) - Trust Services Criteria Mapping

Wazuh supports the Trust Services Criteria (TSC) for SOC 2 audits through log analysis, file integrity monitoring, configuration assessment, vulnerability detection, and active response. The default ruleset includes tsc_ tags for mapping events to TSC criteria.

TSC and SOC 2 Overview

Trust Services Criteria (TSC) 2017 defines a set of criteria for evaluating an organization’s controls as part of a SOC 2 (Service Organization Control 2) audit. TSC was developed by AICPA (American Institute of Certified Public Accountants) and includes five categories:

• Security (CC) - Common Criteria - protection of information and systems
• Availability (A) - system and data availability
• Processing Integrity (PI) - data processing integrity
• Confidentiality (C) - information confidentiality
• Privacy (P) - personal data privacy

The Security (Common Criteria) category is mandatory for all SOC 2 audits. The remaining categories are selected based on the nature of services provided.

TSC Criteria Mapping to Wazuh Modules

Common Criteria (CC) - Security

Additional Criteria

CC6 - Logical and Physical Access Controls

CC6 is one of the most thoroughly covered criteria in Wazuh. It encompasses:

CC6.1 - Logical Access Restrictions

Wazuh monitors all authentication and authorization events:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

Rules tagged with tsc_CC6.1 trigger on access anomalies:

<rule id="5710" level="5">
  <if_sid>5700</if_sid>
  <match>illegal user|invalid user</match>
  <description>sshd: Attempt to login using a non-existent user</description>
  <group>authentication_failed,tsc_CC6.1,tsc_CC6.8,</group>
</rule>

CC6.2 - Account Lifecycle Management

Monitoring account creation and management:

<rule id="100400" level="8">
  <if_sid>5901</if_sid>
  <description>New user account created - SOC 2 audit event</description>
  <group>tsc_CC6.2,tsc_CC6.3,account_changed,</group>
</rule>

CC6.6 - External Threat Protection

Wazuh detects external threats through log analysis rules and event correlation, including brute-force attack detection, port scanning, and known exploit identification.

CC6.8 - Unauthorized Access Prevention

Monitoring multiple failed authentication attempts:

<rule id="5712" level="10" frequency="6" timeframe="120">
  <if_matched_sid>5710</if_matched_sid>
  <description>sshd: brute force detected</description>
  <group>tsc_CC6.8,tsc_CC7.2,authentication_failures,</group>
</rule>

CC7 - System Operations

CC7.1 - Anomaly Detection Monitoring

Wazuh provides continuous monitoring through:

• Real-time log analysis
• FIM for change detection
• System event anomaly detection
• MITRE ATT&CK tactic mapping

CC7.2 - System Component Monitoring

<syscheck>
  <directories check_all="yes" realtime="yes">/usr/bin</directories>
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes" whodata="yes">/var/data</directories>
</syscheck>

CC7.3 - Security Event Assessment

The Wazuh Dashboard provides event assessment tools:

• Classification by severity level (0-15)
• Grouping by rules and categories
• Trend analysis over time

CC7.4 - Incident Response

Active response provides automated incident handling:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <level>10</level>
  <timeout>3600</timeout>
</active-response>

CC8 - Change Management

CC8.1 - Change Control

FIM tracks all changes to critical files and configurations:

<syscheck>
  <directories check_all="yes" whodata="yes" report_changes="yes">/etc</directories>
  <directories check_all="yes" whodata="yes" report_changes="yes">/opt/app/config</directories>
</syscheck>

The whodata attribute captures the user and process responsible for each change, which is critical for SOC 2 audits.

A1 - Availability

A1.1 - Maintaining Availability

Wazuh monitors events that affect availability:

• Service failures and system restarts
• Resource exhaustion (disk, memory, CPU)
• Network issues and disconnections

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/syslog</location>
</localfile>

PI1 - Processing Integrity

PI1.4 - Processing Error Detection

Wazuh detects processing errors through application log analysis:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/app/processing.log</location>
</localfile>

FIM monitors data integrity during processing.

TSC Rule Groups

Wazuh uses the tsc_ prefix for rule tagging. Retrieve available tags:

docker exec wazuh-manager grep -r "tsc_" /var/ossec/ruleset/rules/ | \
  grep -oP 'tsc_[A-Z]+[\d.]+' | sort -u

Key groups:

SOC 2 Audit Support

Wazuh helps organizations prepare for SOC 2 audits through:

Evidence Collection

• Centralized event logs with timestamps
• Access control and authentication records
• SCA configuration compliance reports
• Change control records via FIM

Control Demonstration

• Automated threat detection and response
• Continuous security monitoring
• Regular vulnerability assessment
• Security posture visualization through the dashboard

Report Generation

To query TSC-related alerts via the API:

curl -sk -u admin:$WAZUH_ADMIN_PASS \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{
    "size": 0,
    "query": {
      "bool": {
        "must": [
          { "range": { "timestamp": { "gte": "now-30d" } } },
          { "exists": { "field": "rule.tsc" } }
        ]
      }
    },
    "aggs": {
      "tsc_criteria": {
        "terms": { "field": "rule.tsc", "size": 50 }
      }
    }
  }' | jq '.aggregations.tsc_criteria.buckets'

TSC Dashboard Module

The Wazuh Dashboard includes a TSC module under Modules > Regulatory compliance > TSC. The module provides:

• Alert overview by TSC category
• Grouping by Common Criteria criterion
• Compliance event timeline
• Per-agent detail views

Troubleshooting

TSC alerts not appearing

1. Verify that rules contain tsc_ tags in the <group> field
2. Confirm the TSC module is enabled in the dashboard settings
3. Check the time range filter for correctness

Missing access control data for CC6

1. Review the authentication log collection configuration
2. Confirm log sources are specified in ossec.conf
3. Verify that agents are active and transmitting data

FIM not generating alerts for CC8

1. Confirm monitored directories are specified in <syscheck>
2. Verify that monitoring is enabled
3. When using whodata, confirm that auditd is installed