SIEM

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

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

Одна из первых задач SIEM — достать  все эти события  из разных источников. Затем  со всеми полученными  событиями  надо что-то  делать, т.к. в сыром виде они не очень поддаются прямому сравнению. 

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

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

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

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

Другие функции  типичной  SIEM достаточно  общие, и так или иначе, встречается  в разных 
системах анализа  и управления  чем угодно: 
—  Возможность  визуализировать  данные для анализа  и расследования  инцидентов 
—  Оповещать  ответственных  сотрудников  при возникновении  «интересных»  событий 
—  Строить  отчеты  о состоянии  самой системы и о результатах  ее работы 

SIEM, как правило,  позволяют  гибко настроить  условия поиска самых разных закономерностей  и 
корреляций  в событиях. 

Простые примеры инцидентов, которые  приходится искать с помощью SIEM:

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

—  Использование  поддельных билетов  (ticket), при аутентификации  компьютеров  в домене по протоколу  Kerberos  — атака  Golden  Ticket, при которой  злоумышленник,  получив секретный  ключ сервисной  учетной  записи в Active Directory может  сам создавать билет TGT  (Ticket Granting  Ticket) для любого  пользователя  в домене, даже несуществующего, и указать там  административные  права. А затем  уже с помощью билета  TGT  получить  билет TGS (Ticket Granting  Service),  который  предоставляет  доступ к доменным  ресурсам.
Одна из логик детектирования  заключается  в том, чтобы  следить за выданными  TGT  билетами и отдавать  TGS билет  только  в том  случае, если был  предъявлен  TGT  билет,  выданный ранее. Пользователь  домена получает  TGT  раз в 10 часов, поэтому TGT  и TGS запрос могут не выполняться  сразу, и есть смысл сохранять  события  получения  TGT,  как минимум, в течение  этих 10 часов для каждого пользователя.  В KUMA есть правило корреляции  из коробки, в котором  используется  подобный  механизм обнаружения  атаки Golden  Ticket. 

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

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

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

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

Это  только  ряд простых  примеров  того,  что можно обнаруживать  с помощью SIEM.

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