# Оценка конфигурации безопасности (SCA) в Wazuh

> Security Configuration Assessment в Wazuh 4.14 - политики CIS Benchmarks, YAML-формат, типы проверок, пользовательские политики и troubleshooting

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-sca/


Модуль Security Configuration Assessment (SCA) в Wazuh выполняет проверку конфигурации систем на соответствие стандартам безопасности. Модуль сравнивает текущие настройки контролируемых систем с эталонными политиками и формирует отчет о пройденных, проваленных и неприменимых проверках. Политики основаны на стандартах CIS Benchmarks и могут быть расширены пользовательскими правилами.

## Принцип работы

SCA оценивает конфигурацию конечных точек по трехэтапному процессу:

1. **Загрузка политики** - агент загружает YAML-файлы политик из локального каталога или получает их централизованно с сервера
2. **Выполнение проверок** - каждая проверка в политике тестирует определенный аспект конфигурации (файл, процесс, реестр, команда)
3. **Формирование результатов** - результаты передаются на сервер и индексируются для визуализации в дашборде

```
Агент загружает политику -> Выполнение проверок ->
-> Результаты (passed/failed/not applicable) ->
-> Отправка на сервер -> Индексатор -> Дашборд
```

## Конфигурация SCA в ossec.conf

Модуль SCA настраивается в блоке `<sca>` файла `/var/ossec/etc/ossec.conf`:

```xml
<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <skip_nfs>yes</skip_nfs>

  <policies>
    <policy>etc/shared/cis_ubuntu22-04.yml</policy>
    <policy>etc/shared/cis_apache_24.yml</policy>
    <policy enabled="no">etc/shared/cis_win2022.yml</policy>
  </policies>
</sca>
```

### Параметры конфигурации

| Параметр | Описание | По умолчанию |
|----------|----------|-------------|
| `enabled` | Включение модуля SCA | yes |
| `scan_on_start` | Запуск сканирования при старте агента | yes |
| `interval` | Интервал между сканированиями | 12h |
| `skip_nfs` | Пропуск сетевых файловых систем | yes |
| `policies` | Список файлов политик для применения | - |

## Встроенные политики CIS Benchmarks

Wazuh поставляется с набором политик, основанных на стандартах CIS (Center for Internet Security). Политики покрывают операционные системы и сервисы.

### Linux

| Политика | Файл |
|----------|------|
| CIS Ubuntu 22.04 | `cis_ubuntu22-04.yml` |
| CIS Ubuntu 20.04 | `cis_ubuntu20-04.yml` |
| CIS Debian 11 | `cis_debian11.yml` |
| CIS Debian 10 | `cis_debian10.yml` |
| CIS CentOS 8 | `cis_centos8.yml` |
| CIS CentOS 7 | `cis_centos7.yml` |
| CIS RHEL 9 | `cis_rhel9.yml` |
| CIS RHEL 8 | `cis_rhel8.yml` |
| CIS RHEL 7 | `cis_rhel7.yml` |
| CIS Amazon Linux 2 | `cis_amazonlinux2.yml` |
| CIS SUSE Linux 15 | `cis_sles15.yml` |

### Windows

| Политика | Файл |
|----------|------|
| CIS Windows Server 2022 | `cis_win2022.yml` |
| CIS Windows Server 2019 | `cis_win2019.yml` |
| CIS Windows Server 2016 | `cis_win2016.yml` |
| CIS Windows 11 Enterprise | `cis_win11_enterprise.yml` |
| CIS Windows 10 Enterprise | `cis_win10_enterprise.yml` |

### Приложения и сервисы

| Политика | Файл |
|----------|------|
| CIS Apache HTTP Server 2.4 | `cis_apache_24.yml` |
| CIS MySQL 8.0 | `cis_mysql80.yml` |
| CIS PostgreSQL 13 | `cis_postgresql13.yml` |
| CIS Docker | `cis_docker.yml` |
| CIS Kubernetes | `cis_kubernetes.yml` |
| CIS Nginx | `cis_nginx.yml` |

## Формат файла политики (YAML)

Каждый файл политики SCA состоит из четырех разделов: `policy`, `requirements`, `variables` и `checks`.

### Раздел policy

Содержит метаданные политики:

```yaml
policy:
  id: "custom_ssh_hardening"
  file: "ssh_hardening.yml"
  name: "SSH Server Hardening Policy"
  description: "Security checks for OpenSSH server configuration"
  references:
    - https://www.cisecurity.org/benchmark/distribution_independent_linux
```

### Раздел requirements

Определяет предварительные условия для выполнения политики:

```yaml
requirements:
  title: "Check SSH server is installed"
  description: "Requirements for running the SSH hardening policy"
  condition: any
  rules:
    - 'f:/etc/ssh/sshd_config'
    - 'p:sshd'
```

Если условия не выполнены, политика пропускается, и все проверки получают статус "Not applicable".

### Раздел variables

Определяет переменные для повторного использования в проверках:

```yaml
variables:
  $sshd_config: /etc/ssh/sshd_config
  $pam_dir: /etc/pam.d
  $ssh_service: sshd
  $audit_log: /var/log/auth.log,/var/log/secure
```

Переменные указываются с префиксом `$` и могут содержать несколько путей через запятую.

### Раздел checks

Содержит набор проверок. Каждая проверка включает метаданные и правила тестирования.

```yaml
checks:
  - id: 5001
    title: "Ensure SSH root login is disabled"
    description: "The PermitRootLogin parameter specifies if root can log in using SSH"
    rationale: "Disabling root login forces administrators to use personal accounts"
    remediation: "Set PermitRootLogin to no in /etc/ssh/sshd_config"
    compliance:
      - cis: ["5.2.10"]
      - pci_dss: ["2.2.4"]
      - nist_800_53: ["AC.6"]
      - mitre_attack: ["T1078"]
    condition: all
    rules:
      - 'f:$sshd_config -> !r:^# && r:PermitRootLogin\s+no'
```

## Типы проверок

### Проверка файлов (f:)

Проверяет существование файла и его содержимое:

```yaml
# Проверка существования файла
- 'f:/etc/ssh/sshd_config'

# Отрицание - файл НЕ должен существовать
- 'not f:/etc/hosts.equiv'

# Проверка содержимого (точное совпадение)
- 'f:/etc/ssh/sshd_config -> PermitRootLogin no'

# Проверка содержимого (регулярное выражение)
- 'f:/etc/ssh/sshd_config -> r:^PermitRootLogin\s+no'

# Числовое сравнение
- 'f:/etc/ssh/sshd_config -> n:MaxAuthTries\s+(\d+) compare <= 4'

# Составное условие (AND)
- 'f:/etc/ssh/sshd_config -> !r:^# && r:PermitRootLogin && r:no'
```

### Проверка каталогов (d:)

Проверяет существование каталога и файлов внутри:

```yaml
# Проверка существования каталога
- 'd:/etc/ssh'

# Поиск файлов по паттерну в каталоге
- 'd:/etc/cron.d -> r:\.cron$'

# Проверка содержимого файлов в каталоге
- 'd:/etc/sudoers.d -> r:NOPASSWD'
```

### Проверка процессов (p:)

Проверяет наличие или отсутствие запущенного процесса:

```yaml
# Процесс должен быть запущен
- 'p:sshd'
- 'p:auditd'

# Процесс НЕ должен быть запущен
- 'not p:telnetd'
- 'not p:rshd'
```

### Проверка команд (c:)

Выполняет команду и проверяет вывод:

```yaml
# Проверка вывода команды
- 'c:systemctl is-enabled sshd -> r:enabled'

# Числовое сравнение вывода
- 'c:sshd -T -> n:maxauthtries\s+(\d+) compare <= 4'

# Проверка статуса сервиса
- 'c:systemctl status firewalld -> r:active'

# Проверка прав на файл
- 'c:stat -c %a /etc/shadow -> r:^0?600$'
```

### Проверка реестра Windows (r:)

Проверяет ключи и значения реестра Windows:

```yaml
# Проверка существования ключа
- 'r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa'

# Проверка значения
- 'r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa -> LimitBlankPasswordUse -> 1'

# Числовое сравнение
- 'r:HKEY_LOCAL_MACHINE\...\Lsa -> n:LmCompatibilityLevel compare >= 3'
```

## Логика оценки

### Поле condition

Поле `condition` определяет, как результаты отдельных правил агрегируются в итоговый результат проверки:

| Значение | Описание |
|----------|----------|
| `all` | Проверка пройдена, если ВСЕ правила пройдены |
| `any` | Проверка пройдена, если ХОТЯ БЫ ОДНО правило пройдено |
| `none` | Проверка пройдена, если НИ ОДНО правило не пройдено |

### Результаты проверок

| Статус | Описание |
|--------|----------|
| **Passed** | Конфигурация соответствует требованиям политики |
| **Failed** | Конфигурация не соответствует требованиям |
| **Not applicable** | Проверка не может быть выполнена (объект не существует) |

### Операторы сравнения

| Оператор | Описание |
|----------|----------|
| `r:` | Совпадение по регулярному выражению |
| `!r:` | Отсутствие совпадения по регулярному выражению |
| `n:` | Числовое сравнение |
| `&&` | Логическое И (объединение условий) |

Числовые операторы: `<`, `<=`, `==`, `!=`, `>=`, `>`

## Написание пользовательских политик

### Полный пример политики

```yaml
policy:
  id: "web_server_hardening"
  file: "web_server_hardening.yml"
  name: "Web Server Security Hardening"
  description: "Custom security checks for Apache/Nginx web servers"
  references:
    - https://httpd.apache.org/docs/2.4/misc/security_tips.html

requirements:
  title: "Check web server is installed"
  description: "At least one web server must be present"
  condition: any
  rules:
    - 'p:apache2'
    - 'p:httpd'
    - 'p:nginx'

variables:
  $apache_conf: /etc/apache2/apache2.conf,/etc/httpd/conf/httpd.conf
  $nginx_conf: /etc/nginx/nginx.conf

checks:
  - id: 10001
    title: "Ensure ServerTokens is set to Prod"
    description: "ServerTokens controls the information returned in HTTP headers"
    rationale: "Detailed server information aids attackers in reconnaissance"
    remediation: "Set ServerTokens Prod in the Apache configuration"
    compliance:
      - cis: ["5.13"]
      - pci_dss: ["2.2.4"]
    condition: all
    rules:
      - 'f:$apache_conf -> !r:^# && r:ServerTokens\s+Prod'

  - id: 10002
    title: "Ensure directory listing is disabled"
    description: "Options -Indexes prevents directory listing"
    rationale: "Directory listing exposes file structure to potential attackers"
    remediation: "Add Options -Indexes to directory configuration"
    compliance:
      - cis: ["5.7"]
    condition: all
    rules:
      - 'f:$apache_conf -> !r:^# && r:Options.*-Indexes'

  - id: 10003
    title: "Ensure TRACE method is disabled"
    description: "TraceEnable Off disables HTTP TRACE method"
    rationale: "TRACE method can be used for cross-site tracing attacks"
    remediation: "Set TraceEnable Off in the Apache configuration"
    compliance:
      - cis: ["5.8"]
      - mitre_attack: ["T1190"]
    condition: all
    rules:
      - 'f:$apache_conf -> !r:^# && r:TraceEnable\s+Off'

  - id: 10004
    title: "Ensure Nginx server_tokens is off"
    description: "server_tokens off hides Nginx version in HTTP headers"
    rationale: "Version disclosure assists in targeted exploit selection"
    remediation: "Set server_tokens off in nginx.conf"
    condition: all
    rules:
      - 'f:$nginx_conf -> !r:^# && r:server_tokens\s+off'

  - id: 10005
    title: "Ensure SSL/TLS is configured"
    description: "Web server should use TLS for encrypted communications"
    rationale: "Unencrypted traffic exposes data to interception"
    remediation: "Configure SSL certificate and enable TLS"
    compliance:
      - pci_dss: ["4.1"]
      - nist_800_53: ["SC.8"]
    condition: any
    rules:
      - 'f:$apache_conf -> r:SSLEngine\s+on'
      - 'f:$nginx_conf -> r:ssl_certificate'
```

### Размещение пользовательских политик

Файлы пользовательских политик размещаются в каталоге `/var/ossec/etc/shared/` и подключаются в конфигурации SCA:

```xml
<sca>
  <policies>
    <policy>etc/shared/web_server_hardening.yml</policy>
  </policies>
</sca>
```

### Централизованное распространение

Для централизованного распространения политик через сервер Wazuh:

1. Разместите файл политики в `/var/ossec/etc/shared/default/` на сервере
2. Политика будет автоматически доставлена всем агентам группы `default`
3. Для групп агентов используйте `/var/ossec/etc/shared/<group_name>/`

## Маппинг соответствия стандартам

SCA политики поддерживают маппинг на следующие стандарты:

| Стандарт | Ключ в compliance |
|----------|-------------------|
| CIS Benchmarks | `cis` |
| PCI DSS | `pci_dss` |
| NIST 800-53 | `nist_800_53` |
| HIPAA | `hipaa` |
| GDPR | `gdpr` |
| TSC (SOC 2) | `tsc` |
| MITRE ATT&CK | `mitre_attack` |

## Дашборд SCA

Дашборд SCA в Wazuh Dashboard предоставляет:

- **Обзор политик** - список политик с процентом пройденных проверок
- **Детализация по агенту** - результаты SCA для конкретного агента
- **История изменений** - динамика изменения результатов во времени
- **Проваленные проверки** - список несоответствий с рекомендациями по устранению
- **Фильтрация** - по политике, агенту, статусу проверки, стандарту соответствия

Доступ к дашборду: Wazuh Dashboard - Modules - Configuration Assessment.

## Рекомендации по устранению

Каждая проверка SCA содержит поле `remediation` с инструкцией по устранению несоответствия. Типичный процесс:

1. Просмотрите проваленные проверки в дашборде SCA
2. Отсортируйте по критичности (CIS Level 1 - обязательные, Level 2 - углубленные)
3. Примените рекомендации из поля `remediation`
4. Дождитесь следующего сканирования или запустите повторную проверку вручную

Для повторного запуска сканирования:

```bash
/var/ossec/bin/agent_control -r -u <agent_id>
```

## Сравнение с альтернативными решениями

| Характеристика | Wazuh SCA | OpenSCAP | Lynis | Nessus Compliance |
|---------------|-----------|----------|-------|-------------------|
| Формат политик | YAML | XCCDF/OVAL | Shell | Проприетарный |
| CIS Benchmarks | Да (встроенные) | Да (SCAP) | Да (частично) | Да (платные) |
| Пользовательские политики | Да | Да (сложный) | Да | Ограниченно |
| Централизованное управление | Да (agent.conf) | Нет | Нет | Да |
| Мониторинг в реальном времени | Периодический | По запросу | По запросу | Периодический |
| Интеграция с SIEM | Встроенная | Требует экспорта | Требует экспорта | Через API |
| Лицензия | Open Source (GPLv2) | Open Source | GPL | Коммерческая |
| Поддержка Windows | Да | Ограниченная | Нет | Да |
| API для результатов | REST API | CLI | CLI | REST API |

Wazuh SCA выделяется простотой формата политик (YAML), централизованным распространением через сервер и встроенной интеграцией с индексатором для долгосрочного хранения результатов.

## Устранение неполадок

### Политика не загружается

1. Проверьте синтаксис YAML-файла:
```bash
python3 -c "import yaml; yaml.safe_load(open('/var/ossec/etc/shared/policy.yml'))"
```

2. Убедитесь, что файл политики указан в конфигурации:
```bash
grep -A5 '<sca>' /var/ossec/etc/ossec.conf
```

3. Проверьте логи агента:
```bash
grep sca /var/ossec/logs/ossec.log | tail -20
```

### Все проверки показывают "Not applicable"

1. Убедитесь, что раздел `requirements` выполнен. Если предварительные условия не соблюдены, все проверки получают статус "Not applicable".

2. Проверьте правильность путей в переменных:
```bash
ls -la /etc/ssh/sshd_config  # пример проверки пути
```

3. Убедитесь, что политика соответствует операционной системе агента.

### Результаты SCA не отображаются в дашборде

1. Проверьте связь агента с сервером:
```bash
/var/ossec/bin/agent_control -i <agent_id>
```

2. Убедитесь, что индексатор доступен:
```bash
curl -sk -u admin:password https://localhost:9200/_cat/indices | grep sca
```

3. Проверьте наличие данных SCA:
```bash
curl -sk -u admin:password \
  "https://localhost:9200/wazuh-states-vulnerabilities-*/_search?size=1" \
  -H "Content-Type: application/json"
```

### Проверка не распознает конфигурацию

1. Проверьте, что регулярное выражение корректно:
```bash
grep -P 'PermitRootLogin\s+no' /etc/ssh/sshd_config
```

2. Учитывайте, что проверка `f:` сопоставляет паттерн с каждой строкой файла по отдельности.

3. Для составных условий (`&&`) все части должны совпадать в одной строке.

## Связанные разделы

- [Мониторинг целостности файлов](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) - FIM отслеживает изменения файлов, SCA проверяет корректность конфигурации
- [Обнаружение уязвимостей](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) - совместное использование SCA и vulnerability detection для комплексной оценки
- [Сценарии использования](/docs/wazuh/getting-started/wazuh-use-cases/) - примеры применения SCA в реальных сценариях