Журнал "Information Security/ Информационная безопасность" #4, 2022

будет не на что ставить, ставить ее не будут. Проблемы с поставками оборудо- вания коснутся всех ИТ- и ИБ-сегментов. Сергей Кривошеин, NGR Softlab: SIEM – это весьма требовательный к ресурсам класс систем. Дефицит железа подтолкнет производителей к переходу на новые архитектуры с меньшими тре- бованиями. Но выигрыш в производи- тельности приведет к потерям в функ- циональности. Примеры: переход на СУБД, не поддерживающую полнотекс- товый поиск, или уход со schema-less на реляционную СУБД. Дефицит железа может привести также к появлению мини-SIEM для некоторых отраслей. Анна Андреева, Лаборатория информационной безопасности: SIEM является набором связанных про- граммных решений, и ее нужно где-то развертывать. В сложившейся ситуации вырастет стоимость для облачных реше- ний, а для инсталляций on-premise вырас- тет стоимость как новых решений, так и поддержка существующих. Возможно, вендорам придется на время отложить внедрение нового функционала в системе, если для него требуются дополнительные аппаратные мощности. Заказчикам при- дется отложить подключение новых источ- ников событий для сохранения текущей нагрузки, а также уменьшить сроки хра- нения событий в системе. Максим Степченков, RuSIEM: В условиях дефицита оборудования производителям SIEM-систем необходи- мо будет внести изменения в свой про- дукт. Например, мы используем микро- скопичную архитектуру и сейчас ведем активную оптимизацию работы микро- сервисов, что приведет к уменьшению требований в части железа. Иван Чернов, UserGate: Считаю, что проблема не затронет SIEM. По большому счету, SIEM-система не привязана жестко к аппаратной плат- форме, ведь это софтовое решение, которое может быть инсталлировано на любые доступные закзачику сервера. Особенно это удобно, когда SIEM под- держивает возможность кластеризации для наращивания производительности. Ну а если у заказчика нет собственных свободных мощностей, всегда доступна аренда облачных сервисов. Максим Степченков, RuSIEM: Изменения в современных инфра- структурах происходят постоянно. За 3–5 лет инфраструктура отдельно взятой организации может полностью измениться. В нашем решении есть воз- можность деактивировать правила, сни- жая ложные срабатывания. Скоро появит- ся возможность устанавливать готовый пул правил, заточенных под профиль заказчика, не используя все остальные. Но оптимальным вариантом борьбы с некорректно работающими правилами корреляции из-за изменений в инфра- структуре является непрерывная работа аналитиков с SIEM-системой. Все правила должны постоянно проверяться и обнов- ляться по мере того, как развивается инфраструктура, меняются требования бизнеса. Роман Ванерке, ДиалогНаука: В SIEM должны быть реализованы механизмы Health Check. В идеале адми- нистратор должен своевременно узна- вать о проблемах с нормализацией, раз- личных ошибках и ставших неработаю- щими правилах. Рекомендуется прово- дить регулярный аудит настроенного контента с целью выявления и устране- ния проблем. Сергей Кривошеин, NGR Softlab: Актуальные методы борьбы – норма- лизация в жесткую схему данных, но это требует больших трудозатрат. Тео- ретически с задачей нормализации могло бы помочь машинное обучение, в частности алгоритмы классификации данных. Но это приведет к переносу затрат с инженеров на аналитиков дан- ных, то есть поставит под вопрос эконо- мический эффект. Более эффективным может стать переход на частично сигна- турный способ обнаружения (поведен- ческо-признаковый). Роман Назаров, Лаборатория Касперского: Существует несколько подходов, кото- рые лучше комбинировать для большей эффективности: 1. Регулярная отчетность по правилам и отслеживание изменений в трендах их срабатываний. 2. Проведение тестирования правил через запуск сценариев, которые вызы- вают создание необходимых событий аудита. Тем самым можно убедиться, что событие аудита создается и правило на него реагирует. 3. Log Management с контролем потоков событий и их качества с отслеживанием отдельных источников этих событий. Павел Пугач, СёрчИнформ: Если у вас в ИТ-инфраструктуре про- изошли какие-либо изменения, их нужно отразить во всех системах, которые с ней работают. Зачастую достаточно донастроить правило в SIEM, чтобы оно вновь заработало корректно. В нашей SIEM это удобно делается без написания скриптов. Что касается поддержки новых форматов журналов, то это вообще не вопрос пользователя. Если вендор заявляет, что поддерживает сбор жур- налов такого-то ПО версии N и новее, значит, он должен обеспечить коррект- ную вычитку, как бы ни менялся в реше- нии формат записи данных. Другое дело, если разработчик перечисляет конкрет- ные версии, которые поддерживает. Тогда есть смысл обратиться к вендору с вопросом, планируется ли доработка. Анна Андреева, Лаборатория информационной безопасности: Ответом является мониторинг: нужно отслеживать не только инциденты без- опасности, но и работу самой системы. Появились ли какие-либо ошибки в пар- синге событий? Изменилось ли количе- ство поступаемых событий? Есть ли аномальные всплески или просадки по инцидентам за период времени? Так можно закрыть программные проблемы. Организационные же проблемы будут выявлены во время расследований, например, когда хост не включили в реестр критичных или, наоборот, забы- ли исключить. Немаловажным фактором будет контроль за результатами работы аналитиков. Валерий Горбачев, ДиалогНаука: Специалистов, работающих с SIEM, надо разделять по функционалу: адми- нистрирующий персонал (поддержание работоспособности, управление пользо- вателями и т.д.), операторов, работаю- щих с событиями (подключение источ- ников, написание правил корреляции, нормализации и т.д.) и SOC/CERT (рас- следование инцидентов, реагирование). И уже отталкиваясь от такого разделе- ния, следует определять требования по количеству и подготовке персонала. Роман Назаров, Лаборатория Касперского: Для эффективной работы SIEM нужны три роли: аналитик, инженер и исследо- ватель. Инженер занимается поддержкой работоспособности SIEM, внесением изменений. Минимальное количество SIEM-инженеров – 2, для обеспечения отказоустойчивости. Аналитики разбирают срабатывания SIEM, их потребуется от 2 до 5, в зави- симости от режима работы (8х5 или 24х7), а далее количество масштабиру- ется в зависимости от потока алертов и инцидентов. Исследователь занимается разработ- кой новых и отладкой существующих методов детектирования. Для начала хватит одного исследователя. Как эффективно бороться с правилами, которые со временем перестают корректно функционировать? Как оценить количество и специализацию сотрудников, необходимых для эффективной работы SIEM в организации? 34 • СПЕЦПРОЕКТ