Опыт заказчика: как мы выбрали и внедрили SIEM
Привет, Хабр.
Сегодня мы поделимся историей одного внедрения: про выбор и установку 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» всё это имеется.
