Галина Рябова: На рынке DLP слишком много инструментов и слишком мало концепций

Галина Рябова, руководитель направления Solar Dozor компании «Ростелеком-Солар», рассказала Anti-Malware.ru о том, что нового появилось в Solar Dozor версии 7.0, почему путь к UBA был таким долгим, а также кому и зачем необходим модуль UBA.

Недавно было объявлено о релизе Solar Dozor 7.0. Что появилось в новой версии, и чем она отличается от предыдущей?

Г. Р.: Версия 7.0 развивает концепцию «People-Centric Security», то есть безопасность с фокусом на человеке, и все изменения в версии связаны именно с этой концепцией. Эти изменения были плановыми, мы шли к ним давно.

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

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

В модуле Досье 7-й версии системы стало настолько много информации, что нам пришлось серьезно переработать интерфейс модуля, чтобы эта информация была удобно организована и быстро доступна. После переработки интерфейса модуль Досье стал полноценной средой для решения задач мониторинга сотрудников из групп риска, проведения расследований в отношении персоны или группы персон.

На презентации вы рассказывали, что путь к UBA занял более трех лет. Почему процесс был таким долгим? Почему раньше не релизили хотя бы частично какую-то функциональность?

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

Хотелось избежать долгого внедрения продукта и размытости задач, как при реализации UBA как платформы. Ведь в этом случае необходима сложная интеграция со структурой безопасности и различными ИТ-системами компании, построение аналитической модели угроз под конкретную компанию, сбор больших объемов данных, их очистка, и только затем возможно извлечение пользы. История очень похожа на BI, она тяжела: на стороне заказчика обязательно нужен супераналитик, на стороне вендора или интегратора — тоже; требуется примерно полтора года на внедрение. Нам же хотелось, чтобы наша концепция работала «из коробки». Для этого нужно предложить заказчику уже готовое, проверенное решение. Решение этой задачи и заняло основное время.

Некоторые ваши конкуренты в 2017 году уже анонсировали некие UBA-функции. Вы анализировали опыт конкурентов?

Г. Р.: Целостное решение в данном направлении вывел на рынок, пожалуй, только SearchInform. Но они решали другую задачу – построение психологических портретов, разделение сотрудников по группам риска, например, «Болтуны», «Лентяи», «Скандалисты», «Критики», «Манипуляторы». Поэтому предложенный рынку продукт по сути не относится к классу UBA. У остальных конкурентов нам не удалось найти в открытых источниках более или менее конкретное описание реализованных технологий, которое можно было бы проанализировать. Только маркетинговые названия, анонсы, кулуарные разговоры об этих модулях — больше ничего. Достаточно четко позиционировался InfoWatch, когда анонсировал функциональность для прогнозирования увольнений, но это все-таки слишком узкий фокус, а не комплексный подход.

Во время разработки вы опирались на какие-то научные исследования?

Г. Р.: Да, у нас в штате есть группа математиков. Первое, что мы сделали, когда пришли к концепции UBA, — это построили функциональную модель, под которую разработали математические алгоритмы. При этом мы учли ряд ограничений, основное из которых состоит в том, что мы не должны требовать от пользователя каких-либо настроек. Потому что в основе модуля лежит достаточно сложная математика и аналитика, и нет гарантии, что пользователь, которому мы предложим DLP-решение, будет иметь в штате сотрудников необходимой квалификации. Поэтому в наш алгоритм заложено и нормирование, и автоматическая подстройка модели под изменение поведения пользователя. Мы искали алгоритм и математическую модель, которая не потребует от заказчика наличия нескольких тысяч человек в штате или десятков тысяч слов личной переписки на каждого сотрудника: всё должно работать на любом количестве сотрудников и на любом имеющемся трафике.

Сколько сейчас данных о пользователях нужно накопить предварительно, чтобы UBA начала работать так, как вы планируете?

Г. Р.: Нужны данные за два месяца. Если мы внедряем модуль в уже работающую DLP-систему, то достаточно архива коммуникаций за два месяца, который обрабатывается, и заказчик сразу получает работающую модель. Если модуль внедряется вместе с DLP с нуля, через два месяца, собственно, уже можно рассчитывать на результат. Данных за этот период со скользящим окном в месяц достаточно для того, чтобы понять устойчивое поведение.

Первая версия UBA-модуля работает только на почтовом трафике, потому что именно он содержит наиболее подходящие для отладки модели данные. Аналитика, которой можно доверять, должна строиться на «чистых данных»: гарантированное наличие данных и метаинформации, однозначная идентификация сотрудника, наличие уникального адреса у внешнего контакта и т.п. Эту модель мы проверили на нескольких пилотах и на себе. Сейчас в процессе плотного взаимодействия с большим количеством заказчиков нам необходимо получить обратную связь, донастроить модель в случае необходимости, выявить новые или смежные задачи безопасности. И на основании этой информации добавлять новые каналы и функции. Нам хочется контролируемого полезного развития, а не «хайпового» суперинструмента, работающего по принципу «… я еще и вышивать могу… и на машинке тоже…» — только не понятно, что с этим всем делать.

Что такое «эго-сеть» в терминологии вашего продукта?

Г. Р.: Просто дать определение будет не совсем правильно. В процессе анализа поведения пользователя мы можем посмотреть на его контакты с разных точек зрения. Как мы общаемся с людьми? У нас есть контакты редкие и частые, единичные и регулярные. Иногда мы общаемся один на один, а иногда ставим в копию половину компании. Модель анализа поведения все эти нюансы учитывает.

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

Для безопасника все эти понятия очень интересны. Когда человек увольняется, то помимо всего прочего, особенно если это — ключевой сотрудник, возникают вопросы, которые часто адресуют безопаснику: куда уйдет человек, с чем он уйдет и кого он может за собой увести? И в этом случае начать следует с анализа «эго-сетей» и состава переписки по «эго-сетям».

А если говорить об индексе уязвимости — эта метрика как-то связана с досье?

Г. Р.: Это другое. В нашей DLP-системе есть скоринговый показатель «Уровень доверия», он имеет вполне прикладное значение, показывая, насколько часто и серьезно сотрудник нарушает DLP-политики.

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

Сколько сейчас в модуле предустановленных профилей и паттернов поведения, которые можно использовать «из коробки»?

Г. Р.: Здесь надо различать две сущности — профиль поведения сотрудника и паттерн поведения. Это разные вещи. Профиль поведения — это характерные особенности коммуникаций, которые постоянно анализируются системой в фоновом режиме для каждого сотрудника, поскольку профиль поведения индивидуален. Мы анализируем характер коммуникаций сотрудника по множеству параметров; если по каким-то параметрам сотрудник показывает устойчивое поведение, то мы говорим, что это сходящийся профиль. Если характер коммуникаций постоянно меняется, то в этом случае мы не можем говорить о сходимости профиля и фиксировать аномалии. В целом это чем-то похоже на подходы, используемые в SIEM-системах, только мы анализируем не логи, а коммуникации сотрудников. То есть здесь речь идет об индивидуальных особенностях коммуникаций сотрудников и изменениях в характере этих коммуникаций, которые могут привлечь внимание безопасника и послужить отправной точной для анализа.

Что касается паттернов поведения: когда мы занимались разработкой UBA, то заметили, что некоторые сотрудники, даже если они работают в разных подразделениях, по определенным показателям демонстрируют схожее поведение. Именно такое схожее поведение мы объединили в группы – паттерны поведения. Система ищет среди всех сотрудников компании тех, особенности коммуникаций которых подходят под тот или иной паттерн. На данный момент таких паттернов 19, но я не уверена, что все они останутся в модуле. Потому что мы нацелены на то, чтобы паттерн решал практические задачи безопасности. Сейчас же ряд паттернов по сути является фильтром сотрудников по определенным признакам – получатели информации, «мертвые души», отпускники, те, кто работает во внеурочное время. По результатам первых внедрений мы хотим выяснить, какие из этих 19 паттернов более полезны, какие менее, какие доработать, а какие еще нужно создать.

В паттернах, которые уже есть, есть сотрудники, которые планируют уволиться?

Г. Р.: Вообще, при правильной настройке политик DLP-системы и без UBA-составляющей позволяют хорошо предсказывать увольнения. Ходит ли сотрудник на сайты поиска работы, получал ли он приглашения на собеседования, размещал ли резюме и так далее. А вот предсказать обстоятельства увольнения: как он уволится, куда уйдет, какую информацию он может унести, кого из сотрудников может вместе с собой увести, поможет UBA. При анализе профилей коммуникаций увольняющихся сотрудников мы выявили характерный сценарий поведения: сначала падает интенсивность коммуникаций (снижается рабочая активность из-за обиды или разочарования), затем расширяется круг общения (когда сотрудник принял решение об увольнении, он начинает собирать всё, что нажито непосильным трудом — «а помнишь, мы с тобой работали над проектом, а пришли мне тот документ»). На следующем этапе начинается вывод информационных активов — их копирование на флешку, пересылка на личные почтовые ящики. Обычно безопасник подключается только на последнем этапе и то в случае, если выводимые сотрудником документы защищены правилами политики.

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

Г. Р.: Мы такой задачи при разработке модуля не ставили, потому что не хотели смещаться в область HR-задачи контроля рабочего времени, у нас все-таки инструмент безопасности. Но я думаю, что косвенным образом для оценки эффективности персонала можно применять профили активности сотрудника в течение рабочего дня, о которых я говорила выше. Стандартно агенты DLP-систем передают информацию по активным приложениям и вкладкам браузера, а также времени, когда система не активна. В соответствующем разделе Досье сотрудника эта информация представлена в наглядном виде.

Какие прикладные задачи можно уже сейчас решить с помощью UBA в Solar Dozor?

Г. Р.: Первая прикладная задача — выявление триггеров, требующих проведения расследования. Речь не о расследовании уже случившегося инцидента, а скорее о профилактике зарождающихся проблем. Набор из 19-ти паттернов поведения, реализованных в модуле, является для специалиста по безопасности отправной точкой для старта анализа. Например, начать можно с анализа того, какие сотрудники компании являются получателями и накопителями конфиденциальных информационных активов. Например, на одном из пилотов UBA-модуля выяснилось, что инженеры первой линии техподдержки в процессе своей деятельности получают широкий перечень защищаемой информации, в том числе конфиденциальные данные клиентов компании. В рамках работы с одной заявкой этой информации было немного, но с течением времени совокупность накопленной информации становилась более чем критичной. Соответственно, данное подразделение является для компании зоной риска с точки зрения утечки этой информации. Для службы безопасности этот риск изначально был неочевиден, а предоставленная UBA-модулем информация стала поводом для изменения регламентов работы подразделения.

Каковы требования к специалистам на стороне заказчика, которые работают с UBA? Нужно ли дополнительное обучение?

Г. Р.: Наш UBA-модуль не предъявляет дополнительных требований к сотруднику заказчика. Ему нужно понимать, какие он хочет решать задачи, он должен быть безопасником. Как только он поймет концепцию работы модуля, то сможет применять его для решения своих задач. Прежде всего для двух основных – профилактики и расследования. Что касается профилактики, то лишь с помощью анализа поведения можно выявить ранние признаки зарождения будущего инцидента. Для целей расследования этот модуль единовременно дает столько информации о человеке или о группе людей, сколько с помощью других инструментов можно собрать лишь за несколько месяцев.

У многих есть опасения, что использование такой функциональности приведет к «охоте на ведьм», когда под видом профилактики угроз будут выискивать сотрудников, которые ведут себя как-то не так.

Г. Р.: При эксплуатации DLP-системы всегда встает этический вопрос: у безопасника есть доступ к переписке и к личной информации пользователей. Никакого морального обременения сверх этого UBA в DLP не привнес. Скорее наоборот, модуль может выступить на стороне сотрудника, если это, конечно, добропорядочный сотрудник. Например, он поможет на ранней стадии подсветить ситуации, когда ценный сотрудник решит уволиться из-за, скажем, конфликта на работе, или если он попал в тяжелую жизненную ситуацию. В этом случае у руководства появится возможность помочь работнику и удержать в компании ценные кадры.

А ложные срабатывания могут быть?

Г. Р.: В политиках DLP-системы могут быть ложные срабатывания, потому что мы задаем в них некоторые условия, из которых могут быть исключения. В случае с UBA нет речи о ложных срабатываниях: система беспристрастно отражает факт и характер коммуникации. И ни в одном инструменте, ни в одном паттерне, ни в одном срабатывании нет оценочного суждения, плохо или хорошо. Здесь говорится только одно: человек изменил свое поведение. Это не означает, что он что-то нарушил – просто надо разобраться в причинах изменения.

По вашим ожиданиям, кто будет целевой аудиторией новой UBA? Кому это может быть интересно?

Г. Р.: Этот модуль интересен компаниям любой отрасли. С точки зрения служб безопасности прослеживаются две тенденции. Во-первых, DLP-системы всё больше используются не в узких интересах информационной безопасности, а для решения более широкого круга задач служб безопасности в целом. Вскоре возможности UBA будут востребованы подразделениями экономической, собственной, кадровой безопасности, антикоррупционными службами. Во-вторых, информационная безопасность, как мне кажется, вынуждена переключаться с технологий, данных и низкоуровневых событий на людей, потому что источник всех угроз — люди. И в этом смысле профилактика тех же самых утечек важнее, чем ликвидация их последствий или разбор свершившихся инцидентов. Какой смысл проводить расследование, если всё уже утекло и данные проданы? Только чтобы наказать виновных? В лучшем случае, чтобы сделать выводы на будущее. Но важнее предотвратить то, что, возможно, назревает.

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

С точки зрения математической модели, есть ли какие-то компании, которым гипотетически UBA не подходит вообще?

Г. Р.: Думаю, что нет. Единственное требование Solar Dozor UBA — наличие трафика за два месяца, чтобы делать прогнозы и фиксировать аномалии поведения. Я не знаю компаний, в которых все сотрудники менялись бы раз в два месяца. В этом и состоит привлекательность модели, которую мы нашли: модуль не нуждается в учителе, не предъявляет требований к количеству сотрудников, объему или составу переписки.

Расскажите, пожалуйста, о планах на ближайшие полгода.

Г. Р.: Если говорить о ближайших перспективах, то сейчас мы возьмем некоторую паузу, потому что хотим собрать обратную связь с первых внедрений— это очень важно. Бежать куда-то, размахивая флагами, не собираемся. Хочется сделать надежное прикладное решение.

В ближайшее время точно будем реализовывать поиск похожих по поведению сотрудников: условно говоря, безопасник выявил некоего нарушителя и хочет с помощью UBA обнаружить всех, кто по поведению на него похож. Еще будем анализировать аномалии по количеству контактов. Скажем, для специалистов по продажам или в сфере HR нормально ежедневное появление большого числа новых контактов. А для некоторых других специальностей является нормой постоянный состав контактов, и появление новых — аномалия. Такого рода аномалии пока немного выходят за пределы модели.

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

Спасибо за интервью. Желаем успехов!