DLP для конечных точек как инструмент комплаенса: требования регуляторных органов

Регуляторные нормы, в частности GDPR, HIPAA, PCI DSS, NIS2 и ISO 27001, требуют от компаний контролировать движение чувствительных данных и фиксировать случаи их неправомерного использования. Письменные процедуры обеспечивают лишь незначительную защиту от этого риска. DLP для конечных точек добавляет техническое средство контроля непосредственно на устройстве, которое может предупреждать, блокировать или регистрировать активность до того, как данные попадут в запрос к ИИ, личный почтовый ящик, на USB-накопитель или в облачное хранилище. Кроме того, это обеспечивает DPO или CISO доказательной базой, которая требуется во время аудитов и реагирования на инциденты безопасности.

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

Какие регуляторные нормы определяют ответственность за защиту данных?

Соответствующий список зависит от конкретной отрасли и региона, но базовое требование остается неизменным. Наиболее распространенными являются следующие 10 нормативов:

Регуляторная нормаСфера примененияОсновная обязанность в отношении данных
GDPRПерсональные данные резидентов ЕСНадлежащие технические и организационные меры безопасности; уведомление органа власти о нарушении в течение 72 часов
CCPA/CPRAПерсональная информация резидентов КалифорнииОбоснованные методы безопасности для защиты персональной информации
HIPAAЗащищенная медицинская информация (PHI) в СШАМеры защиты электронной PHI в соответствии с Правилами безопасности (Security Rule)
PCI DSSДанные платежных картЗащита хранимых и передаваемых данных учетных записей
GLBAФинансовые учреждения СШАМеры защиты финансовой информации клиентов
NIST SP 800-53Федеральные системы США, широко используется как базовый стандарт в других сферахКаталог средств контроля, охватывающий принудительное управление потоками информации
NIST SP 800-171 / CMMCПодрядчики оборонных и федеральных ведомствЗащита контролируемой несекретной информации (CUI) в нефедеральных системах
ISO/IEC 27001Организации, сертифицирующие систему управления информационной безопасностью (СУИБ)Приложение A содержит средство контроля для предотвращения утечки данных
NIS2Существенные и важные субъекты в ЕСУправление рисками кибербезопасности и отчетность об инцидентах с ранним предупреждением в течение 24 часов
DORAФинансовые учреждения ЕС и их поставщики ИКТУправление рисками ИКТ и отчетность об инцидентах; применяется с января 2025 года

Хотя формулировки различаются, общая тенденция остается неизменной: требуется обеспечение защиты данных, контроль их перемещения и способность восстановить ход событий в случае инцидента. В двух стандартах этот механизм контроля указывается прямо. Стандарт ISO/IEC 27001:2022 содержит отдельный контроль по предотвращению утечки данных (A.8.12), тогда как в NIST SP 800-53 предусмотрен механизм принудительного регулирования информационных потоков (AC-4).

Кто несет эту ответственность?

Генеральный директор, уполномоченный директор по информационной безопасности (CISO) или офицер по защите данных (DPO) сталкиваются со сложной задачей: обеспечить соблюдение комплаенс-требований и предоставить оценку рисков с соответствующим планом их снижения.

Регламентирующие процедуры внедряются в первую очередь, что вполне оправдано. Политики приемлемого использования, правила обработки информации и тренинги способствуют снижению рисков. В то же время они не влияют напрямую на IТ-системы, обрабатывающие чувствительные данные. Наличие правила с запретом на отправку клиентских баз на личную почту не станет препятствием для переутомленного сотрудника в пятницу вечером.

Практика показывает, что наиболее незаметные утечки возникают изнутри организации. Это происходит либо из-за некорректного перемещения данных самими пользователями, либо из-за действия вредоносного программного обеспечения на их устройствах. В обеих ситуациях данные покидают периметр через непредусмотренные компанией каналы, тогда как основной фокус сосредоточен на официальных инструментах — электронной почте, SharePoint, локальных или облачных хранилищах. Новейшей тенденцией является применение ИИ: вставка чувствительных текстов в запросы к чат-ботам или использование агентов с доступом к файлам.

Почему целесообразно применять контроль на конечной точке?

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

Решения DLP на конечных точках функционируют непосредственно в рабочей среде пользователя. Они способны отреагировать еще до момента прикрепления файла к запросу в ИИ или к личной почте. Это существенно меняет выводы DPO при анализе инцидента: данные ни разу не покидали периметр.

Каким критериям должно отвечать эффективное решение DLP на конечных точках?

При выборе решения рекомендуется проверять следующие восемь пунктов:

  1. Современные каналы связи, в частности ИИ. Решение должно охватывать теневой ИИ и новых облачных провайдеров, наряду с традиционными ежедневными каналами: печатью, локальными и сетевыми хранилищами, съемными носителями и электронной почтой.
  2. Гранулярные сценарии использования. Единого корпоративного правила обычно недостаточно. Система должна по-разному реагировать в зависимости от отдела, роли, канала и типа транзакции.
  3. Все рабочие операционные системы. Поддержка должна включать Windows и macOS, а также дистрибутивы Linux, с которыми работают инженеры.
  4. Охват, не зависящий от конкретных приложений. Сегодня пользователи имеют возможность самостоятельно выбирать браузеры. Решение, способное контролировать исключительно утвержденные производителем приложения, обеспечивает крайне низкую видимость.
  5. Обучение и автоматизированное реагирование. Оповещение, разъясняющее причины нарушения политики, чаще всего оказывается эффективнее безоговорочной блокировки.
  6. Шифрование при выходе данных за периметр. Отдельные процессы передачи являются оправданными (например, отправка чувствительных файлов партнеру или их сохранение на USB-диск). Качественное решение позволяет разрешить передачу с одновременным шифрованием данных, избегая категоричного выбора между блокировкой и полной открытостью.
  7. Быстрое развертывание с потенциалом для масштабирования. Затяжные внедрения и проблемные пилотные запуски часто приводят к стагнации проектов DLP. Рекомендуется стартовать с одного сценария и постепенно его масштабировать в соответствии с изменениями в требованиях IТ и комплаенса.
  8. Оперативная отчетность. События должны трансформироваться в инциденты в рамках самого продукта или экспортироваться в SIEM либо SOAR с помощью API для дальнейшего расследования и координации реагирования аналитиками.

Какое место занимает Netwrix Endpoint Protector?

Netwrix Endpoint Protector является корпоративным решением DLP, построенным на базе приведенных критериев. Система гарантирует соблюдение контентно-зависимых политик на конечных точках под управлением Windows, macOS и Linux, контролируя такие каналы коммуникации, как съемные носители, печать, электронная почта, облачные хранилища и инструменты ИИ, и в то же время сохраняет свою работоспособность на устройствах без доступа к сети. Функционал политик позволяет мониторить активность, генерировать оповещения или блокировать транзакции. Функция принудительного шифрования применяет алгоритмы уровня FIPS к данным во время их записи на согласованные USB-диски, тогда как инструмент eDiscovery осуществляет проверку памяти конечных точек для выявления неактивных чувствительных данных.

Главный вывод: наличие политик не решает проблему

Когда аудитор или регулятор интересуется механизмами подтверждения того, что чувствительные данные не выходят за пределы периметра, одни лишь задокументированные процедуры не станут убедительным аргументом. Целесообразно проверить текущий инструментарий, задав один ключевой вопрос: способна ли система заблокировать конкретный файл непосредственно во время его загрузки в запрос к ИИ или в личную почту? В случае отрицательного ответа фиксируется пробел в защите.

Получить демоверсию Netwrix Endpoint Protector

Подписаться на новости