ГосСОПКА: ФСБ уточняет требования к подключению субъектов КИИ и форматы данных об инцидентах
ФСБ обсуждает в рабочей группе STIX/TAXII как базу для обмена данными с ГосСОПКА. Сравниваем технические форматы с тем, что умеет наш SIEM на практике.
ФСБ уточняет технические требования к подключению субъектов КИИ к ГосСОПКА и обсуждает форматы передачи данных об инцидентах в рабочей группе
После того как 187-ФЗ наконец подписан, технические детали взаимодействия с ГосСОПКА перестали быть абстракцией. В начале июля появились первые конкретные сигналы от ФСБ: регулятор ведёт рабочую группу, где обсуждаются форматы передачи данных об инцидентах. Один из обсуждаемых вариантов - STIX и TAXII. Для нас это повод разобраться, насколько наш SIEM вообще готов к такому разговору.
О том, что порядок взаимодействия с ГосСОПКА пока не утверждён даже в виде проекта, мы писали неделю назад, разбирая что стоит за подписанным 187-ФЗ. Теперь вырисовывается хотя бы направление.
Что такое STIX и TAXII в двух словах
Для тех, кто не сталкивался: STIX (Structured Threat Information eXpression) - это язык описания киберугроз. Инцидент, индикатор компрометации, кампания атакующего, уязвимость - всё это описывается в едином JSON-формате с жёсткой схемой. TAXII (Trusted Automated eXchange of Intelligence Information) - транспортный протокол поверх HTTPS для обмена такими данными между системами.
Международный ситуационный центр, CERT-EU, FS-ISAC - многие организации уже строят обмен данными об угрозах именно на этом стеке. Версия STIX 2.0 вышла в начале 2017 года и сейчас идёт через OASIS как стандарт.
Если ФСБ ориентируется на STIX/TAXII, логика понятна: это готовая, разработанная экосистема с открытыми спецификациями. Изобретать собственный формат с нуля - плохая идея для регулятора, особенно если думать об интеграции с международными CERT.
Что умеет наш SIEM с этим форматом
Мы посмотрели на свой стек с прагматичной точки зрения: что умеем сейчас, что надо доработать.
Импорт индикаторов компрометации. QRadar, на котором мы работаем, умеет потреблять внешние списки IoC через Reference Sets. Если кто-то отдаёт эти данные в STIX-формате - нужна прослойка, которая их распаршивает и заливает в нужные наборы. Готовых коннекторов для STIX 2.0 пока нет в стандартной поставке, но это решаемо Python-скриптом.
Экспорт данных об инциденте. Вот тут сложнее. Когда регулятор просит передать данные об инциденте в STIX-формате, нужно взять инцидент из SIEM и сгенерировать корректный STIX Bundle - с объектами типа incident, indicator, attack-pattern, связями между ними. У каждого нашего инцидента есть таймлайн, затронутые хосты, IOC, правило корреляции, которое сработало. Всё это есть в системе, но маппинг на STIX-объекты надо прописывать руками - универсального экспортёра нет.
Транспорт через TAXII. Это отдельный вопрос. TAXII-сервер - самостоятельный компонент. Клиентских библиотек для Python несколько: cabby для TAXII 1.x, taxii2-client для TAXII 2.0 - они рабочие. Серверную часть для входящего соединения от ГосСОПКА придётся поднимать отдельно.
Что конкретно мы начали делать
Пока официального документа нет, мы работаем с тем, что есть - спецификациями STIX 2.0 и TAXII 2.0 из OASIS плюс тем, что просачивается из рабочей группы.
Первое - маппинг полей. Мы взяли типовой инцидент из нашей практики и попробовали вручную описать его в STIX Bundle. Сразу выяснилось: STIX очень строгий в отношении временных меток и UUID. Каждый объект требует глобально уникального идентификатора и метки времени в UTC с секундами. У нас временные метки в SIEM хранятся в UNIX epoch - конвертация тривиальная, но её надо заложить. UUID генерировать не проблема, но их надо хранить для последующей корреляции: если ФСБ пришлёт запрос «расскажите подробнее об инциденте с UUID таким-то» - надо быть готовым ответить.
Второе - структура типовых объектов. Мы посмотрели на то, что чаще всего фиксируем в инцидентах: сетевые соединения, изменения файлов, lateral movement, подозрительные процессы. STIX покрывает всё это через объекты network-traffic, file, process, user-account. Для АСУ ТП есть расширение, но оно ещё черновое.
Третье - вопрос, который пока без ответа. Неясно, будет ли ГосСОПКА выступать TAXII-клиентом (она сама приходит к нам за данными) или сервером (мы сами отправляем). Это принципиально для архитектуры: в первом случае достаточно поднять TAXII-сервер с доступом наружу, во втором - нужен исходящий агент. Ждём документ от ФСБ.
Почему это важнее, чем кажется
Вопрос формата - это не технический нюанс. Если ГосСОПКА принимает STIX - это значит, что между субъектом КИИ и регулятором появляется машиночитаемый язык. Дальше возможна автоматизация: система сама отправляет уведомление об инциденте без ручного заполнения форм. Это лучше, чем любой XML с произвольной структурой, который каждый интерпретирует по-своему.
Для клиентов, которых мы ведём в рамках мониторинга управляемой безопасности, это влияет на требования к их SIEM. Если раньше можно было работать с любой системой, которая умеет генерировать алерты, то с ГосСОПКА потребуется машиночитаемый вывод в конкретном формате. Системы без API или с закрытой схемой данных создадут проблемы.
Промежуточный итог
Пока документа нет - готовиться к конкретной реализации рано. Но изучить STIX/TAXII сейчас полезно вне зависимости от того, что в итоге утвердит ФСБ: это стандартный формат обмена данными об угрозах, который используется в threat intelligence в широком смысле. Мы уже настраивали корреляционные правила после WannaCry - тогда данные об IoC прилетали в разрозненных текстовых форматах, и их надо было руками разбирать. Структурированный STIX-фид был бы значительно удобнее.
Как только из рабочей группы ФСБ выйдет хоть какой-то проект - разберём детально.