Обладая достаточным опытом развертывания, настройки и эксплуатации некоторых DLP-решений, я попытался составить и прокомментировать перечень вопросов, на которые чаще всего не обращают внимания технические специалисты в самом начале работ по внедрению и имплементации DLP, но которые с высокой вероятностью выходят боком в конце проекта. На примерах, взятых с тематических конференций в darknet, попытаюсь проиллюстрировать глубину проблематики и расставить акценты, которые, на мой взгляд, должны помочь специалистам по защите информации в выборе DLP.
100%-ной защиты нет
За рабочими материалами для настоящего обзора я обратился к потребителям, на мой взгляд, наиболее приближенным к реальности информации по утечкам в киберпространстве, – к пользователям TOR, посетителям закрытых тематических конференций в darknet и администраторам отдельных onion-ресурсов, расположенных в скрытом от внешнего мира сегменте сети Интернет. Ранее я был неприятно удивлен тем, что практически в открытом (в терминах TOR) доступе с минимальной авторизацией или вообще без нее, только при помощи базовых поисковых запросов в TORCH мне выпадали актуальные по состоянию на 2017 г. ссылки и расширенный контекст по целому ряду тем, связанных с утечками конфиденциальной информации из профильных организаций в России и мире. Откуда столь чувствительная информация могла утечь и как появилась в Интернете? Как такое возможно, ведь крупнейшие коммерческие организации и окологосударственные структуры тратят миллионные бюджеты на покупку решений класса DLP, которые, по заверению менеджеров проектов и инженеров по внедрению, должны обеспечить 100%-ную защиту от умышленной или случайной потери контроля над чувствительной информацией?!
И тут я бы хотел сделать первый акцент. Ни одна из существующих в настоящее время автоматизированных систем защиты от утечек конфиденциальной информации по техническим каналам связи (далее – DLP) не дает 100%-ной гарантии защиты владельца или снижения риска утечки информации до нулевого значения.
Риск утечки конфиденциальной информации всегда есть, и вероятность его реализации на практике существенно выше нуля – вне зависимости от наличия в организации внедренной DLP-системы. Установленная DLP может в целом решать задачи, перечисленные во врезке «Задачи DLP».
Чаще всего DLP не является активным участником процессов, предполагающих передачу информации между двумя и более лицами по техническим каналам связи. Сценарий работы DLP «в разрыв» (оказание влияния на процесс передачи информации и блокировка вероятных утечек по мере выявления подозрений) на практике сопряжен с необходимостью со стороны службы информационной безопасности в режиме реального или псевдореального времени принимать решение об отнесении событий с признаками инцидентов к тому или иному виду нарушений либо утечек и отсеивать (возвращать в поток) те события, которые попали в выборку файлов от DLP по формальному соответствию, но нарушениями не являются. Такой дополнительный к базовому бизнес-процессу внутренний виток обработки требует непрерывной работы огромного штата обученных и стрессоустойчивых операторов (офицеров безопасности первой и второй линий разбора инцидентов), присутствие которых в службах информационной безопасности коммерческих организаций без регулярного выявления достаточно серьезных утечек и/или иных инцидентов достаточно сложно (если не сказать – невозможно) обосновать. Руководители высшего звена или собственники бизнеса либо принимают риски утечки на уровне организации, либо требуют принять компенсационные меры по ограничению доступа к чувствительной информации, либо закрывают данный вопрос организационными или административными мерами, поскольку техническое решение видится им наиболее затратным как в краткосрочной, так и в долгосрочной перспективе, а принятие дополнительных единиц с «небизнесовым функционалом» в штат снижает общую рентабельность бизнеса организации.
Нюансы внедрения
«И жили они долго и счастливо… Тут и сказочке конец, а кто слушал – молодец!» – примерно так (не дословно) обычно заканчиваются сказки, долго и упорно рассказываемые консультантами, маркетологами и техническими экспертами компаний – производителей решений класса DLP своим потенциальным и реальным заказчикам (см. врезку «Мифы DLP»). После этих «сказок» следует короткий этап пилотного внедрения, техническая помощь в развертывании отдельных компонентов на площадке заказчика, многоэтапное контрактование, тестирование на псевдобоевых данных, подписание акта или протокола успешного завершения приемо-сдаточных испытаний, при наличии которого может быть осуществлена окончательная оплата по договору поставки DLP-системы в организацию. Крупными мазками, с точностью до отдельных процедур, например тендера на поставку решения DLP, квалификационного отбора продавца лицензий или иных определенных внутренними документами и требованиями регуляторов шагов, указанные этапы от маркетинговой сказки до банковского платежного поручения, предстоит пройти любому заказчику, пожелавшему внедрить у себя в организации решение класса DLP…
Задумывались ли вы о том, сможет ли кто-нибудь сказать заранее, до подписания актов и протоколов проведения приемо-сдаточных испытаний DLP, с какими недостатками и трудностями в работе DLP вы столкнетесь после внедрения «чудо-продукта»?
На этот вопрос полно и объективно не ответит ни один из представителей интегратора, работающих на проекте внедрения. Но это не значит, что он пытается вас обмануть или заставить поверить в универсальную «серебряную пулю». Многие нюансы из тех, что будут описаны ниже, всплывают и выясняются только после многомесячной эксплуатации DLP на реальном трафике. Инженеры компании-интегратора, приходящие на очередной «проходной проект» в вашу организацию, очень часто либо не имеют опыта эксплуатации DLP под реальной нагрузкой, либо ранее эксплуатировали другую версию этой же DLP, либо имеют небольшой практический опыт работы с решением от другого производителя, которое при прочих равных вело себя в «боевых условиях» несколько иначе, чем то, что в итоге успешно завершенного проекта развернуто у вас.
Этот обзор, надеюсь, будет вам интересен в том случае, если вы только собираетесь внедрить у себя в организации DLP – поднятые вопросы станут удачным дополнением к спецификации требований пользователя или техническому заданию на DLP имени любого приглянувшегося вам производителя. Отдельные моменты в обзоре покажутся знакомыми и любопытными, если вы самостоятельно и уже давно выбираете DLP-систему, прочитали на эту тему много статей в Интернете, возможно, что-то уже потрогали руками на стенде, ранее подписались на контекстную рассылку на профильных форумах по DLP, неоднократно посещали профессиональные конференции по информационной безопасности, обменялись визитками с инженерами отечественных и иностранных компаний – производителей решений класса DLP, готовитесь к очередной встрече или технической презентации понравившейся DLP и/или испытываете временные сложности с составлением перечня интересных вам и неудобных для представителей маркетинговых отделов и пресейла компании-интегратора DLP вопросов.
Оставим за рамками обзора ответы на вопросы, почему вы внедрили именно эту DLP, почему именно с таким количеством лицензий, зачем нужно было покупать модули DLP, которые по разным причинам вы не планировали использовать в дальнейшем, а также ответы на многие другие вопросы, учитывающие специфику именно вашей организации, и перейдем к обсуждению более общих, но не менее важных вопросов.
Некоторые эксперты предпочитают делить все аспекты работы DLP на технические и организационные. Но я для иллюстрации глубины проблемы введу иную классификацию. Разделим все нюансы постпроектного сопровождения на две большие группы: архитектурные (далее – А), т. е. те аспекты, которые при выявлении потребуют от производителя продукта доработок и/или внесения существенных изменений в структуру ядра DLP, и конфигурационные (далее – С), т. е. те настройки и уточнения, которые, будучи вами озвученными или формально указанными в техническом задании, могут быть выполнены инженерами в процессе внедрения и адаптации продукта у вас в организации, но про которые часто забывают или умалчивают для упрощения жизни всем.
Ретроспективный анализ данных (А)
В процессе проведения расследований инцидентов, выявленных, в частности, с помощью DLP-системы, требуется проверить ретроспективно материалы, ранее отнесенные и/или обрабатываемые потенциальным нарушителем. И тут, в отсутствие дополнительных систем мониторинга (назовем их первоисточниками информации), может возникнуть первый конфуз, связанный с ограничением по сбору и хранению информации как в базе данных с прямым доступом к событиям в DLP, так и в архиве событий DLP. Дело в том, что большинство DLP не собирают и не хранят всю проходящую через их компоненты (sniffer) информацию, а только фильтруют то, что соответствует выбранному критерию. Таким образом, не происходит фиксация всех возможных событий (например, тех атомарных событий, которые сегодня не подпали под критерий мониторинга, а завтра по различным причинам стали считаться инцидентами). То есть система DLP при недостаточном объеме свободного места на дисковой подсистеме хранения данных работает каждый день, как с чистого листа. Во многих DLP опция «перезатирать» самые старые данные новыми при заполнении 100% объема, выделенного для хранения данных каталоги (диска) на файловой системе, является настройкой по умолчанию.
Полнота оперативного архива – весь трафик или только подпадающий под критерии? (А)
Одной из возможных проблем в работе DLP является неполнота информации, собираемой компонентом DLP под общим названием «сниффер-анализатор потока трафика или потока событий из первоисточников». Простейшие сравнения количества событий с признаками инцидентов, выполненные запросом в базе данных системы-первоисточника и подобным запросом в базе данных DLP, могут выдавать совершенно разные результаты. Точно так же, как и проведенное по заранее подготовленному сценарию тестирование: отправка по электронной почте в Интернет писем, содержащих конфиденциальную информацию, и писем, выявленных в потоке сниффер-анализатором DLP по критериям, ранее настроенным инженерами и аналитиками производителя DLP, выявляет существенную разницу, к сожалению, не в пользу DLP. Таким образом, заявленные настройки и фильтры в DLP не всегда соответствуют реализованным в вашем проекте, и практически каждая из них требует детального анализа и тестирования на реальном потоке информации.
Глубина архива, максимально доступная из интерфейса (С)
В силу ограничений, связанных с выбранными производителями DLP смежными компонентами сторонних производителей, основной базой данных и форматами хранения событий, языком программирования и средой для разработки, в процессе эксплуатации DLP возникают ограничения по масштабируемости отдельных частей, которые негативным образом сказываются на производительности и скорости оперативного доступа к информации. К примеру, такое ограничение выражается в том, что одна из представленных на рынке РФ DLP физически не может оперативно индексировать и обрабатывать данные из поступающих к ней источников старше чем два месяца от текущей даты. Все данные, поступившие ранее указанного срока, автоматически архивируются и размещаются на архивное хранение без оперативного доступа, но с возможностью развертывания из архива на альтернативном контуре DLP в ручном режиме. Другая исследованная DLP при превышении объема хранения данных более 100 Гб и попытке построения индекса регулярно вызывает критичную ошибку базы данных (поток критичных ошибок в лог файл на UNIX-платформе), а на платформе MS Windows является причиной выпадения операционной системы в синий экран. Поэтому в процессе внедрения необходимо проверить корректность работы DLP на максимально доступных (пусть даже искусственно подготовленных специально для подобной проверки) объемах трафика и обрабатываемых данных.
Инструменты для формирования критериев по выявлению нарушений (С)
Важным аспектом эксплуатации DLP является возможность самостоятельно конфигурировать новые критерии для выявления событий с признаками инцидентов по оперативно и регулярно измененяемым параметрам. Если такая возможность в DLP отсутствует (т. е. DLP работает только по заранее определенным, запрограммированным на уровне кода отдельных модулей критериям и схемам анализа) или для настройки DLP под вашу задачу требуется каждый раз выпускать отдельное исправление и ставить обновление на компоненты DLP, то такая модель работы (потенциально, при увеличении объемов) не в полной мере будет соответствовать требованиям руководства компании к скорости выявления нарушений.
DLP как многопользовательская система (А, С)
Если в организации эксплуатацией DLP занимаются только одно подразделение, один-два сотрудника и больше никто, то вопрос многопользовательского доступа к интерфейсу системы может и не возникнуть. Однако в том случае, когда процесс расследования событий с признаками инцидентов требует привлечения представителей сторонних подразделений или функции по проведению анализа и расследования, необходимо делегировать экспертам профильного подразделения, наличие в DLP ролевой модели и возможности разграничения доступа к решению как на уровне учетных записей, так и на уровне данных (по маске, времени, типу первоисточника, типам файлов или фильтрам) будет рассматриваться как дополнительное преимущество данной DLP по отношению к ее аналогам и конкурентам.
Алгоритм обучения DLP (А, С)
Не все события с признаками инцидентов информационной безопасности можно детектировать и предотвратить с помощью DLP (например, инциденты с утечками данных с прикладного уровня или с использованием инструментов стеганографии – побитовое копирование документа в контент картинки). Для их своевременного выявления созданы другие технические решения. Но очень часто по результатам внешней экспертизы появляются новые признаки и критерии, выявление присутствия которых на потоке может быть поручено DLP. Таким образом, достаточно регулярно возникает потребность на базе подтвержденного бизнесом, но ранее не выявленного DLP инцидента информационной безопасности сформировать технические признаки и принудительно обучить DLP выявлять в потоке трафик, формально соответствующий именно этим признакам. Алгоритм и интерфейс для обучения должны быть реализованы в DLP. Но чаще возникает аналитическая задача, которая требует на базе обозначенного извне (по отношению к DLP) события, ранее не признанного как инцидент, сформировать критерии, понятные для DLP, и реализовать их поддержку в процессе работы самой DLP. Для этого инженеры компании- интегратора или производителя DLP должны предоставить заказчику соответствующие инструкции и интерфейсы по дообучению или переконфигурированию DLP.
Способы несанкционированной деактивации DLP-агентов на рабочих станциях (А, С)
Для отдельных DLP-решений по состоянию на I квартал 2017 г. не решен вопрос защиты от деактивации агентского программного обеспечения без уведомления и санкции со стороны офицера информационной безопасности, ответственного за сопровождение DLP. В ситуации, когда пользователь рабочей станции или дополнительное программное обеспечение (например, антивирус) в процессе работы имеет возможность путем переименования запускаемого приложения или выгрузки подозрительной службы из памяти рабочей станции умышленно или случайно остановить работу DLP-агента, вопрос «самозащиты» этого агента становится достаточно критичным. Если DLP-агент помимо исключительно функции мониторинга выполняет на такой рабочей станции функции контроля и блокировки доступа, выгрузка его из памяти (по различным причинам) автоматически влечет за собой реализацию риска утечки чувствительной информации. Другим объектом воздействия пользователей подконтрольных рабочих станций на практике становится локальный текстовый файл-журнал событий DLP-агента, нахождение которого локально на жестком диске подконтрольного устройства может быть продиктовано либо нестабильными каналами связи между рабочими станциями и центральным сервером DLP, либо характером разъездной работы (с ноутбуком) подконтрольного лица. Известны случаи умышленного удаления этого файла-журнала пользователей для скрытия фактов копирования чувствительной информации на съемный носитель.
Способы снижения количества ложных срабатываний (С)
Вопрос формирования критериев для выявления в организации событий с признаками инцидентов информационной безопасности является индивидуальным на каждом конкретном проекте по внедрению DLP. Однако некоторые производители DLP позиционируют свои решения как универсальные и предлагают заранее предустановленный набор критериев и правил, которые они ранее использовали на других проектах и которые, по их заверению, позволят заказчикам быстро достичь желаемой цели. Базовая проверка таких критериев в организации либо неожиданно дает хороший результат – инцидентов по данным признакам нет, либо количество событий с признаками инцидентов превышает допустимые нормы, а их проверка в 100% случаев характеризует ложные срабатывания.
Какую бы DLP-систему вы ни выбрали для своей организации, необходимо четко понимать, для решения какой конкретной задачи данная система вам нужна. Универсальной «серебряной пули» не бывает. Рассчитывать на известность бренда или на корректность работы системы в режиме «автопилота» при любых условиях в случае с решениями класса DLP не приходится. Как правило, эффективность работы DLP напрямую зависит от уровня компетенции офицеров информационной безопасности, которые ее сопровождают и настраивают. В качестве аргумента для руководства в поддержку необходимости внедрения DLP в организации не следует использовать громкие фразы из маркетинговых брошюр интеграторов или производителей DLP-решений. Чаще всего неожиданная интерпретация уникальных возможностей DLP, озвученная вами в диалоге с менеджером, является маркетинговой уловкой и попыткой привлечь внимание к одному из многочисленных DLP-решений.
Заключение
Важно понимать, что даже при наличии развернутой, корректно настроенной и давно эксплуатируемой в вашей организации DLP не следует отказываться от внедрения других организационно-технических мер защиты. Только при комплексном подходе, одной из составных частей которого является DLP, ваша система защиты информации выдержит все внешние и внутренние атаки и своевременно и адекватно отреагирует на них.
Задачи DLP
Десять задач, продиктованных (по мнению производителей DLP) представителями бизнес-подразделений, для решения которых каждой организации может потребоваться современное решение класса DLP.
- Обнаружение в потоке фактов несанкционированной передачи защищаемой информации.
- Блокировка возможных технических каналов утечки информации.
- Выявление, систематизация и учет нарушений работниками политики безопасности компании.
- Выявление следов нарушений и совершения работниками организации противоправных действий (в том числе на экономической, политической, религиозной и иной почве):
- защита от убытков, связанных с утечками информации;
- разоблачение мошеннических схем и саботаж.
- Фиксация фактов некорпоративного (неэтичного) поведения работников.
- Прогнозирование и выявление возможных проблем с сотрудниками компании:
- повышение продуктивности служащих;
- стимуляция соблюдения трудовой дисциплины и рабочего регламента;
- выявление связей между сотрудниками и внешним миром;
- управление лояльностью коллектива и выявление негативных настроений.
- Выполнение требований регуляторов и достижение соответствия положениям стандартов.
- Потоковая категоризация обрабатываемой информации.
- Составление архива событий с признаками инцидентов информационной безопасности:
- контроль расхода ресурсов организации;
- упрощение процесса инвентаризации оборудования и его мониторинга.
- Анализ потоков данных и хранимой информации.
Мифы DLP
Семь громких заявлений, которые использовали представители компаний – производителей DLP для рекламы и продаж своих решений в отечественные компании в 2016–2017 гг.:
- «Наш DLP единственный перехватывает трафик от программного обеспечения Skype».
По факту: один из компонентов DLP должен быть проинсталлирован в формате агента (вопрос совместимости) на рабочую станцию с установленным Skype-клиентом; после запуска (в формате приложения или сервиса – зависит от версии операционной системы) агент перехватывает клавиатурный ввод и вложения через соответствующие прерывания или работает в режиме локального прикладного прокси-сервера;
- «Наш DLP работает в прозрачном для пользователя режиме».
По факту: в структуре DLP-решения могут присутствовать компоненты, позволяющие собирать атомарные события с признаками инцидентов с сетевого оборудования и баз данных на профильных серверах (первоисточниках) без установки дополнительного агентского программного обеспечения на все рабочие станции сотрудников в организации;
- «Компоненты нашего DLP-решения исследуют содержимое всей переписки по электронной почте работников организации».
По факту: сбор и анализ отдельными компонентами DLP осуществляются только для писем, направленных по стандартным (не защищенным внешними наложенными средствами – VPN/TLS/применение RAR с паролем или сертифицированных СКЗИ для защиты вложения, не проприетарным – например, LOTUS) протоколам передачи почтовых сообщений в/из сети Интернет. Если в MIME содержится нестандартное вложение, то такое письмо либо не проверяется, либо отбрасывается в пул «нестандартных» для дополнительного анализа в ручном режиме офицером информационной безопасности компании. Причем если внутренняя переписка (внутренний документооборот в компании) осуществляется с использованием нетиповых (не SMTP-ориентированных) протоколов, корректная настройка DLP на предмет анализа внутренних потоков значительно затрудняется (по времени), вплоть до выполнения соответствующих доработок за счет заказчика проекта;
- «Наш DLP предотвращает возможные утечки в/из облачных хранилищ данных».
По факту: при наличии установленного DLP-агента на рабочей станции, файловая система или отдельные приложения на которой синхронизируют содержимое локальных каталогов с соответствующими местами хранения в облаках, DLP-агент собирает эту информацию и предоставляет для анализа на центральные серверы DLP. При этом количество поддерживаемых версий операционных систем для стационарных и мобильных устройств, лист совместимости DLP-агента с прикладными приложениями, использующими облачное хранение данных, крайне малы и ограничиваются только наиболее распространенными версиями;
- «Наш DLP контролирует все возможные каналы утечки информации из вашей организации».
По факту: это утверждение в большей степени ориентировано на нетехнического специалиста или на лицо, принимающее решение о закупке. Участникам технологического процесса в организации понятно, что большинство чувствительной для бизнеса информации хранится не в файлах на рабочих станциях и не передается по электронной почте или на USB-flash-накопителе, а сосредоточено в единых информационных системах (CRM, ERP, АБС и т. д.), которые намного сложнее контролировать и присутствие DLP-агентов на серверах которых ограничено технологически;
- «Наш DLP может самостоятельно обучаться по контексту инцидентов и прогнозировать возможные угрозы».
По факту: в состав некоторых представленных на рынке в России DLP-решений входит модуль, позволяющий согласно документации к нему обработать большой объем файлов и материалов инцидентов и на выходе предоставить аналитикам готовые признаки и сигнатуры для выявления подобных инцидентов в потоке. И этот DLP-модуль даже где-то запускается. После получения сформированных таким образом критериев и признаков для основной DLP-системы и их прогрузки дальнейшее использование DLP становится крайне затруднительным, поскольку количество ложных срабатываний по данным признакам приближается к 100%. Термин прогнозирования возможных угроз чаще всего означает, что система DLP в своем основном интерфейсе может различными цветами подкрашивать сообщение о выявленных событиях с признаками инцидентов;
- «Наш DLP не требует дополнительных ресурсов от рабочей станции, на которой он установлен».
По факту: DLP-агент при отсутствии действий со стороны пользователей на контролируемом устройстве действительно находится в режиме ожидания и требует минимального количества оперативной памяти. Как только пользователь начинает выполнять действия, для контроля которых был установлен этот DLP-агент, его загрузка становится существенно выше и при определенных условиях значительно снижает производительность устройства, на котором он установлен. В такой ситуации на ум приходит «техническая присказка» начала 2000-х: если вы думаете, что купили себе быстрый компьютер, поставьте на него антивирусное программное обеспечение от одного известного отечественного производителя.
