Привет, Хабр.
Сегодня мы поделимся историей одного внедрения: про выбор и установку SIEM-системы расскажет наш заказчик, Дмитрий Чучин – эксперт в области информационной безопасности, а до некоторого времени – сотрудник компании из финансовой сферы, где он разворачивал «СёрчИнформ SIEM». Попросили его рассказать, как он с коллегами тестировал решения разных вендоров и к каким выводам пришли. Далее текст – от первого лица.
Предыстория
Изначально мы не планировали внедрение SIEM, так как использовали SOC. И в принципе, это закрывало наши потребности. Когда началась пандемия – ситуация изменилась: нагрузка на внешний контур защиты выросла в разы из-за массы подозрительных обращений, фишинговых писем и других вредоносных событий. С SOC невозможно реагировать на инциденты «в моменте», нет необходимого функционала. При этом SOC – дорогая услуга для среднего бизнеса, которая к тому же не закрывает часть событий. Просматривать эти события в ручном режиме оказалось затруднительно: когда переключаешься из одной консоли в другую, картина не становится яснее.
Все эти факторы и надвигающийся карантин привели к тому, что нужно было в срочном порядке организовать удаленное подключение к рабочим местам сотрудников и параллельно усилить защиту сложного ИТ-контура. Собрав аргументы, обратились к руководству с предложением внедрить SIEM in-house и отказаться от SOC. Руководство поддержало инициативу, так как понимало, что это принципиально важно для защиты бизнеса.
Рассмотрев все варианты «Как сейчас – Как будет» и все плюсы «собственного» SIEM, остановились на решении попробовать «быстро» и внедрить какой-нибудь open-source SIEM. Мы попробовали, но скоро поняли, что это не выход.
Open-source vs in-house
Еще до тестирования стало понятно, что «с наскока» внедрить open-source невозможно. Да, это по сути SIEM-система, в ней есть алерты. Но нет правил, непонятно, как подключать коннекторы. Мы потратили на поиск подхода к open-source примерно неделю, осознали, что это полный хаос и отказались от идеи.
В 2021 году мы все же убедили руководство и организовали пилот нескольких коммерческих решений. На тот момент я не представлял, с чем мне придется столкнуться.
Мы брали на тест Graylog, ELK Stack, «СёрчИнформ SIEM», IBM Qradar. Информации о SIEM много, мы решили определиться с ключевыми критериями, которые нам были особенно важны:
количество предустановленных правил, которые сразу покажут результат;
интеграция с другими решениями;
минимальная достаточность функционала, т.е. поддержка нужных коннекторов, а не бесконечного множества;
удобство и наглядность – чтобы информация об инциденте была понятна не только мне, но и руководству.
Тестировали функционал, сравнивали ценовую политику, качество технической поддержки, соответствие требованиям регулятора (в нашем случае это ЦБ РФ).
Основная трудность заключалась в организационных моментах: в анкетировании бизнес- и ИТ-подразделений, последующей инвентаризации всего корпоративного оборудования и конечной конфигурации для передачи лог-событий.
С внедрением SIEM встал вопрос совместной работы над инцидентами (на стыке ИТ и ИБ), мы прописали регламент. Было удобно, что в «СёрчИнформ SIEM» есть таск-менеджер, в котором как в Jira или другом подобном инструменте можно видеть динамику работы над задачей.
Первая SIEM – первый опыт
Пилотировали все выбранные решения около полугода. Это был наш первый опыт работы с SIEM, и как с любым софтом сначала все оказалось непонятно. Но как только картинка стала прорисовываться, оказалось, что SIEM – это настоящие «киберглаза», которые смотрят за тебя и видят всю ситуацию, своевременно информируют об инцидентах безопасности.
В результате тестирования мы остановились на «СёрчИнформ SIEM». Решение в большей степени соответствовало нашим запросам. Плюс его пилот был самым оперативным и удобным. Также немаловажной была интеграция с DLP, получилась своего рода экосистема. Внедрение заняло максимум 2 месяца, это по SIEM-меркам недолго. Понравилось, что много предустановленных правил, сканер сети, карта инцидентов, поддержка нестандартных коннекторов. Руководство же оценило, что за фиксированную сумму денег мы получаем программный продукт с понятными лицензиями и бесконечное расширение правил, что в сервисной модели влечет за собой дополнительные затраты на доработки. Так как при использовании сервиса за доработками нужно обращаться к владельцу ПО: вендору или интегратору. А при покупке «собственного» SIEM доработки могут выполняться силами штатных специалистов (это не требует особых навыков), к тому же не требуется дополнительное финансирование.
«СёрчИнформ SIEM» работает «из коробки»: предустановленные правила сразу начинают давать результат. Но это, конечно, не значит, что работа на этом закончилась. Будет недостаточно подключить, условно, контроллер домена или же какое-либо Linux оборудование к SIEM и жить спокойно. Предстоит делать аудит ПО и оборудования, сверку документов с реальными настройками, реконфигурацию для передачи лог-событий, актуализацию разного рода локальной нормативной документации.
Внедрение SIEM «тянет» за собой многие процедуры. Звучит страшно, и может таким в итоге оказаться, если вендор не помогает. С «СёрчИнформ» таких сложностей не возникло: например, нам нужно было получать больше событий с Event Log, и этот коннектор мы быстро «дошаманили» совместными усилиями.
Кроме того, для работы с SIEM нужно уметь писать правила корреляции, а для этого хорошо представлять, какое сочетание событий является признаком инцидента. Но это решаемый вопрос. Прекрасный инструмент для создания правил корреляции – это матрица MITRE ATT&CK. Она содержит тактики, техники и общеизвестные факты о злоумышленниках, а ознакомиться с угрозами на веб-приложения можно в OWASP Top 10.
Но мы решили подойти к делу еще более предметно, поэтому параллельно с пилотом SIEM запустили пентест.
Пентест и донастройка системы
Итак, благодаря пентесту, мы смогли увидеть и понять, как атакует злоумышленник, сформировать актуальные для нас правила корреляции и по итогу подготовить регламент регистрации инцидентов безопасности и порядок работы с ними. Я всегда буду помнить, как в один прекрасный момент наша SIEM на графике отобразила всплеск в 800 тысяч событий за 10 минут. Это было отличным опытом.
Пентест помог нам определиться, за чем следить в первую очередь. Это странные имена процессов и ключи этих процессов – их хорошо видно по Event Log. Изменения в реестре на предмет регистрации новых служб, сервисов, импорт библиотек. Нужно отслеживать и закрывать любые нетипичные порты, обращения в интернет, анонимные доступы, подозрительные aspx-файлы (почему-то не все компании до сих пор пропатчили свои exchange-сервера), файлы конфигурации в web-доступе (постоянно сталкиваюсь, что компании забывают в онлайне эти документы и даже с паролями) и прочее.
Еще полезно изучать фиды – это структурированные проанализированные данные по разным направлениям: IP-адреса, домены, email отправителей, хэши и пр. На их основании также можно подготовить актуальные для компании правила корреляции.
Донастройки я выполнял довольно часто: постоянно возникают новые киберугрозы, которые необходимо своевременно детектировать, а при возможности заранее устранить уязвимость посредством реконфигурации ПО/оборудования и/или установки патча безопасности. Например, мы, как многие компании после карантина, реализовали систему для удаленного подключения. Это потребовало донастроек, как минимум белых и черных списков, потому что нас завалило ложными сработками – когда привилегированный пользователь подключался удаленно, у него по дереву компьютеров происходило обращение на доступность его машины. Это выглядело как вход на 50-70 компьютеров.
Что учесть при внедрении SIEM
В первую очередь нужно обращать внимание, достаточно ли доступных коннекторов под имеющееся корпоративное оборудование и программное обеспечение. А если нет – каков механизм написания «пользовательских» коннекторов. Во-вторых, важна оперативность технической поддержки, а также наличие дополнительного функционала. Современные SIEM решения, к счастью, имеют под капотом не только сбор событий безопасности и корреляцию правил, но и, к примеру, сканер сети, сканер уязвимостей. В дополнение, при наличии требований со стороны регуляторов, важным будет интеграция с ГосСОПКА и/или автоматизированной системой обработки инцидентов ФинЦЕРТ. В «СёрчИнформ SIEM» всё это имеется.
Комментарии (9)
Vadziku
11.10.2023 07:38-1Не сразу заметил, что блог от СерчИнформ.
Подумал что за детский лепет по выбору и правилам, но теперь все понятно.
Среди тестируемого спектра продуктов однозначно QRadar гораздо круче.
Ну а я сам работаю совсем с другим SIEM, не из списка, чтобы не было подозрений, что я продаю QRadar или сотрудник IBM :-)
new_tata
11.10.2023 07:38+1Статья с личным опытом автора и сравнением - по-вашему, детский лепет, а коммент с аргументами "гораздо круче" и "все понятно" - это, конечно, выверенная взрослая позиция:)
Vadziku
11.10.2023 07:38+1А что мне писать про детский лепет?
"Это офигенно круто"? ????
Озвученные задачи соответствуют совсем начальному уровню, который можно решить вообще с любым SIEM.
А серчинформовский сием вообще вырос из продукта составления электронного досье, и к анализу событий не имел никакого отношения.
Эти хвосты в функциональности продукта видны до сих пор. По крайней мере ещё 5 лет назад, когда я в последний раз интересовался этим продуктом так оно и было.
Гораздо более интересные сиемы - Qradar и Max Patrol SIEM. Не буду называть наш рабочий сием - тот ещё богаче по возможностям, чем эти два. Но совсем не дешёвый, к сожалению.
new_tata
11.10.2023 07:38Ааааа, так вы пришли макспатрол порекламировать. "теперь все понятно" (с)
Аргумент "хвосты видны до сих пор, я смотрел продукт 5 лет назад" - верх профессионализма. За 5 лет многое могло измениться, не считаете? Уровень нашей дискуссии упал ниже плинтуса, пожалуй, давайте на этом закончим, чтобы не смешить народ.Vadziku
11.10.2023 07:38Ещё раз, по складам: я работаю совсем с другим сием, который мощнее макспатрол и я его не называю ????
Кстати, 5 лет назад это был ПОСЛЕДНИЙ раз, когда я интересовался сечинформом.
Следил я за этим продуктом ещё когда он был электронным досье, за все это время впечатляющего прогресса так и не увидел, и он перестал меня интересовать. Тот же курадар за это время развился очень сильно.
FixItFast
11.10.2023 07:38В начале совсем запутался, когда автор написал:
Изначально мы не планировали внедрение SIEM, так как использовали SOC.
Cпустя пару абзацев понял, что речь видимо шла о SOC-as-a-service, который использовался ранее. Ладно, упустим, мой основной вопрос к выбору критериев и здесь мне кажется вы слегка не на том акцентировали внимание:
количество предустановленных правил, которые сразу покажут результат;
Возможно для тех, кто раньше не работал с SIEM, это кажется важным. Однако на практике я сталкивался с тем, что правила из коробки дают очень много фолзов либо не работают вовсе. Как ни крути, все равно правила под ваши актуальные риски и вашу инфраструктуру придётся писать самостоятельно. Из плюсов здесь - в правилах из коробки можно увидеть как предпочтительнее в этом конкретном SIEM их формировать.
интеграция с другими решениями;
Кажется в современных реалиях всё можно интегрировать со всем, если есть время и квалифицированные специалисты. Если про удобство интеграции, то понятно, что решения одного вендора будут интегрироваться между собой сильно проще. Но основной продукт SearchInform - DLP, а это вообще немного сайдовая история для ИБ и вообще вещь в себе. Я в свое время не увидел ощутимых плюсов заведение на SIEM DLP как источника.
минимальная достаточность функционала, т.е. поддержка нужных коннекторов, а не бесконечного множества;
Здесь совсем непонятно, искать на рынке решение которое подходит именно под вас, так можно не найти никогда. Кажется лучше смотреть на гибкость инструмента, который вы выбираете, на возможность создания коннекторов под любой источник. Но кажется это есть в любом нормальном SIEM.
удобство и наглядность – чтобы информация об инциденте была понятна не только мне, но и руководству.
По мне искать наглядность из коробки, и выставлять как критерий при выборе SIEM - такая себе затея. Здесь уже все зависит от вас, вашего понимания опасений и интересов руководства, насколько оно хочет погружаться в процессы ИБ. После того, как будет понимание уже можно формировать для этого руководства дашборы и выводить их хоть на плазму в кабинет ГД. А дашборды сейчас есть в любом SIEM.
Как итог спича, кажется всё же иногда стоит более внимательно относиться к выбору критериев. В следующий раз возможно стоит обратить внимание:
на стоимость решения, а это не только те деньги что вы отдадите вендору при подписании договора, а еще как минимум ежегодную поддержку и оплату труда специалистов, которые будут это решение обслуживать и эксплуатировать;
на наличие этих специалистов на рынке, иначе потом каждого нового работника надо будет учить работать с решением, а это деньги и время;
на оптимизацию, ведь разные SIEM с одними и теме же источниками и идентичными правилами корреляции требуют совсем разного количества ресурсов, а железо нынче в дефиците
на возможности к масштабированию; новые источники, новые типы источников, растущее число серверов и рабочих станций, добавление филиалов - со всем этим приходится сталкиваться при эксплуатации, и не хотелось бы, чтобы масштабирование проходило через боль и слезы.
на отказоустойчивость; маловероятно что вы захотите периодически оставаться без глаз.
Перечень выше далеко не полный, можно еще смотреть на страну вендора (по понятным причинам), на комьюнити и качество поддержки, на сложности эксплуатации и удобство использования как и на многое другое. Все же больше внимания стоит уделить выбору критериев и тогда сможете выбрать то, что подходит именно вам и избежите многих проблем в будущем.
AlexeyK77
А где можно почитать про правила из коробки, которые идут с системой.
И можно ли посмотреть документацию/хелп относительно разработки правил корелляции в SIEM, что бы понять возможности движка сценариев.
SearchInform_team Автор
Список правил можно посмотреть по ссылке. Еще наш системный аналитик проводил вебинар, на котором рассказывал о предустановленных правилах, рекомендуем к просмотру https://youtu.be/wGMSO912Vkk?si=5I7Hb5yPyUjzN4Dk