Александр Клевцов: Мы пришли к машинному обучению не ради хайпа, а ради решения конкретных прикладных задач

Александр Клевцов: Мы пришли к машинному обучению не ради хайпа, а ради решения конкретных прикладных задач

Александр Клевцов

Руководитель направления InfoWatch Traffic Monitor группы компаний InfoWatch.

Окончил Волгоградский Государственный Университет по специальности «Математика». С 2004 года работал в области программирования и системного анализа на научно-технических предприятиях, в частности, по направлению АСУ ТП.

С 2011 года занимается информационной безопасностью. Сегодня является руководителем направления по развитию флагманского решения ГК InfoWatch для предотвращения утечек информации и контроля информационных потоков.

...

Глава направления Traffic Monitor ГК InfoWatch Александр Клевцов в преддверии выхода новой версии отечественной DLP-системы рассказал Anti-Malware.ru о вызовах, продиктованных индустрией, а также о том, как компания на них реагирует и что её принципиально отличает от ближайших конкурентов.

Хотелось бы поговорить сегодня про DLP-рынок. И сам он, и тема борьбы с утечками — не новые. Было большое количество различных сравнений. Удивить кого-то чем-то уже тяжело, с нашей стороны кажется, будто все DLP-продукты одинаковы и становятся если не «дженериками», то чем-то очень сильно на них похожими. Куда идёт рынок? Каковы основные тенденции?

А. К.: Предлагаю начать с нашего горячо любимого Gartner. О чём он говорит? О чём говорит компания InfoWatch? Как мы отвечаем на эти тенденции, как мы реагируем на этот вызов?

Если говорить об основных векторах, которые «подсвечивает» Gartner, то это — защита данных в облаках, что актуально и для международного рынка, и для российского. Компании стараются переводить — и переводят — свою инфраструктуру в облака для снижения издержек, для удешевления эксплуатации средств и самой инфраструктуры. Также Gartner выделяет тенденцию использования личных устройств и удалённых сотрудников. Как вы понимаете, с такими событиями, как глобальный кризис, связанный с пандемией COVID-19, это становится актуальным. Многие российские заказчики перевели сотрудников на «удалёнку», и даже есть такой опыт, что после того как разрешили вернуться в офисы, все продолжают оставаться на удалённой работе. Соответственно, это является определённым вызовом и для DLP-продуктов, потому что меняются ландшафт коммуникаций, ландшафт трафика и, очевидно, сценарий того, как всё это перехватывать.

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

Контроль сотрудников — это особенно актуальная тема. Я приведу пример наших российских заказчиков. У них используется облачный сервис Microsoft Exchange Online, который начал работать задолго до распространения коронавируса, просто для того чтобы было дешевле сопровождать почту, так как компания — достаточно крупная: несколько тысяч сотрудников. И помимо того что используется облачная почта Exchange, ею можно пользоваться с личных устройств. К чему это приводит? Весь почтовый трафик ходит вне локального периметра компании, вне локальной сетевой инфраструктуры. Есть облако, и есть личное устройство. И если DLP находится, так сказать, «на земле», то те классические приёмы, которые мы привыкли использовать в DLP — агентский перехват, шлюзовой перехват внутри инфраструктуры, — становятся абсолютно бесполезными. Поэтому мы как вендор тоже на этот вызов отвечаем определёнными доработками и «фичами».

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

Когда мы говорим, что DLP работает с данными в облаке, как в случае с Microsoft Exchange Online, — это подразумевает, что сама DLP расположена в облаке, хотя бы частично? Или она всё так же размещается on-premise?

А. К.: По-прежнему on-premise, но определёнными доработками и принципами интеграции достигается то, что трафик попадает в локально установленную DLP-систему.

Энное количество лет назад были прогнозы, что DLP тоже может «уехать» в облако. И Google, и Microsoft на базе своих облаков внедряли начальные DLP-функции. Но, по-видимому, идея не получила развития?

А. К.: Революции не случилось — вы совершенно правы. Многие корпоративные средства, тот же Office 365, содержат в себе зачатки DLP в том плане, что тот трафик, который они передают и генерируют, подвергается простым технологиям анализа — стоп-слова и так далее, — но сказать, что эти решения можно использовать как полноценную замену DLP, пока нельзя. Ни на российском рынке, ни на международном.

Если говорить о сценариях применения DLP-продуктов, то, как вы помните, десять лет назад говорили в основном об утечках данных, то есть о прямом применении DLP-систем, а потом стали говорить об их применении для экономической безопасности, для кадровой службы и так далее. Сейчас расширение сферы применения пошло ещё дальше или же новых ниш не возникает?

А. К.: За продуктом InfoWatch Traffic Monitor закреплено такое амплуа, как DLP-система. Не то чтобы мы в маркетинговых материалах пытаемся как-то изменить восприятие этого продукта — наши заказчики уже используют его иначе. Это — состоявшийся факт. Я приведу вам несколько примеров.

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

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

Идём дальше. Был интересный прецедент: один заказчик использует наш Traffic Monitor как систему, позволяющую контролировать правильность документооборота. Просто приведу пример: он с помощью Traffic Monitor проверяет, не отправляют ли сотрудники за периметр компании — по легитимному каналу — документы на старых бланках, не отправляют ли договоры со старыми шаблонами. И когда у нас была дискуссия, сбор данных обратной связи, они вообще про утечки ничего не говорили. В их разговоре вообще не было какого-либо контекста злоумышленника (что кто-то что-то украл, вывел за пределы): система используется для контроля качества документооборота.

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

Профайлинг сотрудников — модное сейчас направление, и многие компании о нём говорят.

А. К.: Расскажу опять о реальном опыте. Вы были в декабре на пресс-конференции, посвящённой новой версии. Помните, я говорил, что у нас вышел новый продукт InfoWatch Vision, который позволяет качественно визуализировать данные, собранные Traffic Monitor? А это — большое количество данных: все каналы, коммуникации, сотрудники — всё, что нужно отразить.

InfoWatch Vision стали интересоваться не только безопасники, но и HR-службы. С помощью этого продукта, этой визуализации они могут определить центр компетенции компании (не побоюсь этого слова, выявить «серых кардиналов»), понять, как нужно оптимизировать бизнес-процесс — не формально, а фактически, исходя из реальных связей между сотрудниками и филиалами, основываясь на трафике, который был собран DLP-системой. Заказчики, которые не являются безопасниками, хотят визуализировать с помощью InfoWatch Vision именно этот ландшафт коммуникаций, который, в свою очередь, собрала DLP-система. Но это — ещё не всё.

Как-то раз знакомые на Facebook добавили меня в чат, и оказалось, что этот чат состоит из известных мне социологов и людей, с которыми я не был знаком. Они рассказали, что делают специальные заказные проекты по исследованию климата в компаниях, чтобы повысить лояльность сотрудников, изучить бизнес-процессы и так далее, и что это достигается благодаря социологическим опросам, когда опрашивают определённые фокус-группы и делают выводы. И вот эти коллеги, прежде мне незнакомые, заявили, что у них есть гипотеза, которая заключается в том, что необходимые выводы можно делать на основе собранного трафика. Они знают, что есть DLP-системы по сбору корпоративного трафика, которые позволяют посмотреть на коммуникацию сотрудников, на карту коммуникаций сверху и сделать определённые выводы. И вся дискуссия у них была на тему: «Как можно проводить социологические исследования, анализируя внутренние коммуникации?». Это был очень интересный опыт, я на данный момент с таким больше не сталкивался. Но такая дискуссия есть.

Службы и представители рынка, которые вообще не связаны с безопасностью, интересуются теми данными, которые собирают DLP-системы.

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

А. К.: Чтобы человека «закрыть», нужно подготовить правильную правовую базу использования DLP. В компании InfoWatch этому уделяется особое внимание. У нас есть целое подразделение InfoWatch Consulting, которое помогает подготовить пакет документов, позволяющих использовать DLP-системы в компании в рамках правового поля. Это — и правильная подготовка трудового договора, при подписании которого сотрудник будет понимать, что вся информация, которую он обрабатывает на рабочем месте, принадлежит компании и что если эта информация будет как-то использована им в личных целях, то это может повлечь за собой последствия; это — и правильное оповещение о том, что весь генерируемый сотрудниками трафик, вся их деятельность контролируется. Только тогда можно говорить о неотвратимости наказания. DLP использовались в судебной практике, об этом можно легко прочитать в интернете. И точно так же можно найти прецеденты, когда заказчик не позаботился о правовом поле использования DLP, и в итоге в процессе спора собранные DLP-системой доказательства не были приняты судом.

Вообще часто ли люди основательно подходят к внедрению DLP и с технической точки зрения, и с юридической, закрывая все возможные тонкие моменты, а не оставляя всё на самотёк, как в упомянутой истории? Или это — в большей степени исключение из правил?

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

Готовится к выходу новая версия InfoWatch Traffic Monitor 7.0 (релиз запланирован на 22 июля. — Прим. ред.). В чём её новизна? Ведь изменение мажорной версии обязывает предложить что-то принципиально интересное?

А. К.: Если двумя словами охарактеризовать принципиальные отличия от предыдущих, то это — релиз про машинное обучение (как бы громко это ни звучало) и про облака.

Что отвечает в этом релизе за Machine Learning? Наша гордость, технология, которая называется «Графический классификатор». Сейчас постараюсь на примере пояснить, в чём её суть. Представьте, что у вас есть некая нефте- или газодобывающая компания. Для неё конфиденциальной информацией является карта георазведки — скриншоты, сканы, фотографии этих карт. И всё усугубляется тем, что этой информацией могут оперировать мобильные офисы: передвижные, удалённые и так далее. В чём сложность? Во-первых, это — графическая информация, то есть всё, о чём привыкли говорить на рынке DLP-вендоры (текст, цифровые отпечатки, регулярные выражения, классификация), сразу отпадает и становится бесполезным. Графическая информация — значит, нужно работать с графикой. Даже цифровые отпечатки здесь бессильны, так как невозможно предусмотреть все карты заранее (нельзя загрузить все карты мира в систему и вылавливать миллион отпечатков), причём в рамках производственного процесса может пересылаться фрагмент этой карты.

И что тогда делать? Нужно каким-то образом научить систему узнавать карты. Поэтому мы естественным образом посмотрели на то, что у нас получается, и прибегли к машинному обучению — создали технологию графического классификатора, который учится на коллекции картинок. Формируем коллекцию, состоящую из 50—300 элементов, «скармливаем» DLP-системе, а она с помощью машинного обучения — метода опорных векторов — формирует графический объект, и впоследствии, когда передаётся любая до этого неизвестная карта георазведки, система позволяет её отлавливать. Мы прибегли к Machine Learning, потому что у нас не было других вариантов и способов. Мы сделали это не ради «хайпа» — мы бы с удовольствием этого избежали, поскольку это дорого.

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

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

Реализовано это не только под карты. «Из коробки» доступно несколько стандартных категорий: лица (это удобно, когда используются персональные данные — например, для отлавливания сканов документов), чертежи, изображения сертификатов и паспортов. Они были и до этого, но сейчас заказчик самостоятельно может брать коллекцию картинок, через графический интерфейс загружать её и обучать систему, что впоследствии позволит отлавливать необходимую графическую информацию.

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

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

В последнее время стали модными темы поведенческой аналитики (UBA), профилирования сотрудников, поиска аномалий в их поведении. Начало казаться, что InfoWatch остался в стороне от всего этого. Таков осознанный выбор компании или вы сейчас не видите реального спроса на эти технологии?

А. К.: Нет, спрос есть. И я бы не сказал, что компания InfoWatch — где-то сбоку. У нас вышла бета-версия InfoWatch Prediction — как раз продукта по выявлению отклонений, аномалий, как вы говорите. И один из сценариев его использования — это прогнозирование увольнения сотрудников. Сейчас он тестируется у ряда заказчиков, показывает неплохие результаты, имеет хороший процент точности срабатываний. То есть мы — не в стороне, следите за анонсами.

Мы готовимся делать новое сравнение DLP-систем, которого у нас уже давно не было (как раз по той причине, о которой я говорил ранее — было ощущение некоего застоя по функциональности, по их применению). Годы идут, всё меняется, поэтому захотелось сделать очередной срез, в связи с чем интересно ваше мнение: если смотреть на рынок, на существующие продукты со стороны потенциального заказчика, на что стоит обратить внимание? Если человек хочет иметь у себя в компании современную DLP-систему, на какие моменты надо смотреть? Что должно входить в «шорт-лист»?

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

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

А. К.: Но есть и другая проблема: часто к DLP приписывают те функции, которые к нему никакого отношения не имеют. Например, контроль учёта рабочего времени — employee monitoring. Или, например, в DLP-продукте становится много функций по контролю и администрированию ресурсов рабочих станций — ну какая это DLP? Это не контроль информации, не контроль трафика, не его анализ, не реакция на инциденты, связанные с трафиком — это чистое endpoint-решение.

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

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

Я приведу такой пример: на Уральском банковском форуме, который проходил в начале 2020 года, я выступал с небольшим докладом и позволил себе такое провокационное заявление: «Персональные данные на рынке DLP-продуктов качественно никто не защищает». И сейчас поясню почему. Вы видели где-нибудь, чтобы подробно разбиралось, что есть персональные данные? Ведь есть ПД в виде реквизитов, в виде описания характеристик субъекта, есть именованные персональные данные (адреса, фамилии, имена, имена детей и так далее) — какие технологии отвечают за их защиту? С какими бизнес-системами должен быть интегрирован продукт, чтобы защищать эти ПД? Просто бы взяли и описали, какими свойствами должен быть наделён DLP-продукт, чтобы качественно выполнять защиту персональных данных — или качественно решать задачу защиты конструкторской документации, что будет интересно, скажем, для ОПК. Вот такой градации — как решать определённую отраслевую задачу, какими качествами и свойствами должен обладать DLP-продукт — я не видел нигде. Все продолжают просто формально ставить галочки.

Мне сравнительно недавно удалось пообщаться с одним вендором, тоже позиционирующим себя как представителя рынка борьбы с нарушениями при обращении с информацией. Разговор был такой: «Персональные данные защищаете?» — «Да, у нас есть регулярки». — «Как классификация текста устроена? Что используете? TEF? IDF? Как вы веса у слов расставляете?» — «Просто количество слов считаем». — «Окей. А морфология у вас как устроена?» — «Да никак. У нас стемминг. Просто обрезаем гласные в конце, и всё». Я прошу прощения за подробности, но вот такие куцые технологии анализа к чему приводят? Во-первых, вы не достигнете определённого уровня автоматизации, будет большое количество ложных положительных срабатываний, и вам придётся разгребать это руками. А во-вторых, такие технологии позволяют защищать только куски документов; для контроля переписки, когда мал объём текста, вещь эта будет бесполезной. То есть формально этот вендор может себе проставить следующие галочки: «такие-то каналы — перехватываем», «словари — есть», «регулярные выражения — есть», «морфология — есть»; но никто не пытается понять, на каких алгоритмах построена классификация текста и может ли она отлавливать не фрагменты документа, а фрагменты переписки, когда люди общаются в почте. Никто так глубоко не копает, никто не выносит эти проблемы наружу.

Весьма тонкие моменты. Как было с мессенджерами несколько лет назад: все писали, что, условно, «мы перехватываем Mail.ru Agent / ICQ», но когда начинаешь вникать, оказывается, что одни только текст перехватывают, другие — файлы (причём кто-то — только исходящие, а кто-то — и входящие, и исходящие). Здесь тоже возникают нюансы, о которых никто не говорит.

А. К.: Я приведу даже более жёсткий пример. У одного из заказчиков мы конкурировали с McAfee, когда он был представлен на рынке — ещё до всех санкционных вещей — как DLP-система. Как был построен перехват трафика? Просто вешались плагины на Chrome и Internet Explorer, то есть любой мог зайти и плагин этот отключить.

Но в контексте американской регуляторики этого было достаточно. Трафик перехватывается? Перехватывается. А то, что этот плагин, то есть перехват трафика, может отключить любой пользователь, не учитывалось. Зато формально галочку поставить можно!

Вопросы защищённости DLP-системы от выключения, её самозащита — это, мне кажется, само по себе отдельная и интересная тема.

А. К.: Эту тематику вообще никто не трогает и не обозревает.

Теперь — о том, что касается сервиса вокруг DLP. Допустим, мы выбрали три продукта, которые нам более-менее подходят. Как вы сказали, у вас есть консалтинг, есть, очевидно, и техническая поддержка, есть дополнительные услуги. Что здесь важно? Какие у компании должны быть развиты компетенции и какие правильные вопросы вендору можно задать со стороны заказчика?

А. К.: Вот я опять же рассказываю с опорой на опыт InfoWatch, указав, какие у нас есть для этого сервисы. Давайте по порядку.

У нас есть консалтинг, который позволяет описать бизнес-процессы, предмет защищаемых данных, подготовить правовое поле для внедрения DLP — это первый этап. Потом у нас есть аналитики внедрения, которые на этапе «пилота», опытной эксплуатации, помогают заказчику подготовить DLP-систему к эффективному использованию — правильно описать политики, правильно описать данные, которые нужно защищать, даже если у заказчика пока не хватает опыта. Я ещё не сказал про отдельный учебный центр — у нас этому уделяется особое внимание: в нём проводятся и практические занятия, и консультации, по результатам обучения выдаётся сертификат и так далее. Учебный центр создавался для тех, кто с продуктом уже работает или ещё только собирается. И, естественно, есть разные уровни технической поддержки.

Наша отдельная песня, наше серьёзное преимущество на рынке — это штат собственных лингвистов. У нас, к примеру, есть 289 разных категорий, готовых, доступных «из коробки» для классификации документов, классификации информации, с которой обращается заказчик. Но если даже этого не хватает, есть какая-то уникальная информация, то на помощь всегда готовы прийти лингвисты: взять документы заказчика, поработать с ним и сформировать политики, а также качественно и оперативно их настроить.

Если, конечно, их пустят, то есть если заказчик — не в «оборонке».

А. К.: Были прецеденты, когда наши лингвисты получали определённый уровень доступа и помогали заказчику. Но выше уже — гостайна, и там этого сделать не получится.

В качестве подведения итога нашей беседы: как вы думаете (с перспективой на два—три года), куда дальше шагнёт DLP-рынок?

А. К.: Тенденция размытого периметра будет сохраняться, он будет размываться сильнее: облака, удалённые сотрудники, фрилансеры, аутсорсеры и так далее. В релизе 7.0 мы поддержали интеграцию с Microsoft Exchange Online, мы теперь перехватываем трафик, который ходит вне локального периметра.

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

У нас есть несколько сценариев. Так, в прошлом году состоялся релиз новой функциональной возможности для интеграции DLP-системы в средство централизованной обработки инцидентов (SOC и так далее). В чём она заключается? Добавили новую интеграционную возможность, когда из средства управления инцидентами — например, IRP — можно изменить решение по инциденту в DLP-системе. Сначала, во-первых, поддерживается импорт, то есть в платформе видны инциденты и события из DLP, и далее можно принять там решение, то есть получается такая двухсторонняя интеграция.

Это — развитие API?

А. К.: Совершенно верно.

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

А. К.: Наверняка вы слышали про интеграцию с SAP и с API. А для чего она была сделана? Для эффективной защиты клиентских баз, номенклатурных, товарных. У нас есть технология «Детектор выгрузок БД» — она как раз позволяет защищать именованные данные, большие массивы, где другая технология DLP не может справиться. Но она, я вам честно скажу, будет абсолютно бесполезна, если к ней не будет «прикручена» возможность интегрироваться с бизнес-системой, где, собственно, эти данные хранятся. То есть сценарий — иной: в предыдущем примере мы интегрировались с системой обработки инцидентов, а здесь — с бизнес-системой (где защищаемые данные хранятся и «живут»).

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

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

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

То есть «посадок» будет больше при их применении?

А. К.: Мы надеемся на сознательность граждан.

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