С того момента как я начал изучать концепции, тактики и модели построения информационной безопасности, то стал всё чаще и чаще цепляться за несоответствие концепций и продуктов. Многие компании-разработчики отечественных продуктов начинают смешивать понятие продукта (по сути, инструмента для решения конкретной задачи в рамках реализации той или иной концепции) и тактики построения ИБ. Как пример, могу привести пример, когда EDR описывают, как инструмент реализации концепции ZTNA, не указывая на то, что EDR позволяет реализовать активной обороны (в основе лежит публикация "Убийственной цепочки" от компании Lockheed Martin). Да, данный класс может стать базисом, вокруг которого можно начать строить ZTNA, но ни в одной стать нет упоминания о едином агента, который может вобрать в себя весь функционал разрозненного зоопарка решений информационной безопасности - агента платформы ИБ.

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

Что общего у Google, Snapchat, Tinder, Amazon и Uber? Все они - платформы, представители бизнес-модели, которая последние 10 лет приносит своим владельцам огромную прибыль. Суть платформы в том, что она создает не продукт, а экосистему, с помощью которой легче открыть новый бизнес, а продавцу и покупателю удобнее взаимодействовать. Платформы захватили интернет: на долю Facebook приходится 25% всех посещений глобальной сети, а Google обеспечивает почти 40% интернет-трафика. Однако этот масштаб пока оценили не все. Авторы рассказывают о том, что изменилось в структуре современного бизнеса, как это влияет на работу компаний и как предпринимателям и руководителям адаптироваться и процветать в новых экономических условиях.

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

Отличный пример платформы ИБ - Cisco SecureX.

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

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

Почему сегодня в России не видно вендора, способного в одиночку развернуть полноценную экосистему ИБ

1. Ширина продуктового портфеля, которой пока нет ни у кого
   Экосистема - это не только NGFW или EDR: нужны собственные решения для identity, ZTNA-шлюзов, SASE-PoP-ов, облачного CASB, OT-мониторинга, CTI-фидов, оркестрации, ML-аналитики и маркетплейс сторонних модулей. Российские игроки сильны максимум в двух-трёх сегментах (пример: UserGate активно расширяет линейку, но до полного стека пока далеко).

2. Капитал и горизонты инвестиций
   По оценкам крупных системных интеграторов, создание ядра + SaaS-операторских мощностей требует 8-10 млрд ₽ и 3-5 лет R&D без мгновенной окупаемости. Даже гигантам с гос-долей сложнее «заморозить» такие деньги, когда рынок просит быстрые «железные» замены индивидуальных решений.

3. Дефицит кадров и экспертизы «сквозь стэк»
   Нехватка специалистов ИБ в РФ уже превышает 70 тыс. человек; компании нанимают людей «на поддержку» существующих коробок, а не на архитектуру новой платформы. Это подтверждает и статистика рынка Zero Trust: интерес растёт, но реальные внедрения единичны.

4. Гос-регуляторика и сертификация
   Любое «ядро» придётся вести через ФСТЭК/ФСБ: минимум год, дорого, с риском реверта требований. Для «открытой» экосистемы задача усложняется - сертифицировать придётся не только ядро, но и механизм подключения внешних плагинов.

5. Фрагментированный заказчик: «сначала закрыть дыру, потом думать о стратегии»
   После ухода зарубежных поставщиков бизнес закупает точечные аналоги; перестройка под платформу откладывается «на потом». Отсюда — слабый спрос на масштабную экосистему и низкая готовность со-инвестировать в её развитие.

6. Сетевой эффект работает против одиночек
   Чтобы ценность маркетплейса была очевидна, нужно 5-7 крупных партнёров и десятки плагинов. Партнёры же не пойдут, пока нет трафика. Разорвать порочный круг в одиночку трудно; на Западе это делали консорциумы или лидеры глобального масштаба, которых в РФ пока нет.

7. «Облако» как обязательный слой, а облачный рынок расколот
   Экосистеме нужен распределённый облачный слой (PoP-ы, CDN--security edge). Российский облачный ландшафт после 2022 г. также фрагментирован: федеральные ИТ-гиганты строят каждый свою платформу и вряд ли уступят её под контроль одного ИБ-вендора.

Исходя из этих причин я считаю, что наиболее логичный шаг в развитии ИБ - это создание открытой платформы, которая позволит объединить решения различных вендоров для обеспечения наилучшего сервиса.

И тут на сцену выходит открытая платформа ИБ: общий, проверяемый всеми фундамент, к которому подключаются компоненты любого производителя - от коммерческих до совсем открытых проектов.

Платформенная бизнес-модель: как «open» превращается в деньги

Открытый исходный код вовсе не значит бесплатный бизнес. Большинство зрелых OSP-проектов используют open-core: базовое ядро и стандарты доступны всем, а коммерческая ценность создаётся надстройками и сервисами. Схематично денежные потоки выглядят так:

Почему модель работает

• Сетевой эффект. Чем больше сторонних коннекторов и плейбуков появляется в маркетплейсе, тем выше ценность ядра - классика двух-сторонней платформы library.wannabe.ru.

• Широкий TAM. Благодаря свободному ядру попробует даже стартап; вырастет — купит SaaS-хостинг или MDR.

• Снижение R&D-издержек. Комьюнити закрывает баги и пишет интеграции; вендор фокусируется на «премиум» поверх ядра ventureinsecurity.net.

• Прозрачность → доверие. Код открыт, независимые аудиторы легче проводят due-diligence безопасности перед сделкой.

• Гибкое ценообразование. От «pay-as-you-go» (Elastic) до «one license - all inclusive» (Stellar Cyber): заказчик выбирает модель под свой бюджет и риски.

Классическая «линейная» модель «продал коробку — забыл» устаревает: клиенту нужны обновления, интеграции и автоматизация, а не просто софт. Open Security Platform превращает поставщика ИБ из продавца точек контроля в оркестратора экосистемы, где ценность рождается во взаимодействии участников.

Что же такое Open Security Platform

Open Security Platform (OSP) - это архитектура кибербезопасности, в которой ядро кода и форматы данных доступны сообществу, а все функции (сбор, хранение, аналитика, реагирование) расширяются через открытые API и стандарты. В отличие от традиционной «платформы одного вендора», OSP по умолчанию рассчитана на многопродуктовую экосистему: любой разработчик может подключить свой сенсор, playbook или ML-модуль, не переписывая всё под закрытый SDK. Такой подход решает извечную боль SOC-команд, где десятки разрозненных инструментов «разговаривают» на своих диалектах и заставляют аналитика прыгать между экранами

Ключевые признаки

Где проходит граница «open»

·        Truly open - когда и код, и стандарты открыты, а вендор зарабатывает на value-add-сервисах (хостинг, ML, премиум-поддержка).

·        Pseudo-open — когда ядро проприетарное, а «открытость» сводится к платному SDK; при миграции компания всё равно попадает в lock-in Axios.

Почему нужны открытые стандарты

1.     Сокращают time-to-integrate. Поддержка OCSF или STIX/TAXII в новом продукте даёт «родной» диалог с существующим стеком.

2.     Упрощают аудит и due-diligence. Прозрачные форматы данных позволяют быстрее проверять соблюдение требований и искать аномалии.

3.     Питают автоматизацию. Когда все события описаны одинаково, движки XDR/ML видят полную картину и точнее ловят угрозы.

В результате Open Security Platform превращает «зоопарк» инструментов в единую экосистему: выбираем лучшие компоненты рынка, быстро скрещиваем их через открытые интерфейсы и остаёмся хозяевами своих данных - без боязни, что очередное закрытие API парализует безопасность.

Ключевые строительные блоки

Как блоки складываются в единую экосистему

1.     Сенсоры (Wazuh-агент, Zeek, облачные аудит-логи) пишут события сразу в формате OCSF.

2.     Data Lake (Elastic/ClickHouse) хранит нормализованный поток; XDR-слой читает оттуда «чистые» данные.

3.     Open XDR коррелирует, обогащает CTI-фидами по STIX/TAXII и генерирует детект.

4.     SOAR/Orchestrator формирует OpenC2-команды, рассылая их в сетевые/облачные контроллеры.

5.     Маркетплейс расширений добавляет новые коннекторы, playbook’и и ML-модули, не ломая основные стандарты.

Такой набор стандартных «кирпичей» даёт гибкость Lego: можно заменить любую деталь (анализатор, lake, SOAR) — всё остальное продолжит работать на открытых интерфейсах.

Почему компаниям в РФ выгодно развивать открытую платформу ИБ

1.1 Импортозамещение без компромиссов

Санкции бьют по лицензиям, обновлениям и поддержке. Когда у вас прослойка API, а не жёстко спаянный стек, заменить модуль DPI или EDR можно без «глубокого вскрытия».

1.2 TCO ↓ за счёт стандартизированной интеграции

Бюджет ИТ-безопасности на 30–40 % уходит в «нестандартные коннекторы» и поддержку устаревших схем обмена. Общие протоколы (gRPC, OpenTelemetry, STIX/TAXII) убирают эту строку почти полностью.

1.3 Единый слой данных → более быстрый SOC

Когда все логи и события поступают в единую схему, корреляция «VPN-подключение → попытка AWS STS → скачивание S3» собирается SQL-запросом, а не шестью парсерами.

1.4 Сертификация «ядра», а не каждой коробки

В ФСТЭК/ФСБ можно принести одно ядро, а плагины проверять выборочно. Это реальная экономия сроков на Project Gate и ГОСТ-тесты.

1.5 Рынок кадров

Открытый SDK + документация = «массовая профессия инженер платформы ИБ», а не элитарный клуб «коробочных» специалистов.

Переход. Разобрались, зачем это бизнесу. Но что ждёт создателя платформы? Перейдём на сторону разработчиков.

Плюсы и подводные камни для разработчика платформы

Плюсы и подводные камни для разработчика платформы

Плюсы

1.     Широкий рынок. Каждая компания, строящая Zero Trust-архитектуру, ваш потенциальный клиент.

2.     Эффект сети. Чем больше партнёров и плагинов, тем выше ценность ядра — классическая платформа «chicken-and-egg» стратегия.

3.     Данные как топливо. Общий даталейк даёт уникальные наборы telemetry для обучения защитных ML-моделей.

4.     Господдержка. Проекты с импортозамещением и открытыми API легче получают субсидии и гранты.

Подводные камни

1.     Долгий путь до критической массы. Без стока интеграций платформа «не звучит», а партнёры не спешат тратить ресурсы первыми.

2.     Поддержка обратной совместимости. Каждая эволюция API = потенциальный риск поломать чужие плагины.

3.     Бремя сертификаций. Разработчик ядра отвечает за уязвимости третьих лиц, если они проходят через общий контур.

4.     Конкуренция с собственными партнёрами. Рано или поздно придётся выбирать, чей модуль продвигать на витрине.

Экосистемные уровни зрелости

Когда знаете свой уровень, можно прописать роад-мап и бюджет. Осталось понять, зачем всё это прямо сейчас.

Подытожить хотелось бы такими собственными размышлениями на этот счет.

Современные стратегии Zero Trust и ZTNA, активная оборона, киберустойчивость - это не «коробочные» продукты, а архитектурные подходы. Тем не менее на рынке продолжают появляться описания EDR-систем как якобы готовых «ZT-платформ», что лишь усугубляет путаницу и заставляет компании складывать вокруг пользователя целый зоопарк агентов. Чем больше таких разрозненных инструментов, тем выше расходы на поддержку, тем сложнее расследовать инциденты и тем больше слепых зон остаётся в защите.

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

Проблема в том, что ни один российский вендор сегодня не тянет весь стек в одиночку. Чтобы платформа состоялась, понадобится союз крупных заказчиков, нескольких разработчиков и государственная поддержка - прежде всего в виде открытого стандарта передачи событий и политик, условного «ГОСТ-API». Без него любая «платформа» рискует остаться ещё одной закрытой экосистемой.

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

О дальнейших шагах, примерах пилотов и готовящихся спецификациях я регулярно пишу в Telegram: tt.me/zero_trust_SDP. Подписывайтесь, если хотите следить за тем, как из инструментального зоопарка постепенно складывается настоящая экосистема.