Безопасность Корпоративной Информации
 

Как предотвращать утечки информации через Skype в связи с появлением в нем сквозного шифрования?

В январе этого года Майкрософт начали тестирование сквозного end-to-end шифрования для передачи данных по Скайпу. Эта функция получила название “Частные беседы” (“Private Conversation”). Шифрование работает для звонков, текстовых сообщений, а также для файлов. Используется протокол Signal, разработанный некоммерческой организацией Open Whisper Systems.

Летом данный функционал уже попал в insider preview сборки новейшей на тот момент 14-й версии Скайпа, а чуть позднее появился и в 8-й версии.

Безусловно, в Скайпе и до появления “Частных бесед” использовалось шифрование, но это не было шифрованием канала между двумя пользователями, на ключах, выработанных только для их конечных устройств. Фактически для обычного общения Скайп использует TLS-протокол, который «накрывает» канал между пользователем и облаком Скайпа. Тут необходимо отметить, что до покупки этого мессенджера Майкрософтом в Скайпе использовалось AES-шифрование канала с 256-битными сессионными ключами, но потом от этого полностью отказались.

Практически все современные системы предотвращения утечек данных (DLP-системы) научились отслеживать (а некоторые даже и контролировать) обычную передачу сообщений и файлов в Скайпе. Для решения этой задачи используют стандартный прием - подмену сертификатов, известную как атака «человек посередине» (MitM). Однако, для “Частных бесед” этот трюк уже не работает. Не получится просто так взять и «встать» посередине протокола Signal.

В связи с этим перед DLP-системами встает реальная проблема – как перехватывать “Частные беседы” и предотвращать утечку данных через один из самых популярных мессенджеров?

Конечно всегда есть железобетонный способ - не замечать данного канала утечки, везде заявляя, что контроль Скайпа продуктом поддерживается. Это чисто маркетинговый подход, свойственный псевдо-DLP. В сущности, подмена понятий в таких решениях идет уже с самого начала – заявляя контроль Скайпа (и других каналов утечки данных), производитель на самом деле имеет ввиду пассивный мониторинг, без возможности осуществлять полноценный контроль передаваемых файлов и сообщений на лету. Грубо говоря, остановить утечку такое псевдо-DLP не может, а вся его функция сводится к сбору доказательной базы.

Команда разработчиков DeviceLock смогла найти техническое решение, позволяющее нашей DLP-системе полноценно контролировать “Частные беседы” в Скайпе. Особо подчеркну, что в данном случае речь идет именно о контроле, а не о пассивном мониторинге. DeviceLock DLP может в реальном времени принимать решение о разрешении или запрещении передачи файлов и сообщений в зависимости от их содержимого и заданных для данного пользователя политик безопасности.

Рассмотрим на реальном примере, как запрещается передача сообщений, содержащих адреса электронной почты или файлы с ИНН в “Частной беседе”.

- Создаем два правила для протокола Skype, запрещающие адрес электронной почты и ИНН в исходящих файлах и сообщениях.

- Пробуем сообщением передать адрес электронной почты в “Частной беседе”.

Передача адреса электронной почты в Частной беседе Skype

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

Теневая копия сообщений из Частной беседы Skype, созданная DeviceLock DLP

- Теперь попробуем в “Частной беседе” передать два файла, один из которых содержит ИНН.

Передача файлов в Частной беседе Skype

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

Теневая копия файла из Частной беседы Skype, созданная DeviceLock DLP

Этот простейший пример применения контентной фильтрации в режиме реального времени демонстрирует способность DeviceLock DLP полноценно контролировать передачу данных в Скайпе даже при условии применения им сквозного шифрования в “Частных беседах”.

Автор: Ашот Оганесян