Введение

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

Наверное, у большинства специалистов по ИБ слова «правила корреляции» и «корреляционный движок» прочно ассоциируются с таким классом решений, как SIEM. Вероятно, так сложилось потому, что именно там они и задействованы. Здесь же хочется показать вам, что существуют такие задачи в ИБ, решить которые можно не только привычным способом, но и в том числе с применением логики правил корреляции.

Применение правил вне SIEM

Переиспользование давно известных механизмов можно сравнить с подходом разработчика — бывает так, что нам очень нравится определенная библиотека или метод в языке, и мы стремимся любую возникающую проблему этим методом решить. Иногда это бывает эффективно, иногда не очень, но здесь будут собраны 7 примеров применения правил корреляции вне SIEM там, где это действительно сработало.

Некоторые из этих решений мы уже успешно применили и в наших продуктах и активно ими пользуемся.

Что такое правило корреляции, если упростить?

Сначала договоримся, что именно мы подразумеваем под этим и постараемся этот термин обезличить. Правила — это не только про инциденты и события безопасности, это больше о том, что у нас есть набор свойств и атрибутов, которые мы можем связать простым или сложным логическим условием, чтобы потом сделать вывод. Выводы могут быть любыми: принимать или нет какое‑либо решение, запускать ли процесс, эскалировать ли запрос и многое другое.

Суть отчуждаемой логики правил корреляции в том, что у нас появляется возможность сделать какой‑либо вывод на основе свойств и условий.

Мы выявили следующие кластеры применения правил корреляции, где они действительно нам помогли:

• АСУ ТП: поиск и подтверждение воздействия на систему.

• SOC: скоринг для UEBA и макрокорреляции.

• SSDLC: правила для сертификации и управления процессом безопасной разработки.

• SGRC: прогнозирование рисков, autocompliance, расчет КИР и критерии запуска планов восстановления.

Когда мы впервые обезличили и применили «отчужденный» механизм правил корреляции — как будто деталь головоломки встала на свое место. Однако, в процессе решения этих задач прийти к такому было непросто и далеко не очевидно.

Рассмотрим эти кластеры подробнее на примерах.

АСУ ТП: применение в промышленности

Применение правил в промышленности связано с контролем производственного процесса и выявлением в нем нарушений. Это могут быть как объективные факторы сбоев, так и поиск какого‑либо внешнего воздействия. В данном случае подобные проверки можно применять и настраивать в традиционных SCADA‑системах, но в целом эти системы могут быть разными, в том числе и не связанными друг с другом.

Какие же задачи решает применение правил? Вот они:

• Выстраивание потока данных о стабильности работы ассетов производства там, где нельзя проставить СЗИ.

• Получение выводов о факте влияния через косвенные признаки остановки работы.

• Добавление правил корреляции в SCADA с возможностью передать технологу управление движком.

Единый движок корреляции в этом случае может предоставить единую консоль, в которой можно унифицированно создавать правила по контролю производственного процесса, связывать разные потоки как между собой, так и с потоками ИБ и ИТ‑систем.

Чтобы было проще, приведем два примера:

Рефрижераторы и перевозка грузов — представим, что с них производится дискретный сбор данных о температурном режиме. В случае нарушения режима за Х минут в У раз генерируется оповещение, по результату которого можно будет скорректировать маршрут водителя, создать тикет и т. д.

Второй пример — допустим, есть система хранения сырья; в данном случае мы получаем от нее потоки данных по температуре и влажности. Во‑первых, мы уже можем получать алерты о в том случае, если эти данные выходят за рамки допустимых. Если мы сможем связать эти данные с потоком информации от СКУД или видеонаблюдения, мы получим возможность при фиксации алертов из смежных систем ранжировать эти сработки по критичности, запускать автоматизированное реагирование и т. д.

Суть здесь будет заключаться в том, чтобы передать технологу возможность контроля поиска ошибок технологического процесса в режиме одного окна.

SOC: скоринг для UEBA

Применение правил корреляции для расчета превышения порога скоринга было нашей самой первой попыткой переиспользования этой логики где‑то вне SIEM.

У нас есть коробочное решение UEBA, назначение которого заключается в поиске поведенческих аномалий для пользователей или устройств. Интересно то, что этот продукт изначально использовался и представлялся как решение совсем другой проблемы — нужно было компенсировать SIEM и его «несовершенные» правила корреляции, потому что аномалию нельзя просто так просчитать заранее.

Зачем же мы добавили сюда правила? Дело в том, что нам пришлось решать не задачу о том, как выявить инцидент или подозрение на него, наша задача была скорее математической.

В рамках UEBA мы накапливаем различные алерты относительно каждого из объектов. После того как в течение заданного периода времени алертов накопилось достаточно, по достижении порогового значения мы уже можем формировать традиционный инцидент на основе этих данных.

Нам пришлось доработать наш движок правил корреляции, потому что простого правила — Х раз за У минут — нам было недостаточно. Каждый из алертов имеет свой определенный вес, и нам нужно считать не количество, а сумму весов. В итоге правило вышло таким: если сумма весов Х за У минут превысила порог, в этом случае мы генерируем инцидент.

SOC: макрокорреляции

Продолжим решать задачи, связанные с инцидентами. Правила корреляции также можно успешно применить в SOAR, потому что потребностей мы там обнаружили несколько:

• Выстраивание дополнительных связей и поиск похожих инцидентов. Дело в том, что правила могут не только выявить алерт или инцидент, они могут скоррелировать между собой две сущности — то есть мы можем понять, к примеру, насколько два инцидента друг на друга похожи. Обычно такой задачей занимаются аналитики, отсматривая инциденты вручную; заранее где‑то захардкодить разово признаки похожести тоже не получится, потому что поток может быть сколь угодно разнообразный: меняется инфраструктура, состав СЗИ и выявляемые инциденты. Корреляционный движок позволяет централизованно из одной точки соединять инциденты, управлять логикой сопоставления атрибутов, одновременно с этим предоставляя возможность гибко все поменять, будь то временной диапазон или сам атрибут: домен, учетная запись или их контекст: группы серверов и пользователей.

• Поиск атак и агрегация нескольких инцидентов в единую цепочку KillChain. Кроме похожих друг на друга инцидентов, также можно выявлять инциденты, которые связны между собой последовательно: то есть, выявленные инциденты одной атаки можно, к примеру, выстроить в порядке техник/тактик MITRE, дав аналитику больше контекста для расследования. Таким образом, мы получаем новый объект для работы, а еще можем находить маркеры поведения злоумышленников.

Вся суть применения правил корреляций в SOAR в том, что мы применяем движок к уже выявленным инцидентам; наша цель — связать их, обогатить новой информацией и определить их критичность.

SSDLC: безопасная разработка

Давайте обратим внимание на смежную сферу — безопасную разработку.

Сначала поговорим о довольно узкоспециализированном примере — сертификации. Кто пытался автоматизировать этот процесс самостоятельно, тот понимает, насколько это может быть тяжело как в самом начале разработки, так и в процессе применения. Если говорить конкретно о динамическом тестировании, то есть регулирующий орган, который и говорит нам, как это правильно делать и на какие параметры нужно обратить внимание. Для того, чтобы получить сертификат, вам как раз и требуется предоставить доказательства того, что тестирование было необходимым и достаточным.

Предположим, у вас есть фаззинг‑ферма, где крутятся инстансы фаззеров, и в какой‑то момент вам нужно их остановить при достижении условий. Что это могут быть за условия? Рассмотрим самое основное — Х часов без новых путей для сработок. Казалось бы, причем тут правила корреляции? Но когда у вас очень много инстансов и очень большой поток данных, делать это вручную — мягко говоря тяжело. Автоматизировать можно, но это будет децентрализованный подход, да и условия с течением времени могут поменяться. Чтобы упростить себе задачу и добавить возможность гибко этим управлять, можно сделать это, наоборот, централизованно, через правила корреляции, в которые как раз и можно будет добавлять новые условия или корректировать старые.

Другой пример — контроль пайплайна сборки и деплоя. Мы можем написать правила корреляции, которые будут анализировать скоуп сделанных изменений, чтобы дополнительно запускать проверки по юнит‑тестам или ручному тестированию.

Контролируя ошибки в процессе сборки или деплоя, нарушения и отклонения от временных рамок, мы можем выявить признаки внешнего воздействия на пайплайн и создать алерт для последующей проверки процесса. Схожим же образом можно выявить в том числе атаку на цепочку поставок.

Как видите, от маленькой конкретной проблемы мы переходим уже к глобальному подходу и работаем с самим процессом.

SGRC: расчет КИР

Как вообще строится расчет ключевых индикаторов риска? Мы можем рассчитать их, основываясь на информации, полученной из смежных систем. Допустим, в вашей организации КИР рассчитываются на основе информации из систем управления инцидентами, активами и уязвимостями.

Если в вашей организации очень много ДЗО, филиалов, дочек или не очень много людей, которые эти данные обрабатывают, тяжело в режиме реального времени оценить влияние этого потока данных на КИРы. А что, если мы будем обращаться сами в эти смежные системы за информацией? Например, получим инциденты и их типы, просканированные сервера и уязвимости на них, а из активов — нет ли новых устройств.

Исходя из этого, применив правило корреляции, мы можем и рассчитать КИР, и проверить, не превысили ли мы заданное ранее пороговое значение.

В процессе работы над нашими продуктами мы задавались тем же вопросом: как мы могли бы упростить жизнь заказчику и можно ли вообще заложить в коробочное решение формулу, которая помогала бы отслеживать изменение КИР. Потом мы просто поняли, что инструмент у нас уже есть — достаточно просто переиспользовать правила корреляции.

SGRC: Прогнозирование рисков

Пойдем еще дальше. КИР — это только одно звено в цепочке того, что представляет собой общий уровень риска в организации. Помимо индикаторов риска, на общий уровень могут влиять, бизнес‑процессы, системы и их компоненты. В данном случае мы можем перейти от расчета показателей к прогнозированию — как только меняется КИР или критичность какой‑либо системы, мы сразу можем сказать, в какую сторону поменяется общий уровень риска.

SGRC: autocompliance

Для нас автоматический комплаенс — это процесс автоматизированного, непрерывного сбора данных и непрерывного же расчета показателей, в результате чего заказчик получает степень своего соответствия внешним или внутренним стандартам не раз в квартал при очередном аудите, а в режиме реального времени.

В данном случае применение движка корреляции можно выполнить в двух направлениях:

• Создание алертов при выходе за конкретные показатели или их комбинацию — это позволяет своевременно скорректировать ситуацию перед непосредственным аудитом.

• Проверка на консистентность. Так как данные могут поступать как автоматически, так и вручную, нередки случаи ошибок или ввода некорректной информации. Правила корреляции позволят провести проверку показателей, определить, не конфликтуют ли они друг с другом и верна ли оценка. Классический пример — когда оценка непрерывности и показатели RTO, RPO и ряд других для компонентов не должны сильно отличаться от оценки, которая, к примеру, дается по информационной системе в целом.

SGRC: непрерывность бизнеса

Продолжая тему непрерывности, поговорим о еще одной бизнес‑задаче. Что насчет планов восстановления и запуска задач по нему?

Вот у вас случилось какое‑то ЧП. Одновременно с этим у вас есть несколько планов, в которых расписано, какие действия предпринять и кому. Как вам понять, когда стоит начать работать по этому плану и как выбрать его из нескольких? И дополнительное условие — все это автоматизировать.

Счет иногда идет на минуты, если система очень критическая. Здесь нам тоже помогут правила корреляции. Представьте, что у вашей организации есть сайт, который крутится на сервере; и в какой‑то момент вы получаете алерт о том, что этот сервер по какой‑то причине недоступен. Что вам делать? Есть несколько планов восстановления для этого сервера: обращение к провайдеру на случай сбоев соединения, а может быть вообще нужно переехать в другой дата‑центр. Обычно на принятие этого решения уходит много времени и согласований.

Для решения этой проблемы достаточно подвязать корреляционный движок, указав условия для автоматического выбора и запуска плана: к примеру, учет времени недоступности, поиск заявок от ИТ‑департамента о профилактических работах. Возможно, час для вас не очень критичен, а вот три — это уже много.

Выводы

Мы потратили достаточно много времени на исследование проблем, о которых мы рассказали ранее. Несмотря на то, что их можно решить и другими способами, в нашем случае наиболее эффективным было переиспользование того, что у нас уже было разработано.

Попробуйте и вы посмотреть на проблему, которая долго не решается или требует больших затрат, под другим углом. Возможно, применение правил корреляции тоже вам поможет.