Продолжаю свою статью о внедрении и использовании SIEM (часть1). Как я и обещал, во второй части я расскажу о корреляции и визуализации событий. Я расскажу о основных заблуждениях руководства в части понимания, что такое корреляция, порассуждаю на тему того, что реально важно, а что не очень, приведу примеры эффективной и неэффективной корреляции событий.
Корреляция в рамках SIEM – сопоставление информации из разных событий с целью последующего реагирования. Способы реагирования – создать новое событие, отправить уведомление администратору по электронной почте или в консоль, выполнить скрипт, завести кейс внутри SIEM, записать информацию в лист(список).
Визуализация – отображение информации из разных событий в виде графиков, диаграм, списков в режиме реального времени или за определенный промежуток времени.
В своей работе я столкнулся с рядом заблуждения со стороны коллег и руководства в понимании, что есть корреляция. Первое – корреляция это сопоставление событий обязательно с разных источников событий. Это абсолютно неверно, т.к. у нас могут быть события разного типа с одного источника, которые так же нужно сопоставлять, как пример события с межсетевого экрана, который при этом является еще VPN шлюзом и системой предотвращения вторжений или события от веб-серверов с разными методами. Второе большое заблуждение – корреляция осуществляется на лету, т.е. время возникновения события небольшое. Третье заблуждение – корреляция нужна только для того, чтобы выявлять инциденты. Четвертое заблуждение – на все можно и нужно реагировать письмом.
Основное заблуждение о визуализации в том, что она нужна только, чтобы показать красивые картинки руководству.
Итак, для чего же на самом деле нужна корреляция, какие в ней основные принципы? Основное – это обогащение интересных событий дополнительной информацией. Как пример, у нас есть голые IP адреса источников, которые раздал DHCP сервер нашим клиентам и мы видим обращения с этого адреса на межсетевом экране к ботнет серверам, но там нет информации о имени пользователя, лезть на DHCP сервер долго и нудно, хочется сразу узнать имя пользователя.
Для этого мы забираем логи с рабочей станции для того, чтобы понять какому пользователю или имени машинки назначился IP адрес, который уличили в попытке подключения к ботнету и уже в скореллированном событии видим полную информацию о том кто же это сделал. Это пример эффективной корреляции.
Пример неэффективной корреляции – это прежде всего корреляция событий, которые будут часто срабатывать и не будут нести никакой полезной информации, например события о блокировке/обнаружении атаки на IPS совместно с событие о разрешительном срабатывании правила на межсетевом экране. Это правило будет неэффективным в силу того, что будет огромное количество спама, при этом как правило IDS/IPS не отличаются точностью своих сигнатур, а значит дают большое количество ложных срабатываний. Основным критерием неэффективной корреляции является спам неинформативным событиями (уведомлениями).
Еще одной большой головной болью в работе с SIEM является определить, что же важно, а что не очень. Часто данный выбор будет сугубо индивидуальным, но я позволю себе выделить основные моменты. Как мы помним основными угрозами информационной безопасности являются нарушение целостности, доступности и конфиденциальности. При этом, если нарушение конфиденциальности для большинства носит репутационные риски бьет в перспективе на потерю дохода, то нарушение целостности и доступности ударяет здесь и сейчас.
Исходя из этой логики важно быстро реагировать на следующие события: попытки DDoS атак, которые мы можем отслеживать путем анализа событий межсетевых экранов, маршрутизаторов, коммутаторов, netflow, сбором событий о состоянии оборудования с систем ИТ мониторинга (zabbix, nagios и другие), заражение хостов вирусами, брутфорс атаки из интернета к оборудованию на периметре сети, сбои в работе серверов (остановка, запуск служб, изменение прав пользователей, потенциально опасные команды админов), непонятно зачем открывшиеся порты (события со сканеров), взаимодействия с использованием незащищенных протоколов (отслеживаем по портам tftp, telnet и т.п. события на межсетевом экране), остановку в отправке и блокирования логов.
Также очень эффективным является активное использование сторонних скриптов, которые на определенные события будут уведомлять пользователей о том, что их учетная запись заблокирована в ввиду нарушения политике ИБ в части VPN и т.п., т.е. рутинные задачи, которые часто делают в ручную и где цена ошибки не сильно велика.
Для чего эффективна визуализация? Визуализация очень эффективное средство прежде всего для анализа большого количества однотипных логов, в которых надо наблюдать статистику. Приведу примеры. Хороший кейс для визуализации – это интеграция срабатываний IDS/IPS, МСЭ, netflow с GoogleMaps, а именно визуализация того откуда и куда (если инфраструктура распределенная) у нас идет наибольшее количество запросов, срабатываний сигнатур, трафика, при этом можно всегда настроить так, чтобы при большем числе запросов картинка менялась. Например маленький кругляшок – это от 1 до 100 запросов в час, средний до 1000 и т.д…
Как-то не получилось написать много о принципах хорошей корреляции без привязки к внутренним процессам, поэтому часть три будет вместе со второй.
Итак, встречайте часть три.
Основные процессы, которые можно упростить и решать с помощью SIEM.
1. Инвентаризация и управление уязвимостями
Считаю, что это один из ключевых процессов в построении систем ИБ любой организации, скажем так – это шаг 1.
Как реализовывается – отправкой в SIEM результатов сканирований, составление NAT трансляций с логов МСЭ или логов netflow, выгрузка информации из различных каталогов(AD, Sharepoint и т.п.) и ведение списка активов с категоризацией. Сканирования могут осуществляться самописными скриптами, сканера уязвимостей и сетевыми сканерами.
Преимущества – вся нужная информация в одном месте и с ней удобно работать, строить отчеты, визуализировать и сравнивать.
Можно здесь добавить дополнительный скрипт или написать правило, которое будет позволять интеграцию с системой управления инцидентами для последующего закрытия уязвимости или проблемы с безопасностью администраторами.
2. Контроль периметра сети
Визуализация срабатывания правил МСЭ, IDS/IPS, DNS, контроль обращений к C&C серверам и т.п… Данные кейсы должны мониториться аналитиком ИБ в течении дня и должна быть реакция и проактивный разбор инцидента.
Для подобных кейсов является плохой идеей настраивать уведомления по срабатыванию. Для них наиболее эффективен каждодневный анализ в режиме реального времени.
На выходе от анализа подобных кейсов мы повышение эффективности работы всех средств защиты за счет выработки рекомендаций в ходе анализа логов. Мы можем понять на что реагирует средство защиты и нужно ли оно нам, составить список правил МСЭ, которые чаще всего срабатывают, а которые не срабатывали вовсе и оптимизировать работу МСЭ в целом. Мы можем найти зараженные хосты, которые не поймал антивирус.
3. Compliance
С помощью SIEM без проблем анализируются несоответствия стандартам безопасности настроек операционных систем, сетевого оборудования, VPN доступа, т.е. любой конфиг, который можно пропарсить и отправить на анализ. Можно сказать, что в целом любой современный сканер умеет это делать, но тут будет немного лукавства, зачастую они обладают излишней функциональностью и плохо справляются с этой функцией и эффективнее использовать самописный скрипт, который выдернет нужные настройки и отправит на анализ в SIEM. Дальше в SIEM можно визуализировать и уведомить о том какие сервера, группы серверов не соответствуют определенным проверкам.
4. Защита от атак из сети интернет.
Самое злободневное и требующее достаточно долгого анализа, чтобы понять что это вот оно – это DDoS атаки, при этом они имеют свойство достаточно серьезно выводить из строя работу системы. Анализ логов МСЭ, веб-серверов, DNS, netflow позволит увидеть резкое изменение количество source адресов и тип трафика, который они отправляют, что может сигнализировать о начале DDoS атаки, что сократит время реакции на нее.
5. Контроль отправки логов.
Это одно из самых важных, что нужно реализовать в рамках SIEM. Эффективно вести список источников, которые отправляют последние 2 часа и уведомлять о истечении времени жизни записи в списке. Так же эффективно смотреть какие логи не прошли через МСЭ по их логам.
Теперь поговорим немного о кадрах.
Как показывает практика в части работы с SIEM есть два больших направления – эксплуатация и развитие первое, а второе непосредственный мониторинг и работы с консолью, т.е. процессинг.
Заниматься этими направлениями должны разные люди, совмещение невозможно.
Что включает в себя эксплуатация и развитие? Прежде всего это поддержание в работе самой SIEM, общение с техподдержкой и т.п… Вторая важная задача – это создание и развитие существующих инструментов для сбора логов и правил корреляции, их тестирование и ввод в эксплуатацию, написание документации по работе с данными правилами и сценариями.
Процессинговая часть включает в себя постановку на мониторинг новых серверов, реагирования на события, анализ логов через средства визуализации, настройку новых средств визуализации и формирование запросов на написание новых правил корреляции.
Важно понимать, что совмещение этих двух ролей приведет к потере эффективности всей инсталляции. Слишком разные роли, которые требуют разных личностных качеств от сотрудника, которые несовместимы в одном человеке.
Вместо заключения хочу сказать, что внедрение SIEM целесообразно в крупных компаниях, у которых есть достаточный бюджет на содержание штата специалистов высокого уровня, которые являются здесь ключевым звеном, а так же наличие средств на покупку дорогого софта выхлоп, от которого будет заметен через несколько лет. Пресловутая корреляция событий, которую всегда так много рекламируют тоже более актуальна для крупных компаний с большим количество серверов и сетевого оборудования. Большинству небольших компаний будет достаточно обойтись обычным лог менеджментом, которое можно чудесно реализовать с помощью open-source решений и WebUI средств защиты, а так же отчетами, которые можно генерировать различными сканерами.
Корреляция в рамках SIEM – сопоставление информации из разных событий с целью последующего реагирования. Способы реагирования – создать новое событие, отправить уведомление администратору по электронной почте или в консоль, выполнить скрипт, завести кейс внутри SIEM, записать информацию в лист(список).
Визуализация – отображение информации из разных событий в виде графиков, диаграм, списков в режиме реального времени или за определенный промежуток времени.
В своей работе я столкнулся с рядом заблуждения со стороны коллег и руководства в понимании, что есть корреляция. Первое – корреляция это сопоставление событий обязательно с разных источников событий. Это абсолютно неверно, т.к. у нас могут быть события разного типа с одного источника, которые так же нужно сопоставлять, как пример события с межсетевого экрана, который при этом является еще VPN шлюзом и системой предотвращения вторжений или события от веб-серверов с разными методами. Второе большое заблуждение – корреляция осуществляется на лету, т.е. время возникновения события небольшое. Третье заблуждение – корреляция нужна только для того, чтобы выявлять инциденты. Четвертое заблуждение – на все можно и нужно реагировать письмом.
Основное заблуждение о визуализации в том, что она нужна только, чтобы показать красивые картинки руководству.
Итак, для чего же на самом деле нужна корреляция, какие в ней основные принципы? Основное – это обогащение интересных событий дополнительной информацией. Как пример, у нас есть голые IP адреса источников, которые раздал DHCP сервер нашим клиентам и мы видим обращения с этого адреса на межсетевом экране к ботнет серверам, но там нет информации о имени пользователя, лезть на DHCP сервер долго и нудно, хочется сразу узнать имя пользователя.
Для этого мы забираем логи с рабочей станции для того, чтобы понять какому пользователю или имени машинки назначился IP адрес, который уличили в попытке подключения к ботнету и уже в скореллированном событии видим полную информацию о том кто же это сделал. Это пример эффективной корреляции.
Пример неэффективной корреляции – это прежде всего корреляция событий, которые будут часто срабатывать и не будут нести никакой полезной информации, например события о блокировке/обнаружении атаки на IPS совместно с событие о разрешительном срабатывании правила на межсетевом экране. Это правило будет неэффективным в силу того, что будет огромное количество спама, при этом как правило IDS/IPS не отличаются точностью своих сигнатур, а значит дают большое количество ложных срабатываний. Основным критерием неэффективной корреляции является спам неинформативным событиями (уведомлениями).
Еще одной большой головной болью в работе с SIEM является определить, что же важно, а что не очень. Часто данный выбор будет сугубо индивидуальным, но я позволю себе выделить основные моменты. Как мы помним основными угрозами информационной безопасности являются нарушение целостности, доступности и конфиденциальности. При этом, если нарушение конфиденциальности для большинства носит репутационные риски бьет в перспективе на потерю дохода, то нарушение целостности и доступности ударяет здесь и сейчас.
Исходя из этой логики важно быстро реагировать на следующие события: попытки DDoS атак, которые мы можем отслеживать путем анализа событий межсетевых экранов, маршрутизаторов, коммутаторов, netflow, сбором событий о состоянии оборудования с систем ИТ мониторинга (zabbix, nagios и другие), заражение хостов вирусами, брутфорс атаки из интернета к оборудованию на периметре сети, сбои в работе серверов (остановка, запуск служб, изменение прав пользователей, потенциально опасные команды админов), непонятно зачем открывшиеся порты (события со сканеров), взаимодействия с использованием незащищенных протоколов (отслеживаем по портам tftp, telnet и т.п. события на межсетевом экране), остановку в отправке и блокирования логов.
Также очень эффективным является активное использование сторонних скриптов, которые на определенные события будут уведомлять пользователей о том, что их учетная запись заблокирована в ввиду нарушения политике ИБ в части VPN и т.п., т.е. рутинные задачи, которые часто делают в ручную и где цена ошибки не сильно велика.
Для чего эффективна визуализация? Визуализация очень эффективное средство прежде всего для анализа большого количества однотипных логов, в которых надо наблюдать статистику. Приведу примеры. Хороший кейс для визуализации – это интеграция срабатываний IDS/IPS, МСЭ, netflow с GoogleMaps, а именно визуализация того откуда и куда (если инфраструктура распределенная) у нас идет наибольшее количество запросов, срабатываний сигнатур, трафика, при этом можно всегда настроить так, чтобы при большем числе запросов картинка менялась. Например маленький кругляшок – это от 1 до 100 запросов в час, средний до 1000 и т.д…
Как-то не получилось написать много о принципах хорошей корреляции без привязки к внутренним процессам, поэтому часть три будет вместе со второй.
Итак, встречайте часть три.
Основные процессы, которые можно упростить и решать с помощью SIEM.
1. Инвентаризация и управление уязвимостями
Считаю, что это один из ключевых процессов в построении систем ИБ любой организации, скажем так – это шаг 1.
Как реализовывается – отправкой в SIEM результатов сканирований, составление NAT трансляций с логов МСЭ или логов netflow, выгрузка информации из различных каталогов(AD, Sharepoint и т.п.) и ведение списка активов с категоризацией. Сканирования могут осуществляться самописными скриптами, сканера уязвимостей и сетевыми сканерами.
Преимущества – вся нужная информация в одном месте и с ней удобно работать, строить отчеты, визуализировать и сравнивать.
Можно здесь добавить дополнительный скрипт или написать правило, которое будет позволять интеграцию с системой управления инцидентами для последующего закрытия уязвимости или проблемы с безопасностью администраторами.
2. Контроль периметра сети
Визуализация срабатывания правил МСЭ, IDS/IPS, DNS, контроль обращений к C&C серверам и т.п… Данные кейсы должны мониториться аналитиком ИБ в течении дня и должна быть реакция и проактивный разбор инцидента.
Для подобных кейсов является плохой идеей настраивать уведомления по срабатыванию. Для них наиболее эффективен каждодневный анализ в режиме реального времени.
На выходе от анализа подобных кейсов мы повышение эффективности работы всех средств защиты за счет выработки рекомендаций в ходе анализа логов. Мы можем понять на что реагирует средство защиты и нужно ли оно нам, составить список правил МСЭ, которые чаще всего срабатывают, а которые не срабатывали вовсе и оптимизировать работу МСЭ в целом. Мы можем найти зараженные хосты, которые не поймал антивирус.
3. Compliance
С помощью SIEM без проблем анализируются несоответствия стандартам безопасности настроек операционных систем, сетевого оборудования, VPN доступа, т.е. любой конфиг, который можно пропарсить и отправить на анализ. Можно сказать, что в целом любой современный сканер умеет это делать, но тут будет немного лукавства, зачастую они обладают излишней функциональностью и плохо справляются с этой функцией и эффективнее использовать самописный скрипт, который выдернет нужные настройки и отправит на анализ в SIEM. Дальше в SIEM можно визуализировать и уведомить о том какие сервера, группы серверов не соответствуют определенным проверкам.
4. Защита от атак из сети интернет.
Самое злободневное и требующее достаточно долгого анализа, чтобы понять что это вот оно – это DDoS атаки, при этом они имеют свойство достаточно серьезно выводить из строя работу системы. Анализ логов МСЭ, веб-серверов, DNS, netflow позволит увидеть резкое изменение количество source адресов и тип трафика, который они отправляют, что может сигнализировать о начале DDoS атаки, что сократит время реакции на нее.
5. Контроль отправки логов.
Это одно из самых важных, что нужно реализовать в рамках SIEM. Эффективно вести список источников, которые отправляют последние 2 часа и уведомлять о истечении времени жизни записи в списке. Так же эффективно смотреть какие логи не прошли через МСЭ по их логам.
Теперь поговорим немного о кадрах.
Как показывает практика в части работы с SIEM есть два больших направления – эксплуатация и развитие первое, а второе непосредственный мониторинг и работы с консолью, т.е. процессинг.
Заниматься этими направлениями должны разные люди, совмещение невозможно.
Что включает в себя эксплуатация и развитие? Прежде всего это поддержание в работе самой SIEM, общение с техподдержкой и т.п… Вторая важная задача – это создание и развитие существующих инструментов для сбора логов и правил корреляции, их тестирование и ввод в эксплуатацию, написание документации по работе с данными правилами и сценариями.
Процессинговая часть включает в себя постановку на мониторинг новых серверов, реагирования на события, анализ логов через средства визуализации, настройку новых средств визуализации и формирование запросов на написание новых правил корреляции.
Важно понимать, что совмещение этих двух ролей приведет к потере эффективности всей инсталляции. Слишком разные роли, которые требуют разных личностных качеств от сотрудника, которые несовместимы в одном человеке.
Вместо заключения хочу сказать, что внедрение SIEM целесообразно в крупных компаниях, у которых есть достаточный бюджет на содержание штата специалистов высокого уровня, которые являются здесь ключевым звеном, а так же наличие средств на покупку дорогого софта выхлоп, от которого будет заметен через несколько лет. Пресловутая корреляция событий, которую всегда так много рекламируют тоже более актуальна для крупных компаний с большим количество серверов и сетевого оборудования. Большинству небольших компаний будет достаточно обойтись обычным лог менеджментом, которое можно чудесно реализовать с помощью open-source решений и WebUI средств защиты, а так же отчетами, которые можно генерировать различными сканерами.
