Константин Пасечников: Наш заказчик точно знает, чего хочет от DLP

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

Константин, здравствуйте! Судя по списку клиентов InfoWatch, Ваши продукты ориентированы на крупных заказчиков. Однако мы помним, что в компании были попытки создать DLP-решение для среднего и малого бизнеса. Как сейчас обстоят дела с позиционированием флагманского решения? Что представляет собой целевой сегмент для Traffic Monitor?

Traffic Monitor всегда был и останется решением для Enterprise. Для SMB сегмента нужен другой продукт, как с точки зрения пользовательского функционального наполнения (в SMB, как правило, нет выделенных офицеров безопасности), так и с точки зрения  характеристик, не относящихся к функциональным (производительность, масштабируемость, простота настройки/установки).

 На какую максимальную нагрузку рассчитан InfoWatch TrafficMonitor?

Если считать в пользователях, то Traffic Monitor держит нагрузку в 50 тыс. пользователей при верхнем ограничении трафика в 400 Мбит/с. Но все зависит от конкретной схемы внедрения. Traffic Monitor – решение шлюзовое, трафик пользователей можно анализировать в локальном филиале, а можно заводить трафик филиалов в центральный офис, и через центральный шлюз выводить в сеть. От конкретной схемы развертывания решения зависит предел по нагрузке.

Чем обусловлены существующие ограничения продукта?

Любое решение уровня Enterprise аппаратно зависимо. Потому, чем современнее и мощнее ИТ-инфраструктура, тем производительнее и эффективнее построенная информационная система, и наоборот. Но дело даже не в этом: много ли вы знаете компаний с числом сотрудников за полсотни тысяч? Выполнить проект в таком аккаунте – серьезное испытание для любого производителя. У нас такие проекты есть, так стоит ли вообще поднимать тему ограничений?

Но сложности, всё же, есть? Не может же быть все гладко и безоблачно…

Основная сложность – объемы хранимой информации. Наше решение сохраняет копию всего исходящего трафика в базе данных. Как правило, клиенты в оперативном доступе хотят иметь данные за полгода, а это уже терабайтные объёмы. В среднем в день 100 пользователей генерируют около 2ГБ данных. Дальше посчитайте, какой объём нужен для хранения данных 50 тыс. пользователей в течение полугода.

А если, к примеру, хранить не копию трафика, а ссылки на документы, прошедшие через систему, повысится ли производительность?

Гиперссылки вместо текста? – допустим. На практике это будет выглядеть так: мы пытаемся найти по ссылке нужную информацию, а документа, на который ссылается система, больше нет. Удалили, потеряли - мы видим ссылку в никуда. Как доказать без копии документа, что именно этот документ ушел за пределы компании? Как доказать, что утечка вообще имела место быть?

Но документы можно хранить во внешнем хранилище..

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

Многие эксперты уверяют, что внедрение DLP-систем, особенно это касается InfoWatch Traffic Monitor, достаточно трудоемкий процесс и сопровождается долгим периодом настройки. Действительно ли это так и что делает компания для того, чтобы облегчить жизнь инженерам на этапе установки?

Ни одно корпоративное решение не ставится  непринуждённым движением руки. Так или иначе, его нужно встраивать в инфраструктуру. Некоторые производители, и InfoWatch в их числе, облегчают жизнь своим партнерам-интеграторам посредством так называемых best practices. Опыт предыдущих внедрений анализируется, классифицируется, чтобы его можно было тиражировать.

Есть иллюзия, что решение, уж коль за него уплачены деньги, заработает «сиз коробки», само «заведется». Это не так. Систему приходится настраивать под каждого заказчика. И не важно, какая инфраструктура в основе. Адаптировать решение под политики информационной безопасности, сильно различающиеся от компании к компании, все равно придется. Нужно смотреть, какая информация циркулирует в организации, что считается конфиденциальным и прочее и прочее. Аксиома больших проектов – практически все всегда зависит от специфики заказчика. Даже внедрение антивируса в крупных компаниях – целый проект. Впрочем, когда мы говорим о «пилоте» – об установке и настройке Traffic Monitor на несколько машин для того, чтобы наглядно показать клиенту, какая же информация у него уходит наружу, - мы готовы отвечать за сроки. На развертывание системы в «пилотной» конфигурации уходит в среднем один-два дня. Хотя есть много примеров, когда систему ставили и полностью настраивали за 2 часа. Сама «пилотная» эксплуатация, как правило, длится около месяца.

Но есть же какие-то дефолтные настройки. Почему клиент не использует их?

Есть и настройки, и стандартные схемы, и «Автолингвист» для сортировке документов по категориям. На «пилоте» автомат делает 90% работы. Тонкий тюнинг – уже руками специалиста. Но, как я уже объяснил, в «боевом» проекте типизировать политики, схемы внедрения, настройки не получается – у каждого Enterprise-клиента есть свои уникальные требования.

Кстати, каковы в настоящее время варианты интеграции (установки) InfoWatch Traffic Monitor в существующую инфраструктуру компании?

Основных два – мы ставим решение «в копию», когда снимаются теневые копии всего трафика, но система не препятствует отправке любых документов и сообщений. Второй вариант – установка «в разрыв». В этом случае нелегитимные отправки конфиденциальных документов блокируются. Это картина в общем, дальше бесконечное число вариаций.

Наша задача – получить откуда-то трафик, контролировать HTTP, почту, мессенджеры, принтеры, а также движение файлов на внешние накопители. И способы получения этого трафика самые разные. Например, почтовый трафик можно получать через SPAN или MTA или плагин для Lotus Notes. У больших заказчиков, кстати, часто встречаются ситуации, когда трафик нужно снимать разными способами с нескольких разных точек и потом ещё добавлять специальные правила фильтрации/агрегации.

Плюс ко всему заказчик сам выбирает, ставить ему наше решение в «разрыв» или «в копию». В первом случае, то есть «в разрыв», мы работаем через решения партнеров – Blue Coat, Cisco и т.д.

Почему?

Считаю, каждый должен заниматься своим делом – мы неплохо находим в исходящем потоке корпоративной информации конфиденциальные данные, а продукты Blue Coat, Cisco и др. решают задачу организации отказоустойчивых прокси-соединений.

Есть ли предпочтения по производителю оборудования? Или система работает с любым железом?

Что касается сетевого оборудования – не принципиально, лишь бы трафик шел в систему. По серверам – главное, чтобы выдерживались системные требования.

Некоторые эксперты годами публично критикуют надежность InfoWatch Traffic Monitor и его хроническую «сырость». На чем, на Ваш взгляд, основывается это мнение, и что делается для изменения такого отношения рынка?

Давайте так, у меня за этот год показатель успешности для проектов – 95%. Это и «пилоты», и «боевые» внедрения. Успешно – это когда Traffic Monitor интегрирован в инфраструктуру, система показала результат, и у заказчика нет претензий к ее работе. Если эксперты готовы предоставить столь же красноречивые цифры – милости прошу. Впрочем, сильно сомневаюсь в том, что у критиков нашего решения найдется хоть один весомый аргумент, помимо голословных и надоевших уже порядком обвинений в «сырости».

А откуда, по-вашему, появилось это мнение?

Могу только предполагать. У любого продукта есть своя история. На заре становления Traffic Monitor мы не смогли обеспечить достойный уровень поддержки клиента. А специфика работы в сегменте крупного бизнеса такова, что клиент сначала оценивает сервис, а потом продукт. Если сервис плох, до оценки продукта дело не доходит. Отсюда весь негатив – «эксперты» обсуждают и осуждают продукт, который они в глаза не видели.

Но я еще раз призываю всех оперировать цифрами и фактами. У нас есть данные по удовлетворенности клиентов, они открыты. Заказчику ничто не мешает ставить нам двойки за сервис, но показатель удовлетворенности почему-то держится на уровне 80-85%. Есть информация о лояльности заказчиков, есть процент успешных проектов – 95 заказчиков из 100 переходят от «пилота» к «боевому» внедрению. Что еще нужно? И это при том, заметьте, что мы предлагаем полноценные DLP-решения, в отличие от многих конкурентов. Внедрение настоящего DLP – это сложно и дорого, и об этом мы тоже всегда честно говорили. И тем не менее у нас покупают, у них нет – парадокс…

То есть дешевых DLP не бывает?

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

Получается, дело в незрелости рынка? Клиент не знает, что ему на самом деле нужно?

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

Какова сейчас судьба продуктов для криптографической защиты InfoWatch Crypto Storage? Насколько данное направление оказалось подходящим для компании и востребованным на рынке? Планируется ли как-то развивать корпоративную версию InfoWatch Crypto Storage Enterprise?

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

IDC предлагает рассматривать шифрование и DLP как часть стратегии информационной защиты и контроля (IPC). Почему бы все же не пойти по пути интеграции продуктов в единое решение?

Не стоит забывать, что функциональные особенности продуктов не пересекается. Идеология да, но не функциональные особенности. Интеграция ради интеграции – затея пустая. Можно Traffic Monitor интегрировать с антивирусом? Можно. А нужно? Вряд ли. Решения должны взаимно дополнять друг друга. Потому наиболее рационально не интегрировать продукты, создавая «монстроподобный» комбайн, а открыть офицеру безопасности управление криптозащитой из единой консоли управления, например, Traffic Monitor’а. Для «айтишников» такие консоли уже есть, но наш функционал нужен не «айтишникам», а специалистам по ИБ. Просто есть понятие инцидента, в ИТ и ИБ это совершенно разные вещи.

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

Слухи сильно преувеличены :). Дальнейшее развитие  защиты на endpoint-е продолжается. Собственно, этот функционал остается в нашем решении.

Но есть два подхода к построению защиты – шлюзовые решения и установка агентов на конечных точках. Верно ли, что InfoWatch в свое время сделал акцент на защиту на уровне шлюза?

Это неверно. От защиты конечных устройств никто никогда не отказывался, и от агентов на конечных устройствах отказаться в ближайшее время тоже не получится. Тот же Skype перехватывается только на конечной точке, защита мобильных устройств вряд ли возможна без наличия агента на устройстве. Мне кажется, неверно делать однозначный выбор между защитой на шлюзе и защитой на конечном устройстве. Система должна работать в комплексе. Тем более, что и современные каналы связи, и мощности рабочих станций позволяют реализовать смежный вариант.

В заключении беседы – традиционный вопрос про будущее. Верите в перспективы облачных ИБ-решений?

Любое шлюзовое решение после небольшой доработки может заработать в облаке. Мысли насчет развития InfoWatch в этом направлении есть. Не исключаю, что именно за счет облачной модели распространения – в виде DLP as a Service – получится расширить аудиторию наших потенциальных клиентов, предложив SMB-компаниям законченное, полноценное решение для защиты их информационных активов.

Cпасибо!