Спецпроекты

Безопасность Стратегия безопасности Техническая защита

DLP-рынок потеряет независимость?

Рынок DLP (Data Loss Prevention – системы защиты от утечек данных) - ровесник третьего тысячелетия. Однако менее чем за 10 лет он успел пройти нелегкий путь от младенчества до зрелости и уже переживает кризис среднего возраста. Сегодня аналитики и практики решают его судьбу – есть ли будущее у фокусированных DLP-продуктов или они растворятся и станут элементами комплексных ИБ-решений? Cтанут ли DLP-разработчики добычей крупных ИБ-компаний или смогут отстоять независимый рынок?

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

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

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

Модели внедрения DLP

Дилемма самостоятельный продукт/элемент неразрывно связана с концептуальными взглядами на создание корпоративной системы ИБ. От специфики структуры управления зависит и выбор концепции внедрения DLP. Сегодня в этой области выделяются три основных подхода: канальный, функциональный и смешанный. В первом случае обеспечение безопасности происходит по типу защищаемого объекта. Рассмотрим типовую компанию, в которой ответственный за почтовый шлюз не только выбирает и устанавливает программное обеспечение, следит за своевременной установкой свежих версий, модифицирует для решения специфических бизнес-задач, но также обеспечивает его защиту от всех видов угроз. Функциональная модель концентрирует свое внимание не на объектах, а на прикладных задачах. В этом случае в ИТ-отделе компании происходит специализация: появляются эксперты, которые отвечают за разработку и реализацию корпоративной политики защиты от вирусов, хакерских атак, спама, утечек, несанкционированного доступа и т.д. Как правило, один эксперт берет на себя сразу несколько из перечисленных обязанностей. Смешанный подход является компромиссом двух предыдущих: один специалист компании занимается как техническим обеспечением объекта (например, почтового шлюза), так и некоторыми функциями его безопасности (например, защитой от спама и вирусов).

Важно отметить управленческие особенности каждой из перечисленных моделей. Очевидно, что канальный подход требует сильного централизованного руководства, которое будет диктовать единую политику, жестко контролировать ее соблюдение. В отсутствие "сильной руки" компанию неминуемо ждет "буйство мнений", когда каждый специалист реализует тот метод защиты вверенного ему объекта, который считает правильным. Таким образом, в ИТ-инфраструктуре может появиться, например, сразу несколько антивирусов разных разработчиков. Функциональный подход предполагает известную степень децентрализации, при этом прикладные направления получают большую свободу действий для реализации своих специализированных задач. При этом не только не страдает унификация политики, но ее качество даже повышается: конкретные прикладные политики разрабатываются профильными специалистами.


Канальный подход к обеспечению ИБ требует сильного централизованного руководства

Функциональный подход имеет ряд очевидных преимуществ. Во-первых, нельзя быть специалистом по всем типам угроз, при этом одновременно отвечать за техническую сторону объекта защиты. "Фокусники" всегда лучше разбирались в своей предметной области. Соответственно, защита, построенная на таком подходе по умолчанию лучше. С точки зрения защиты от утечки эта модель имеет дополнительный плюс, поскольку парадигма DLP в корне отличается от других областей ИБ. Здесь речь идет о защите секретов, в отличие от защиты сети, серверов или рабочих станций. DLP решает бизнес-задачу, в то время как в сферу компетенции других областей попадают задачи прикладного характера. Прикладные задачи имеют ряд ограничений – по вовлеченным подразделениям, распределению ответственности. DLP же пронизывает весь бизнес, всю работу организации. Это мнение разделяет Рич Могулл, на протяжении многих лет бывший ведущим ИБ-аналитиком исследовательского центра Gartner: "Единственный способ решить проблему защиты от утечки состоит в создании целостного решения. Не имеет ровным счетом никакого смысла строить отдельные политики на уровне сети, серверов или баз данных. Наоборот, необходимо разработать одну политику и распространить ее на всю инфраструктуру".

Короткая ссылка