«Мы не знали, с чем придется столкнуться» - эксперт Дмитрий Чучин об опыте внедрения SIEM

Дмитрий Чучин: В связи с тем, что на тот момент у нас на аутсорсе работал Операционный центр, другими словами – SOC, вопрос внедрения «собственного» решения типа SIEM остро не стоял. Катализатором стала пандемия, поскольку в Интернете мы фиксировали упоминания о значительном росте числа фишинговых писем, вредоносных событий, подозрительных обращений на внешние контуры. К сожалению, SOC не обеспечивал в должном режиме необходимый нам функционал из-за отсутствия возможности оперативного вмешательства и реагирования на новые киберугрозы. Просматривать в ручном режиме события безопасности, которые SOC не закрывал по сервисной модели, стало проблематично. То есть картины в целом увидеть не получалось, все время приходилось переключаться из консоли в консоль.

В связи с этим и с потенциальным локдауном пришлось в оперативном режиме не только обеспечивать возможность удаленного подключения к рабочим местам работников, но и в полной мере обеспечить защиту в таком хаотичном ИТ-контуре. Тогда мы в отделе собрали все вводные и вышли к руководству с инициативой внедрения «собственного» SIEM и ухода от SOC.

Дмитрий Чучин: Да, к счастью, руководство поддержало нашу инициативу, поскольку всегда открыто к новым технологичным решениям, способствующим развитию бизнеса. Рассмотрев все варианты «Как сейчас – Как будет» и все плюсы «собственного» SIEM, остановились на взвешенном решении попробовать «быстро» внедрить какой-нибудь open-source SIEM. Мы попробовали, но очень быстро поняли, что это не выход.

Дмитрий Чучин: Еще до тестирования стало понятно, что «быстренько» внедрить open-source невозможно. Да, это по сути SIEM-система, в ней есть алерты. Но нет правил, непонятно, как подключать коннекторы. Мы потратили на поиск подхода к open-source примерно неделю, осознали, что это полный хаос и отказались от идеи. В 2021 году мы все же убедили руководство и организовали пилот нескольких коммерческих решений. Безусловно, на тот момент я не представлял, с чем мне придется столкнуться.

Дмитрий Чучин:Мы брали на тест Graylog, ELK Stack, «СёрчИнформ SIEM», IBM Qradar. Информации о SIEM много, мы решили определиться с ключевыми критериями, которые нам были особенно важны. Это количество предустановленных правил, которые сразу покажут результат, интеграция с другими решениями и минимальная достаточность функционала. Под последним я подразумеваю поддержку нужных нам коннекторов, а не бесконечного множества. Тестировали функционал, сравнивали ценовую политику, качество технической поддержки, соответствие требованиям регулятора (в нашем случае это ЦБ РФ).

Кроме того, обращали внимание на удобство. Например, мне было важно, чтобы информация об инциденте была понятна не только мне, но и руководству. Еще с внедрением SIEM встал вопрос совместной работы над инцидентами (на стыке ИТ и ИБ), мы прописали регламент. Но было удобно, что в «СёрчИнформ SIEM» есть таск-менеджер, в котором как в Jira или другом таск-трекере можно видеть динамику работы над задачей.

Дмитрий Чучин: Непреодолимых задач к счастью не было, все решалось, но на все нужно было много времени. Основная трудность заключалась в организационных моментах: в анкетировании бизнес- и ИТ-подразделений, последующей инвентаризации всего корпоративного оборудования и конечной конфигурации для передачи лог-событий.

Пилотировали все выбранные решения около полугода. Это был наш первый опыт работы с SIEM, и как с любым софтом сначала все оказалось непонятно. Но как только картинка начала прорисовываться, мы поняли, что это очень нужная система. SIEM – это настоящие «киберглаза», которые смотрят за тебя и видят всю ситуацию, своевременно информируют об инцидентах безопасности.Догнать и перегнать: Российские ВКС прирастают новыми функциями 8.6 т

В результате тестирования мы остановились на «СёрчИнформ SIEM». Его пилот был самым оперативным и удобным. Также немаловажным была интеграция с DLP, получилась своего рода экосистема. Внедрение заняло максимум 2 месяца, это по SIEM-меркам недолго. Понравилось, что много предустановленных правил, сканер сети, карта инцидентов, поддержка нестандартных коннекторов. Руководство же оценило, что за фиксированную сумму денег мы получаем программный продукт с понятными лицензиями и бесконечное расширение правил, что в сервисной модели влечёт за собой дополнительные затраты на доработки.

Дмитрий Чучин: Действительно, нужно уметь писать правила корреляции, а для этого хорошо представлять, какое сочетание событий является признаком инцидента. Но это решаемый вопрос. Прекрасный инструмент для создания правил корреляции – это матрица MITRE ATT&CK. Эта матрица содержит тактики, техники и общеизвестные факты о злоумышленниках, а ознакомиться с угрозами на веб-приложения – OWASP Top 10.

Но мы решили подойти к делу еще более предметно. Мы вспомнили хрестоматийную фразу – чтобы понимать, как действует преступник, нужно мыслить как преступник. Поэтому параллельно с пилотом SIEM мы запустили пентест. На основе полученных событий с пентеста мы смогли увидеть и понять, как атакует злоумышленник, сформировать актуальные для нас правила корреляции и по итогу подготовить регламент регистрации инцидентов безопасности и порядок работы с ними. Я всегда буду помнить, как в один прекрасный момент наша SIEM на графике отобразила всплеск в 800 тысяч событий за 10 минут. Это было отличным опытом.

Еще полезно изучать фиды – это структурированные проанализированные данные по разным направлениям: IP адреса, домены, email отправители, хэши и пр. На их основании также можно подготовить актуальные для компании правила корреляции.

Дмитрий Чучин: Пентест нам помог определиться, за чем следить в первую очередь. Это странные имена процессов и ключи этих процессов – их хорошо видно по Event Log. Изменение в реестре на предмет регистрации новых служб, сервисов, импорт библиотеки. Нужно отслеживать и закрывать любые нетипичные порты, обращения в интернет, анонимные доступы, подозрительные aspx-файлы (почему-то не все компании до сих пор пропатчили свои exchange-сервера), файлы конфигурации в web-доступе (постоянно сталкиваюсь, что компании забывают в онлайне эти документы и даже с паролями) и прочее.

Донастройки я выполнял довольно часто: мир киберугроз не стоит на месте и постоянно возникают новые киберугрозы, которые необходимо своевременно продетектировать, а при возможности заранее устранить соответствующую уязвимость посредством реконфигурации ПО/оборудования и/или установки патча безопасности. Например, мы, как многие компании после карантина, реализовали систему для удаленного подключения. Это потребовало донастроек, как минимум белых и черных списков, потому что нас завалило ложными сработками – когда привилегированный пользователь подключался удаленно, у него по дереву компьютеров происходило обращение на доступность его машины. Это выглядело как вход на 50-70 компьютеров.

Дмитрий Чучин: На деле так оно и есть. SIEM действительно внедряется из коробки, предустановленные правила сразу начинают давать результат. Но, конечно, нельзя успокаиваться, дальше предстоит другая работа. Будет недостаточно подключить, условно, контроллер домена или же какое-либо Linux оборудование к SIEM и жить спокойно. Предстоит делать аудит имеющегося «на борту» компании ПО и оборудования, сверку документов с реальными настройками, реконфигурацию для передачи лог-событий, актуализацию разного рода локальной нормативной документации.

Как бы ужасно и непреодолимо это ни выглядело, внедрение SIEM «тянет» за собой нужные процедуры и шаг за шагом требуемая цель будет достигнута. Кроме того, важно, насколько вендор готов помогать. С «СёрчИнформ», например, было удобно и быстро работать. Нам было нужно получать больше событий с Event Log, и этот коннектор мы быстро «дошаманили» совместными усилиями.

Дмитрий Чучин: В первую очередь я бы обратил внимание, достаточно ли доступных коннекторов под имеющееся корпоративное оборудование и программное обеспечение. А если нет – каков механизм написания «пользовательских» коннекторов. Важна оперативность технической поддержки, а также наличие дополнительного функционала. Современные SIEM решения, к счастью, имеют под капотом не только сбор событий безопасности и корреляцию правил, но и, к примеру, сканер сети, сканер уязвимостей. В дополнение, при наличии требований со стороны регуляторов, важным будет интеграция с ГосСОПКА и/или автоматизированной системой обработки инцидентов ФинЦЕРТ.