SIEM в России — состояние и перспективы рынка

Артем Медведев: По моему мнению, рынок находится на ранней стадии насыщения. Более зрелым выглядят только банковский сектор и телеком-сегмент, где наличие SIEM продиктовано требованиями бизнеса и регуляторов. В ТЭК интерес к ИБ и, в частности, к SIEM-системам стремительно развивается последние пару лет, в тренде темы АСУ ТП и защиты производства. Ключевая мера емкости рынка – TAM (Total Addressable Market) – для SIEM-решений отдельно не ведется, но список наших клиентов в России, где мы работаем на протяжении уже 8 лет, нелинейно растет из года в год. Я полагаю, на этот год в России решения класса SIEM готовы приобрести от 1000 до 3000 заказчиков, тех, у кого есть бюджет на такие проекты, – около 1000–1500. Поэтому, даже несмотря на усилившуюся конкуренцию, мы наблюдаем стабильный рост продаж решений HP ArcSight. Сегодня мы имеем более 5000 заказчиков в мире, более 300 в России. В США рынок значительно более развит, поэтому насыщение диктует вендорам необходимость развивать функционал систем, создавать интеграционные решения и альянсы с другими производителями. Как следствие, мы видим развитие таких тем, как User Behavior Analytics, Threat Discovery, Reputational Databases и т.д. Пользователям на Западе уже нужно больше, чем просто SIEM.

Олег Бакшинский: Отчеты ведущих мировых аналитических агентств показывают, что SIEM-рынок по-прежнему находится в росте – +21% в 2014 году в сравнении с 2013. Он обуславливается использованием SIEM-систем промышленными предприятиями и провайдерами сервисов ИБ. 21% в сравнении с общим ростом в 5,3% всего рынка ПО ИБ – это достаточно много. Так что можно с уверенностью сказать, что рынок ещё не «насытился» SIEM-системами.

Алексей Горелышев: Хочу отметить, что мировой рынок SIEM на 2014 год оценивался примерно в 1,6 миллиарда долларов, с 2009 года он вырос почти в 3 раза. При этом Gartner отмечает, что на американском и европейском рынках уровень запросов на продукты SIEM стабилизируется.

Что касается российского рынка SIEM, он пока невелик, но растёт быстро. 2 года назад в исследовании, проведённом под руководством Евгения Царёва, прогнозировался его 3-кратный рост c 2009 по 2015 год – с 8 до 24 миллионов долларов. С учётом оценки рынка за 2014 год (20 млн долларов) можно сказать, что прогноз сбывается и рынок действительно ещё далёк от 100%-ной насыщенности.

Кроме того, важная тенденция – появление и активное продвижение российских решений. Ещё 2 года назад об отечественных SIEM вообще никто не слышал. А поскольку их появление совпало с обострением международной обстановки, можно ожидать, что расклад российского рынка SIEM будет заметно меняться.

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

Поэтому мы гарантированно будем иметь возможность наблюдать симбиоз 2 направлений: компании, которым нужно рабочее решение прямо сейчас, будут традиционно пользоваться проверенными, качественными и, к сожалению, не российскими решениями Enterprise-уровня. Те компании, которые будут вынуждены использовать абсолютно сырые отечественные разработки, станут своеобразным beta community и тем самым помогут разработке российского ПО. Но даже при абсолютно идеальном развитии событий говорить о выходе полноценного и «устоявшегося» отечественного SIEM можно будет, минимум, через 2 года. Так что сейчас мы будем наблюдать параллельное существование двух векторов, причем достаточно длительное время.

Александр Чигвинцев: Отмечу, что системы SIEM будут трансформироваться в комплексные платформы анализа всей доступной информации. Как и RSA, многие вендоры стали в том или ином виде добавлять модули анализа сетевой активности в свои решения. Получают развитие идеи Больших Данных для выявления определенных типов угроз ИБ. И российский рынок, как и Запад, движется в этом направлении.

Артем Медведев: «Российский SIEM» еще себя не осознал. Заказчики получили технологии, но пока не до конца понимают, как использовать их с максимальной пользой для бизнеса и для его безопасности. Думаю, российские компании будут следовать международным трендам с некоторой задержкой в несколько лет. Темы Big Data и доступности данных для любой аналитики только доходят нашего рынка.

Алексей Горелышев: В целом мы прогнозируем рост российского сегмента рынка SIEM на уровне 30%. Стоимость реализации отдельно взятых проектов, по нашему мнению, останется на прежнем уровне. Хотя уже сейчас заметно появление low-end решений отечественных производителей. Такие системы найдут свою нишу, особенно в свете ключевого тренда в государственных и окологосударственных компаниях – импортозамещения.

Но мы делаем ставку на высокотехнологичные решения и повышение уровня зрелости SIEM: не просто log management, а серьёзный корреляционный анализ разнообразных данных, включая конфигурации и трафик. В следующие 2–3 года значительную роль на рынке SIEM-систем будет играть эффективность решений, позволяющих сопоставлять события, регистрируемые в системе, с уязвимостями актива. Качество работы с активами, полнота и актуальность базы знаний уязвимостей будут выходить на передний план.

Легкость внедрения и интеграции продукта в существующую инфраструктуру компании также будет оставаться в приоритете при выборе SIEM. С учетом реалий российского рынка преимущество будет у тех производителей, кто сможет выстроить внутренние и внешние процессы так, чтобы добавление новой, ранее не известной системы в контур мониторинга и управления занимало считанные дни.

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

Аутсорсинг систем безопасности, включая SIEM, будет расти. В финансовом выражении он будет не столь заметен, при этом качество аутсорсинга экспертизы, а также поддержки на этапе внедрения и эксплуатации станет одним из ключевых критериев выбора партнера. В этом случае на российском рынке безусловное преимущество получат отечественные производители, имеющие эффективные команды R&D, поддержки и, самое главное, команды, обладающие опытом отражения и расследования реальных атак. Компания-производитель также должна иметь отлаженную технологию накопления и оперативного распространения такой позитивной экспертизы в своих продуктах и сервисах.

Олег Бакшинский: Рынок SIEM в России изначально формировался крупными заказчиками. По моему мнению, дальнейшая судьба рынка будет зависеть от средних компаний, основными требованиями которых являются простота внедрения и эксплуатации решения, легкость администрирования, функционал «из коробки», быстрый, видимый результат от использования. А в крупных компаниях, где финансовый аспект в силу экономической ситуации станет снова играть немаловажную роль, можно будет ожидать замены дорогих и сложных решений на более простые и менее затратные.

Александр Чигвинцев: Главная проблема традиционных SIEM-решений даже не во внедрении. Гораздо сложнее поддерживать развернутую систему в актуальном состоянии, адаптируя ее «контент» (парсеры, правила корреляции, отчеты, оповещения и т.д.) к текущим и перспективным угрозам ИБ.

Михаил Чернышев: Я также предлагаю не мыслить в категории «самого сложного этапа внедрения». Есть понятие «эксплуатация SIEM» – это процесс, который подразумевает не только реакцию на уже написанные правила корреляции, но, что самое главное, непрерывную адаптацию SIEM к изменениям в области угроз и в модели бизнеса компании. Этот этап, на мой взгляд, является наиболее сложным для заказчика в силу устоявшегося убеждения, что любая, причем сколь угодно сложная, система должна быть сдана «под ключ».

Алексей Горелышев: Полагаю, в случае SIEM вряд ли можно говорить об одном «самом сложном» этапе. Это на самом деле напоминает миф о продуктах безопасности, которые достаточно поставить из коробки, и всё – якобы дальше они сами обеспечат безопасность. Увы, так не бывает. При внедрении SIEM есть, как минимум, 3 важнейших процесса: подключение и настройка источников, обучение системы, то есть разработка правил корреляции, автоматизация выявления инцидентов, и построение процесса управления инцидентами, включая разработку регламента, создание команд, интеграцию с системами HelpDesk и т.д.

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

Евгений Афонин: Камнем преткновения также становится определение требований к итоговой системе и результатов работ: зачастую заказчики приобретают необходимые знания в предметной области SIEM в ходе самого внедрения. Этим иногда пользуются поставщики решений SIEM/SIM начального уровня для продвижения своих продуктов. Когда через 6–12 месяцев заказчик начинает выдвигать требования к развитию такой системы, выясняется, что их выполнение невозможно по причине ограничений продукта или излишне трудоемко. На этом этапе может сильно облегчить жизнь сотрудничество с опытным интегратором, который обладает не только необходимым опытом внедрения SIEM-систем для решения задач сбора событий, но и расширенными компетенциями по развитию уже существующих платформ в различных вертикалях (банки, телекомы и пр.). Партнер также может помочь в решении более интересных ИБ-задач: расчета KPI, управления инцидентами на основе динамических рисков, реализации антифрода, выявления поведенческих паттернов и т.д.

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

Олег Бакшинский: Нетривиальными можно в первую очередь назвать необычные источники, не производящие события в стандартном понимании SIEM-систем. Из нашей практики таковыми являлись аналоговые элементы систем безопасности предприятия (камеры, датчики слежения и движения). Также отдельным блоком систем можно выделить АСУ ТП (ICS, SCADA), нетривиальность которых можно измерить сложностью их интеграции.

Артем Медведев: Если говорить о нестандартных «ситуациях», у нас есть коннекторы для большинства ИС российского производства. Мы также работаем с журналами отечественных АБС и технологических контроллеров на производстве.

Евгений Афонин: За 5 лет работы с HP ArcSight скопилось достаточно историй из этой области. Так, одно из отечественных средств сетевой безопасности хранило события аудита в СУБД. Казалось бы, ничего не предвещало беды – задача достаточно тривиальная, на 3–4 часа. Но не тут-то было, все события хранились в зашифрованном виде.

Другой пример: одно из нескольких сотен устройств, формирующих сетевые потоки (Flow) в корпоративной сети, почти случайным образом дублировало часть событий. Ошибка была плавающей и на больших объемах – более 50 Гб событий в день – вносила значительные ошибки в логику их анализа. Пришлось писать «искусственный интеллект», который выявлял возникновение этой ошибки по заданным признакам и вносил необходимые коррективы. Это фактически утроило время создания коннектора, хотя со стороны SIEM-системы прием событий был выполнен на 100%. Менее квалифицированный партнер и заказчик могли не обратить внимание на некоторые нестыковки в результирующих корреляционных выкладках.

Были и получение по SYSLOG сообщений в кодировке DOS866 (в 2011 году), и перемешивание кусков событий в файле между собой, когда многострочные события приходили кусочками (2 строки первого события, 1 строка второго события, 3 строки первого события, 1 строка третьего события) без какой-либо закономерности, и требование заказчика переводить события на русский язык в реальном времени, и многое другое. К счастью, за все эти годы не было нерешенных задач, как правило, возможностей SDK и квалификации инженера вполне хватает. Хотя иногда мы обращаемся за океан к нашим коллегам в HP или в штаб-квартиры других зарубежных вендоров.

Михаил Чернышев: Нестандартных коннекторов на сегодняшний день не так много. По умолчанию SIEM от Intel Security поддерживает более 400 различных систем «из коробки». В качестве нетривиального примера можно привести интеграцию с одной из отечественных разработок. Подключение журналов системы защиты мобильных устройств включило в себя написание как транспортного слоя (Perl, ODBC), так и непосредственно парсера для извлеченных и отправленных к SIEM-системе журналов. Нетривиальность заключалась в проприетарности СУБД, для которой на момент подключения не было прямого коннектора. Как следствие, и возникло требование по разработке программы на Perl с извлечением журналов из базы через собственный клиент с последующей их отправкой стандартно через Syslog. Был интересный и обоюдополезный опыт.

Александр Чигвинцев: Что касается нашего решения, через пакетную часть Security Analytics можно мониторить сетевые устройства и протоколы. Например, события АСУ ТП. При этом метаданные – нормализованная информация – представляются в стандартизованном, с «логовыми» данными, виде. Это позволяет в рамках одной «метамодели» анализировать весь спектр собранной информации.

Алексей Горелышев: Нетривиальные источники постоянно встречаются нам при работе с системами ERP (SAP), АСУ ТП, а также с оборудованием телекомов. Другой частый пример – нестандартные протоколы доступа и форматы хранения данных в проприетарных системах: эти форматы зачастую вообще не документируются вендорами.

Стандартными протоколами доступа к системе являются, например, SSH, RPC, WMI, TELNET. Они широко распространены и хорошо описаны в документации. А вот получить доступ к SAP ERP для сбора логов можно по протоколам SAP RFC, SAP DIAG. Они нестандартны по отношению к другим системам и применяются только в SAP ERP. Соответственно по ним необходимо подключиться к системе (не каждый SIEM это может) и забрать логи, которые при этом лежат в нестандартных форматах (их еще необходимо уметь обработать).

Отдельная группа нетривиальных источников – программные и программно-аппаратные отечественные средства защиты информации: «Континент», «Гарда Предприятие», VipNet, Kaspersky Endpoint, SecretNet, ФПСУ-IP, «Дозор-Джет», продукты InfoWatch и др.

Александр Чигвинцев: Основная проблема Open Source SIEM для корпоративного заказчика, имеющего масштабную инфраструктуру с большим количеством разнообразных ИТ-систем, подлежащих мониторингу, – это библиотека парсеров/коннекторов. Современные промышленные SIEM-решения «из коробки» понимают 100–200 тысяч разнообразных форматов событий (например, только Windows-сервер генерирует несколько тысяч типов сообщений). У «открытого» SIEM же возникает проблема с поддержкой этого многообразия типов данных: выходит обновление ПО Windows/firmware сетевого оборудования и т.д., и необходимо оперативно обновлять парсеры под эти источники событий.

Поэтому пока, как нам представляется, фокусные заказчики для Open Source SIEM – это либо небольшие компании с ограниченным набором источников событий, либо, наоборот, – очень большие игроки рынка, которые могут содержать свой штат специалистов для адаптации и обслуживания Open Source решений.

Олег Бакшинский.: За весь наш многолетний опыт мы не видели подобных точек взаимодействия, разве что порой Open Source SIEM-решения пытаются продавать под видом коммерческих продуктов. Однако это незначительный процент рынка, который в остальном поделен между основными производителями корпоративного ПО. Большинство заказчиков уже давно осознали большую совокупную стоимость владения «бесплатными» Open Source решениями и риски, связанные с отсутствием поддержки таких продуктов.

Евгений Афонин: Я предлагаю посмотреть на вопрос несколько с другой стороны: как правило, специалисты, которые способны самостоятельно развивать Open Sourсe SIEM, обладают достаточно хорошей квалификацией и высоко ценятся. В условиях традиционного кадрового голода в ИБ/ИТ это приводит к тому, что они привлекаются для решения более приоритетных задач.

Алексей Горелышев: По нашим оценкам, сейчас 95% крупных заказчиков используют коммерческие продукты. Основной причиной такого выбора является наличие поддержки системы при отсутствии необходимости иметь собственных специалистов высокого класса по работе с SIEM. Решения Open Source в этом проигрывают: никто не отвечает за их надёжность, не обещает настройку и поддержку, некому предъявить проблемы.

тя есть еще 5% крупных клиентов, которые используют Open Source SIEM: обычно это связано с решением частных задач, требующих специальной настройки. В этом случае «открытый код» помогает, но только при наличии квалифицированного персонала. Кроме того, Open Source использует средний и малый бизнес, который не хочет или не может тратиться на коммерческое решение.

Что касается точек соприкосновения, можно заметить, что несколько успешных решений Open Source приобретены корпоративным бизнесом, который развивает их и в платных продуктах. Это, например, OSSIM (AlienVault), Cassandra (DataStax), Snort (Cisco), OpenSOC (Cisco), Elastic (ELK).

Евгений Афонин: Как правило, 1–2 раза в год объявляется кампания по бета-тестированию. Наши коллеги из-за океана с должным вниманием относятся к отечественному рынку и, несмотря на ограниченность мест, нам пока удавалось включать в кампанию наших клиентов и партнеров в России. Например, в текущем году мы провели 2 бета-теста наших продуктов – HP ArcSight ESM и HP ArcSight Logger. Это позволяет партнерам лучше подготовиться к появлению новых версий наших решений на рынке, быть более оперативными в части подготовки предложений по расширенным возможностям наших продуктов. Кроме того, это дает возможность напрямую транслировать свое мнение разработчикам, поскольку участники бета-теста общаются с ними, минуя техподдержку или наших продакт-менеджеров.

Алексей Горелышев: К тестированию бета-версий MaxPatrol SIEM привлекались и привлекаются ключевые партнеры нашей компании, крупнейшие игроки на рынке ИБ. Практически у всех наших авторизованных партнеров по решениям класса Enterprise в рамках собственных лабораторий существуют стенды. Они используются как для пробных тестирований продуктов, так и для обучения собственных сотрудников, а также для демонстрации решений ключевым заказчикам.

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

Александр Чигвинцев: Естественно, наши партнеры перед установкой новых версий Security Analytics своим заказчикам проводят их тестирования в своих тестовых зонах. При возникновении проблем они могут открывать заявки на техподдержку в RSA. Иногда эти заявки трансформируются в предложения по развитию функционала решения (Enhancement requests).

Михаил Чернышев: Все партнеры и заказчики имеют право регистрации в наших многочисленных бета-программах. В их ходе участники получают доступ к дистрибутивам и документации, регулярные обновления по сценариям тестирования и форму обратной связи, которая затем анализируется руководителями по разработке. Замечания и пожелания, сформированные в течение бета-тестирования, учитываются и при необходимости включаются в релиз.

Если партнер или заказчик чувствует необходимость в новой функции или доработке продукта, он имеет право на создание запроса на улучшение. Всем запросам обязательно назначаются ответственные менеджеры, далее в порядке приоритета они включаются в те или иные релизы. Разумеется, ничто не мешает завести и экзотический запрос, в таком случае система отслеживания запроса обязательно оповестит незадачливого автора о невозможности встроить неординарную функцию в неприспособленный для этого продукт.

Олег Бакшинский: Специальную статистику в этой области мы не ведем. В России немного интеграторов, готовых тратить ресурсы на полноценное участие в такого рода тестировании. Мы чаще наблюдаем более активное участие конечных заказчиков, которые действительно заинтересованы в появлении нового функционала и внесении предложений по его реализации. Механизм их воплощения в жизнь стандартный и полностью зависит от выявленных замечаний, приоритетности задач в команде разработчиков и существующего плана развития продукта.