Возможности контентной фильтрации в DLP-системах являются их изюминкой и детально описываются каждым разработчиком DLP в рекламных материалах и презентациях. Всегда ли при этом эффективен контентный анализ? Действительно ли он необходим и стоит ли при выборе DLP-решения делать акцент на широте функций контентных фильтров в ущерб механизмам контентной фильтрации?
Безусловно, функционал контентной фильтрации является необходимым в современных DLP-системах — при попытке сотрудника передать или сохранить корпоративные данные он позволяет использовать интеллектуальные методы принятия решений, основанные на проверке содержимого документов. Возможность анализа контента означает гибкость в борьбе с утечками, избирательный подход в разработке сценариев работы DLP-системы. Например, с помощью контентных фильтров можно реализовать как сценарий минимальных привилегий, когда при широком запрете использования различных устройств и коммуникационных сервисов DLP-система будет спокойно «пропускать» файлы и данные, не содержащие значимой для организации информации, так и обратный вариант, когда при либеральном подходе к правам сотрудников на использование каналов передачи и хранения информации будут блокироваться и/или протоколироваться только те попытки передачи информации, где выявлен несанкционированный к передаче контент.
Арсенал современных технологий контентного анализа (КА) весьма широк. Сюда входят прежде всего такие классические инструменты, как анализ содержимого на наличие ключевых слов и их сочетаний, в развитых DLP-системах обогащенный возможностями морфологического анализа с учетом транслитерации, опечаток, синонимов и т. д., а также поддержкой готовых наборов отраслевых и промышленных словарей на разных языках мира, и анализ на основании регулярных выражений, позволяющий детектировать и фильтровать данные, имеющие выраженную структуру (идентификационные номера, адреса электронной почты и т. п.). В числе «жизненно необходимых» часто упоминаются анализ по цифровым отпечаткам для текстовых и бинарных данных, контроль файлов по их грифу или тегу, различные усовершенствованные алгоритмы — такие как алгоритм Байеса и другие методы самообучения системы. Среди вспомогательных средств контентного анализа — извлечение текста из графических данных (OCR), распаковка архивов, анализ свойств и атрибутов анализируемых файлов и др.
Однако, прежде чем начать выбирать и оценивать DLP-систему по ее «интеллектуальной» части — широте функций КА, стоит проверить, во всех ли случаях возможно применение контентного анализа, все ли сценарии передачи и распространения данных, порождаемые бизнес-логикой организации, могут быть надежно поставлены под контроль средствами контентной фильтрации?
Начнем с простого примера — политика безопасности компании, создающей интеллектуальную собственность в форме рекламных роликов, не допускает передачи файлов в видео-форматах. Возможно ли при этом использовать, например, анализ по ключевым словам, или проверку в базе цифровых отпечатков? Конечно, нет — в видеоформате попросту нет ни пригодных для анализа текстовых форматов данных, ни возможности выделить пригодный для верификации сегмент. Это означает, что для этой компании такой вид контентного анализа, как цифровые фингерпринты, будет попросту бесполезным. Аналогичные примеры можно привести и для других форм данных, в особенности для конструкторской документации.
Таким образом, «интеллектуальность» DLP-решения не всегда является первичным основанием и преимуществом при выборе системы. Суть контентного анализа в его современном общепринятом понимании — это детектирование и обработка текстового содержимого данных. При этом главная задача DLP-системы — сначала извлечь пригодное для анализа текстовое содержимое из потока передаваемых по сети данных, сохраняемых на внешних накопителях или печатаемых файлов и документов, а затем применить к выделенному текстовому контенту заданные правила его фильтрации и по ее результату выполнить необходимые действия с передаваемыми или сохраняемыми данными.
Рассмотрим другой пример, более распространенный, — анализ документов, сохраненных в формате MS Word.
Ни один метод контентной фильтрации не применим, если пытаться анализировать бинарное содержимое этого документа, а точнее — контейнера в формате MS Word. Ни морфологический анализ, ни проверка по шаблонам регулярных выражений, ни даже анализ по цифровым отпечаткам не дадут никаких результатов, если не извлечь сначала из этого контейнера текстовое содержимое. Анализ графических изображений, внедренных в контейнер Word, также будет невозможен, если этот документ не «разобрать» предварительно на «составные части» — собственно графические элементы, текстовое содержимое, свойства документа и прочие встроенные объекты.
Задачу анализа документов MS Word в силу популярности и распространенности этого формата можно отнести к классическим, а потому извлечение объектов из word’овских контейнеров — чуть ли не первое, что программируется разработчиком при создании механизмов контентной фильтрации. Такие форматы, как проектные документы AutoCAD и подобных систем, относятся к более сложным случаям. Тем не менее предположим, что DLP-система успешно справляется не только с рассматриваемым примером, но и рядом других форматов файлов и документов, извлекая из них текстовое содержимое, пригодное для анализа «интеллектуальной частью» системы.
Но откуда же DLP-система берет этот документ для разбора и анализа? Ведь ни один протокол сетевого типа, ни одно сетевое приложение, ни один тип устройств и протоколов работы с устройствами не спроектированы на передачу данных в DLP-систему. Это означает, что разработчику потребуется реализовать в DLP-системе задачи перехвата протоколов и операций приложений, распознавания различных типов принтеров, детектирования передачи данных по различным протоколам синхронизации мобильных устройств и т. п.
Например, если DLP-система не способна перехватывать и инспектировать передачу данных через веб-почту и по протоколу MAPI (что, кстати, возможно только при перехвате данных на рабочей станции, но не на уровне сервера), то технологии контентной фильтрации будут применимы в лучшем случае для документов, извлеченных из протокола SMTP.
И, наконец, если DLP-решение не способно контролировать приложение на уровне интерфейса, то у нее нет возможности применить «движок» контентной фильтрации к передаваемым по интерфейсу данным. Все ли современные DLP-решения способны контролировать, например, LPT-порт в канале печати?
Это ключевой функциональный момент в работе DLP-решения — прежде, чем начнет работать анализатор контента, должна отработать полностью вся цепочка контекстного анализа, начиная с нижнего уровня, и никак не наоборот. Чтобы «машина» контентного анализа смогла применить заданную администратором политику выявления искомых данных в анализируемых файлах (т. е. фильтровать по определенным критериям контент пересылаемых по какому-либо каналу данных), она должна прежде всего получить пригодные для анализа текстовые данные. DLP-система должна обладать способностью контролировать все наиболее опасные, с точки зрения утечки, каналы передачи данных, в особенности сетевые коммуникации, канал печати, канал синхронизации с мобильными устройствами и локальный канал подключения Plug-n-Play устройств (флеш-носители и т. п.). Каждый такой канал, в свою очередь, разделяется на уровни по физическим и логическим интерфейсам, которые используются каналом. Каждое устройство подключается к физическому каналу — интерфейсу, обрабатываются соответствующими приложениями, которые используют определенные типы данных и наконец, эти типы данных содержат некий контент.
Итак, любое устройство или сетевое подключение прежде всего должно быть точно идентифицировано на уровне интерфейса или порта. Затем DLP-система должна определить приложение или службу, которая работает с этим подключением для определения типа канала. На следующем шаге определяется тип или формат передаваемых данных, что позволяет (если формат поддержан системой) извлекать текстовую информацию, пригодную для работы контентных правил и фильтров. И только тогда приступает к работе «движок» контентной фильтрации, только тогда проявляется «интеллект» системы.
При этом всего одна «дырка» в логической цепочке уровней контроля приводит к невозможности применения контентных фильтров и нарушению требований бизнес-логики защиты от утечек, отображенной в DLP-политике. Более того, «продвинутые» сотрудники, знающие об использовании на предприятии DLP-системы, такую «дырку», скорее всего, достаточно быстро найдут и при наличии злого умысла непременно ею воспользуются. Выбирая DLP-решение с учетом поддерживаемых им методов контентного анализа и фильтрации, следует ясно понимать, что их использование очень похоже на игру в «слабое звено» с участием злоумышленников и службы безопасности.
В качестве реального примера последствий несоблюдения логики сочетания контекстных и контентных методов DLP-контроля можно привести простейший способ обхода одного достаточно известного на мировом рынке DLP-решения — чтобы в обход контентных фильтров распечатать документ, содержащий конфиденциальную информацию, достаточно просто отправить документ на печать непосредственно из оперативной памяти, не сохраняя файл на жестком диске.
Другой немаловажный аспект, напрямую влияющий на эффективность применения контентной фильтрации, — это компонентная архитектура DLP-системы. Например, при серверной реализации контентный анализ операций передачи и сохранения данных с лэптопов мобильных сотрудников невозможен в случае недоступности выполняющего контентный анализ сервера — при этом обязательно потребуется контекстный контроль сетевых каналов и периферийных устройств, выполняемый локальным DLP-агентом. Кроме того, когда ведется перехват и контентный анализ данных, передаваемых на локальные (периферийные) устройства или в шифруемые проприетарным криптоалгоритмом сетевые сервисы (такие как Skype), также следует учитывать фактическую реализацию «контентного движка». В хостовой реализации DLP-системы контентный анализ выполняется непосредственно на контролируемом компьютере, что, с одной стороны, позволяет гибко контролировать мобильных сотрудников и такие каналы, как Skype или MAPI, а с другой — создает дополнительную нагрузку на рабочие станции при выполнении контентного анализа.
Означает ли все вышесказанное, что контентная фильтрация не нужна? Вовсе нет. Это действительно необходимая интеллектуальная часть любой DLP-системы несмотря на ряд сложностей в создании DLP-политик, построенных на анализе содержимого. Именно активное использование контентного анализа позволяет найти приемлемое сочетание интересов служб информационной безопасности и бизнес-подразделений в использовании современных коммуникационных технологий и устройств.
Вывод, который следует из анализа слабых мест в архитектуре DLP-фильтров, заключается в том, что построенная только на анализе контента DLP-система не может служить надежным инструментом контроля передачи информации через локальные и сетевые каналы, если при этом не обеспечивается полноценный контроль каналов на физическом и логическом уровнях специализированными решениями. Более того, с точки зрения гарантированной информационной безопасности, блокировка каналов передачи данных либо расширенный аудит в сочетании с контролем типа передаваемых данных и последующим анализом накопленных данных аудита более эффективны, нежели попытка создать сложные логические правила контроля данных на основании ключевых слов и цифровых отпечатков.
Эффективность DLP-системы в целом зависит не только от качества методов детектирования и анализа текста, но также от качества и полноты функциональных возможностей контроля по контекстным параметрам, возможности перехватывать, блокировать и протоколировать передачу данных на уровне протоколов, портов и устройств, которые логически предшествуют контентному анализу — то есть от качества и эффективности архитектуры DLP-системы.
Автор статьи — директор по решениям компании «Смарт Лайн Инк».
СПЕЦПРОЕКТ КОМПАНИИ «СМАРТ ЛАЙН ИНК»
