Поговорив позавчера про структуру затрат на услуги коммерческих SOCов, сегодня я бы хотел обратиться к теме их монетизации и лицензирования (но лицензирования не в контексте ФСТЭК или ФСБ). Эта заметка больше будет интересна для тех, кто строит свой SOC и хочет на нем зарабатывать, но так как таких компаний становится все больше, аудитория у поста не будет совсем уж узкой. Да и то, что SOCи сегодня запускают и внутри групп компаний и хотят вывести их на самоокупаемость тоже означает, что вопрос монетизации центров мониторинга может быть интересен гораздо более широкой аудитории. В конце концов, всегда хочется знать ответ на вопрос «Почему так дорого?» 🙂
Итак, моделей ценообразования и монетизации SOCов существует немало и их выбор зависит от множества факторов и, в первую очередь, от стратегии развития (если мы говорим о заработке, то стратегия его получения должна быть). Одно дело — желание срубить денег по-быстрому и совсем другое — постепенный рост. Одно дело — желание обойти конкурентов (тут и демпингануть можно) и совсем другое — создание гибкой и надежной базы для роста. Одно дело — продемонстрировать результаты в первые 4-6 месяцев и совсем другое — планировать выход на прибыльность года через 3-4. Ответив на эти вопросы, вы сможете сориентироваться в направлении, которое вы можете взять за основу.
Итак, первый и один из самых распространенных вариантов — это ценообразование исходя из количества и типа устройств, которые берутся на мониторинг и, возможно, управление. Модель проста и понятна всем участникам процесса. Под устройством обычно понимается средство сетевой безопасности (IPS, NGFW, WAF, маршрутизатор и т.п.).
Соответственно на мониторинг отдаются в первую очередь пассивные средства защиты (в рамках концепции активной обороны ), установленные на периметре. Они почти не требуют участия человека в своей работе и, будучи настроенными один раз, просто отдают свои события в SOCaaS и принимают из него обновления решающих правил (сигнатур, ACL и т.п.). В перспективе на аутсорсинговый SOC можно заводить средства активной защиты, требующие внимания человека — EDR/NDR/XDR, DLP, UEBA и т.п. и установленные преимущественно внутри инфраструктуры (что требует некоторого пересмотра раздела гарантий и ответственности).
Схожая модель — по числу источников логов или числу оконечных устройств. В первом случае за точку отсчета мы берем именно источник телеметрии, которых на одном узле может быть более одного (например, на сервере СУБД это могут быть логи от ОС, СУБД и EDR). Во втором случае мы считаем по числу ПК. Этот принцип привычен для производителей антивирусов, EDR и т.п. ИБ-решений.
Модель «по EPS» (events per second) или «по FPS» (flows per second) также популярна, так как базируется на модели лицензирования, принятой во многих SIEM, который является ядром многих аутсорсинговых SOCов. Она понятна для них, но регулярно вызывает проблемы с калькуляцией у заказчиков, которые вынуждены каким-то образом считать EPS/FPS для использования у себя устройств и приложений, что является не такой уж и тривиальной задачей. Да, у провайдеров услуг SOC бывают калькуляторы со средними значениями EPS, но они могут отличаться от ваших значений. При этом у вас могут измениться значения по ходу мониторинга. Например, вы рассчитываете стоимость SOCaaS для мониторинга сетевого оборудования Cisco и берете в расчет 4-й уровень регистрации событий (warnings) из 8 существующих. Но в процесс расследования инцидентов от вас могут потребовать включить 7-й уровень (debugging), что сразу изменить объем передаваемых сообщений из журнала регистрации.
Схожий с лицензированием по числу ПК или устройств вариант — по числу сотрудников, но он не пользуется большой популярностью в SOCах. Хотя в компаниях, в которых каждый работник имеет свое устройство — это могло бы быть вполне удобным и понятным инструментом расчета. Интересным, для заказчика, видится вариант лицензирования по числу инцидентов, но заранее предсказать их число достаточно сложно и поэтому такой вариант не любят SOCостроители. Хотя тут можно было бы привести аналогию с мобильной связью — вам предлагают некий усредненный тариф (допустим, 10 инцидентов в день), а все, что сверх нормы тарифицируется по завышенным ценам. Это будет снижать нагрузку на SOCaaS и стимулировать вас лучше заниматься ИБ, чтобы не платить за каждый инцидент «сверх лимита».
Наконец, возможна схема, которая иногда применяется поставщиками услуг борьбы с DDoS или услуг по реагированию на инциденты (IRR или DBRS), когда вы платите только за используемые услуги в момент реализации у вас инцидента. Это интересная услуга и она была бы интересна заказчикам, но поставщикам услуг SOC она не очень выгодна, так как требует от них все равно затрат, которые могут быть и не возмещены заказчиком, если у него не происходит ни одного инцидента.
Также на ценообразование может влиять и сезонность доходов / расходов заказчиков, но это уже точно выходит за рамки небольшой заметки.
А вот то, что обязательно надо отметить, — это вариант использования разных уровней обслуживания по примеру «золотого», «серебряного» или «платинового» уровней обслуживания в авиакомпаниях, в гостиницах и т.п. На самом деле это делается только для того, чтобы заставить клиента платить больше или для тех клиентов, которые хотят ощущать свою важность. Им присваивается некий статус, который они и оправдывают, платя больше.
Давайте честно признаемся себе, что деньги делаются на простых, понятных, типизированных и легко масштабируемых услугах.
Они обычно и включаются в некий базовый пакет, которые и продается «как пирожки». Все остальные «вишенки на торте» — требуют от коммерческого SOC дополнительных усилий и часто не оправданы с экономической точки зрения. Поэтому, следуя заветам гуру маркетинга, обычно создается несколько тарифов, в которых самый базовый малоинтересен, но позволяет «попробовать» (хотя в SOCaaS триалы не практикуются), а самый дорогой рассматривается как нечто недостижимое, но показывающее крутизну центра мониторинга. Заказчики обычно берут средний вариант, считая, что это их выбор, хотя на самом деле это и не так.
В реальности, эти тарифные планы являются скорее неким началом разговора, так как клиент часто хочет немного отсюда, немного оттуда, и на выходе получает персонализированный тариф, который, конечно, дороже стандартного пакета (за эксклюзив и персональное отношение надо платить).
Вспоминая заметку про цену чашки кофе, хочу вспомнить еще одну историю.
По данным Госкомстата прибыль чашки кофе на АЗС соответствует прибыли с 6 (!) литров проданного бензина. АЗС вынуждены продавать топливо с минимальной наценкой и часто получают прибыль от реализации сопутствующих товаров, а не от продажи бензина, дизеля или газа.
Такая история может быть и в SOCах и вам могут навязывать различные дополнительные услуги, которые и будут приносить владельцу SOCа основные деньги. Возможно, эти услуги вам и нужны, но возможно и нет. Тут вы должны сами думать о том, что из ваших хотелок действительно вам нужно, а что можно отложить до лучших времен или сделать своими, более дешевыми силами.
Заметка Модели монетизации SOC или как разработать тариф на мониторинг ИБ? была впервые опубликована на Бизнес без опасности .
