Зачем на самом деле нужны DLP-решения и почему они не являются лекарством от утечек?
Рынок решений DLP (Data Leak Prevention) появился относительно недавно, но за это время успел серьезно эволюционировать. Игроки уже осознали необходимость такого класса решений, и мы видим очередной виток его развития. Изначально DLP-решения рассматривались как способ предотвращения утечек данных – этакая спасительная пилюля от всех болезней. В этом была основная ошибка. Сами по себе решения ни от чего не защищают, а представляют собой механизм со своими достоинствами и недостатками. И, как показывает практика, современный российский бизнес только созревает для DLP.
Проблема первая - решения DLP требуют четкого понимания всех внутренних процессов, потоков данных и их классификации, а для этого необходим определенный уровень зрелости, что для сегодняшнего российского бизнеса нетипично. Это означает, что среднестатистической российской компании перед внедрением решения DLP необходимо оценить собственную готовность к этому процессу и ответить на простые вопросы, например: "Какие категории критичной информации у нас обрабатываются?", "В каких бизнес-процессах она циркулирует?", "Есть ли понимание рисков, связанных с утечками таких данных?" и т.д.
Эти вопросы - лишь верхушка айсберга. Существует множество других вопросов, на которые нужно дать прозрачные и однозначные ответы, прежде чем приступать к внедрению решения DLP. В противном случае внедрение DLP превратится в модификацию стандартных правил в системе, в зависимости от понимания ситуации. Конечно, в деле построения системы DLP по наитию возможен счастливый исход, но в основном такой подход приводит к множеству ложных срабатываний и сложностям анализа выходных данных.
Проблема вторая - работа решения DLP основана на статистике и вероятностях (процент встречаемых ключевых слов, процент соответствия шаблону документа и т.д.). То есть по определению в решения DLP заложено принятие рисков некоторых утечек. Это сильно отличает такие системы от классических средств защиты. Например, если в файерволе закрыли порт, трудно себе представить, что система будет работать по принципу "может, иногда я и буду пропускать через этот порт, но не часто, чтобы не расслаблялись". Понятно, что это не минус решений DLP, а особенность, существующая в силу принципов работы и попыток формализовать неформализуемое.
Возникает вполне резонный вопрос: "А что же делать дальше?"
Решение первой проблемы я вижу в пересмотре классических подходов к использованию DLP. Не стоит DLP позиционировать в качестве системы защиты от утечек данных. Давайте для "незрелых" российских бизнесов введем название "система оповещения сотрудников о риске утечки данных". То есть будем использовать DLP как систему повышения осведомленности в области ИБ (Security Awareness - осведомленность в области ИБ) сотрудников. DLP слабо защищает от злоумышленника, а вот помочь сотруднику случайно не "слить" важный и критичный документ вполне может. Постепенно сотрудники будут лучше понимать принципы информационной безопасности компании.
Вторая проблема решается через дополнение DLP до полноценной системы защиты, в которой задаются однозначные правила. Это позволит отбросить переживания за вероятности срабатывания. Как это сделать? Ответ лежит в специализированных решениях классификации данных. Все документы в компании маркируются грифом секретности (и другими параметрами), дальше DLP-система однозначно по метаданным принимает решение о дальнейших действиях с документом. Примером такого решения может быть TITUS.
Подводя итог, отмечу, что, изменив отношение к концепции DLP, мы сможем решить проблему внедрения таких систем в "незрелых" компаниях, а классифицировав информацию (через метаданные) по типу секретности, уйдем от неточности принятия решений системой.
