Привет, Хабр! В декабре у нас завершилась программа экспортной акселерации Global Partners Program. Несколько месяцев совместно с Московским экспортным центром мы помогали 15 b2b-стартапам подготовиться к выходу на рынки Азии и Латинской Америки. И сегодня хотим познакомить вас с одним из выпускников – CyberLympha. Это стартап в сфере ИБ, который развивает ПО CL DATAPK: продукт обеспечивает видимость всех элементов сети АСУ ТП предприятия и предоставляет исчерпывающую информацию по их состоянию. Это решение для мониторинга безопасности промышленных сетей применяется в нефтегазовой, энергетической, производственной, металлургической, химической отраслях и в системах умного города.

Теперь компания, в которой 30 сотрудников, планирует вывести разработку на рынки стран APAC и в частности Сингапура, где уже приняла участие в конференции GovWare. О масштабировании бизнеса и подробном устройстве продукта рассказала сама команда. Добро пожаловать под кат.

— Не могли бы вы как можно детальнее объяснить, как устроена ваша разработка? Какая схема, какие подсистемы?

CL DATAPK — это программное обеспечение, работающее на базе ОС семейства Linux, в том числе и сертифицированных версий. Код продукта проприетарный. Общая схема выглядит примерно так:

CL DATAPK — модульное решение, построенное на микросервисной архитектуре. Это позволяет CL DATAPK выполнять сразу полный комплекс функций, присущих системам мониторинга ИБ, легко масштабироваться и, что наиболее важно, обеспечивать безопасность взаимодействия с защищаемой системой.

В составе решения имеются следующие подсистемы:

• Взаимодействия с пользователем – графический пользовательский web-интерфейс для работы с продуктом, в котором также реализована политика управления доступом – все действия пользователей в CL DATAPK регистрируются и сверяются с прописанными для учетной записи полномочиями;

• Анализа данных – здесь сосредоточены основные сервисы, обрабатывающие данные мониторинга:

  • ведение каталога объектов защиты (т.е. сетевых узлов защищаемой системы) – каталог позволяет систематизировать все компоненты АСУ ТП, указать различную информацию о них (например, физическое расположение или к какой конкретно системе относится объект). Также каталог снабжен интерфейсами для поиска объектов по любым параметрам. Кроме того, для каждого объекта осуществляется сбор его конфигурации (с которой также можно ознакомиться через интерфейс пользователя) и сравнение текущей конфигурации с эталоном – это позволяет выявить следы каких-то несанкционированных действий (например, кто-то взял и создал дополнительную административную учетную запись в системе – такое событие явно требует реакции со стороны подразделения, ответственного за обеспечение ИБ).

  • управление событиями ИБ – этот модуль отвечает за обработку событий, полученных от объектов защиты: нормализацию (т.е. приведение события к общему формату), корреляцию (т.е. поиск определенных шаблонов в потоке событий, описываемых специальными правилами). Также этот модуль обеспечивает хранение событий с возможностью поиска по всему массиву событий;

  • анализ трафика – этот модуль реализует как традиционный поиск сетевых атак на основе базы сигнатур атак, так и анализирует состав информационных потоков между объектами защиты. Каждый информационный поток может быть одобренным (т.е. известным системе на основе описанного правила или явного указания оператора), неодобренным – т.е. это новый информационный поток, который не описан правилами и неизвестен оператору. Такой поток может быть признаком несанкционированных действий в системе. И есть промежуточный вариант, когда поток одобряется только на время: например, при проведении каких-то работ в системе оператор может временно одобрить потоки по протоколу SSH от рабочей станции администратора к компонентам системы, а когда работы будут завершены – появление нового потока с протоколом SSH уже будет считаться признаком инцидента ИБ;

  • поиск уязвимостей и оценка соответствия – собранные конфигурации объектов защиты могут быть также проанализированы на предмет наличия в них известных уязвимостей или небезопасной конфигурации. Для этого используются описания уязвимостей или шаблоны безопасной конфигурации на языке OVAL. OVAL – открытый стандарт, поэтому можно использовать различные источники с описаниями уязвимостей или правил безопасности конфигурации. В частности, банк данных угроз и уязвимостей ФСТЭК России публикует свою базу уязвимостей не только в текстовом виде, но и в виде набора описаний на языке OVAL.

• Сбора данных объектов защиты и анализа трафика. CL DATAPK использует два основных канала получения информации о защищаемой системе: это пассивное прослушивание трафика и активный сбор информации непосредственно с различных устройств. Пассивное прослушивание трафика дает значительно меньше информации о системе, но такой метод гарантирует отсутствие любого влияния со стороны CL DATAPK на защищаемую систему. Собранный трафик анализируется с помощью модуля глубокой инспекции пакетов (Deep packet inspection – DPI), что позволяет выделить в нем различную полезную информацию: реквизиты объектов защиты (в том числе, выявление ранее неизвестных объектов), события, передаваемые объектами по сети, информационные потоки. Однако наиболее полный состав функций CL DATAPK реализует, когда используется активный сбор данных с объектов защиты. Для этого CL DATAPK содержит ряд коннекторов – специальных программ, реализующих подключение к объекту защиты по одному из протоколов удаленного доступа (SSH, WMI, SQL и пр.). Для самого сбора данных в CL DATAPK реализованы сценарии, которые используют соответствующий коннектор, а также сведения о параметрах доступа к объекту (в том числе логин и пароль). Запуском сценариев управляет модуль активного сбора данных, он же отвечает за проверку целостности сценария – каждый сценарий сбора данных снабжен электронной подписью, чтобы злоумышленник не мог его исказить и заставить вместо сбора данных нанести какой-то прямой вред объекту (например, удалив важные для работы объекта файлы).

Собственная безопасность CL DATAPK – это основной приоритет разработки продукта. Недопустимо, чтобы средство, призванное обеспечить безопасность, вдруг само становилось слабым звеном, через которое злоумышленник взломает всю систему. Электронные подписи сценариев – это один из таких механизмов. Также в CL DATAPK реализована специальная защищенная база данных, где хранятся учетные записи для доступа к объектам защиты – получить их из этой базы может только модуль активного сбора данных. Это сделано для того, чтобы даже если злоумышленник каким-то образом сможет взломать подсистему взаимодействия с пользователем, то он все равно не сможет добраться до защищаемой системы: получить учетные данные для допуска ему не позволит сервис, обслуживающий защищенную базу данных, а изменение сценариев сбора данных приведет к тому, что они просто перестанут выполняться.

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

Посмотрим немного на реализацию концепции монитора безопасности в CL DATAPK.

Общая схема аутентификации и авторизации запросов пользователя выглядит следующим образом:

Основным протоколом взаимодействия пользователя и серверной части CL DATAPK является протокол HTTPS. Минусом этого протокола является отсутствие встроенного понятия сеанса, но с другой стороны это автоматически позволяет реализовать главное свойство монитора безопасности – его непрерывность (т.е. при каждом обращении пользователя это обращение должно проходить через монитор безопасности).

В случае CL DATAPK все REST-запросы обрабатываются сервером NGINX, вот так:

location /api/v1/exporter/ {
   proxy_pass              http://exporter/;
   auth_request            /auth_backend/nginx_authorization;
   auth_request_set        $error_message $upstream_http_x_error_message;
   auth_request_set        $auth_user_id $upstream_http_x_auth_user_id;
   auth_request_set        $auth_user_login $upstream_http_x_auth_user_login;
   auth_request_set        $auth_user_name $upstream_http_x_auth_user_name;
   auth_request_set        $auth_user_surname $upstream_http_x_auth_user_surname;
   auth_request_set        $auth_user_patronymic_name $upstream_http_x_auth_user_patronymic_name;
   auth_request_set        $action_object $upstream_http_x_action_object;
   proxy_set_header        X-Auth-User-Id $auth_user_id;
   proxy_set_header        X-Auth-User-Login $auth_user_login;
   proxy_set_header        X-Auth-User-Name $auth_user_name;
   proxy_set_header        X-Auth-User-Surname $auth_user_surname;
   proxy_set_header        X-Auth-User-Patronymic-Name $auth_user_patronymic_name;
   proxy_set_header        X-Request-Id $request_id;
   proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
   error_page 401 403      /auth_backend/nginx_auth_failed;
}

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

{'object_name': 'exporter.catalogs.status', 'action_names': ['GET']},
{'object_name': 'exporter.export.catalogs', 'action_names': ['GET']},
{'object_name': 'exporter.export.catalogs.tar', 'action_names': ['POST']},
{'object_name': 'exporter.export.catalogs.file', 'action_names': ['POST']},
{'object_name': 'exporter.files.delete', 'action_names': ['POST']},
{'object_name': 'exporter.import.catalogs.tar', 'action_names': ['PUT']},
{'object_name': 'exporter.import.catalogs.file', 'action_names': ['PUT']},
{'object_name': 'exporter.report', 'action_names': ['GET']},

Если в результате авторизации монитор безопасности приходит к выводу, что действие должно быть разрешено — запрос перенаправляется в соответствующий бэкэнд (например, каталог объектов защиты), в противном случае пользователь получает стандартную ошибку 403 (запрещено). И, конечно же, каждое действие (разрешенное или запрещенное) может быть сохранено в журнал событий CL DATAPK.

— За счет чего CL DATAPK обеспечивает видимость всех элементов сети АСУ ТП предприятия?

В основе подхода лежит работа с несколькими источниками данных о защищаемой системе:

• копия сетевого трафика, получаемая с зеркалирующего порта;

• конфигурации компонентов АСУ ТП, собираемые безагентным методом;

• события, происходящие на компонентах АСУ ТП, также собираемые безагентным методом.

Эти источники позволяют получить представление не только о топологии сети АСУ ТП, количестве и типах конечных устройств, подключенных к ней, но и об их аппаратной и программной конфигурациях, а затем отслеживать изменения в системе и оперативно реагировать на них. Корреляция событий из разных источников помогает предоставлять операторам наиболее полную информацию об инциденте, чтобы сократить время, необходимое для расследования и принятия компенсационных мер.

— Как CL DATAPK используется для построения SOC (Security Operations Center) предприятия?

Наиболее частый сценарий применения CL DATAPK в SOC — интеграция с другими продуктами, на базе которых построен корпоративный или профессиональный SOC. В этом сценарии CL DATAPK — это глаза и уши SOC в сегменте АСУ ТП и других промышленных систем, эксплуатируемых Заказчиком.

Дело в том, что сети и устройства АСУ ТП имеют определённую специфику, требуют иного подхода к защите и мониторингу, нежели классические ИТ‑активы и сервисы. DATAPK выполняет сбор данных с объектов защиты в промышленной сети, их предварительную обработку и нормализацию. Дальнейшая обработка, корреляция и формирование инцидентов может производиться как на уровне CL DATAPK, так и на уровне общей системы управления инцидентами, эксплуатируемой данным SOC.

API CL DATAPK открыт и доступен в рамках основной лицензии, поэтому собрать связку можно практически с любой вышестоящей системой, поддерживающей произвольные источники данных.

— Почему для масштабирования вы выбрали Азиатско‑Тихоокеанский регион?

При выборе региона оценивали его потенциал конкретно в нашем сегменте рынка и сложность выхода на него. APAC оказался наиболее сбалансированным, плюс в регионе есть Сингапур, город‑государство, которое можно назвать окном в Юго‑Восточную Азию. Наша международная компания зарегистрирована именно в Сингапуре. Впрочем, Азиатско‑Тихоокеанский регион для нас приоритетный, но не единственный. Работаем и по другим рынкам, Ближний Восток, страны ближнего зарубежья. Рассматривали также индийский рынок, но с ним пока решили повременить, чтобы не расфокусировать усилия.

— Расскажите о нюансах работы в Азиатско‑Тихоокеанском регионе. С какими сложностями пришлось столкнуться?

Другая культура. Это с одной стороны общие слова, а с другой это реальная особенность, которую нужно учитывать и при знакомстве, и в переговорах. Непосредственно Сингапур ближе к привычной нам западной цивилизации, но нюансы, пришедшие, например, из Китая, есть и там. За пределами Сингапура Юго‑Восточная Азия совершенно неоднородна, везде нужно учиться работать на местном рынке.

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

— Насколько высокая конкуренция в регионе? Как там относятся к российским специалистам?

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

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

— Чем работа там отличается от работы в России?

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

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

— Во время GPP вы приняли участие в конференции со стендом в Сингапуре: GovWare 2022. Можете рассказать подробнее о подготовке, проведении и итогах?

На выставку мы положили глаз еще до старта акселератора и планировали участвовать в ней как минимум со стендом. Главной частью подготовки стала доработка, а иногда и полная переработка материалов, размещенных в открытом доступе, в том числе на вебсайте компании. За что мы точно благодарны GPP, так это за контакт их эксперта в Сингапуре, работа с ним позволила нам организовать несколько важных и интересных встреч, как на стенде, так и вне выставки.

Сама выставка оказалась неожиданно хорошей. У нас был опыт участия в международной выставке GISEC в Дубае в 2021 году, так вот на GovWare «качество» аудитории было выше на порядок, намного больше людей в теме, представителей системных интеграторов и конечных заказчиков. Да и с организационной точки зрения всё было сделано на пять баллов.

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

— В рамках GPP вы доработали продуктовое предложение. Как бы его охарактеризовали сейчас?

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

— Есть ли у вас планы по развитию CL DATAPK в России?

У нас не просто планы по развитию — у нас утвержденный план продаж с дорожной картой его реализации. Дело в том, что DATAPK — продукт реальный и на российском рынке доступен уже много лет, имеет инсталлированную базу, растет и развивается. Вполне возможно, что в ближайшее время будет сделано разделение версий для внутреннего и внешнего рынков.

— Как и когда планируете привлекать инвестиции для развития системы CL DATAPK?

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