SIEM под КИИ: корреляционные правила для ГосСОПКА и каталог индикаторов компрометации

ФСТЭК на прошлой неделе выпустил методические рекомендации по обнаружению компьютерных атак на объекты КИИ - документ, которого ждали с прошлого года. Он не обязывающий в смысле приказа, но явно сигнализирует как регулятор смотрит на то, что должно происходить внутри SOC или хотя бы внутри SIEM на значимом объекте. У нас сейчас в работе несколько клиентов именно с этой задачей, так что материал попал в точку.

Делимся наблюдениями из реальной работы, а не пересказом документа.

Что изменилось с выходом рекомендаций

До этого момента требования ФСТЭК к обнаружению атак на КИИ были разбросаны по приказам № 235 и № 239 - там есть обязательные меры по мониторингу, но без детализации как именно это делать. Новый документ - первая попытка дать хоть какой-то практический ориентир: что именно мониторить, какие индикаторы фиксировать, как должна выглядеть передача данных в ГосСОПКА.

Для нас важен конкретный сигнал: ФСТЭК явно ориентируется на матрицу ATT&CK и понятие тактик/техник атакующих. Это не слова в воздухе - это значит, что SIEM-правила, написанные «от сигнатур» в стиле старого IDS, регулятора в перспективе не удовлетворят. Нужна корреляция, которая мыслит техниками, а не только конкретными hash-ами вредоноса.

Что мы делаем на практике

Один из текущих проектов - промышленное предприятие с двумя значимыми объектами КИИ второй категории. SIEM уже стоит - MaxPatrol SIEM, доставшийся вместе с MaxPatrol 8 как часть инфраструктурного аудита. Корреляционных правил под КИИ там не было: стандартный набор PT, который хорош для корпоративного периметра, но не заточен под специфику промышленных сетей.

Первый шаг - каталогизация индикаторов компрометации, применимых к данной среде. Не тянуть стандартный feed из TI-платформы и применять всё подряд, а сначала понять что вообще может происходить именно здесь.

Выделили три группы источников событий:

• Корпоративный периметр - AD, почта, VPN, прокси. Здесь стандартная логика работает неплохо, но нужна привязка к инвентарю критичных систем.
• Демилитаризованная зона между IT и OT - historian-серверы, инженерные станции с доступом в промышленную сеть. Это самая интересная зона с точки зрения атак: кто, когда, с какого хоста установил RDP-сессию к historian-серверу - вопрос, на который SIEM должен давать ответ быстро.
• Промышленная сеть - тут сложнее. Пассивный мониторинг трафика через SPAN-порт даёт видимость протоколов Modbus/DNP3, но коррелировать это с событиями с уровня IT нужно аккуратно: ложные срабатывания здесь стоят дороже, чем в корпоративном сегменте. Оператор АСУ ТП, получив пять алертов за смену на «подозрительные» команды, которые оказываются нормальной работой, через неделю начнёт их игнорировать.

Корреляционные правила: откуда брать логику

Методические рекомендации ФСТЭК называют несколько типов атак, которые нужно детектировать. Мы их прокладываем через матрицу ATT&CK - там есть тактики и техники, в том числе применимые к промышленным системам: разведка через промышленные протоколы, модификация логики управления, манипуляции с уставками.

Несколько правил, которые мы написали или серьёзно доработали:

Множественные провалившиеся аутентификации с последующим успешным входом - классика, но привязанная к критичным системам из реестра объектов КИИ. Сработка на попытку брутфорса к historian-серверу должна идти иначе, чем к обычной рабочей станции.

Нестандартное время доступа к инженерным станциям - конкретно для этого предприятия инженеры работают по графику, и вход в 2 ночи с легитимной учётки - это повод смотреть внимательнее, а не просто логировать.

Изменение конфигурации на сетевом оборудовании OT-зоны - любая команда изменения конфигурации коммутаторов или маршрутизаторов в промышленном сегменте пишется отдельно и эскалируется немедленно.

Аномальные обращения к historian - массовая выгрузка исторических данных за длинный период, особенно в нерабочее время, - это либо подготовка к атаке, либо кто-то делает что-то без ведома ИБ-службы.

Логика эскалации в ГосСОПКА

С подключением к ГосСОПКА мы работаем ещё с января, и один из открытых вопросов тогда был именно про эскалацию: как SIEM-событие превращается в уведомление в НКЦКИ.

Сейчас картина чуть яснее. Методические рекомендации ФСТЭК разграничивают уровни: событие информационной безопасности, инцидент информационной безопасности, и компьютерный инцидент по терминологии ФСБ/НКЦКИ. Не каждый SIEM-алерт становится инцидентом, и не каждый инцидент уходит в ГосСОПКА немедленно.

Мы прописываем это как трёхуровневую логику:

• Уровень 1 - событие: SIEM сработал, аналитик смотрит, нет эскалации. Большинство алертов заканчиваются здесь.
• Уровень 2 - инцидент: подтверждённая вредоносная активность или нарушение политики, требующее реагирования. Фиксируется во внутренней системе учёта инцидентов, оценивается влияние на объект КИИ.
• Уровень 3 - уведомление НКЦКИ: инцидент подтверждён, объект КИИ затронут, уходит структурированное уведомление по установленному формату. Срок - 24 часа для значимых объектов.

Узкое место сейчас - переход с уровня 2 на уровень 3. Нет ни одного инструмента, который бы делал это автоматически: XML для НКЦКИ формируется вручную или полуавтоматически, и человек должен принять решение что именно туда идёт. Это правильно с точки зрения контроля, но при высоком объёме инцидентов будет болью.

Где мы сейчас

Набор правил для первого объекта уже в тестовом режиме - две недели наблюдаем за ложными срабатываниями перед тем как переводить в боевой режим. Второй объект пока в стадии инвентаризации источников событий: выясняется, что несколько систем АСУ ТП вообще не имеют механизма передачи логов в стандартном виде - только проприетарные форматы, для которых нужен кастомный коннектор.

Плюс остаётся открытым вопрос модели угроз. ФСТЭК обещал отраслевые модели угроз для машиностроения - пока их нет, работаем по общей методике, с поправками на специфику конкретной площадки. Корреляционные правила, написанные сейчас, скорее всего, потребуют ревизии когда отраслевые документы выйдут.

Запись об аудите КИИ продолжим - есть что рассказать по обеим площадкам.