Редакция журнала "Информационная безопасность", 24/11/22
Эволюция SIEM в России происходит под влиянием нескольких важных факторов. С одной стороны, это приближение функциональности к предельному уровню для систем этого класса и поиск путей для перехода к Next Generation SIEM. С другой стороны, уход иностранных вендоров с отечественного рынка и общий вектор импортозамещения открыли для российских решений новые горизонты для интенсивного развития. Актуальными остаются и вопросы оптимизации работы специалистов, работающих с SIEM, как в количественном, так и в качественном аспекте.
Участники:
Анна Андреева, генеральный директор ООО “Лаборатория информационной безопасности”
Александр Булатов, коммерческий директор NGR Softlab
Роман Ванерке, технический директор АО “ДиалогНаука”
Валерий Горбачев, руководитель направления внедрения СЗИ, АО “ДиалогНаука”
Сергей Кривошеин, директор центра развития продуктов NGR Softlab
Роман Назаров, руководитель направления SOC Консалтинг “Лаборатории Касперского”
Павел Пугач, системный аналитик “СёрчИнформ”
Максим Степченков, совладелец RuSIEM
Иван Чернов, менеджер по развитию UserGate
Как сказывается уход иностранных вендоров на российских SIEM?
Анна Андреева, Лаборатория информационной безопасности: Иностранное программное решение без поддержки вендора со временем становится непригодным для использования. Сейчас на фоне выросшего спроса на SIEM началась разработка новых российских решений этого класса. Но разработка любого ПО – это долгий и трудозатратный процесс, особенно на начальных этапах. Поэтому первое время, при возросшей стоимости новых продуктов, их функциональность и удобство использования будут уступать давно развивающимся решениям.
Павел Пугач, СёрчИнформ: Не думаю, что функциональность российских SIEM сильно изменится. Например, SIEM не разучились контролировать оборудование CISCO, когда вендор ушел из России. Сложности возникают у тех систем, которые базировались на иностранных компонентах – движках обработки, парсерах, коннекторах и т.д. Им приходится быстро адаптировать решения под отечественную инфраструктуру или бесплатные открытые аналоги. С этой же задачей столкнулись и заказчики, поэтому спрос и предложение развиваются синхронно. При этом есть шанс, что импортозамещение стимулирует разработку новых коннекторов к российскому оборудованию и ПО, а также новых правил корреляции в связи с появившимися угрозами. К тому же нужно поддержать возможности, которые до сих пор были только у иностранных SIEM, ведь потребности заказчиков остались.
Что касается цены, то ситуация больше отразилась на стоимости и себестоимости продуктов, которые имеют в своем составе аппаратные компоненты.
Александр Булатов, NGR Softlab: Заказчики уже давно ориентируются на российских разработчиков SIEM-систем, ведь многие изначально понимали риски использования иностранных ИБ-решений. Многих к этому подтолкнула политика импортозамещения последних лет. На ценообразование сейчас оказывают противоположное влияние две тенденции: освобождается ниша дорогостоящих иностранных решений, но при этом появляются новые разработчики и усиливается внутренняя конкуренция. Однако для конечного заказчика изменилось немногое: есть как предложения, требующие больших бюджетов и ресурсов для обслуживания, так и решения, способные удовлетворить спрос организаций, которые очень тщательно выбирают SIEM-систему с учетом финансовых ограничений.
Максим Степченков, RuSIEM: Функционал отечественных SIEM находится на достаточно хорошем уровне, а в некоторых аспектах даже опережает иностранные решения. Это обуславливается тем, что производители российских SIEM-систем прекрасно знают специфику российского рынка и способны быстро подстраиваться под новые требования заказчиков и регуляторов. Да, уход иностранных вендоров внес некоторые коррективы в требования заказчиков к функционалу российских SIEM-решений, однако эти повышенные требования были ожидаемы, и часть необходимого функционала уже находится в активной разработке. К вопросу стоимости производители российских SIEM-систем подошли по-разному: некоторые отечественные вендоры подняли цены на свои решения. Но наша компания приняла решение зафиксировать цены на уровне прошлого года, чтобы поддержать отечественных заказчиков. И на текущий момент поднятие базовой стоимости решения у нас не ожидается.
Валерий Горбачев, ДиалогНаука: Насколько мы можем судить, стоимость растет в условия сокращения конкурентной среды. В части функциональности – хочется верить, что в близкой перспективе из-за перехода на российское ПО и наплыва feature request наконец появятся функции, которые давно реализованы в зарубежных решениях и к которым заказчики уже привыкли.
Иван Чернов, UserGate: После массового ухода с российского рынка иностранных компаний, в том числе производителей SIEM, у отечественных игроков появились новые широкие возможности. Уже можно говорить о фундаментальных изменениях, фактически приведших к принципиально новому образу рынка ИТ в России, где ключевую роль начали играть российские разработчики решений. Поэтому, говоря о драйверах или новых точках роста бизнеса в отрасли информационных технологий, можно уверенно называть главную из них – новую конфигурацию рынка без зарубежных компаний, но с уже сформированными на базе иностранных решений конкретными ожиданиями и спросом. Иными словами, иностранные платформы уже недоступны, но российские компании хотят привычного уровня эффективности и клиентского сервиса.
По каким векторам развиваются SIEM-решения в России?
Павел Пугач, СёрчИнформ: Нельзя сказать, что до сих пор российские SIEM были непродуктивны. Они уже несколько лет конкурентоспособны на мировом рынке и функционально не уступают иностранным аналогам. Но сейчас наши SIEM ориентируются в большей степени на внутреннего заказчика, ведь освободилась огромная ниша, и возможности наших SIEM стали очевиднее для заказчиков. Основной вектор развития сейчас, как ни крути, – импортозамещение, независимо от того, нужно ли замещать саму SIEM либо SIEM должна в своем составе заменить какие-либо компоненты или поддержать новые источники российского происхождения. В остальном происходит эволюционное развитие.
Анна Андреева, Лаборатория информационной безопасности: Для начала требуется наличие большой постоянно обновляющейся базы правил детектирования, широкая поддержка различных коннекторов и доступная стоимость. Напрашивающееся направление развития – использование bigdata-решений, например TH-запросы и модели ML, а также IRP и TI-платформы, интегрированные в SIEM.
Роман Ванерке, ДиалогНаука: SIEM в первую очередь предназначена для сбора, хранения и анализа событий ИБ. Если SIEM будет охватывать широкий спектр источников событий, обеспечивать высокую производительность и отказоустойчивость, эффективно использовать аппаратные ресурсы и иметь качественный контент для выявления инцидентов и нарушений, то это, безусловно, обеспечит ей широкое распространение на рынке.
Иван Чернов, UserGate: Конкуренция – ключевое условие развития рынка ИБ и направления SIEM-систем в частности. Мы наблюдаем устойчивое стремление подавляющего большинства российских разработчиков завоевать внезапно возникшие ниши, предоставив довольно требовательным пользователям высокий уровень клиентского сервиса. Cудя по всему, SIEM будет развиваться в сторону универсальных платформ анализа любой доступной информации, использования Big Data в выявлении угроз информационной безопасности и так называемой априорной защиты. То есть предоставлять средства упреждающего, профилактического анализа возможных угроз и векторов атаки, выдавать рекомендации по их компенсации и устранению.
Пойдут ли российские решения по пути NG-SIEM? Каковы перспективы облачных SIEM в России?
Роман Ванерке, ДиалогНаука: Безусловно, движение в сторону NG-SIEM будет. Наверное, ключевой вопрос в сроках и терминологии, ведь NG-SIEM можно трактовать по-разному. SIEM в своем базовом исполнении производит множество алертов, и требуется постоянная работа, чтобы снизить долю ложных срабатываний. Стоит также отметить, что рынок требует продвинутой аналитики на больших объемах данных и на больших скоростях, чего зачастую можно достигнуть только в облачной реализации.
Сергей Кривошеин, NGR Softlab: NG-SIEM в текущей парадигме – это мультикомбайн. Некоторые отечественные SIEM уже полным ходом движутся к этому статусу: функционал обогащается встроенными IRP, NDR, UEBA и прочими подсистемами, востребованными в SOC. На мой взгляд, эпитет Next Generation можно применять к SIEM, только если подключение нестандартных источников станет интуитивным, а способы обнаружения уйдут от сигнатурной модели. Что касается облачных SIEM, то они направлены на небольшой сегмент бизнеса, где службы ИБ еще не доросли до осознания востребованности SIEM.
Максим Степченков, RuSIEM: Если подразумевать под NG-SIEM переход от классического выявления инцидентов через правила корреляции к использованию искусственного интеллекта и машинного обучения для выявления угроз, то этот процесс среди российских вендоров уже начался. Мы тоже стремимся к тому, чтобы SIEM-система подсвечивала заказчику моменты, которые еще не охвачены правилами корреляции. Если же в термин NG-SIEM закладывать обработку еще большего объема и типов данных для прогнозирования вероятности того, что определенные события или инциденты произойдут в будущем, то это более сложная задача, требующая больших вычислительных ресурсов. Оптимальным вариантом для решения этой задачи может стать использование облаков, ведь далеко не каждый заказчик способен найти нужные мощности в своей инфраструктуре. Но, несмотря на привлекательность облачных сервисов, в России заказчики по-прежнему предпочитают варианты установки SIEM-решений on-premise. И в среднесрочной перспективе ситуация вряд ли изменится.
Иван Чернов, UserGate: Однозначно российские решения пойдут по перспективному пути NG-SIEM: она комплексная и более гибкая для заказчика. Это выражается в повышении комфорта использования систем специалистами, снижении порога входа в уверенное владение продуктом. Используя NG-SIEM, легче и проще управлять периметром безопасности компании и обеспечением тем самым процессов повышения эффективности бизнеса. Кроме того, NG-SIEM аккумулируют в себе дополнительные функции, становятся более многофункциональными и универсальными, представляют собой комплексный инструмент полного цикла работы с инцидентами, от первичного сбора информации до способов реагирования и финального формирования отчетности для информирования специалистов и компетентных органов.
Анна Андреева, Лаборатория информационной безопасности: Решения NG уже появляются на рынке, это логичное развитие класса SIEM. Когда-то подобный этап прошли межсетевые экраны и антивирусы. В облако имеет смысл переходить, когда затраты на поддержку инфраструктуры превышают стоимость облачного решения либо когда инфраструктуры вовсе нет. Такой вариант определенно заинтересует небольшие компании из-за простоты подключения, а крупных заказчиков – из-за возможности быстро масштабировать вычислительные ресурсы под растущие потребности.
Павел Пугач, СёрчИнформ: Если есть спрос, будут и предложения. По факту NG-SIEM обычно называют систему, в которой реализован функционал еще трех-четырех смежных классов, например сканер уязвимостей, Vulnerability Management, EDR. Такая система будет полезна в условиях нехватки ресурсов на внедрение отдельных продуктов. Интерес к SIEM в облаках пока по инерции сохраняется, но будет планомерно снижаться. Заказчикам удобно, когда провайдер берет на себя вопрос обеспечения железа. Но и вендорам, и облачным провайдерам также сложно закупать и обслуживать новые серверные мощности – а их потребуется больше. К тому же сейчас снизилось доверие к хранению данных где бы то ни было, кроме как in-house. Это подчеркнул и уход иностранных вендоров, когда заказчики лишались оплаченных лицензий, сервисов, а вместе с ними и данных, которые хранились в этих сервисах.
Как скажется дефицит микроэлектроники на рынке SIEM-решений?
Павел Пугач, СёрчИнформ: Дефицит микроэлектроники скажется на рынке SIEM точно так же, как на любом другом рынке ПО, например на рынке ОС. Если ОС, SIEM или любую другую систему будет не на что ставить, ставить ее не будут. Проблемы с поставками оборудования коснутся всех ИТ- и ИБ-сегментов.
Сергей Кривошеин, 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 в организации?
Валерий Горбачев, ДиалогНаука: Специалистов, работающих с SIEM, надо разделять по функционалу: администрирующий персонал (поддержание работоспособности, управление пользователями и т.д.), операторов, работающих с событиями (подключение источников, написание правил корреляции, нормализации и т.д.) и SOC/CERT (расследование инцидентов, реагирование). И уже отталкиваясь от такого разделения, следует определять требования по количеству и подготовке персонала.
Роман Назаров, Лаборатория Касперского: Для эффективной работы SIEM нужны три роли: аналитик, инженер и исследователь. Инженер занимается поддержкой работоспособности SIEM, внесением изменений. Минимальное количество SIEM-инженеров – 2, для обеспечения отказоустойчивости. Аналитики разбирают срабатывания SIEM, их потребуется от 2 до 5, в зависимости от режима работы (8х5 или 24х7), а далее количество масштабируется в зависимости от потока алертов и инцидентов. Исследователь занимается разработкой новых и отладкой существующих методов детектирования. Для начала хватит одного исследователя.
Анна Андреева, Лаборатория информационной безопасности: Количество сотрудников необходимо выбирать исходя из требуемого временного режима реагирования и SLA, а также предполагаемого объема, типа и глубины разбора инцидентов. Если вы не готовы выделять целый рабочий день аналитика на исследование потенциально зараженного хоста, а поручите ИТ перезалить хост, то вам не нужна L3. А если нет необходимости вручную подтверждать каждый вход в критичный сегмент, то не нужна и L1. Для L1 достаточно любого технического образования, обучать их придется самостоятельно, для остальных линий требуется опыт расследований.
Максим Степченков, RuSIEM: Количество и специализация сотрудников, необходимых для работы с SIEM, зависит от множества факторов, в том числе и от самой системы. Минимальное количество персонала для работы с нашей системой начинается от одного сотрудника, а точное число зависит от условий заказчика: размера компании, потока поступающих событий, филиальной сети, типов источников и необходимости разрабатывать кастомные правила. В нашей системе вся работа ведется в едином веб-интерфейсе, а необходимые парсеры мы при необходимости готовы разработать за заказчика. В нашей SIEM предусмотрены элементы реагирования, а также нет необходимости в дополнительных знаниях, например языков программирования. И работа с системой становится легкой.
Павел Пугач, СёрчИнформ: По специализации сотрудников вам подскажет вендор: один скажет, что специалист должен быть профессиональным программистом и, скажем, к тому же изучить два новых языка разработки. Другой – что для работы с SIEM достаточно среднего уровня пользователя ПК с пониманием, что такое ЛВС, а остальному "научим сами за два часа по удаленке". Требования к квалификации сотрудников, которые с ней работают, различаются для разных систем.
Вопрос о количестве сотрудников решать только компании. Границы очень условные: если у вас сто единиц сетевого оборудования, то может хватить и пары человек. Если имеется тысяча единиц оборудования и 6 тыс. сотрудников – наверное, двух сисадминов и одного безопасника вам будет маловато. Если аналитики в стандартное рабочее время справляются со своими задачами по SIEM и всеми остальными, скорее всего, вам их хватает. Если нет – расширяйте штат.
Какими инструментами можно снизить нагрузку на SIEM-аналитика без итогового снижения качества детектирования?
Сергей Кривошеин, NGR Softlab: Большая часть времени аналитика уходит на расследования, предварительное (определение FP) или глубокое – по факту инцидента. Наилучший эффект в оптимизации нагрузки дадут средства автоматического сбора и обогащения данных. Это можно делать на стороне SIEM или уже в IRP. В первом случае собранная информация может снизить FP-rate, то есть повлияет на точность обнаружения. Использование поведенческой аналитики для формирования локальных репутационных баз хостов или пользователей может также снизить количество ложных подозрений.
Валерий Горбачев, ДиалогНаука: В первую очередь уменьшение нагрузки на SIEM-аналитика обеспечивается снижением уровня ложных срабатываний. Для этого как минимум нужны качественно проведенная категоризация активов, реализованная работа по кастомизации правил корреляции для конкретной организации/отрасли, налаженное взаимодействие между ИБ и ответственными администраторами систем от ИТ.
Роман Назаров, Лаборатория Касперского: Вижу три направления снижения нагрузки:
1. Тюнинг правил детектирования для снижения FP. Обычно решается средствами SIEM с подключением внешних систем для расширения контекста.
2. Автоматизация рутинных операций аналитика при обработке инцидента. Это, как правило, решается через IRP/SOAR, частично через SIEM.
3. Применение алгоритмов для автоанализа инцидентов. Аналитик в такой схеме может вообще не участвовать либо может верифицировать финальный вердикт по инциденту.
Анна Андреева, Лаборатория информационной безопасности: Аналитики часто совершают однотипные действия, их можно автоматизировать с помощью IRP-системы: автоматически проверить IP-адреса, хеши файлов, запустить антивирусную проверку и передавать в работу уже обогащенный данными инцидент. Для некоторых типовых событий стоит перейти с простого факта на математические модели поведения и расследовать только аномалии. Еще одним важным влияющим фактором будет классификация самих инцидентов: какие из них регистрируются только для real-time уведомлений, какие требуют участия аналитика, а какие можно просматривать постфактум в рамках TH.
Павел Пугач, СёрчИнформ: Главный вопрос в том, что составляет основную часть загрузки вашего SIEM-аналитика. Если это 600 задач в день, то, очевидно, лучшим инструментом для снижения его нагрузки будет найм еще одного специалиста. А если проблема в том, что он руками вынужден писать скрипты, чтобы провести анализ, то решением станет графический конструктор запросов и дашборды, чтобы визуально определять нужные зависимости. Вполне возможно, что специалист занимается тем, что вручную отправляет письма об инцидентах разным сотрудникам, потому что в SIEM не настроена интеграция с почтовым сервисом. Решение очевидно: настроить такую интеграцию. А самое правильное – брать SIEM, в которых такие задачи решены "из коробки" либо вендор готов помочь решить в процессе использования системы.
Иван Чернов, UserGate: Стоит рассмотреть переход на решения класса NG-SIEM, а также использование машинного обучения и вообще искусственного интеллекта, которые за счет более широкого инструментария и автоматизации процессов снижают нагрузку на персонал. Эти инструменты в целом также улучшат качество мониторинга и реагирования на инциденты, что естественным образом приведет к сокращению объемов ручной работы операторов, ведь большая часть операций будет неизбежно автоматизирована.
Максим Степченков, RuSIEM: Инструменты, помогающие снизить нагрузку на SIEM-аналитиков могут, быть разными. Например, в RuSIEM можно добавлять в карточку инцидента описание логики срабатывания правила корреляции или прописывать мини-плейбуки с рекомендациями по реагированию, чтобы в случае возникновения инцидента аналитикам не приходилось тратить время на то, чтобы разобраться, по какому принципу был выявлен конкретный инцидент и что делать дальше. Можно также использовать механизмы автоматизации реакции на инциденты, в том числе через запуск различных скриптов. В качестве дополнительных инструментов для снижения нагрузки на аналитиков могут выступать и сторонние системы класса IRP/SOAR, которые тесно интегрируются с SIEM.
