Comments 6
Можно пару вопросов) Очень интересная тема.
Вы все логи в сием шлете? Не делали промежуточных сборщиков на чем-нибудь бесплатном (logshash) c предварительной фильтрацией и отправкой на сием только важных (некий первый, грубый уровень фильтрации)? Очень уж дорогой каждый EPS.
В чем инвентаризируете инфраструктуру — где описываете что за каким IP закреплено, тип сервера, что за система что за сервисы, критичность — для дальнейшей загрузки в сием и корреляции?
Что предварительно сделали с инфраструктурой перед внедрением сиемки (инвентаризация, политики и проч) и по ходу развития?
Вообще у вас насколько большая инфраструктура, которую мониторите, какой ее состав (больше маршрутизаторы/ком. обрудование или информсистемы), и какой поток EPS обрабатывает SIEM? И во сколько все это обошлось (хотя бы порядок цен)
Вы все логи в сием шлете? Не делали промежуточных сборщиков на чем-нибудь бесплатном (logshash) c предварительной фильтрацией и отправкой на сием только важных (некий первый, грубый уровень фильтрации)? Очень уж дорогой каждый EPS.
В чем инвентаризируете инфраструктуру — где описываете что за каким IP закреплено, тип сервера, что за система что за сервисы, критичность — для дальнейшей загрузки в сием и корреляции?
Что предварительно сделали с инфраструктурой перед внедрением сиемки (инвентаризация, политики и проч) и по ходу развития?
Вообще у вас насколько большая инфраструктура, которую мониторите, какой ее состав (больше маршрутизаторы/ком. обрудование или информсистемы), и какой поток EPS обрабатывает SIEM? И во сколько все это обошлось (хотя бы порядок цен)
Да легко:) Затем и пишу, чтобы рассказать и подсказать.
Т.к. использовали Arcsight, то промежуточные сборщики — это коннекторы, функции у них те, которые я описал в статье (нормализация, фильтрация и т.п.), собственно все SIEM имеют либо отдельные сборщики, либо встроенные. Я считаю, что Arcsight в части сбора логов идеален, т.к. обладает очень гибкими механизмами. Если интересно будет, то могу написать отдельные статьи про арксайт и возможности его компонентов.
Коннектор стоит на отдельном физическом или виртуальном сервере, на который приходят логи, т.е. схема такая: источник > сборщик логов -> SIEM->СУБД -> SAN. Так же арксайт не лицензируется особо по EPS, т.е. ограничение как бы есть и как бы его нет, т.е. упираемся в основном в производительность самого сервера. Железо нужно нормальное с современными процессорами и кол-м оперативки не менее 96 Гб.
Я пришел в компанию, когда была куплена SIEM и лежала в разобранном виде, потому в подготовке инфры не участвовал, да и не было в этом смысла, т.к. она очень быстро менялась.
Инвентаризация так же идет через SIEM, в качестве источников информации выступают логи с МСЭ, результаты сканирований с помощью сканеров уязвимостей и сетевых(nmap), самописные скрипты для Linux в части управления обновлениями, для Windows — AD, WSUS, что то велось в Sharepoint, для него писал приложение, которое выдергивало инфу о том какие есть сервера. В общем в этой части у нас был небольшой хаос в части инструментов :) Арксайт позволяет писать правила, которые будут заполнять инвентаризационные списки. Очень удобно.
Когда пришел в компанию изначально изучил схему сети и те ИС, которые есть, категоризация серверов бумажная и т.п… Собственно SIEM в итоге стал тем продуктом, над которым крутятся сейчас многие процессы ИБ.
Порядок цен не назову, но думаю сейчас около 500 000$ будет стоить. EPS — в пике до 10,000, средняя цифра — 3500 с учетом агрегации и фильтрации мусора. Думаю по цифрам понятно на сколько большая инфраструктура :) В основном средства защиты, сервера баз данных, вебы, сетевое оборудование (без коммутаторов, только МСЭ и маршрутизаторы), для коммутаторов слишком мало полезных сценариев можно написать, когда нет рабочих станций пользователей.
Т.к. использовали Arcsight, то промежуточные сборщики — это коннекторы, функции у них те, которые я описал в статье (нормализация, фильтрация и т.п.), собственно все SIEM имеют либо отдельные сборщики, либо встроенные. Я считаю, что Arcsight в части сбора логов идеален, т.к. обладает очень гибкими механизмами. Если интересно будет, то могу написать отдельные статьи про арксайт и возможности его компонентов.
Коннектор стоит на отдельном физическом или виртуальном сервере, на который приходят логи, т.е. схема такая: источник > сборщик логов -> SIEM->СУБД -> SAN. Так же арксайт не лицензируется особо по EPS, т.е. ограничение как бы есть и как бы его нет, т.е. упираемся в основном в производительность самого сервера. Железо нужно нормальное с современными процессорами и кол-м оперативки не менее 96 Гб.
Я пришел в компанию, когда была куплена SIEM и лежала в разобранном виде, потому в подготовке инфры не участвовал, да и не было в этом смысла, т.к. она очень быстро менялась.
Инвентаризация так же идет через SIEM, в качестве источников информации выступают логи с МСЭ, результаты сканирований с помощью сканеров уязвимостей и сетевых(nmap), самописные скрипты для Linux в части управления обновлениями, для Windows — AD, WSUS, что то велось в Sharepoint, для него писал приложение, которое выдергивало инфу о том какие есть сервера. В общем в этой части у нас был небольшой хаос в части инструментов :) Арксайт позволяет писать правила, которые будут заполнять инвентаризационные списки. Очень удобно.
Когда пришел в компанию изначально изучил схему сети и те ИС, которые есть, категоризация серверов бумажная и т.п… Собственно SIEM в итоге стал тем продуктом, над которым крутятся сейчас многие процессы ИБ.
Порядок цен не назову, но думаю сейчас около 500 000$ будет стоить. EPS — в пике до 10,000, средняя цифра — 3500 с учетом агрегации и фильтрации мусора. Думаю по цифрам понятно на сколько большая инфраструктура :) В основном средства защиты, сервера баз данных, вебы, сетевое оборудование (без коммутаторов, только МСЭ и маршрутизаторы), для коммутаторов слишком мало полезных сценариев можно написать, когда нет рабочих станций пользователей.
Спасибо, а когда ждать следующую статью про корреляцию? Мне например, в особенности интересно как наладить проверку реальности атак уровня веб-приложения.
К примеру, SQL-иньекции. Допустим есть веб сервер с кучей сайтов (все на одном IP 11.22.33.44 — только вир.т. хосты разные), и один из виртуальных серверов на нем — xxx.abc.ru. IDS обнаруживает атаку и залоггирует payload (http://xxx.abc.ru/path/script.php?param=INJECTION_HERE). IDS отправляет в SIEM в CEF алерт что мол на IP 11.22.33.44 была атака типа SQL и номер алерта в IDS 123456.
Как быть дальше? Как я предполагаю: По приходу такого алерта надо запустить скрипт, который получает из базы IDS payload атаки (лог веб-сервера не подойдет — POST не логгируется), распарсить его, вычленить поле Host, вычленить атакуемый параметр, запустить sqlmap/сканер, проверить параметр на иньекцию и ждать в сием результатов сканирования? Разумеется с использованием WAF в режиме регистрации можно первые шаги упростить.
Еще интересно как быть с «инвентаризацией» веб-ресурсов — чтобы регулярно актуализировать списки проверки веб-сканерами (чтобы находились все сайты на всех поддоменах и во всех подпапках, все скрипты в них и все параметры — не все сканер может выявить самостоятельно). Условие — автоматизированность — систем очень много. И возможно ли сразу увязать результаты такой инвентаризации и проверки сиемкой? Чтобы уже были знания по «безопасным» параметрам?
Можете осветить в следующей статье подобные кейсы?
PS. Про WAF от Валларма с его самопроверкой наличия иньекций знаю, но он дороговат в редакции нужной нам…
К примеру, SQL-иньекции. Допустим есть веб сервер с кучей сайтов (все на одном IP 11.22.33.44 — только вир.т. хосты разные), и один из виртуальных серверов на нем — xxx.abc.ru. IDS обнаруживает атаку и залоггирует payload (http://xxx.abc.ru/path/script.php?param=INJECTION_HERE). IDS отправляет в SIEM в CEF алерт что мол на IP 11.22.33.44 была атака типа SQL и номер алерта в IDS 123456.
Как быть дальше? Как я предполагаю: По приходу такого алерта надо запустить скрипт, который получает из базы IDS payload атаки (лог веб-сервера не подойдет — POST не логгируется), распарсить его, вычленить поле Host, вычленить атакуемый параметр, запустить sqlmap/сканер, проверить параметр на иньекцию и ждать в сием результатов сканирования? Разумеется с использованием WAF в режиме регистрации можно первые шаги упростить.
Еще интересно как быть с «инвентаризацией» веб-ресурсов — чтобы регулярно актуализировать списки проверки веб-сканерами (чтобы находились все сайты на всех поддоменах и во всех подпапках, все скрипты в них и все параметры — не все сканер может выявить самостоятельно). Условие — автоматизированность — систем очень много. И возможно ли сразу увязать результаты такой инвентаризации и проверки сиемкой? Чтобы уже были знания по «безопасным» параметрам?
Можете осветить в следующей статье подобные кейсы?
PS. Про WAF от Валларма с его самопроверкой наличия иньекций знаю, но он дороговат в редакции нужной нам…
В части SQL-инъекций наиболее эффективно как раз анализировать посты и/или логи СУБД. Описанная вами задача решается проще и быстрее в части определения актуальности атаки.
1. Провели внутреннее сканирование веб-серверов сами и нашли уязвимости, которые есть на серверах
2. Заполнили списки уязвимостей для хостов
3. При срабатывании сигнатуры IDS/WAF смотрим актуален ли данный тип атаки для данного сервера.
Это в т.ч. хороший способ избавляться от ложных срабатываний. Вторую статью думаю на следующей неделе ждать. Я в меньшей степени хочу описывать реальные примеры, мне интереснее описать концепцию как делать хорошо, а как не делать.
Дальше исходя из правильного принципа, зная его можно лепить что угодно. Это как знать как управлять авто и самому выбирать куда и как ехать.
По инвентаризации. Тут нужно понимать, что в Арксайт можно засунуть и проанализировать любую информацию, как это сделать в вашей ситуации виднее вам. Из описанного вами сценария я бы использовал питон или баш скрипт, который по сислогу бы отправлял в SIEM нужную мне информацию и на SIEM я бы ее уже анализировал. По сути сделать complience check на siem не проблема, если отправлять на нее события с перечнем параметров, которые должны быть. У нас был реализован подобный кейс.
1. Провели внутреннее сканирование веб-серверов сами и нашли уязвимости, которые есть на серверах
2. Заполнили списки уязвимостей для хостов
3. При срабатывании сигнатуры IDS/WAF смотрим актуален ли данный тип атаки для данного сервера.
Это в т.ч. хороший способ избавляться от ложных срабатываний. Вторую статью думаю на следующей неделе ждать. Я в меньшей степени хочу описывать реальные примеры, мне интереснее описать концепцию как делать хорошо, а как не делать.
Дальше исходя из правильного принципа, зная его можно лепить что угодно. Это как знать как управлять авто и самому выбирать куда и как ехать.
По инвентаризации. Тут нужно понимать, что в Арксайт можно засунуть и проанализировать любую информацию, как это сделать в вашей ситуации виднее вам. Из описанного вами сценария я бы использовал питон или баш скрипт, который по сислогу бы отправлял в SIEM нужную мне информацию и на SIEM я бы ее уже анализировал. По сути сделать complience check на siem не проблема, если отправлять на нее события с перечнем параметров, которые должны быть. У нас был реализован подобный кейс.
Как в ARCSIGHT с пользовательским интерфейсом? Когда я последний раз проверял там был жутко неудобный «толстый» клиент и ограниченный в функционале веб-клиент.
Как насчет ADHOC запросов?
Как насчет ADHOC запросов?
Интерфейс не изменился :) Я не могу назвать его неудобным в сравнении с тем же IBM Qradar, да он объемный, но там есть практически все что нужно, но это вопрос вкуса и привычки. Начиная с 6 версии стало удобнее управлять дисковым пространством, которое выделено базе и в целом много очень удобных фишек появилось. Про особенности управления Арксайтом стараюсь не писать в своей статье, т.к. хочется рассказать про общие принципы, а не продукт. Про продукт пусть сейлы рассказывают:)
По ADHOC запросами, что подразумеваете? Формирование своих SQL запросов? Если да, то там можно написать (накликать через UI) запрос практически любой сложности (не могу сейчас придумать, что нельзя написать :)) с разным способом визуализации.
По ADHOC запросами, что подразумеваете? Формирование своих SQL запросов? Если да, то там можно написать (накликать через UI) запрос практически любой сложности (не могу сейчас придумать, что нельзя написать :)) с разным способом визуализации.
Sign up to leave a comment.
Успешное внедрение SIEM. Часть 1