Как-то раз попалось мне на глаза любопытное судебное дело, связанное с утечкой информации. Инцидент был интересен тем, что опровергал сразу несколько мифов о корпоративной информационной безопасности:
за слив информации можно получить только условный срок;
сумма штрафа, если его вообще дадут, будет символической;
инсайдеры не выдумывают каких-либо хитростей для выноса информации, предпочитая действовать напролом.
Решил реконструировать этот инцидент, основываясь на материалах дела. Поэтому «всё выдумано, а совпадения случайны». Тем не менее, под катом яркая история о том, как сотрудник с условными ИО «Иван Денисович» смог вынести информацию за периметр немалой (на самом деле очень крупной) компании, каким образом его вычислили и чем доказали в суде виновность. Для тех, кто больше предпочитает смотреть, есть видео-версия.
Также бонусом покажу, как можно было бы предотвратить «вынос тела», не нахватав при этом ложных сработок.
Миссия выполнима: как инсайдер выносил ПДн
Иван Денисович занимал немалую должность в банке – целый начальник отдела продаж. Но несмотря на это, решил обогатиться не совсем законным путём. На «пробив» размениваться не хотелось. Поэтому было принято решение умыкнуть клиентскую базу. Благо доступ к ней был в силу служебной необходимости.
Главной мишенью стала одна из АИС (автоматизированная информационная система), из которой можно было выгрузить данные о клиентах: ФИО, паспортные данные, дату рождения, адрес места жительства, номер мобильного телефона, полный номер кредитной карты, место работы, остаток собственных средств и т.п.
Учитывая полноту сведений, Иван Денисович предварительно оценил стоимость одной строки в 5 рублей. Чем больше строк – тем больше денег. Потенциальная выручка – миллионы или даже десятки миллионов рублей. Видимо, удержаться от искушения не представлялось возможным. Разработав план, Иван Денисович приступил к его осуществлению.
Этап 1. АИС-Сетевой каталог-Компьютер №1-Компьютер №2
Учитывая, какие сведения содержала АИС, доступ к ней предоставлялся не всем. Система находилась в закрытом сетевом сегменте «Alpha», а совершать те или иные действия пользователи могли только со специальных АРМов (автоматизированных рабочих мест). По служебным обязанностям Иван Денисович имел доступ в этот сегмент, поэтому он спокойно воспользовался АРМом (на схеме ниже обозначен как «Компьютер №1»), отправив с него команду на формирование выгрузки данных. Система сформировала архив почти на 6 ГБ, который сотрудник и скачал.
Что ж. Начало положено, но до успеха было ещё далеко. Из сегмента «Alpha» в общий корпоративный сегмент сети данные можно было передать только с помощью «корпоративного файлового перекладчика» (однонаправленного шлюза). Иван Денисович точно не знал, но наверняка догадывался, что информацию в организации как-то защищают. Поэтому, для подстраховки, перед использованием однонаправленного шлюза он предпринял некоторые меры предосторожности:
Переименовал архив в «выпускной2.mp4» (возможно, руководствовался тем, что 6 ГБ архив с текстовой информацией привлечёт внимание, а с фильмом – нет).
Создал из получившегося «фильма» многотомный запароленный архив.
Дело в том, что файловый перекладчик (шлюз) имел лимит в 25 МБ. Зачем нужен был пароль? Скорее всего, чтобы воспрепятствовать автоматическому анализу. К примеру, некоторые DLP-системы вообще не умеют работать с многотомными архивами, другие – могут определить только, какой файл летит (зашифрованный, многотомный, битый и т.п.). Наша, например, умеет «собирать» многотомный архив, открывать его, индексировать то, что внутри и проверять извлечённое содержимое на предмет нарушений политик безопасности. Однако ни одна DLP-система (по крайней мере из известных мне) не умеет подбором паролей расшифровывать многотомные архивы, после проверять их и поднимать тревогу.
Как бы то ни было, Иван Денисович успешно переслал 187 частей архива на Компьютер №2.
Компьютер №2 – это ПК, который стоял в переговорке и чаще всего использовался для проведения планёрок. В принципе, на нём информация могла бы и закончить свой путь, если бы там были открыты USB-порты. Иван Денисович хотел слить данные именно на флешку. Почему – загадка. Может с Компьютера №2 тоже не было выхода в интернет. Может выход был, но каналы контролировались DLP-системой.
В любом случае у Ивана Денисовича была какая-то тактика и он её придерживался. Нужно было передать данные на корпоративный командировочный ноутбук (Компьютер №3), на котором, в силу служебной необходимости, USB-порты были открыты. Но как это сделать, не привлекая внимания систем защиты и санитаров? Решение проистекало из начальных условий. Есть Компьютер №2 и Компьютер №3. На обоих установлен почтовый клиент (Outlook), на обоих в клиенте настроен доступ к его корпоративному почтовому ящику. Вывод? Попробовать Foldering.
Foldering – техника общения, использующая черновики электронных писем. На корпоративный лад Иван Денисович адаптировал её следующим образом:
На Компьютере №2 создаётся новое письмо. В качестве вложения прикрепляется часть многотомного архива.
Письмо сохраняется в качестве черновика и синхронизируется с почтовым сервером.
На Компьютере №3 открывается почтовый клиент. Черновик письма «подтягивается» с почтового сервера.
На Компьютере №3 черновик открывается, вложение сохраняется.
Повторить предыдущие пункты ещё 186 раз.
Таким образом, информация оказалась на командировочном ноутбуке, была записана на флешку и успешно вынесена за пределы организации.
Вся схема целиком.
Как обнаружили утечку
В данном случае, увы, нашли только постфактум. Иван Денисович вынес информацию и опубликовал на нескольких площадках объявление о продаже. По заведённой традиции, на подобных ресурсах на слово джентльмену не верят и просят ответить делом. То есть, предоставить образец данных. Этот образец и заполучила служба безопасности банка.
Проведя анализ, пришли к выводу, что это не компиляция, а реальная утечка. И завертелось. Департамент ИБ, движимый Жёстким Ощущением Приближающегося Апокалипсиса (далее, ЖО… нет, пожалуй, тут без аббревиатуры обойдёмся) смог быстро (в пределах суток) восстановить всю цепочку событий. Было принято решение довести дело до суда.
Расследование и раскаянье
Теперь перейдём к расследованию и к тому, как компании удалось доказать в суде, что Иван Денисович вынес информацию. Компактно собрал основные тезисы на схеме.
Пояснения в студию. Всё началось с логов SIEM-системы. По ним установили факт запросов с Компьютера №1 (из-под определённой учётки) к АИС на формирование выгрузки, а также факт обращения к сетевому каталогу (куда был выгружен архив информации из АИС).
Далее исследовали жёсткий диск Компьютера №1. С помощью софта для восстановления данных удалось восстановить все файлы и понять последовательность действий Ивана Денисовича. На руку сыграло и то, что Компьютер №1 не так часто использовался и доступ людей к нему изначально ограничен. Таким образом, был найден архив и его многотомная запароленная копия. Была доказана идентичность содержимого архивов (история умалчивает, откуда взяли пароль, но хочется верить, что Иван Денисович сказал его в порыве раскаяния, а не после терморектального криптоанализа).
Затем анализировались логи однонаправленного шлюза. Из них стало понятно, куда дальше передавались данные (в сетевую папку). Из других логов выяснили, кто обращался к папке (обращался Компьютер №2). Анализируя его HDD нашли части многотомного архива. Идентичность этих частей с частями из Компьютера №1 подтвердили, сравнив хеши.
Настал черёд Компьютера №2. Вывод об использовании почты, скорее всего, был сделан на основании перехвата из DLP-системы. В материалах дела также отмечалось, что «черновики писем на тот момент не проверялись системой защиты от утечек». Как же тогда доказать использование почтового сервера? Безопасники решили следовать принципу «Бритва Оккама» и не прогадали.
Из Компьютера №2 и Компьютера №3 изъяли HDD. На них нашли профиль сотрудника в почтовом клиенте (.odt). Посмотрели, осталось ли что-либо в черновиках (не осталось). Посмотрели, осталось ли что-либо в разделе «Удалённые» (осталось!). Иван Денисович, похоже, забыл, что при нажатии кнопки «Удалить» письмо на самом деле не удаляется, а перемещается в «корзину», откуда, как правило, удаляется автоматически спустя 30 дней.
Таким образом, были найдены части многотомного архива на всех трёх компьютерах. Учитывая, что у файлов есть ещё метки создания и его изменения, была восстановлена хронология событий.
Не до конца понятно (лично мне), как же компания доказала, что информация передавалась на флешку. В материалах сказано, что «исследованием журнала событий ПО «Sysmon» выявлены события, указывающие на копирование файлов многотомного архива» на USB-накопитель.
Вот такая история. Но это ещё не конец.
Как можно было не запустить ситуацию до слива?
Теперь попробуем разобраться, можно ли было предотвратить слив правильно приложенными усилиями (ПО, как вы помните из кейса, в пострадавшей компании работало, но «прилажено» было «не той стороной». Так что давайте сделаем «работу над ошибками» и обсудим, что надо было сделать, чтобы осечек не случалось).
Но начнём с небольшой теории. Если брать линию жизни инцидента, я выделяю 2 стадии перед попыткой инсайдера вынести информацию:
Стадия формирования намерений.
Стадия накопления информации.
Графически можно представить так:
В свою очередь стадию накопления информации можно разделить на 3 шага:
Запрос к «БД»;
Экспорт информации в виде файла (трансформация информации);
Пересылка файлов в сторону внешнего мира.
И их всегда 3, больше выделить не получится. Например, возьмём пробив. Сотрудник работает у оператора сотовой связи. К нему пришёл друг и просит детализацию разговоров третьего лица. Сотрудник запрашивает детализацию (1 пункт), фотографирует на телефон – трансформация информации и появление её в виде файла, но уже на устройстве (2 пункт). И наконец, отправляет другу через Телеграм (3 пункт).
Теперь к практике. В схеме Ивана Денисовича была комбинация из всех трёх пунктов. Как должно было отработать защитное ПО.
Самый первый запрос к АИС могла бы отследить DAM-система. Но если действия сотрудника вписывались в легитимный сценарий, превентивно действовать на этом этапе не получилось бы. Поэтому пойдём по цепочке дальше.
В нашей истории информация последовательно появлялась у человека на жёстком диске на компьютере 1, 2 и 3. За работу с информацией в покое отвечает класс решений DCAP (в нашей линейке продуктов это FileAuditor). Посмотрим, что с его помощью можно было бы сделать.
Одной из задач системы является выявление и маркировка новой информации, подпадающей под настроенные контентные правила. К примеру, нам нужно отслеживать появление документов с персданными на Компьютере №1.
Создаём правило, которое поможет находить и помечать информацию, содержащую ПДн. В условиях прописываем регулярное выражение для «номера карты» и устанавливаем порог входа (50 цепочек).
Далее продолжаем задавать ограничения, ограничивая применение правила: искать 50 номеров кредиток система будет только в указанных форматах файлов (можно указать и по типу, и по сигнатуре).
Правило при необходимости можно сделать и сложнее: например, чтобы были только свежие документы, с определённым именем, чтобы правило применялось только к определённым компьютерам и т.п.
При работе данного правила безопасник будет получать уведомления об обнаруженных файлах. Так, если воспроизвести действия Ивана Денисовича (скачать архив с персданными, а затем его переименовать), мы увидим, что система проставила метки на файлы «reconstruction.rar» и «футбол.mp4». Взглянем на журнал операций, зафиксированных по первому файлу.
Первое зафиксированное действие по «reconstruction.rar» (нижняя красная черта) – скачивание архива через Chrome. При скачивании браузер сперва присваивает информации служебное имя. После завершения скачивания информация помещается туда, куда выбрал пользователь. Отсюда и записи в столбце «Старое имя». Если посмотреть выше (верхняя красная черта), то увидим, как человек перенёс файл из папки «Downloads» в папку «Dramatic Reconstruction».
Теперь взглянем файлом «футбол.mp4». Откуда на нём вдруг взялась метка про персданные? Станет понятно, если подгрузить операции по файлу.
Видно (надеюсь), что имело место переименование. Пользователь просто поменял «reconstruction.rar» на «футбол.mp4». Но парсеру-то всё равно на название. Поэтому и появилась метка.
Следующим действием Ивана Денисовича было создание многотомного запароленного архива. Так как FileAuditor проставляет метки в файловой системе, а не внедряет их непосредственно в файлы, понадобится создать новое правило. Система будет проставлять метку на документы определённых форматов, но только если они запаролены.
В результате окажутся помечены нужные нам архивы.
Теперь, когда метки проставлены, можно сформировать правила, по которым помеченная информация будет распространяться. Иван Денисович передавал архивы с Компьютера №2 на Компьютер №3 с помощью корпоративного почтовика. Это можно предотвратить, запретив передачу запароленной информации.
В правиле можно много чего указать, но нам достаточно выбрать запрещающее действие, указать список процессов, а также метку. В итоге логика следующая: запрещено передавать через почтовые клиенты файлы с указанной меткой.
В результате работы правила пользователь не сможет в том числе и сохранить черновик письма, если в качестве вложения прикрепит помеченный системой (запароленный архив) документ.
Но важнее не только уметь что-то блокировать, но и знать, что было заблокировано. Крайне важен аудит (поэтому он и был включён при создании запрещающего правила). Внизу на скрине зафиксировано 3 попытки прикрепить вложение к письму. Это может служить подтверждением намерения сотрудника вынести информацию.
Наконец, финальный аккорд плана Ивана Денисовича – запись информации с Компьютера №3 на флешку. Здесь можно было бы действовать как DCAP-системой, так и DLP. Рассмотрим последнюю.
Во-первых, можно включить шифрование записываемой информации на USB-накопители. Если же по какой-то причине этого делать не хочется, можно не давать записывать сотруднику файлы с помощью контентной блокировки. Настраивается очень просто и похоже на то, что мы делали в FileAuditor. Создаём правило «не писать на флешку» и выбираем «блокировать файлы, защищённые паролем».
Естественно, включаем аудит, чтобы подтвердить намерения пользователя. Все попытки зафиксированы.
Чему нас учит этот инцидент? Во-первых, вновь работает аксиома «инцидент легче предотвратить, чем разгребать последствия». Во-вторых, внутри компании угрозы не менее опасны, чем снаружи. Ну и в-третьих, комплексный подход – рулит. Не нужно ломать голову и ворошить ПК, когда есть инструменты, которые делают расследование легким, удобным и без нервов.
