Мне всегда очень импонировал армейский способ организации порядка, когда всё одинаковое, зелёное и квадратное — как говорится, «пострижено, покрашено и засеяно песком». При многих своих очевидных недостатках такой подход имеет и плюсы, особенно хорошо заметные в большой корпоративной среде. В этой статье хотелось бы остановиться на вопросе выбора имён/идентификаторов для различных сущностей.
Практически в любом крупном SOC’е есть набор однотипных объектов, счёт которым идёт на сотни, если не на тысячи. Самый яркий пример — правила корреляции в SIEM, хотя то же самое справедливо и для её коннекторов/агентов, отчётов и так далее. И довольно часто (по крайней мере, в моей практике) приходится отвечать на типовые вопросы, как то:
— а сколько у нас всего правил корреляции?
— сколько из них работают (или, по крайней мере, должны работать), а сколько — тестируются или выведены из эксплуатации?
— сколько из них непосредственно генерируют алерты, а сколько выполняют вспомогательные функции?
— на каких источниках событий (логах) основаны эти правила?
— какой тактике/технике MITRE соответствуют эти правила?
— к какому типу (по различным классификациям) относятся эти правила?
— и так далее и тому подобное...
Ваш покорный слуга регулярно получал большинство из перечисленных выше вопросов либо от руководства, либо от аудиторов. Первоначально для поиска ответа приходилось каждый раз искать/придумывать ключевые слова для фильтрации этого списка в «Экселе», а затем сводить результат в единый отчёт. Очень быстро проявились побочные эффекты такого способа: покраснение глаз, боль в голове, долгое время выполнения запроса, ненависть к аудиторам. Спустя некоторое время нашлось простое, но оказавшееся очень эффективным решение: выработать единую конвенцию именования правил и воплотить её в жизнь.
Затраты на мероприятие: два совещания для брейншторминга, пара дней на составление списка «старое имя — новое имя», а также несколько недель на собственно переименование правил в SIEM (как выяснилось, массовое переименование правил может сносить ей крышу, так что пришлось это делать небольшими пачечками).
Для примера приведу вариант схемы имени правила (разумеется, список полей будет уникальным для каждого SOC’а — их надо подбирать под себя):
PRD-client_1-0123-042-P1-AD-TA0006-T1056,T1556-Login Page Code Changed
DEV-client_2-0124-000-P2-Windows,Unix---High CPU Utilization Detected.
Как видно, схема очень проста:
— между различными полями используем одинаковый разделитель (в нашем случае это дефис);
— если поле пустое, то этот разделитель всё равно сохраняем на месте;
— если в поле нужно дописать более одного значения, то используем внутрипольный разделитель (в примере это запятая);
— вводимые в поле данные не должны содержать приведённые выше разделители.
Некоторые примеры полей:
— тип правила (генерирует алерты / вспомогательное / в разработке / выведено из эксплуатации);
— клиент / подразделение, в интересах которого работает правило (либо же «глобальное», если работает для всех);
— уникальный числовой идентификатор правила;
— версия правила (счётчик, увеличивается на 1 после каждого изменения);
— приоритет (удобно для построения квадратно-гнездового SOC’а на раннем этапе зрелости, когда приоритет алерта ещё не получилось сделать динамическим);
— источник(и) событий для правила;
— тактика(и) и техника(и) MITRE;
— имя правила.
После того как все правила переименованы, экспортируем полный список в «Эксель», разбиваем на колонки, используя выбранный разделитель, исправляем обнаруженные ошибки. Когда все ошибки исправлены, у нас получается несколько громоздкие, но удивительно удобные для построения разнообразнейших отчётов имена. Если вы такое ещё не внедрили, задумайтесь!
.png)