Всем привет.
Так получилось, что последние несколько лет провел в процессе внедрения SIEM Arcsight ESM в одном крупном телекоммуникационном провайдере. Считаю, что сделал это весьма успешно и в итоге ушел на несколько другую стезю, т.к. уперся в некоторый потолок, который есть в России в целом по направлению безопасности. Для того, чтобы не сложилось ложного понимания у читателя уточню, что я работал именно внутри компании, а не на проекте от системного интегратора и SIEM использовалась исключительно для внутренних нужд, а не для создания коммерческого Security Operation Center (далее SOC). В целом тематика внедрения и использования SIEM освещена слабо, да и в целом те инсталляции, которые я видел обычно не приносили достаточной эффективности тем кто ее внедрял. Мне с коллегами на мой взгляд удалось реализовать свой собственный SOC ядром, которого является SIEM, приносящий огромную пользу не только отделу ИБ, но и другим отделам в частности и всей компании в целом, включая руководство.
Данная статья будет полезна для руководителей отделов ИБ, которые думают о внедрении SIEM и специалистам в области ИБ, которые занимаются эксплуатацией и развитием SIEM в своей компании. Статья будет состоять из нескольких частей, т.к. словоблудствовать буду много :). В первой части статьи мы поговорим о выборе железа для SIEM и эффективном сборе логов, я немного расскажу об особенностях моей инфраструктуры, во второй части я расскажу о корреляции и визуализации логов, что это такое, зачем надо, когда эффективно и когда не очень и в третьей части мы порассуждаем о том как правильно администрировать SIEM и следить за ее здоровьем, какие процессы можо завязать на SIEM, как это сделать, какие кадры нужны, как проходил процесс расследования инцидентов у нас, какую пользу получает компания в целом и руководство в частности от SIEM на практике, а не в маркетинговых презентациях продажников из интеграторов.
Поехали.
Начну с описания особенностей моей архитектуры. Основной ее особенностью было то, что она очень большая и территориально распределенная, но при этом отсутствовали рабочие станции пользователей как класс, так же защищаемая инфраструктура постоянно росла. Учитывайте это при формировании архитектуры SIEM.
Перейдем к архитектуре SIEM. Первое, что тут нужно понимать, что неважно какую SIEM вы внедряете и сколько серверов для нее нужно и какие требования к железу, в зависимости от SIEM может требоваться разное число серверов. Так например с Arcsight мы использовали отдельные сервера, на которые ставили софт для сбора логов, а база данных и коррелятор логов были на других серверах. Основным же моментом в архитектуре SIEM является система хранения данных (СХД). Что тут сразу хочу сказать, что ни один интегратор не в силах посчитать сколько у вас будет реально логов, никому тут не верьте, считайте сами, смотрите ограничения SIEM на максимальный размер СХД и пляшите от него. Здесь чем больше места тем лучше, так же нужны быстрые диски, желательно прямое соединение СХД с SIEM. Так же обязательно подключение к системе резервного копирования (СРК). Оптимальным на мой взгляд временем хранения логов на горячую является один месяц, хранение на СРК минимум полгода. Основные проблемы, которые могут тут вас ожидать – это упирание в скорость чтения и записи, которые будут сильно отражаться на том на сколько быстро вы сможете выгрузить нужные вам логи и при работе нескольких людей с SIEM. Поэтому чем быстрее будет СХД тем лучше. Вот так вот плавно мы подошли к второму вопросу первой части статьи, а именно к управлению логами.
Управление логами в терминологии Arcsight SIEM, да я думаю и в целом любой SIEM очень удобно разбить на следующие стадии: получение лога(сбор), нормализация событий, агрегация событий, фильтрация событий, категоризация событий, приоритезация событий. В Arcsight все эти задачи выполняют коннекторы, для части источников событий поставляются из коробки, некоторые нужно писать самому.
Особенности получения логов – основной особенностью является то, что нужно планировать нагрузку на сеть, особенно при использовании SYSLOG, т.к. возможен спам и нужно совместно с сетевиками продумать наилучший вариант отправки логов.
Нормализация событий – парсинг лога, т.е. приведение полученного события в тот вид, который понятен человеку и базе данных, которая крутится под капотом SIEM. Если более детально берем событие, бьем его на части и закидываем в ячейке таблицы базы данных SIEM, т.е. адрес источника события летит в столбец источник событий базы данных. В общем все события должны быть нормализованы.
Агрегация событий – очень интересный и полезный момент (не все SIEM поддерживают эту функцию), который позволяет сократить количество мусора в логах. Агрегация представляет собой схлопование нескольких одинаковых событий в одно, к примеру мы имеем 30 обращений за 30 секунд с одного IP адреса на наш сервер, которые зафиксировал наш пограничный межсетевой экран, в базе данных это будет 30 строк, агрегация нужна, чтобы сделать из этих 30 событий всего лишь одно. Агрегация наиболее эффективна для логов межсетевых экранов, netflow, IDS/IPS, веб серверов.
Фильтрация событий – выбрасываем то, что не нужно или оставляем только то, что нужно. Очень полезная штука особенно для логов с операционных систем, антивирусов, IDS/IPS. Что наиболее эффективно делать, чтобы определить, что событие вам неинтересно. Нужно написать правило, которое будет записывать в лист ( в терминологии Arcsight, не знаю есть ли у конкурентов такая функция) или построить отчет о всех событиях, которые были в течении недели с каждого источника и анализировать его с точки зрения информативности. Результатом этого анализа является изменение уровня логирования на источнике событий, либо настройка фильтров на сборщике логов SIEM. Забегая вперед скажу, что логи межсетевых экранов лучше не зафильтровывать, т.к. они очень полезны при расследовании инцидентов.
Категоризация событий – назначении однотипным событиям с разных источников одной категории, чтобы удобнее было обрабатывать. Сразу скажу, что штука выглядит более перспективной чем является ей на самом деле в том случае, если у вас очень много разных источников и вы просто не успеваете настроить категоризацию правильно. Для тех у кого инфраструктура растет медленно думаю будет полезным.
Приоритезация – выставление приоритета события в рамках SIEM. К примеру нам пришло событие с severity CRIT, но мы знаем что для ИБ – это не критикал и ставим ему INFO.
Перейдем немного к практике и поговорим о самых информативных источниках логов.
Моим безусловным лидером являются сканеры уязвимостей, которые позволяют осуществить инвентаризацию, перечень открытых портов, сервисов и уязвимостей на сети. Здесь я бы рекомендовал использовать сразу несколько инструментов и собирать все в листы, либо отчеты, а затем уже привязывать все это дело к ITIL, т.е. создавать внутренние тикеты и закрывать проблемы согласно внутренним политикам ИБ. Собственно SIEM здесь является инструментом, на который все сканеры скинули информацию и аналитик уже ее анализирует просматривая все отчеты только в одном месте. Так же сюда я бы отнес самописные скрипты, которые могут собирать информацию из DNSBL, C&C серверах из интернета.
Второе место для меня занимают межсетевые экраны, netflow, VPN шлюза и IPS/IDS/WAF, которые позволяют определить всевозможные сканирования, попытки DDoS-атак, другие нарушения сетевой безопасности в т.ч. внутренними пользователями и оптимизировать работу средств защиты.
Третье место – операционные системы, с логов операционных систем можно понять, что нас взломали или админ шалит.
Четвертое место – базы данных, по их запросам можно так же увидеть попытки увести от нас важную информацию.
Пятое место – антивирусы.
Думаю на этом первую часть можно закончить. Ждите вторую, в которой я расскажу о том, что лучше визуализировать, что с чем коррелировать, о чем уведомлять, а на что можно реагировать скриптами и зачем.
Так получилось, что последние несколько лет провел в процессе внедрения SIEM Arcsight ESM в одном крупном телекоммуникационном провайдере. Считаю, что сделал это весьма успешно и в итоге ушел на несколько другую стезю, т.к. уперся в некоторый потолок, который есть в России в целом по направлению безопасности. Для того, чтобы не сложилось ложного понимания у читателя уточню, что я работал именно внутри компании, а не на проекте от системного интегратора и SIEM использовалась исключительно для внутренних нужд, а не для создания коммерческого Security Operation Center (далее SOC). В целом тематика внедрения и использования SIEM освещена слабо, да и в целом те инсталляции, которые я видел обычно не приносили достаточной эффективности тем кто ее внедрял. Мне с коллегами на мой взгляд удалось реализовать свой собственный SOC ядром, которого является SIEM, приносящий огромную пользу не только отделу ИБ, но и другим отделам в частности и всей компании в целом, включая руководство.
Данная статья будет полезна для руководителей отделов ИБ, которые думают о внедрении SIEM и специалистам в области ИБ, которые занимаются эксплуатацией и развитием SIEM в своей компании. Статья будет состоять из нескольких частей, т.к. словоблудствовать буду много :). В первой части статьи мы поговорим о выборе железа для SIEM и эффективном сборе логов, я немного расскажу об особенностях моей инфраструктуры, во второй части я расскажу о корреляции и визуализации логов, что это такое, зачем надо, когда эффективно и когда не очень и в третьей части мы порассуждаем о том как правильно администрировать SIEM и следить за ее здоровьем, какие процессы можо завязать на SIEM, как это сделать, какие кадры нужны, как проходил процесс расследования инцидентов у нас, какую пользу получает компания в целом и руководство в частности от SIEM на практике, а не в маркетинговых презентациях продажников из интеграторов.
Поехали.
Начну с описания особенностей моей архитектуры. Основной ее особенностью было то, что она очень большая и территориально распределенная, но при этом отсутствовали рабочие станции пользователей как класс, так же защищаемая инфраструктура постоянно росла. Учитывайте это при формировании архитектуры SIEM.
Перейдем к архитектуре SIEM. Первое, что тут нужно понимать, что неважно какую SIEM вы внедряете и сколько серверов для нее нужно и какие требования к железу, в зависимости от SIEM может требоваться разное число серверов. Так например с Arcsight мы использовали отдельные сервера, на которые ставили софт для сбора логов, а база данных и коррелятор логов были на других серверах. Основным же моментом в архитектуре SIEM является система хранения данных (СХД). Что тут сразу хочу сказать, что ни один интегратор не в силах посчитать сколько у вас будет реально логов, никому тут не верьте, считайте сами, смотрите ограничения SIEM на максимальный размер СХД и пляшите от него. Здесь чем больше места тем лучше, так же нужны быстрые диски, желательно прямое соединение СХД с SIEM. Так же обязательно подключение к системе резервного копирования (СРК). Оптимальным на мой взгляд временем хранения логов на горячую является один месяц, хранение на СРК минимум полгода. Основные проблемы, которые могут тут вас ожидать – это упирание в скорость чтения и записи, которые будут сильно отражаться на том на сколько быстро вы сможете выгрузить нужные вам логи и при работе нескольких людей с SIEM. Поэтому чем быстрее будет СХД тем лучше. Вот так вот плавно мы подошли к второму вопросу первой части статьи, а именно к управлению логами.
Управление логами в терминологии Arcsight SIEM, да я думаю и в целом любой SIEM очень удобно разбить на следующие стадии: получение лога(сбор), нормализация событий, агрегация событий, фильтрация событий, категоризация событий, приоритезация событий. В Arcsight все эти задачи выполняют коннекторы, для части источников событий поставляются из коробки, некоторые нужно писать самому.
Особенности получения логов – основной особенностью является то, что нужно планировать нагрузку на сеть, особенно при использовании SYSLOG, т.к. возможен спам и нужно совместно с сетевиками продумать наилучший вариант отправки логов.
Нормализация событий – парсинг лога, т.е. приведение полученного события в тот вид, который понятен человеку и базе данных, которая крутится под капотом SIEM. Если более детально берем событие, бьем его на части и закидываем в ячейке таблицы базы данных SIEM, т.е. адрес источника события летит в столбец источник событий базы данных. В общем все события должны быть нормализованы.
Агрегация событий – очень интересный и полезный момент (не все SIEM поддерживают эту функцию), который позволяет сократить количество мусора в логах. Агрегация представляет собой схлопование нескольких одинаковых событий в одно, к примеру мы имеем 30 обращений за 30 секунд с одного IP адреса на наш сервер, которые зафиксировал наш пограничный межсетевой экран, в базе данных это будет 30 строк, агрегация нужна, чтобы сделать из этих 30 событий всего лишь одно. Агрегация наиболее эффективна для логов межсетевых экранов, netflow, IDS/IPS, веб серверов.
Фильтрация событий – выбрасываем то, что не нужно или оставляем только то, что нужно. Очень полезная штука особенно для логов с операционных систем, антивирусов, IDS/IPS. Что наиболее эффективно делать, чтобы определить, что событие вам неинтересно. Нужно написать правило, которое будет записывать в лист ( в терминологии Arcsight, не знаю есть ли у конкурентов такая функция) или построить отчет о всех событиях, которые были в течении недели с каждого источника и анализировать его с точки зрения информативности. Результатом этого анализа является изменение уровня логирования на источнике событий, либо настройка фильтров на сборщике логов SIEM. Забегая вперед скажу, что логи межсетевых экранов лучше не зафильтровывать, т.к. они очень полезны при расследовании инцидентов.
Категоризация событий – назначении однотипным событиям с разных источников одной категории, чтобы удобнее было обрабатывать. Сразу скажу, что штука выглядит более перспективной чем является ей на самом деле в том случае, если у вас очень много разных источников и вы просто не успеваете настроить категоризацию правильно. Для тех у кого инфраструктура растет медленно думаю будет полезным.
Приоритезация – выставление приоритета события в рамках SIEM. К примеру нам пришло событие с severity CRIT, но мы знаем что для ИБ – это не критикал и ставим ему INFO.
Перейдем немного к практике и поговорим о самых информативных источниках логов.
Моим безусловным лидером являются сканеры уязвимостей, которые позволяют осуществить инвентаризацию, перечень открытых портов, сервисов и уязвимостей на сети. Здесь я бы рекомендовал использовать сразу несколько инструментов и собирать все в листы, либо отчеты, а затем уже привязывать все это дело к ITIL, т.е. создавать внутренние тикеты и закрывать проблемы согласно внутренним политикам ИБ. Собственно SIEM здесь является инструментом, на который все сканеры скинули информацию и аналитик уже ее анализирует просматривая все отчеты только в одном месте. Так же сюда я бы отнес самописные скрипты, которые могут собирать информацию из DNSBL, C&C серверах из интернета.
Второе место для меня занимают межсетевые экраны, netflow, VPN шлюза и IPS/IDS/WAF, которые позволяют определить всевозможные сканирования, попытки DDoS-атак, другие нарушения сетевой безопасности в т.ч. внутренними пользователями и оптимизировать работу средств защиты.
Третье место – операционные системы, с логов операционных систем можно понять, что нас взломали или админ шалит.
Четвертое место – базы данных, по их запросам можно так же увидеть попытки увести от нас важную информацию.
Пятое место – антивирусы.
Думаю на этом первую часть можно закончить. Ждите вторую, в которой я расскажу о том, что лучше визуализировать, что с чем коррелировать, о чем уведомлять, а на что можно реагировать скриптами и зачем.
