Wazuh та Kubernetes: Федеровані інструменти аудиту в SIEM

Управління журналами та подіями в гетерогенній інфраструктурі створює труднощі у виконанні вимог відповідності, обсягах даних та різних стратегіях управління. Ваша інфраструктура, ймовірно, зростає, і ви використовуєте багато інструментів безпеки, панелей моніторингу та інтеграцій… Залишайтеся спокійними; ми вже стикалися з подібною ситуацією раніше. 🤙

Обсяг

Ця стаття визначає централізоване рішення для аудиту безпеки в середовищі Kubernetes. Міжфункціональна команда, що підтримує пул Kubernetes кластерів (з кількома вимогами безпеки та інструментами), потребує масштабованого рішення SIEM для регульованого середовища.

Команда з безпеки та архітектори вирішили використовувати Falco, Trivy і журнали аудиту Kubernetes разом із Wazuh SIEM в Kubernetes. 👌

Інші інструменти безпеки, такі як NeuVector, Tetragon, kube-bench або AquaSecurity, разом з різними SIEM та застарілими варіантами, також можуть бути розглянуті в обсязі.

pic

Вимоги та особливості

Підхід до SIEM

Wazuh — це безкоштовна, з відкритим кодом платформа для запобігання загроз, виявлення та реагування. Вона захищає робочі навантаження в локальних, віртуальних, контейнеризованих та хмарних середовищах. Це рішення SIEM забезпечує агент безпеки для моніторингових систем і сервер управління для збору та аналізу даних.

Wazuh допомагає впроваджувати вимоги відповідності для регулювання і видимості. Це досягається через автоматизацію, покращення контролю безпеки, аналіз журналів і реагування на інциденти. Набір правил Wazuh підтримує такі рамки і стандарти, як PCI DSS, HIPAA, NIST 800–53, TSC та GDPR.

Ми розробили Wazuh для інтеграції в Kubernetes як XDR рішення, яке обробляє більше випадків використання без необхідності агента на кожній системі кінцевої точки.

Архітектура

  • Клієнтський рівень → Експортує журнали та події на сервер з Kubernetes кластерів.
  • Серверний рівень → Збирає, аналізує, сповіщає та ініціює дії у Kubernetes кластерах.
  • Frontend рівень → Візуалізує та представляє події для користувачів.

pic

Високорівнева архітектура дизайну

Клієнтський рівень містить Kubernetes кластери з кількома джерелами, такими як Falco, Elastic та агенти Wazuh на віртуальних машинах, хмарні монітори та Github.

Серверний рівень розгорнутий в середовищі Kubernetes, забезпечуючи централізовану та високо доступну інфраструктуру. Цей рівень включає сервер Wazuh, OpenSearch як індексатор даних, Kafka та спеціально розроблені “Wazuh Super Agents”. "Kafka посередині" дозволяє розширювати різні випадки використання, від інструментів клієнтського рівня до тем Kafka.

Falco — це платформа безпеки в реальному часі з відкритим кодом, яка виявляє та реагує на підозрілу поведінку. Ми вирішили інтегрувати її з Wazuh для стандартизованої підтримки мультикластерного використання замість використання підходу "кластер за кластером" і "інструмент за інструментом".

pic

Різноманітність тем Kafka з різних джерел

Чудово, на цьому етапі всі повідомлення з різних джерел централізовані в темах 😊… але… Які кроки необхідно виконати для інтеграції з сервером Wazuh? Відповідь — це "Wazuh Super Agents", які були розроблені. Ці агенти споживають теми Kafka та відправляють дані на сервер Wazuh, як звичайний агент Wazuh... Цей метод дозволяє деталізоване управління та багатокористувацьке управління темами, виходячи за межі лише EDR.

pic

Рішення архітектури

Якщо вас цікавить "Wazuh Super Agent", основний код надано нижче.
Це агент Wazuh з розширеною підтримкою функцій, включаючи інтеграцію з третіми сторонами, rsyslog тощо... усе це підтримується продуктом.

---  
# Джерело: logstash/templates/configmap-pipeline.yaml  
# проблема в ontrack: https://github.com/logstash-plugins/logstash-input-kafka/issues/192  
apiVersion: v1  
kind: ConfigMap  
metadata:  
 name: {{ accountAgentTst }}-log-logstash-pipeline  
 labels:  
 app: "{{ accountAgentTst }}-log-logstash"  
 chart: "logstash"  
 heritage: "Helm"  
 release: "{{ accountAgentTst }}-log"  
data:  
 logstash.conf: |  
 input {  
 kafka{  
 codec => json  
 bootstrap_servers => "x-kafka.x-kafka.svc:9092"  
 topics_pattern => ".*-{{ accountAgentTst }}"  
 # topics_pattern => "logging_filebeat-{{ accountAgentTst }}"  
 client_id => "x-siem_{{ accountAgentTst }}"  
 group_id => "x-siem_{{ accountAgentTst }}"  
 metadata_max_age_ms => 60000  
 auto_offset_reset => "earliest"  
 }  
 }  

 output {  
 file {  
 path => "/var/log/kafka/kafka_{{ accountAgentTst }}.log"   
 file_mode => 0655  
 codec => json_lines  
 }  
 }

# Зв'язок з сервером WAZUH з контейнера ubuntu  
apiVersion: v1  
kind: ConfigMap  
metadata:  
 name: ubuntu-agent-cm-{{ accountAgentTst }}  
 labels:  
 app.kubernetes.io/name: ubuntu-agent-{{ accountAgentTst }}  
data:  
 ubuntu-agent.sh: |-  
 # перевіряємо значення повернення. Якщо ми отримуємо ціле число, то агент вже зареєстрований.
Це агент Wazuh з розширеною підтримкою функцій, включаючи інтеграцію з третіми сторонами, rsyslog тощо... усе це підтримується продуктом.

Джерело: logstash/templates/configmap-pipeline.yaml

проблема в ontrack: https://github.com/logstash-plugins/logstash-input-kafka/issues/192

apiVersion: v1
kind: ConfigMap
metadata:
name: {{ accountAgentTst }}-log-logstash-pipeline
labels:
app: "{{ accountAgentTst }}-log-logstash"
chart: "logstash"
heritage: "Helm"
release: "{{ accountAgentTst }}-log"
data:
logstash.conf: |
input {
kafka{
codec => json
bootstrapservers => "x-kafka.x-kafka.svc:9092"
topicspattern => ".*-{{ accountAgentTst }}"
# topicspattern => "loggingfilebeat-{{ accountAgentTst }}"
clientid => "x-siem{{ accountAgentTst }}"
groupid => "x-siem{{ accountAgentTst }}"
metadatamaxagems => 60000
autooffset_reset => "earliest"
}
}

output {
file {
path => "/var/log/kafka/kafka{{ accountAgentTst }}.log"
filemode => 0655
codec => json_lines
}
}
```

# Зв'язок з сервером WAZUH з контейнера ubuntu  
apiVersion: v1  
kind: ConfigMap  
metadata:  
 name: ubuntu-agent-cm-{{ accountAgentTst }}  
 labels:  
 app.kubernetes.io/name: ubuntu-agent-{{ accountAgentTst }}  
data:  
 ubuntu-agent.sh: |-  
 # перевіряємо значення повернення. Якщо ми отримуємо ціле число, то агент вже зареєстрований.
- name: ubuntu-agent-cm  
 mountPath: /var/tmp/ossec.conf  
 subPath: ossec.conf  
 - name: rsyslog-configwazuh  
 mountPath: /var/tmp/rsyslog.configwazuh  
 subPath: rsyslog.configwazuh  
 - name: rsyslog-configwazuh  
 mountPath: /var/tmp/rsyslog.confwazuhfile  
 subPath: rsyslog.confwazuhfile  
 - name: cacert-ssl  
 mountPath: /usr/local/share/ca-certificates  
 readOnly: true  
 - name: cert-ssl  
 mountPath: /var/tmp/certs/  
 readOnly: true  
 - name: logging-data  
 mountPath: /var/log/remote/  
 readOnly: false  
 - name: rsyslog-configwazuh  
 mountPath: /etc/logrotate.d/kafkarotate.conf  
 subPath: kafkarotate.conf  
 volumes:  
 - name: ubuntu-agent-cm  
 configMap:  
 name: ubuntu-agent-cm-{{ accountAgentTst }}  
 defaultMode: 0655  
 - name: rsyslog-configwazuh  
 configMap:  
 name: rsyslog-configwazuh-cm-{{ accountAgentTst }}  
 defaultMode: 0655  
 - name: cacert-ssl  
 secret:  
 secretName: cacert-{{ instanceSubDomain }}.int.{{ instanceDomain }}  
 - name: cert-ssl  
 secret:  
 secretName: cert-{{ instanceSubDomain }}.{{ instanceDomain }}  
 - name: logstashconfig  
 configMap:  
 name: {{ accountAgentTst }}-log-logstash-config  
 - name: logstashpipeline  
 configMap:  
 name: {{ accountAgentTst }}-log-logstash-pipeline  
 - name: logstashpattern  
 configMap:  
 name: {{ accountAgentTst }}-log-logstash-pattern

Після налаштування Wazuh потрібно конфігурувати правила, мітки, сповіщення, відповіді та інтеграцію з фронтальним шаром.
В нашому конкретному випадку ми вибрали Wazuh з інтеграцією через API з Jira, що було зручніше для нашої підтримки. Також ми налаштували сповіщення, щоб правильно ідентифікувати моніторинговану систему (наприклад, Falco), назву кластера, подію та її серйозність.

pic

Приклад Wazuh Dashobard “Super Agent”

pic

Приклад сповіщення Jira від Wazuh

Які є основні відмінності нашого рішення?

  • Централізована архітектура SIEM, інтегрована з поширеними інструментами безпеки Kubernetes.
  • Об’єднані дашборди
  • Повне розгортання в Kubernetes.
  • Повністю відкриті компоненти.
  • API комунікація між компонентами
  • Wazuh “Super Agents” забезпечують зв'язок між серверами без агентів на моніторингових системах.
  • Falcosidekick інтегрований з Kafka у багатокластерному рішенні.
  • Використання OpenSearch як бекенду Wazuh забезпечує безпечну комунікацію.
  • Транспорт і мережа між клієнтами і серверами захищені VPN та TLS з’єднаннями.
  • Модель доставки, що асоціюється з поліпшенням

Роздуми

  • Оцінити кількість необхідного сховища та витрати на сховище
  • Оцінити модель обслуговування після впровадження та витрати на управління
  • Рішення може вимагати управління сертифікатами для всіх розгорнутих компонентів (Wazuh, Opensearch, Kafka…)
  • SIEM потребує сильної організації управління та кваліфікованої команди
  • Навчання по SIEM для виявлення помилок позитивних та негативних спрацьовувань
  • Постійне вдосконалення
  • Wazuh для Kubernetes постійно розвивається.
  • Переконайтеся, що продукти та рішення відповідають вашим політикам та регламентам (збереження даних, GDPR…)
  • Мета цього документа не полягає в наданні глибокого аналізу інструментів та регламентів.
  • Стратегії резервного копіювання та відновлення даних
  • Це рішення було розроблене у 2023 році, і сьогодні ми використовуємо інший продукт SIEM.

Перекладено з: Wazuh & Kubernetes: Federated Audit Tools in SIEM

Вам також може сподобатися

Розуміння ролей IAM в AWS: AssumeRole та призначення ролей
Поради та хитрості за лаштунками
WebForms у PHP!

Leave a Reply

Your email address will not be published. Required fields are marked *