Кон­фигура­цион­ный файл встро­енно­го в Windows средс­тва монито­рин­га Sysmon может раз­растать­ся до тысячи строк, которые опи­сыва­ют пра­вила отбо­ра регис­три­руемых в логах событий. Стан­дар­тный набор фун­кций Sysmon для про­вер­ки кон­фига неудо­бен и зат­рудня­ет работу ана­лити­ка. В этой статье я покажу, как сос­тавлять пай­плайн CI/CD для валида­ции кон­фига Sysmon и сде­лать невоз­можной потерю событий.

Глав­ная проб­лема при работе с Sysmon в том, что в слу­чае ошиб­ки ты получа­ешь текст с атри­бута­ми XML-фай­ла, как на кар­тинке ниже.

Пример вывода ошибки Sysmon
При­мер вывода ошиб­ки Sysmon

www

Один из методов сос­тавле­ния кон­фига Sysmon я уже опи­сал в статье на «Хаб­рахаб­ре».

Ошиб­ки могут быть свя­заны с опе­чат­ками, некор­рек­тны­ми парамет­рами, новыми типами событий — все они спо­соб­ны при­вес­ти к наруше­нию про­цес­са монито­рин­га. Для авто­мати­чес­кой про­вер­ки мы мог­ли бы вос­поль­зовать­ся схе­мой XSD, которая не пос­тавля­ется вмес­те с Sysmon.

www

На GitHub был похожий про­ект, автор опи­сывал XSD-схе­му для раз­ных вер­сий Sysmon и раз­работал модули PowerShell. В нас­тоящее вре­мя про­ект не под­держи­вает­ся.

Для решения проб­лемы мы можем вос­поль­зовать­ся под­ходом Detection-as-Code (DaC). Для его реали­зации я вос­поль­зовал­ся воз­можнос­тями GitLab CI/CD.

info

Прак­тики DevOps набира­ют обо­роты во всех сфе­рах ИТ. Detection engineering не исклю­чение — кол­лабора­ция получи­ла наз­вание Detection-as-Code.

 

Краткое введение в Detection-as-Code

Detection-as-Code — это под­ход вклю­чения прак­тик DevOps в деятель­ность ана­лити­ков SOC и CERT, а так­же инже­неров по внед­рению СЗИ и средств монито­рин­га. DaC поз­воля­ет струк­туриро­вать управле­ние пра­вила­ми обна­руже­ния, кон­фигура­цион­ными фай­лами, про­вес­ти тес­тирова­ние до их исполь­зования в конеч­ном про­дук­те.

В боль­шинс­тве слу­чаев для соз­дания нового пра­вила или редак­тирова­ния сущес­тву­юще­го ана­лити­ку необ­ходимо открыть встро­енный редак­тор исполь­зуемо­го про­дук­та. Изме­нения, вно­симые в поль­зователь­ском интерфей­се, труд­но и неудоб­но отсле­живать. Под­ход DaC поз­воля­ет быть уве­рен­ным, что мы ничего не сло­маем. В про­цес­се CI/CD соз­дава­емый кон­тент тес­тиру­ется до того, как он будет дос­тавлен в целевую сис­тему.

 

Пайплайн

 

Этапы

Мой пай­плайн вклю­чает пять эта­пов:

  1. ".pre" — сбор­ка Docker-кон­тей­нера.
  2. build — сбор­ка кон­фига из модулей для нуж­ной Sysmon вер­сии схе­мы.
  3. test-schema — тес­тирова­ние получен­ных кон­фигов на соот­ветс­твие схе­ме Sysmon.
  4. test-on-windows — тес­тирова­ние кон­фигов на хос­тах (при необ­ходимос­ти мож­но исполь­зовать Windows 10 и Windows 7, если нужен кон­фиг для легаси).
  5. deploy — дос­тавка кон­фига до поль­зовате­лей.
Пример вывода ошибки Sysmon
При­мер вывода ошиб­ки Sysmon

Так выг­лядит начало фай­ла .gitlab-ci.yml:

stages:
- ".pre"
- build
- test-schema
- test-on-windows
- deploy
workflow:
rules:
- changes:
- templates/*.xml

Клю­чевое сло­во stages опре­деля­ет эта­пы в пай­плай­не, а workflow — пра­вило, опи­сыва­ющее, ког­да он будет запус­кать­ся. Мой пай­плайн запус­кает­ся толь­ко при изме­нении модулей кон­фига.

 

Нулевой этап. Сборка образа Docker

Для сбор­ки обра­за Docker я исполь­зую под­ход Docker-in-Docker. Docker-файл так­же находит­ся в репози­тории. На этом эта­пе мы уста­нав­лива­ем Ansible, pywinrm и кол­лекцию Ansible Community.Windows в собира­емый образ.

FROM python:3.12-bookworm
LABEL maintainer="d3f0x0"
RUN apt-get update && apt-get upgrade -y && pip install --upgrade pip && apt-get install ansible -y && pip3 install pywinrm && ansible-galaxy collection install community.windows && apt-get clean
VOLUME [ "/data" ]
WORKDIR /data
CMD ["ansible-playbook", "--version"]

Job для GitLab выг­лядит вот так:

build-docker:
stage: ".pre"
image: docker:dind
tags:
- docker
services:
- name: docker:dind
script:
- echo -n "$CI_REGISTRY_PASSWORD" | docker login -u $CI_REGISTRY_USER $CI_REGISTRY --password-stdin
- docker pull "$CI_REGISTRY_IMAGE:latest" || true
- >
docker build
--pull
--cache-from $CI_REGISTRY_IMAGE:latest
--label "org.opencontainers.image.title=$CI_PROJECT_TITLE"
--label "org.opencontainers.image.url=$CI_PROJECT_URL"
--label "org.opencontainers.image.created=$CI_JOB_STARTED_AT"
--label "org.opencontainers.image.revision=$CI_COMMIT_SHA"
--label "org.opencontainers.image.version=$CI_COMMIT_REF_NAME"
--tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
.
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

В резуль­тате образ будет добав­лен в реестр Docker соот­ветс­тву­юще­го про­екта GitLab. Его мы будем исполь­зовать на осталь­ных эта­пах.

 

Первый этап. Билд конфига

Пер­вый шаг в обес­печении надеж­ности кон­фига Sysmon — это про­вер­ка струк­туры XML-фай­ла. XML дол­жен быть валид­ным, что­бы Sysmon кор­рек­тно интер­пре­тиро­вал кон­фиг.

Я решил раз­делить свой кон­фиг по модулям, которые может регис­три­ровать драй­вер Sysmon (ProcessCreate, NetworkConnection и так далее). Этот спо­соб исполь­зует­ся в репози­тории sysmon-modular.

Пример вывода ошибки Sysmon
При­мер вывода ошиб­ки Sysmon

Что­бы мож­но было работать с раз­ными вер­сиями Sysmon, я пре­дус­мотрел вари­ант, ког­да ито­говый кон­фиг собира­ется на осно­ве схем, пос­тавля­емых вмес­те с Sysmon.

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    2 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии