Почему лицензирование технологий - это не всегда хорошо с точки зрения ИБ

Не секрет, что получить новый продукт (и не только в ИБ) можно тремя способами - разработать самому, купить готовое, лицензировать технологию (или, как вариант, получить право на распространение чужого продукта под своим именем). Вот про последний вариант в контексте ИБ мне и хотелось бы поговорить, а точнее показать некоторые риски, которые надо учитывать при использовании данного сценария.

Лицензирование технологий - это популярный метод у разработчиков тех или иных технологий ускорить выпуск своего продукта на рынок. Далеко не всегда есть время, а иногда и компетенции на разработку функционала, который уже кто-то реализовал и готов им поделиться. Самый банальный вариант - использование open source компонентов при создании собственных решений. Кто-то берет целый Hadoop для своих решений, кто-то ограничивается обычной библиотекой OpenSSL. Результат один - мы задействуем чужие технологии в своих продуктах и затем предлагаем их заказчикам, которые обычно не сильно задумываются о том, из чего состоит купленное ими изделие и какие риски они должны учитывать при выборе ИБ-решений (да и ИТ тоже).

Возьмем уже старый, но близкий мне пример. Компания Cisco лицензировала у компании netForensics одноименную систему управления событиями безопасности, которую затем стала предлагать под новым именем Cisco SIMS (Security Information Management System). Мы ее некоторое время успешно продавали через свой канал продаж, но потом столкнулись с тем, что у компании netForensics сильно ухудшилась внутренняя ситуация - качество продукта снизилось, поддержка стала работать из рук вон плохо, число нареканий от заказчиков стало возрастать. А повлиять на чужой продукт мы были не в состоянии. Итог закономерен - мы прекратили сотрудничество с netForensics (с 2012-го года они переименовались в BlackStratus), а Cisco SIMS исчез из нашего прайс-листа. И для нас и для заказчиков риски были минимизированы, но ситуация все равно неприятная.

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

А теперь обратимся к отечественному рынку ИБ и посмотрим на сотрудничество “Код безопасности” с компанией Agnitum, которая лицензировала свои технологии и разрешила “Коду безопасности” встроить свой движок по борьбе с вредоносным кодом в Secret Net Studio. А потом компания Agnitum была куплена Яндексом, который не пожелал (и это его право) продолжать ранее заключенные договора лицензирования технологий Agnitum. Итог - “Код безопасности” потерял часть своего функционала и вынужден был в спешном режиме искать альтернативу, с которой все непросто. Антивирусный движок остался только один - зарубежный Nod32 от ESET, который не будет сертифицироваться в ФСБ и по высоким классам ФСТЭК. Модуль HIPS оказался потерян полностью и сейчас "Код безопасности" пытается написать его самостоятельно (что делать текущим пользователям - не совсем понятно).

Ситуация с “Кодом безопасности”, Agnutum и Яндекс не уникальна для российского рынка. Сейчас многие российские компании идут по пути лицензирования чужих (и не всегда российских) технологий. Кто-то WAF лицензирует, кто-то SIEM (например, OSSIM или ArcSight), кто-то антивирус (тот же Nod32), кто-то анализатор кода (например, Fortify), кто-то системы контроля доступа (какой-нибудь SSH Security Communications), кто-то системы управления идентификацией (например, Identity Manager). И дело тут не в отсутствии компетенций по разработке аналогичных решений. Просто в условиях, когда страна декларирует курс на импортозапрещение, зарабатывать на западных решениях становится сложнее, а ниша, в которую могут потечь денежные потоки, не уменьшается. Логично что у ряда разработчиков возникает идея по-быстренькому сваять “российский” продукт на базе уже имеющихся технологий (западных или отечественных). Я уже как-то писал про то, что это не совсем импортозамещение, но сейчас мне хотелось рассмотреть эту проблему под другим углом зрения.

Что будет, если разработчик приобретаемой технологии “загнется” или будет куплен более крупным игроком, который не захочет развивать это направление своей деятельности? Что будет делать производитель, использующий чужие технологии? А что будет делать потребитель? Вот возьмем, к примеру, Attack Killer от Infowatch. Продукт, который базируется на решениях четырех разных компаний - Infowatch Appercut, Infowatch Targeted Attack Detector (решение от Cezurity), Wallarm WAF и Qrator AntiDDoS. Когда в Интернет утек черновик этой статьи, Рустем Хайретдинов накидал мне еще фактов про Attack Killer, поэтому просто процитирую его: "На самом деле всё гораздо хуже - внутри Апперката есть SQLite, а внутри Валларма - ngnix. InfoWatch Traffic Monitor содержит десятки лицензируемых компонентов - СУБД Oracle или PostgreSQL на выбор, голосовые перехватчики от ЦРТ, OCR от ABBY, а скоро ещё и КППС, и т.п. Апперкату ещё сложнее - он пишется на Java, который принадлежит Oracle, который грозится запретить его лицензирование." Допустим, Wallarm, активно смотрящий на Запад, будет там куплен каким-нибудь IBM, Dell или Cisco, не имеющих в своем портфолио Web Application Firewall. Или Oracle все-таки запретит лицензирование Java Как это скажется на Attack Killer? Рустем пишет, что этот риск проработан на уровне договоров и там где это возможно, существуют резервные/дублирующие технологии. Тот же Oracle может быть заменен на PostgreSQL. В любом случае это тот риск, который стоит рассматривать до приобретения решения, а не после.

Но это не единственный риск лицензируемых технологий. Другой вопрос заключается в устранении уязвимостей в них. Тут впору вспомнить историю с уязвимостью Heartbleed в библиотеке OpenSSL, на базе которой построено немалое количество продуктов в мире, включая и российские. Среди них были и сертифицированные по требованиям ФСТЭК решения. И когда ФСТЭК обратилась к их разработчикам с просьбой сообщить об устранении серьезной дыры в сертифицированных решениях часть разработчиков ответила, что не имеет возможности Heartbleed устранить, так как у них нет компетенций в этой области, а код чужой и копаться в нем они тоже не умеют. История умалчивает, что стало с сертификатами на эти решения, но умалять от этого проблему не стоит. Если продавец не может устранить уязвимость в применяемых чужих open source компонентах (OpenSSL, Kibana, Elasticsearch, Hadoop, OSSIM, Snort и т.п.), то как это скажется на безопасности потребителя? Это второй из возможных рисков, о котором стоит, как минимум, помнить.

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