В 28-м выпуске Belyaev_Podcast эксперты обсудили vendor lock-in в информационной безопасности: почему привлекательная цена на старте может обернуться дорогим продлением, что происходит с данными и правилами корреляции при смене SIEM или SOC и как заранее проверить возможность перехода на другое решение. Гостем выпуска стал Максим Степченков, генеральный директор IT Task и RuSIEM. Соведущей выступила Ева Беляева, руководитель отдела разработки продуктов Security Vision, а ведущим бессменно остается Дмитрий Беляев. «Компьютерра» — медиапартнер Belyaev_Podcast.
Зависимость от поставщика формируется постепенно. После нескольких лет эксплуатации компания успевает настроить интеграции, обучить сотрудников, накопить правила и встроить продукт в ежедневные процессы. Когда приходит время продлевать договор или менять систему, стоимость перехода складывается уже из гораздо большего числа факторов, чем цена новой лицензии.
По словам участников выпуска, оценивать такой риск стоит еще при выборе решения. Важны форматы хранения данных, документация интеграций, возможность переноса настроек, условия долгосрочного продления и объем работы, который компания сможет продолжить самостоятельно после завершения договора.
Скидка на старте может ничего не говорить о стоимости через несколько лет
Отдельно участники разобрали ценовую зависимость. Дмитрий Беляев рассказал о случае, когда поставщик выиграл тендер благодаря низкой стартовой цене, а уже через год стоимость продления выросла в два–два с половиной раза. Эти расходы заранее в бюджет не закладывались, поэтому компании пришлось срочно искать альтернативу.
Максим Степченков предложил еще до покупки запрашивать стоимость владения на три–пять лет и по возможности фиксировать условия в договоре. По его словам, в практике IT Task были заказчики, которым цену закрепляли сразу на пять лет.
«Скидка — это зачастую ловушка».
Максим Степченков
Для заказчика здесь важна предсказуемость. После внедрения у компании уже есть интеграции, обученная команда и настроенные процессы, а значит, переговоры о продлении проходят совсем с другой позиции. Переход на альтернативу к этому моменту может потребовать дополнительных денег и времени.
API еще не гарантирует простой переход на другую систему
Ева Беляева назвала тревожным признаком закрытые интеграции и отсутствие технической документации. Если поставщик обещает быстро подключить продукт к существующей инфраструктуре, эти возможности стоит проверить во время пилота.
Особенно это заметно на примере SIEM. Даже если правила корреляции можно экспортировать, перенести их в другую систему без доработки удается далеко не всегда. У разных платформ свои языки описания правил, форматы данных и логика обработки событий.
«Если у вендора вообще ничего не описано, и вендор просто на словах говорит, что там все просто, все легко подключается, сразу подружимся — скорее всего, что-то там не так идет».
Ева Беляева, руководитель отдела разработки продуктов Security Vision
Участники предлагают проверять сценарий выхода еще на этапе пилота: можно ли выгрузить данные в читаемом виде, перенести правила и сценарии, заменить отдельный компонент и продолжить работу остальных систем.
Максим Степченков также рассказал о проектах, где две SIEM некоторое время работали параллельно. Такой переход позволяет проверить новую платформу до отключения действующей. Временная схема при этом требует отдельного контроля, поскольку промежуточные интеграции иногда остаются в инфраструктуре гораздо дольше запланированного.
При смене SOC можно потерять накопленную экспертизу
Отдельная часть выпуска была посвящена внешним центрам мониторинга безопасности. За годы работы SOC накапливает историю инцидентов, правила корреляции, материалы расследований и знания об особенностях конкретной инфраструктуры.
Степченков рассказал о случаях, когда после прекращения договора у заказчика возникали сложности с получением накопленных данных и правил. Во многом такие ситуации зависели от того, как стороны изначально оформили условия сотрудничества.
Ева Беляева уточнила, что модели работы внешних SOC различаются. Исполнитель может работать непосредственно в инфраструктуре заказчика, используя его системы и ресурсы, поэтому сам факт привлечения внешней команды еще не определяет судьбу накопленных материалов.
Для компании важнее заранее закрепить, кто владеет логами, историей инцидентов, созданными под нее правилами и документацией, а также как будет проходить передача информации при смене исполнителя.
Критичность системы зависит от последствий ее отключения
Участники также поспорили о том, где vendor lock-in наиболее опасен. Ева Беляева выделила SOAR, поскольку такая платформа связана со множеством средств защиты и со временем начинает влиять на архитектуру всей экосистемы. Максим Степченков предложил оценивать системы по тому, что произойдет с бизнесом при их отключении.
В случае SOAR часть работы некоторое время можно выполнять вручную. Однако Дмитрий Беляев обратил внимание на другой риск: компания могла уже сократить объем ручной работы и численность команды благодаря автоматизации. Тогда отключение платформы резко увеличит нагрузку на оставшихся специалистов.
Такой подход позволяет оценить зависимость практичнее. Компания должна понимать, какие процессы остановятся сразу, что сотрудники смогут временно делать вручную, сколько ресурсов для этого понадобится и как долго организация выдержит подобный режим.
Возможность сменить поставщика стоит проверять заранее
Участники выпуска сошлись в том, что глубокая интеграция с одним поставщиком сама по себе не означает ошибочного решения. Единая экосистема может упростить эксплуатацию, поддержку и взаимодействие между продуктами.
Риск появляется в тот момент, когда компания уже не может сравнивать варианты из-за слишком высокой стоимости перехода. Поэтому к цене лицензии стоит сразу добавлять стоимость выхода: перенос данных, замену интеграций, обучение сотрудников и возможный период параллельной эксплуатации двух решений.
Выпуск №28 Belyaev_Podcast «Vendor Lock-in: как заказчика запирают в экосистеме. Как выйти?» доступен на нескольких площадках: