Доброго времени суток всем!
Сама по себе тема SIEM является в последнее время популярной. В виду комплексной сложности этих систем, вопросы, связанные с их использованием, глубокие и объемные. Существует довольно много статей (на Хабре и не только), посвященных SIEM. Однако в подавляющем большинстве они затрагивают тему с точки зрения теории, методологии и общих принципов построения процессов. А вот статей, описывающих практические аспекты применения/настройки этих систем, совсем нет катастрофически мало. Эта статья описывает как на практике подружить IPS и SIEM на примере Cisco IPS и Prelude, а также приведен пример правила корреляции, позволяющего выявить успешную эксплуатацию наболевшей в последние дни уязвимости HeartBleed.

1. Введение / постановка задачи

Итак, мы внедрили IPS в Inline, что дальше?
Очевидно, что следующим шагом необходимо как-то следить за тем что IPS отлавливает, в каком количестве, кого и откуда атакуют и т.д.
Если быть более конкретным:

1. Нужно поддерживать актуальный для защищаемых хостов набор активных сигнатур.
2. Для эффективной работы IPS-сенсоров необходимо постоянно «держать руку на пульсе»: нужно постоянно адаптировать сенсор под конкретные сеть и трафик. Достигается это путём настройки правил с исключениями.
3. Среди множества алертов, полученных от IPS, необходимо выделять действительно важные и критичные.
4. Для критичных алертов также необходимо обеспечить корректный набор агрессивных действий (блокировка трафика, сброс сессий, бан IP и т.д.), предпринимаемых сенсором, а также оповещения администратора о них.
5. Состояние самого сенсора также необходимо отслеживать (загруженность сканирующего движка, ошибки обновления, сроки действия лицензий и т.д.).

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

2. «Штатные» средства просмотра событий IPS

Существует множество способов собирать и обрабатывать события от IPS.
Из штатных средств просмотра событий от сенсоров Cisco есть такие варианты:

2.1 Просмотр событий локально на сенсоре

Это средство, принцип действия которого можно охарактеризовать как «в лоб». На каждом сенсоре существует своё локальное хранилище событий. Само собой, увидеть в нем можно только то, что было обнаружено непосредственно на конкретном сенсоре.

Какой-либо группировки/агрегации событий по каким-либо признакам не предусмотрено. Максимум, что можно себе позволить – отфильтровать отображаемые события по ряду критериев (критичность сигнатуры, время выборки, показывать/не показывать системные события сенсора). Сам листинг событий при этом выглядит следующим образом:

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

2.2 Cisco IPS Manager Express

Следующей «родной» альтернативой предыдущему средству является IME. Это бесплатное решение от Cisco, позволяющее осуществлять конфигурацию и мониторинг событий для максимум 10-ти IPS-сенсоров. В плане конфигурации стоит заметить, что тут речь идёт об общей консоли для устройств, т.е. нет возможности создавать политики конфигурации (за исключением трёх параметров, относящихся к функциям Global Correlation, Reputation Filtering и Network Participation).
Что касается сбора событий – здесь уже ситуация сильно лучше: алерты от различных сенсоров собираются в общую базу данных.

Поддерживаются сбор событий как от IPS-апплаинсов/модулей, так и от IOS-IPS роутеров. Есть возможность группировки и фильтрации событий по различным признакам. В каждое событие можно «провалиться» для просмотра более подробной информации:

Ещё одной полезной функцией IME является возможность оповещать через email о полученных от IPS событиях. Критериев выбора об оповещениях всего два: Attack Severity Rating и RiskRating.

Хоть IME и является довольно функциональным инструментом, но не лишён ряда ограничений. Один из существенных недостатков это то, что IME не клиент-серверная система, а по сути своей – обычное приложение, использующее базу данных MySQL. В предыдущих версиях IME даже не поддерживался на серверных и x64-битных ОС. Также ограничениями являются максимальное количество поддерживаемых устройств (не более 10-ти) и количество обрабатываемых событий в секунду (100 EPS).

2.3 Cisco Security Manager

CSM позиционируется уже как полноценное Enterprise решение, предназначенное для централизованного управления различными устройствами (IPS, ASA/PIX, IOS-роутеры и т.д.). Количество устройств, которыми можно управлять, зависит от приобретенной лицензии. Само управление уже осуществляется на основе политик: можно сделать эталонный набор настроек, который впоследствии можно тиражировать.
С точки зрения сбора, хранения и отображения событий, CSM очень похож на IME:

Здесь, как и в IME, имеется возможность группировки/агрегации и фильтрации отображаемых событий по различным критериям. Помимо событий от IPS, в CSM есть возможность также отслеживать события от файрволлов ASA/FWSM/PIX.
В каждый алерт также можно «провалиться» для просмотра более подробной информации:

Хотя CSM позиционируется как Enterprise решение, в отличии от того же IME, он не умеет собирать алерты с IOS-IPS (но при этом умеет их настраивать через политики). Также CSM не умеет осуществлять оповещения по e-mail о событиях, отловленных IPS.

3. SIEM

Описанные выше решения хороши каждое по-своему. Но, с точки зрения сбора событий, они являются довольно узконаправленными: кроме событий от IPS (и от файрволлов, в случае с CSM) увидеть в них мы больше ничего и не сможем.

Довольно часто в моей практике у коллег из соседних отделов возникают вопросы:

• У нас тут <по каналам загрузка возросла | сервис перестал отзываться | система отъехала | что-то случилось>, не знаете с чем связано?
• А у вас (у ИБ) там ничего подозрительного не было замечено?
• etc

Именно в таких случаях появляется необходимость проверить события с роутеров, свитчей, логи с unix/windows, журналы специфичных систем, антивирусы, почтовые шлюзы и т.д. На самом деле этот список можно продолжать бесконечно.
А ещё всё это между собой сопоставить по каким-либо критериям (произвести корреляцию), получить на ходу дополнительную информацию о хостах, участвующих в событии: что за ресурс, уязвим или нет, какие порты открыты и т.д.
Вот здесь и приходят на помощь SIEM системы. Всё вышеперечисленное они делать умеют, а при должном усердии – ещё и автоматизировано.

Одной из таких систем является малоизвестный в Рунете зверь, по имени Prelude. О нём и пойдёт речь.
Почему именно о нём?

1. Он мне нравится.
2. Он работает (и уже довольно давно).
3. У него есть OSS версия.
4. Имеет нативную совместимость с другими OSS-системами.
5. При желании можно подключить любой источник, который пишет лог.
6. Из него можно собрать свой собственный «швейцарский нож» под свои задачи выявления, расследования и реакции на инциденты.
7. Модуль корреляции реализован в виде подключаемых скриптов на Python, что означает гибкость в самом полном смысле этого слова. Полноценный язык программирования дает возможности для написания любых правил корреляции.
8. Есть удобный интерфейс Prewikka.

В основе работы Prelude лежит формат IDMEF, предопределяющий поля в получаемых сообщениях. Помимо предопределенных полей также можно создавать свои собственные, с заданным именем и форматом (additional data), куда можно записать всё, что не вписывается в стандартные поля. На основе данных, записанных в различные поля, может осуществляться фильтрация, агрегация и корреляция событий.

3.1 Архитектура Prelude

В упрощенном варианте архитектуру системы можно представить следующим образом:

Manager – является ядром системы. Отвечает за прием уже нормализованных (распаренных) событий от LML-агентов, модуля корреляции, сторонних систем или подчиненных менеджеров (доступно в коммерческой версии). Полученные сообщения записывает в базу данных. Также отвечает за оповещения через email.

LML – агент системы и основной поставщик событий. Осуществляет прием логов от различных систем (через локальный файл или через syslog на UDP-порт). Полученные логи разбирает/нормализует на основе набора правил, состоящих из регулярных выражений. Нормализованные события отдаёт Manager-у. LML может работать как локально (на одном сервере с Manager-ом), так и удаленно.

Correlator – модуль корреляции. Подключается к Manager-у как агент. Производит корреляцию поступивших в Manager событий на основе плагинов, реализованных в виде Python-скриптов.

DataBase – собственно база данных, где хранятся все события, обработанные системой.

3^rd Party Systems – сторонние системы с поддержкой IDMEF, позволяющие подключать их напрямую к Manager-у.

Prewikka – основной интерфейс системы, реализованный на Web. Предназначен для отображения обработанных событий, их агрегации/фильтрации, вывода статистики и т.д.

Выглядит это всё вот так:

События отображаются в таблице, в столбцах которой расположена информация о/об:

• классификации алертов (Classification), содержащие поля с названием события, признаком его (не)успешного завершения, id-события (номер сигнатуры, номер уязвимости по CVE и т.п.), критичности события и т.д.
• источнике/цели (Source/Target), содержащие поля с ip-адресом, mac-адресом (если он присутствовал в событии), исходном имени пользователя, процессе, файле и т.д.
• анализаторе (Analyzer – источнике события), содержащие поля с ip-адресом, классе анализатора и т.д.

Количество отображаемых IDMEF-полей зависит от типа события и правила его обработки. Некоторые поля могут быть индексируемые, т.е. содержать несколько значений. Например, может быть два поля userid.name, в одном из которых будет записано значение samaccountname, а во втором – SID этой же учетной записи. А, например, в случае события от системы проверки целостности файлов в информации об источнике и цели не будет отображено ни адреса, ни порта, ни протокола – эти поля будут заняты информацией об измененном файле, контрольных суммах и другой дополнительной информации.
В любое событие можно «провалиться» для просмотра более подробной информации:

4. Как забирать события с сенсоров?

Перед подключением IPS к нашей системе в качестве источника, нужно понять, как из IPS можно достать, хранящиеся в нем алерты.
Существует два c метода передачи событий от сенсоров Cisco (и один полу-метод для IOS-IPS) во внешние системы:

1) Через SNMP Trap, который отправляет сам сенсор по факту срабатывания сигнатуры или системного события.
Отправляемые сенсором трапы имеют следующий вид:

#012iso.3.6.1.2.1.1.3.0 15:1:47:08.58#011iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.4.1.9.9.383.0.1#011iso.3.6.1.4.1.9.9.383.1.1.1.0 6822393729640#011iso.3.6.1.4.1.9.9.383.1.1.2.0 "07 DE 04 0A 0B 2C 0E 00 "#011iso.3.6.1.4.1.9.9.383.1.1.3.0 "07 DE 04 0A 07 2C 0E 00 "#011iso.3.6.1.4.1.9.9.383.1.1.4.0 "IPS-SENSOR-01"#011iso.3.6.1.4.1.9.9.383.1.2.2.0 2147516416#011iso.3.6.1.4.1.9.9.383.1.2.3.0 "Heartbleed"#011iso.3.6.1.4.1.9.9.383.1.2.4.0 "OpenSSL Information Disclosure"#011iso.3.6.1.4.1.9.9.383.1.2.5.0 4187#011iso.3.6.1.4.1.9.9.383.1.2.6.0 0#011iso.3.6.1.4.1.9.9.383.1.2.7.0 "S785"#011iso.3.6.1.4.1.9.9.383.1.2.13.0 0#011iso.3.6.1.4.1.9.9.383.1.2.14.0 "iBCRX+m57XRkOtzSnz0MSIw/CJWscqWUKqhEjadJYMWue6yLZAgTFpc8+LuL#012H/4o5rulPzbm1D9tQZ2tnoY/qfwSZ3H1VE2Wt2/rwUHcjVaKjGue9I0FdGZN#012JgpdbIcOOiBxB0T0JJ0qsqAzTMO37pf6GNOcByoHVgcgubBM2x148331MWSP#012O4hROt/p8Zpk8ZmNBIfUwy4yA0ByxPANY4e+ixHoPOe0aJGk1GUthnyAhKn8#012ztzv/kfCXHyPH5X7DBXTTXYZN+Xv6vnWYJV3tojoaOIpv6shRYLjeg84qeO5#012vY3P0uXwcYSCj1YY4rdgQpQvL8PkOxYDAgAEDgAAAA=="#011iso.3.6.1.4.1.9.9.383.1.2.15.0 "FgMCANwBAADYAwJTQ1uQnZtyC7wMvCuSqEiXz705BMwWCoUDkJ93BDPU3gAA#012ZsAUwArAIsAhADkAOACIAIfAD8AFADUAhMASwAjAHMAbABYAE8ANwAMACsAT#012wAnAH8AeADMAMgCaAJkARQBEwA7ABAAvAJYAQcARwAfADMACAAUABAAVABIA#012CQAUABEACAAGAAMA/wEAAEkACwAEAwABAgAKADQAMgAOAA0AGQALAAwAGAAJ#012AAoAFgAXAAgABgAHABQAFQAEAAUAEgATAAEAAgADAA8AEAARACMAAAAPAAEB#012GAMCAAMBQAAYAwIAAwFAAA=="#011iso.3.6.1.4.1.9.9.383.1.2.16.0 "192.168.1.1:51716"#011iso.3.6.1.4.1.9.9.383.1.2.17.0 "osIdSource=\"unknown\" osRelevance=\"relevant\" osType=\"unknown\" 10.10.10.1:443"#011iso.3.6.1.4.1.9.9.383.1.2.21.0 "InterfaceAttributes:  context=\"single_vf\" physical=\"Unknown\" backplane=\"PortChannel0/0\" ; "#011iso.3.6.1.4.1.9.9.383.1.2.25.0 70#011iso.3.6.1.4.1.9.9.383.1.2.26.0 5#011iso.3.6.1.4.1.9.9.383.1.2.27.0 6#011iso.3.6.1.4.1.9.9.383.1.2.42.0 70#011iso.3.6.1.4.1.9.9.383.1.2.49.0 "vs0"#011iso.3.6.1.4.1.9.9.383.1.3.1.0 "high" 

2) Через стандарт SDEE. В этом случае IPS-сенсор работает как Web-сервер, а внешние системы самостоятельно к нему подключаются и забирают новые алерты. Именно этот метод используется в продуктах CSM и IME. В Cisco в стандарте SDEE используются расширение CIDEE, описывающее дополнительные поля.
Посмотреть SDEE-алерты в «чистом виде» можно через браузер, забив в адресной строке https://<sensor-ip-address>/cgi-bin/sdee-server (нужно будет пройти аутентификацию).
Сами алерты выглядят так:

<sd:evIdsAlert eventId="6821065810849" vendor="Cisco" severity="informational" cid:alarmTraits="2147483648">  <sd:originator>   <sd:hostId>IPS-SENSOR-01</sd:hostId>   <cid:appName>sensorApp</cid:appName>   <cid:appInstanceId>27106</cid:appInstanceId>  </sd:originator>  <sd:time offset="240" timeZone="GMT+04:00">1392668796044445000</sd:time>  <sd:signature  description="TCP Drop - Segment out state order" id="1330" cid:version="S642" cid:type="anomaly" cid:created="20050304">   <cid:subsigId>17</cid:subsigId>   <cid:sigDetails>TCP segment is out of state order</cid:sigDetails>  </sd:signature>  <sd:interfaceGroup>vsx</sd:interfaceGroup>  <sd:vlan>302</sd:vlan>  <sd:participants>   <sd:attacker>    <sd:addr cid:locality="Inside">192.168.0.1</sd:addr>    <sd:port>443</sd:port>   </sd:attacker>   <sd:target>    <sd:addr cid:locality="AS_Inside">10.10.10.1</sd:addr>    <sd:port>24479</sd:port>    <cid:os idSource="learned" type="windows-nt-2k-xp" relevance="relevant" />   </sd:target>  </sd:participants>  <sd:actions>   <cid:snmpTrapRequested>true</cid:snmpTrapRequested>  </sd:actions>  <cid:riskRatingValue targetValueRating="medium" attackRelevanceRating="relevant">25</cid:riskRatingValue>  <cid:threatRatingValue>25</cid:threatRatingValue>  <cid:interface>ge0_3</cid:interface>  <cid:protocol>tcp</cid:protocol> </sd:evIdsAlert> 

Немного забегая вперед, сразу стоит отметить, что использование SDEE имеет свои плюсы и минусы. Данные, получаемые через SDEE, содержат больше информации об алерте по сравнению с SNMP-трапом. Например здесь присутствует информация о предпринятых сенсором активных действиях. Но для экспорта данных через SDEE в SIEM, требуется специальный коннектор (в Prelude он есть только в коммерческой версии).

3) Через syslog (только для IOS-IPS). Для полноты картины также стоит отметить и некоторые особенности IOS-IPS. Они так же поддерживают SDEE, но не умеют отправлять алерты через SNMP. В отличие от своих «старших» братьев, IOS-IPS умеет писать информацию об алертах в локальное syslog-хранилище роутера. Syslog роутера в свою очередь может быть передано на внешний сервер. Однако данные, которые пишутся в syslog, крайне скудны:

Для IOS 12.x:

Aug 20 14:21:35 MSK: %IPS-4-SIGNATURE: Sig:15002 Subsig:1 Sev:50  [192.168.1.1:1066 -> 10.10.10.1:5938] RiskRating:30 

Отсутствует даже название сигнатуры. Только её SingatureID и SubsibgnatureID.

Для IOS 15.x:

Mar  3 11:15:24 MSK: %IPS-4-SIGNATURE: Sig:11020 Subsig:0 Sev:25 BitTorrent Client Activity [192.168.1.1:62809 -> 10.10.10.1:6881] VRF:NONE RiskRating:25 

А вот через SDEE те же самые алерты будут представлены уже в «нормальном» виде, т.е. с подробной информацией:

<sd:evIdsAlert eventId="139779925140" vendor="Cisco" severity="informational">  <sd:originator>   <sd:hostId>IOS-IPS-ROUTER</sd:hostId>   </sd:originator>  <sd:time offset="0" timeZone="UTC">1397799251079951920</sd:time>   <sd:signature description="Jabber Activity" id="11204" version="S588">   <cid:subsigId>0</cid:subsigId>    <cid:sigDetails>jabber:</cid:sigDetails>   </sd:signature>  <cid:protocol>tcp</cid:protocol>   <cid:riskRatingValue>25</cid:riskRatingValue>   <sd:participants>   <sd:attacker>    <sd:addr>192.168.1.1</sd:addr>     <sd:port>61208</sd:port>    </sd:attacker>   <sd:target>    <sd:addr>10.10.10.1</sd:addr>     <sd:port>5222</sd:port>    </sd:target>   <sd:vrf_name>NONE</sd:vrf_name>   </sd:participants>  <sd:actions />   <cid:interface>Fa0/1</cid:interface>   <cid:vrf_name>NONE</cid:vrf_name>  </sd:evIdsAlert> 

5. Настройка

Для реализации задуманного на OSS версии подойдёт только вариант с SNMP-трапами.
Схема подключения при этом будет выглядеть так:

1. IPS ловит атаку и отсылает по этому поводу SNMP-Trap. (IOS-IPS сразу шлет лог на rsyslogd).
2. Принимаем SNMP-Trap и передаем в syslog.
3. rsyslogd пишет полученный трап в файл.
4. LML разбирает лог, нормализует его, вытаскивает значения из интересующих нас полей и записывает их в соответствующие поля IDMEF (маппинг).
5. Нормализованное событие передается в Manager, которое он записывает в базу данных. После этого событие становится доступным для просмотра через Prewikka.
6. Поступающие события от IPS также можно отправлять на модуль корреляции (этот этап будет рассмотрен отдельно).

5.1 Подготовка

Предварительно необходимо установить и настроить сам Prelude. Как это делать, уже было описано здесь.
Помимо Prewikka и prelude-manager нам потребуются prelude-lml и prelude-correlator.
Также дополнительную информацию можно найти на официальном сайте Prelude.

Чтобы обрабатывать snmp-трапы потребуется настроить демоны snmptrapd и rsyslogd (либо аналогичные).
Основная задача – принимать snmp-трапы и писать их в файл.
Сделать это можно, например так:

snmptrapd.conf

donotlogtraps  no printeventnumbers  yes ignoreauthfailure  yes authCommunity log,execute public traphandle default /usr/sbin/snmptthandler 

rsyslog.conf

if $programname == 'snmptrapd' \ then /var/log/snmptrapd & ~ 

5.2 Настройка на стороне сенсора

Следующим шагом необходимо заставить наш сенсор отправлять snmp-trap-ы каждый раз, когда происходит срабатывание сигнатур, а также в случае ошибок на самом сенсоре. Для этого нужно глобально включить SNMP-Trap-ы и указать целевой сервер и community, куда их отправлять:

6. Корреляция Heart bleed

# # Copyright (C) 2014 Vladimir Lapshin <vmlapshin at gmail dot com> # Copyright (C) 2014 lei_wulong # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; see the file COPYING.  If not, write to # the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. #  import re from PreludeCorrelator.pluginmanager import Plugin from PreludeCorrelator.context import Context import time import subprocess  localtime = time.localtime() timestamp = time.strftime('%d %b %H:%M:%S', localtime)  print str(timestamp) + ' HeartBleed plugin  (correlator) INFO: Starting...'  class heartbleed(Plugin):     def run(self, idmef):         if not idmef.match('alert.classification.text', re.compile('^OpenSSL Information Disclosure$|^Other security event$')):             return          addr = idmef.Get('alert.target(*).node.address(*).address')         if not addr:             return          port = idmef.Get('alert.target(0).service.port')         if not port:             port='443'          script = str('python2.6 /etc/prelude-correlator/heartbleed.py ') + str(addr).strip('[\'\']') + str(' -p ') + str(port)         print script         PIPE = subprocess.PIPE         p = subprocess.Popen(script, shell=True, stdin=PIPE, stdout=PIPE, stderr=subprocess.STDOUT, close_fds=True)         while True:             s = p.stdout.readline()             if not s:                 break             if re.findall('server is vulnerable', s):                 ctx = Context(("HEART_BLEED", addr), update=True, idmef=idmef)                 ctx.Set("alert.classification.text", "HeartBleed vulnerability detected")                 ctx.Set("alert.correlation_alert.name", "HeartBleed vulnerability detected")                 ctx.Set("alert.assessment.impact.severity", "high")                 ctx.Set("alert.classification.reference(0).origin", "vendor-specific")                 ctx.Set("alert.classification.reference(0).name", "CVE-2014-0160")                 ctx.alert()                 ctx.destroy()                 print 'Vulnerable!'                 return 

7. Эпилог