Всем привет. Так получилось, что последние несколько лет я провел в процессе внедрения SIEM Arcsight ESM у одного крупного телекоммуникационного провайдера.
Я думаю, что сделал это очень успешно и в итоге пошел несколько по другому пути, потому что.
уперся в определенный потолок, который существует в России в целом в сфере безопасности.
Во избежание недопонимания среди читателей уточню, что я работал внутри компании, а не над проектом системного интегратора, и SIEM использовался исключительно для внутренних нужд, а не для создания коммерческого Центра управления безопасностью (далее по тексту).
в качестве SOC).
В целом тема внедрения и использования SIEM освещена слабо, и в целом те установки, которые я видел, обычно не приносили достаточной эффективности тем, кто это внедрял.
Мне и моим коллегам, на мой взгляд, удалось реализовать собственное SOC-ядро – SIEM, которое приносит большую пользу не только отделу ИБ, но и другим отделам в частности и всей компании в целом, включая руководство.
.
Данная статья будет полезна руководителям отделов ИБ, задумывающимся о внедрении SIEM, и специалистам по ИБ, которые занимаются эксплуатацией и развитием SIEM в своей компании.
Статья будет состоять из нескольких частей, потому что.
буду много болтать :).
В первой части статьи мы поговорим о выборе оборудования для SIEM и эффективном сборе логов, я немного расскажу об особенностях моей инфраструктуры, во второй части я расскажу о корреляции и визуализации логов, что это такое , зачем это нужно, когда это эффективно, а когда нет, а в третьей части мы обсудим, как правильно администрировать SIEM и следить за его работоспособностью, какие процессы можно завязать на SIEM, как это сделать, какой персонал нужны, как проходил у нас процесс расследования инцидентов, какую выгоду получает компания в целом и менеджмент в частности от SIEM на практике, а не в маркетинговых презентациях продавцов-интеграторов.
Идти.
Начну с описания особенностей моей архитектуры.
Ее главной особенностью было то, что она была очень большой и географически распределенной, но при этом не было пользовательских рабочих станций как класса, а защищаемая инфраструктура постоянно росла.
Учитывайте это при формировании вашей SIEM-архитектуры.
Перейдем к архитектуре SIEM. Первое, что здесь нужно понять, это то, что не имеет значения, какой тип SIEM вы внедряете и сколько серверов для этого требуется и каковы требования к оборудованию, в зависимости от SIEM может потребоваться разное количество серверов.
Так, например, с Arcsight мы использовали отдельные серверы, на которых устанавливали ПО для сбора логов, а база данных и коррелятор логов находились на других серверах.
Главным моментом в SIEM-архитектуре является система хранения данных (СХД).
Сразу хочу сказать, что ни один интегратор не сможет подсчитать, сколько логов у вас будет на самом деле, не верьте здесь никому, посчитайте сами, посмотрите ограничения SIEM на максимальный размер СХД и танцуйте от это.
Здесь чем больше места, тем лучше, также нужны быстрые диски, желательно прямое подключение СХД к SIEM. Также необходимо подключиться к резервной системе (BSS).
На мой взгляд, оптимальный срок хранения горячих логов — один месяц, хранения на IBS — не менее полугода.
Основные проблемы, которые могут вас здесь поджидать, — это ограничения на скорость чтения и записи, что сильно повлияет на то, насколько быстро вы сможете скачать нужные вам логи и когда с SIEM работают несколько человек.
Поэтому чем быстрее система хранения, тем лучше.
Вот так мы плавно подошли ко второму вопросу первой части статьи, а именно к управлению журналами.
Управление логами в терминологии Arcsight SIEM, да и вообще, я думаю, любой SIEM очень удобно разделить на следующие этапы: получение лога (сбора), нормализация событий, агрегирование событий, фильтрация событий, категоризация событий, приоритезация событий.
В Arcsight все эти задачи выполняются коннекторами; некоторые источники событий поставляются «из коробки»; некоторые вам нужно написать самому.
Особенности получения логов - основная особенность в том, что нужно планировать нагрузку на сеть, особенно при использовании SYSLOG, т. к.
возможен спам и нужно совместно с сетевиками продумывать лучший вариант отправки логов.
Нормализация событий – парсинг логов, т.е.
приведение полученного события в форму, понятную человеку и базе данных, работающей под капотом SIEM. Если взять событие более детально, разбить его на части и поместить в ячейку таблицы базы данных SIEM, т.е.
адрес источника события улетает в столбец источника событий базы данных.
В общем, все события должны нормализоваться.
Агрегация событий — очень интересный и полезный пункт (не все SIEM поддерживают эту функцию), позволяющий уменьшить количество мусора в логах.
Агрегация - это свертывание нескольких одинаковых событий в одно, например, у нас есть 30 обращений за 30 секунд с одного IP-адреса на наш сервер, которые зафиксировал наш Edge Firewall, в базе данных будет 30 строк, агрегация нужна для сделать эти 30 есть только одно событие.
Агрегация наиболее эффективна для журналов брандмауэра, сетевого потока, IDS/IPS и веб-серверов.
Фильтрация событий — выкидываем ненужное или оставляем только нужное.
Очень полезная штука особенно для логов операционных систем, антивирусов, IDS/IPS. Как наиболее эффективно определить, что мероприятие вам не интересно? Вам нужно написать правило, которое будет записываться в лист (в терминологии Arcsight, не знаю, есть ли такая функция у конкурентов) или построить отчет обо всех событиях, произошедших за неделю, из каждого источника и проанализировать его из с точки зрения информационного содержания.
Результатом этого анализа является изменение уровня ведения журнала в источнике событий или настройка фильтров в сборщике журналов SIEM. Забегая вперед, скажу, что логи фаервола лучше не фильтровать, потому что они очень полезны при расследовании инцидентов.
Категоризация событий – отнесение однотипных событий из разных источников к одной категории для удобства обработки.
Скажу сразу, вещь выглядит более перспективной, чем есть на самом деле, если у вас много разных источников и у вас просто нет времени правильно настроить категоризацию.
Для тех, у кого инфраструктура развивается медленно, думаю, будет полезно.
Приоритезация – установка приоритета события внутри SIEM. Например, мы получили событие с серьезностью CRIT, но знаем, что для ИБ оно не является критическим и устанавливаем его с INFO. Перейдем немного к практике и поговорим о наиболее информативных источниках логов.
Мой безусловный лидер — сканеры уязвимостей, которые позволяют провести инвентаризацию, составить список открытых портов, сервисов и уязвимостей в сети.
Здесь я бы рекомендовал использовать сразу несколько инструментов и собирать все в листы или отчеты, а потом все это привязывать к ITIL, т.е.
создавать внутренние тикеты и закрывать проблемы в соответствии с внутренними политиками ИБ.
Собственно, SIEM здесь — это инструмент, которому все сканеры отправили информацию, а аналитик уже анализирует ее, просматривая все отчеты только в одном месте.
Я бы сюда еще включил самописные скрипты, умеющие собирать информацию с DNSBL, C&C серверов из Интернета.
Второе место у меня занимают межсетевые экраны, netflow, VPN-шлюз и IPS/IDS/WAF, которые позволяют обнаруживать всевозможные сканирования, попытки DDoS-атак и другие нарушения сетевой безопасности, в т.ч.
внутренних пользователей и оптимизировать работу мер безопасности.
Третье место — операционные системы, по логам операционной системы можно понять, что нас взломали или админ разыгрывает. Четвертое место — базы данных; по их запросам вы также можете увидеть попытки отобрать у нас важную информацию.
Пятое место – антивирусы.
Думаю, на этом мы сможем закончить первую часть.
Ждите второго, в котором я расскажу о том, что лучше визуализировать, что с чем соотносить, о чем уведомлять и на что можно отвечать скриптами и почему.
Теги: #siem #siem #SIEM #arcsight #управление журналами #информационная безопасность
-
Советы По Покупке Нового Ноутбука
19 Oct, 24 -
Якорь
19 Oct, 24 -
Критика Айфона
19 Oct, 24 -
Тест Бюджетного Навигатора Lexand Si-365
19 Oct, 24
