Detection-as-Сode. Строим пайплайн для конфига Sysmon

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

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

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

Краткое введение в 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 — дос­тавка кон­фига до поль­зовате­лей.

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

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

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

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

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

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

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

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

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

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