Как-то раз попалось мне на глаза любопытное судебное дело, связанное с утечкой информации. Инцидент был интересен тем, что опровергал сразу несколько мифов о корпоративной информационной безопасности:
за слив информации можно получить только условный срок;
сумма штрафа, если его вообще дадут, будет символической;
инсайдеры не выдумывают каких-либо хитростей для выноса информации, предпочитая действовать напролом.
Решил реконструировать этот инцидент, основываясь на материалах дела. Поэтому «всё выдумано, а совпадения случайны». Тем не менее, под катом яркая история о том, как сотрудник с условными ИО «Иван Денисович» смог вынести информацию за периметр немалой (на самом деле очень крупной) компании, каким образом его вычислили и чем доказали в суде виновность. Для тех, кто больше предпочитает смотреть, есть видео-версия.
Также бонусом покажу, как можно было бы предотвратить «вынос тела», не нахватав при этом ложных сработок.
Миссия выполнима: как инсайдер выносил ПДн
Иван Денисович занимал немалую должность в банке – целый начальник отдела продаж. Но несмотря на это, решил обогатиться не совсем законным путём. На «пробив» размениваться не хотелось. Поэтому было принято решение умыкнуть клиентскую базу. Благо доступ к ней был в силу служебной необходимости.
Главной мишенью стала одна из АИС (автоматизированная информационная система), из которой можно было выгрузить данные о клиентах: ФИО, паспортные данные, дату рождения, адрес места жительства, номер мобильного телефона, полный номер кредитной карты, место работы, остаток собственных средств и т.п.
Учитывая полноту сведений, Иван Денисович предварительно оценил стоимость одной строки в 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. Создаём правило «не писать на флешку» и выбираем «блокировать файлы, защищённые паролем».
Естественно, включаем аудит, чтобы подтвердить намерения пользователя. Все попытки зафиксированы.
Чему нас учит этот инцидент? Во-первых, вновь работает аксиома «инцидент легче предотвратить, чем разгребать последствия». Во-вторых, внутри компании угрозы не менее опасны, чем снаружи. Ну и в-третьих, комплексный подход – рулит. Не нужно ломать голову и ворошить ПК, когда есть инструменты, которые делают расследование легким, удобным и без нервов.
Комментарии (75)
vtal007
03.02.2022 10:42+3Обычно проблема в высоком % ложных срабатываний.
Ну и еще - безопасники мешают работать людям
Допустим, Вы запретили записывать запороленные архивы на флешки. А если сотруднику надо (именно надо) передать кому-то запороленный архив. И не дело безопасников сувать туда нос (поэтому и заполоролен, в целях безопасности)
Или на каждый чих вызывать СБ-иста, чтобы он лично присутствовал?
Phoen
03.02.2022 11:13+4Обычно проблема в высоком % ложных срабатываний.
Это факт, но в целом аномалии со временем искать получается неплохо.
Ну и еще - безопасники мешают работать людям
Ну во первых это финтех и аудиторы с PCIDSS не дремлют. Во вторых - с позиций удобства согласен, с позиции бизнеса - это необходимое зло (или не зло).
Допустим, Вы запретили записывать запороленные архивы на флешки. А если сотруднику надо (именно надо) передать кому-то запороленный архив. И не дело безопасников сувать туда нос (поэтому и заполоролен, в целях безопасности)
Обычно есть регламентированные пути передачи чувствительных данных, не архивчики. Но да, ситуаций где кому-то будет неудобно из-за очередной инновационной DLP можно придумать (и не придумать) массу.
vtal007
03.02.2022 11:18-1В бытность моей работы, я скидывал архив одного проекта на свой личный яндекс-диск. С точки зрения СБ - утечка. А с точки зрения нач. отдела - бекапы в разных местах
Каким образом предлагаете передавать даннные (в которые запрещено сувать нос сотрудникам, за пределами узкого круга. В том чисел СБ-истом тоже нельзя) кроме как архивом? Экселевские запороленные файлы взламываются проще, насколько я знаю
При этом эти данные бывает надо передать своим же коллегам. Или не своим, а каким-то консалтерам
Phoen
03.02.2022 11:33+6В бытность моей работы, я скидывал архив одного проекта на свой личный яндекс-диск. С точки зрения СБ - утечка. А с точки зрения нач. отдела - бекапы в разных местах
Ну тут без комментариев, в больших компаниях бэкапить что-то сколь либо чувствительное "во вне" нельзя, совсем.
Каким образом предлагаете передавать даннные (в которые запрещено сувать нос сотрудникам, за пределами узкого круга. В том чисел СБ-истом тоже нельзя) кроме как архивом? Экселевские запороленные файлы взламываются проще, насколько я знаю
Вариантов больше чем кажется. Мне вот приходилось записывать cd-r и передавать под роспись результаты работы одной запатентовоной деньгоприносящей штуки (понятно что и там все запаролено, пароль передавался отдельно).
При этом эти данные бывает надо передать своим же коллегам. Или не своим, а каким-то консалтерам
У коллег либо есть легитимный доступ к данным, либо нет. Третьего не дано.
p.s. Если что я не ИБшник, но наверное слишком давно в финтехе.
vtal007
03.02.2022 11:41-4Оно нельзя, когда для плохих целей. Вон тот Денисович попался не потому, что базу слил, а потому что использовал ее в плохих целях. А если бы он эту базу использовал для хороших целей (губеру бы отнес, хз зачем, ситуация выдуманная), то никаких проблем бы у него не было. Еще бы и премию получил
CD-r. А откуда у Вас на компе есть CD-r и будет ли читалка на той стороне? да и чем это безопасней то? Денисочу было бы гораздо проще, будь у него писалка дисков. А так пришлось с почтой извращаться
У коллег есть право. Но доступа нет. например это холдинг. Вы работаете в УК. Формально у Вас есть право смотреть их доки (ну, финотчеты например). Но нет доступа в их компы. Опять таки в целях безопасности. Вам могут только передать эту инфу (таким образом передающий сотрудник несет ответственность за передачу)
Вы рассуждаете с точки зрения идельного мира. А фактические ситуации они шире. А на каждый чих прописывать правила в айти-системе и в инструкциях - невозможно
(в некоторых организациях народ обменивается уже через вотсап всякими данными, которые очевидно не должны "утекать" буржуям и вообще за пределами компании), но жизнь она такая. В случае реальной утечки конечно вздрючат виноватого. Но пока нет проблем - нет проблем.
Phoen
03.02.2022 11:58+3Оно нельзя, когда для плохих целей. Вон тот Денисович попался не потому, что базу слил, а потому что использовал ее в плохих целях. А если бы он эту базу использовал для хороших целей (губеру бы отнес, хз зачем, ситуация выдуманная), то никаких проблем бы у него не было. Еще бы и премию получил
Есть данные которые нельзя предоставлять третьим лицам, совсем. И персоданные тут на первом месте (вспомните как в один момент все начали подкидываться с GDPR).
CD-r. А откуда у Вас на компе есть CD-r и будет ли читалка на той стороне? да и чем это безопасней то? Денисочу было бы гораздо проще, будь у него писалка дисков. А так пришлось с почтой извращаться
а) Иммутабельность б) После отчуждения ответственностьза сохранность фактически на конкретном лице (я б на его месте мухлевать не стал).
Таковы были условия передачи с принимающей стороны согласованные с ИБ компании в которой я на тот момент работал. Ивану Денисовичу было бы +- одинаково)
У коллег есть право. Но доступа нет. например это холдинг. Вы работаете в УК. Формально у Вас есть право смотреть их доки (ну, финотчеты например). Но нет доступа в их компы. Опять таки в целях безопасности. Вам могут только передать эту инфу (таким образом передающий сотрудник несет ответственность за передачу)
Ну так вот надо сначала согласовать подход к передаче данных и как гарантировать их безопасноть, а не прыгать с завязанными глазами по граблям. Давайте перефразирую, если в ходе вашего придуманного на коленке процесса передачи часть чувствительных данных попадут не в те руки, при этом кто передавал понятно и последствия для вас не радужные (менее чем у Ивана Денисовича, но все таки) - что делать и кому плакаться?
Вы рассуждаете с точки зрения идельного мира. А фактические ситуации они шире. А на каждый чих прописывать правила в айти-системе и в инструкциях - невозможно
Я рассуждаю с точки зрения процессов которые в том или ном виде работают последние несколько десятков лет в финтехе, поскольку и статья про финтех. Как передавать сверхсекретный шаблон сайта на ucoz'e для команды в контре - да как удобнее в принципе)
vtal007
03.02.2022 12:10>Есть данные которые нельзя предоставлять третьим лицам, совсем
Я не про перс. данные. Я про фин. документы, например
ИБ компании просто нужно было, чтобы была физическая передача. Чтоб акт составить. Вот ценный диск. Вот мы его передали. Дальше не наша ответственность. А интернет -черный ящик.
Сложно сказать, архив запоролен. Попадет не в те руки.. Типа шел, шел, потерял флешку. Ну такое конечно мей би, но вероятность низкая. Ну и нашедший флешку с запороленным архивом будет довольно долго его взламывать (если вообще будет)
Ну да, оно в теории верно, что сначала надо согласовать. Согласовывать будете недели 2, а работать надо "вчера". Какой-нить Сбер может себе позволить простой работника в месяц. А другие организации - не очень
Phoen
03.02.2022 12:49Я не про перс. данные. Я про фин. документы, например
Ну фин. документы, какие-то инсайды и прочее такое тоже могут повлиять как минимум на репутацию компании и финансовые показатели, как максимум на целые рынки. Тут просто надо смотреть глобальнее и тогда такие меры начинают казаться оправданными.
ИБ компании просто нужно было, чтобы была физическая передача. Чтоб акт составить. Вот ценный диск. Вот мы его передали. Дальше не наша ответственность. А интернет -черный ящик.
Ну это достаточно обоснованное мнение и как бы не хотел я во многом с ним согласен.
Сложно сказать, архив запоролен. Попадет не в те руки.. Типа шел, шел, потерял флешку. Ну такое конечно мей би, но вероятность низкая. Ну и нашедший флешку с запороленным архивом будет довольно долго его взламывать (если вообще будет)
К чему приводили забытые(?) в баре прототипы айфонов или какие-нибудь важные ноутбуки интернет помнит)
Ну да, оно в теории верно, что сначала надо согласовать. Согласовывать будете недели 2, а работать надо "вчера". Какой-нить Сбер может себе позволить простой работника в месяц. А другие организации - не очень
А чтобы было не 2 недели - нужны процессы способные ускорить и облегчить эту процедуру. Как раз сбер со своими ~300к сотрудников я думаю в этом на внутренней кухне достаточно приуспел, иначе бы оно вообще не смогло шевелиться.
vtal007
03.02.2022 12:56+1Забытые айфоны - это вроде считается маркетинговыми акциями под названием "контролируемая утечка" :) (так-то зачем с собой таскать прототип в бар)
dartraiden
03.02.2022 17:21+3Оно нельзя, когда для плохих целей.
Если защита информации строится понятиях сотрудников о том, что есть хорошо, а что плохо — то у компании большие проблемы.
Когда-то натыкался на случай: к работнику оператора сотовой связи пришёл знакомый, сказал, что хочет проверить свою девушку на измену и для этого нужна детализация звонков. С точки зрения человека это была не плохая цель. Вот только это был номер вовсе не девушки, то бишь — обычный пробив.
vesper-bot
03.02.2022 12:11+1Экселевские запороленные файлы взламываются проще, насколько я знаю
ЕМНИП после переезда на xmlzip-формат взломать офисные документы сдало достаточно сложно (AES128 как минимум), вот до того ломалось в самом деле легко.
tark-tech
03.02.2022 22:46+4свой личный яндекс-диск
ЭЭЭЭ.... Вам в этой фразе ничего глаз не режет? В самом деле?
kerneus
04.02.2022 17:48PGP контейнер с подписью ответственного человека за передачу таких данных?
Да можно даже при помощи ссл сделать
Flidermouse
03.02.2022 12:35+3безопасники мешают работать людям
Работа у них такая. «Безопасность не должна быть удобной» (с)на каждый чих вызывать СБ-иста, чтобы он лично присутствовал
да, согласование действий, проверка спеца от ИБ, вплоть до «скиньте файлы мне в папку, придёте за флэшкой после проверки и согласования».
Hlad
03.02.2022 10:44+2Насколько помню, стеганография позволяет прятать информацию в маскирующие видеофайлы с соотношением до 1:2. То есть, Иван Денисович мог закатать этот файл с перс.данными внутрь какого-нибудь «День рожденья Дуси HD.avi», и получившийся видеофайл вполне себе будет проигрываться. Понятно, что постфактум это будет отслежено, но как в этом случае препятствовать выносу информации через почтовик и флешку?
Xapu3ma-NN
03.02.2022 11:02+1Обычно на таких армах разрешено только определенное ПО из доверенного списка. Powershell, python инерпритотор и подобные штуки явно не присутствуют. Как Вы планируете делать стеганографию в таком случае?
LaRN
03.02.2022 11:40Как вариант можно данные выгружать не как есть, а по-xor-ит с чем то. И тогда в выгрузке не будет осмысленных данных.
Для, этого хватит просто возможностей sql, если данные слили из БД.
Сможет ли анализатор содержимого файлов такое детектировать.?
Xapu3ma-NN
03.02.2022 11:49+2Я не знаю что может чей-то анализатор сожержимого файлов.
Но я думаю что директор по продажам, руками не писал кастомные запросы в базу данных по выгрузке клиентов. Скорее всего там обвязка в виде приложения,crm системы или еще како-то банковского клиента, и оставлять возможность что-то xor'ить в запросе из такой обвязки как минимум странно.
Опять же это только мои предположения исходя из опыта в offensive security, как и что там устроено мы не узнаем :)
FlashHaos
03.02.2022 15:56+1Ни разу в жизни не видел заблокированного powershell. Работал в госбанках. Так что не думаю, что какая-то проблема в этом есть.
Xapu3ma-NN
03.02.2022 16:04Ну поэтому ransomeware'щики и обеспечены работой. Но наш конкретный опыт не отражает полную картину. А я видел обратную ситуацию, когда не только тулы запрещены, но и сделана нормальная сетевая сегментация, и даже pivoting не помогает. Но из этого же нельзя сделать вывод "что так у всех" верно?)
labyrinth Автор
03.02.2022 11:04+13Как по мне, подозрение должен вызывать уже сам факт наличие на арме какого-то "видео".
Hlad
03.02.2022 11:53Ну, не видео, а любого крупного файла. Стеганография работает с очень многими форматами, просто КПД во всех остальных случаях намного хуже…
tlv
04.02.2022 04:34>Как по мне, подозрение должен вызывать уже сам факт наличие на арме какого-то "видео".
Запрос в техподдержку написал, приложил видео воспроизведения проблемы.
sshikov
04.02.2022 07:36+1Это АРМ во внутренней сети (если не виртуалка). На нем закрыты (физически отсутствуют) USB порты. На нем нет какого попало софта (у не разработчиков — отключены инструменты отладки в браузерах — то есть даже javascript). Если он его снял на камеру/телефон — его не должно быть на диске.
И самое главное — почему техподдержка в другом сетевом сегменте? То есть, ну сняли, ладно — но зачем пересылает? Понятно что можно выдумать разную правдоподобную фигню, но реально оправдать такое действие было бы практически невозможно.
vadim_bv
04.02.2022 12:21С чего бы? В эпоху удаленки могут быть записи лекций / митапов, как пользоваться тем или иным инструментом (у нас есть).
sshikov
04.02.2022 16:41У нас тоже есть. В таком случае легально пересылающему видео сотруднику ведь не сложно будет показать, что это именно видео митапа, и рассказать, где он его взял, чем записал и т.п.?
vadim_bv
04.02.2022 17:30Я отвечал на утверждение про
подозрения должен вызывать уже сам факт наличие на арме какого-то «видео»
.
Само собой, не надо называть видео «Выпускной Дуси», или как оно там называлось на АРМе.sshikov
04.02.2022 17:50+1Я так и понял. Уточню — если у вас есть доступ к карточкам, это вероятно виртуалка. Причем отдельная, специально для этого. Откуда там митапы и т.п.? Все равно вопросы возникают.
vadim_bv
04.02.2022 18:14Сейчас проверил :-)
Доступ к данным карточек (но не к номерам в чистом виде) есть с виртуалки. К конфлуэнсу, где у нас лежат ссылки на записи митапов, — нет; только с основной машины.
Черновики в аутлуке доступны и там, и там )
drumminman
05.02.2022 11:54Это как бы не персональный арм то был, а по сути толстый клиент для работы с бд клиентов, несколько я понимаю.
dartraiden
03.02.2022 17:28+4Откуда на арме изначально возьмётся видеофайл «День рожденья Дуси HD.avi», в который можно было бы что-то закатать? Насколько я понимаю, там USB-порты отключены (иначе, файл бы не пришлось пересылать на компьютер 2), а данные поступают только из АИС.
Hlad
03.02.2022 19:01Ну так откуда то же взялся архиватор, который архивирует с паролем…
Кроме того, не обязательно нужен видеофайл: можно чуть ли не в блокноте превратить любые данные в BMP-шку с непонятным белым шумом. Это будет тоже разновидность стеганографии
Silvestor
03.02.2022 10:45+7Так а что в итоге по Ивану Денисовичу? Карамельку дали?
В начале статьи описали ложные чувства, но не развенчали их.
vtal007
03.02.2022 10:54+2да там ссылка есть на "дело"
приговорил:
признать ФИО2 виновным в совершении преступления, предусмотренного ст. 183 ч. 3 УК РФ и назначить наказание в виде 2 (два) лет 10 (десять) месяцев лишения свободы, с отбыванием наказания в колонии-поселении.
Меру пресечения в отношении ФИО2 в виде домашнего ареста – оставить без изменения до вступления приговора в законную силу, сохранив ранее установленные запреты и ограничения. По вступлении приговора в законную силу указанную меру пресечения - отменить.
Возложить на ФИО2 обязанность следовать по месту отбывания наказания в колонию-поселение за счет государства самостоятельно; явиться в территориальный орган уголовно-исполнительной ФИО1 для получения, в соответствии со ст. 75.1 УИК РФ, предписания о направлении к месту отбывания наказания и обеспечения его направления в колонию-поселение;
Плюс еще и бабла
Гражданский иск ПАО Сбербанк к Зеленину ФИО33 о взыскании в счет возмещения вреда, причиненного деловой репутации ПАО «Сбербанк» в размере 25 856 157 рублей 00 копеек – удовлетворить.
Взыскать с Зеленина ФИО34 в пользу ПАО Сбербанк в счет возмещения вреда, причиненного деловой репутации ПАО «Сбербанк» денежные средства в размере 25 856 157 (двадцать пять миллионов восемьсот пятьдесят шесть тысяч сто пятьдесят семь) рублей 00 копеек.
labyrinth Автор
03.02.2022 11:00Ивану Денисовичу-то ничего не было. Он выдуман. А реальному человеку из дела, помимо того, что уже написано выше, ещё и штраф дали:
Взыскать с ФИО34 в пользу ПАО ...банк в счет возмещения вреда, причиненного деловой репутации ПАО ...банк денежные средства в размере 25 856 157 (двадцать пять миллионов восемьсот пятьдесят шесть тысяч сто пятьдесят семь) рублей 00 копеек.
ky0
03.02.2022 10:53+8Выгрузка здорового куска базы штатными методами вообще, имхо, должна детектироваться элементарно. Другое дело, если, например, И. Д. сделал бы примерно то же самое с каким-нить бэкапом или вовсе с помощью напарника, имеющего доступ к СУБД мимо SIEM.
Phoen
03.02.2022 11:04+1Бэкапы обычно отчуждаемы, за базой тоже весьма серьезный контроль (в том числе регламентированный PCIDSS). Вот если есть доступ к ETL в проме и подобная активность легетимна, а в трансформациях особенно никто не разбирается - вот там уже и контент фильтр обойти кажется что не такая уж проблема.
Zibx
03.02.2022 11:02Эвристика по записи на флешку запароленного архива бесполезна если пользователь это сразу заметит. Ничто не мешает домешивать данные в конец настоящего видеофайла. Или перегонять кусочки в base64 и утекать через обычные файлы. Стеганографию опять же никто не отменял, подмешивать данные в биты пнг. Код для всей этой магии можно отлично писать на VBA.
dimkin-eu
03.02.2022 11:18+4Всякие security best practices хоть и не советуют передавать почтой sensitive информацию, всё же настойчиво советуют её передавать запароленной ( и пароль отдельно и по другому каналу), поэтому в какой-то момент огораживание пользователей может выйти боком.
Sh0p
03.02.2022 16:07+2Сбер такой сбер. А Иван Денисович тоже мамкин хацкер. Не мог тузом в базу залогиниться штоле? Откуда ваще в альфе мог взяться выпускной.mp4 ???? Ещё раз убеждаюсь, что все начальники дураки
sshikov
03.02.2022 21:12+1>Откуда ваще в альфе мог взяться выпускной.mp4
Именно. И нахрена его пересылать (обратно) наружу, где он очевидно был снят на телефон?
mixsture
03.02.2022 16:57+1Итого, Иван Денисовичу достаточно было воспользоваться file-erase утилитами и на каждом этапе делать заново архив с паролем и вся бы эта схема доказательства развалилась. Думаю, поэтому и так мало реальных дел — уж очень легко схема разваливается.
dartraiden
03.02.2022 17:34+1Итого, Иван Денисовичу достаточно было воспользоваться file-erase утилитами
Которых на АРМе нет, как и возможности их туда вкорячить. Если только не городить из говна и палок через fsutil.mixsture
04.02.2022 15:29file-erase — это просто. Достаточно не удалять файл, а в него записать другие данные такого же или большего размера. Можно и без особых утилит это сделать.
dartraiden
04.02.2022 15:39-1Это если там HDD, а не SSD… с последнего гарантированно удалить что-то можно, только выполнив SecureErase.
pankraty
04.02.2022 08:36Как вариант - делать выгрузки такого же размера примерно каждый день, чтобы а) создать впечатление, что это нормальный рабочий процесс, а не разовая аномалия, б) затереть следы утекшей выгрузки, в) убедиться, что не привлёк внимания СБ. А базу продавать через год, когда следов уже не найти. В идеале - после списания АРМ2 с регламентным уничтожением HDD, но это можно и не дождаться.
aik
03.02.2022 18:13+5По-моему, товарища должны были взять на выгрузке шести гигов из базы. Потому что «пробивать» отдельных лиц по запросу — это одно и может сойти за законное использование, а вот сдампить несколько гигов — должно бы вызывать вопросы.
sshikov
03.02.2022 21:10+1Ну, в работе аналитика больших данных — 6 гигов вообще ни о чем. Может он на них свои модели обучает? Так что как минимум этот лимит сильно зависит от роли. Для роли начальника отдела — да, должно быть под вопросом сразу.
Я бы сказал, что очевидное слабое звено не тут — а на пересылке из защищенного сегмента сети во внешний. Потому что появление во внутренней сети какого-то там видеоролика — уже вызывает явные вопросы: а как он вообще туда попал? А нахрена его пересылать наружу? И так далее.
Более того, вызывает вопрос сама необходимость для какого-то там «начальника отдела продаж» иметь доступ к "«корпоративному файловому перекладчику». Для пересылки каких-таких данных на постоянной основе изнутри наружу ему это нужно? И если бы ему эту пересылку нужно было согласовать — у любого человека со стороны озвученные выше вопросы возникли бы.VitalKoshalew
04.02.2022 08:12+3Если у вас аналитик имеет доступ к полям с номерами кредитных карт, у вашего PCI DSS аудитора с вами будет невесёлый разговор. В теории. А на практике, как мы видим, никто аж целому Сберу слова ни сказал.
В остальном согласен, ситуация поражает. Самый очевидный вектор атаки с наградой в «миллионы или даже десятки миллионов рублей» вообще никак не контролируется. Ладно б в IT резервную копию выкрали и расшифровали, а тут простой пользователь может а) выгрузить базу, б) передать её через шлюз, вся суть которого в том, чтобы предотвратить передачу базы!sshikov
04.02.2022 16:34>Если у вас аналитик имеет доступ к полям с номерами кредитных карт, у вашего PCI DSS аудитора с вами будет невесёлый разговор.
Да, конечно. Тут речь скорее была о том, что объемы — они разные для ролей. Начальнику отдела продаж вообще непонятно, нафига выгрузка такого размера. То что он начальник — ничего тут не значит. У него есть свой круг задач, в него явно не входит анализ миллионов записей с номерами карт.
Я вам больше скажу — в нашей конкретной системе нет полей с картами. Но мы работаем с остальными полями «оттуда». Так нам даже это стоило кучу мороки — доказать тот факт, что мы поля не берем, оказалось мало. Пришлось проделать еще много чего, чтобы мы даже случайно их не взяли. Например, в результате какой-то SQL иньекции.
>никто аж целому Сберу слова ни сказал.
Ну это не факт. Не знаю, кому чего сказали, но нам доступ туда усложнился. То есть, реакция была. Насколько широкая — сказать тут трудно.VitalKoshalew
04.02.2022 19:19Тут речь скорее была о том, что объемы — они разные для ролей.
Я рискну чрезмерно обобщить, но, по моему мнению, за исключением редчайших случаев, на которые можно хоть комиссию из 10 надзирающих за процессом собирать, никому и никогда не нужна ручная выгрузка значимых для PCI DSS размеров. Там, где машины между собой общаются, там могут быть объёмы. Человеку же нужен единичный доступ. Это — основа защиты данных кредитных карт. Этой функции там вообще не должно было быть.Я вам больше скажу — в нашей конкретной системе нет полей с картами. Но мы работаем с остальными полями «оттуда». Так нам даже это стоило кучу мороки — доказать тот факт, что мы поля не берем, оказалось мало. Пришлось проделать еще много чего, чтобы мы даже случайно их не взяли. Например, в результате какой-то SQL иньекции.
Ну да, это базовые требования PCI DSS — ограничение доступа ко всей cardholder data, а не только к PAN. Я не знаю деталей вашей системы, но в норме должно быть разделение на разработчиков и Operations, и доступ разработчикам к cardholder data должен быть закрыт «с той стороны».>никто аж целому Сберу слова ни сказал.
Ну это не факт. Не знаю, кому чего сказали, но нам доступ туда усложнился. То есть, реакция была. Насколько широкая — сказать тут трудно.
Я имел в виду, что заранее на наличие у пользователей функции выгрузки закрыл глаза их аудитор. Весь 7-й раздел PCI DSS о том, что такого не должно быть.
То, что вам доступ «усложнили», показывает лишь то, что до этого было нарушение PCI DSS, а тут их припугнули и они стали что-то где-то выполнять. Есть надежда, что теперь стали относится серьёзно. Удивляет то, что это произошло в 2020+ году. В Северной Америке с большего прогресс был виден уже 5+ лет назад, тоже после громких скандалов. Есть, конечно, и исключения, к сожалению, но, мне хочется надеяться, не размера Сбер-а.sshikov
04.02.2022 19:28>Я рискну чрезмерно обобщить
Да не, даже если тут обобщение — то идея все равно выглядит верной. В моей работе такое есть — но я никогда не забираю эти объемы через тот же интерфейс, через который их получает обычный пользователь. Ну т.е. если вы инженер или аналитик больших данных, или там обучаете модели — вам могут быть нужны объемы, но тогда у вас скорее всего — другие каналы их получения, чем у начальника отдела продаж.VitalKoshalew
04.02.2022 20:57Я не могу себе представить никакие модели или анализы на основе именно cardholder data (PAN, Cardholder Name, Expiration Date, Service Code). По hash-ам паролей тоже аналитику делать? Под словом «никому» и имел в виду «никому, включая инженеров и аналитиков».
По большому счёту, вообще любая аналитика внутри CDE — сомнительное удовольствие. Мой совет — автоматически фильтровать, выводить за пределы scope (а ещё лучше никогда не вводить туда) данные, по которым нужна аналитика.sshikov
04.02.2022 20:59+1Я не говорил про анализ данных карт. Я лишь говорю, что те случаи, когда нужен анализ реально больших объемов — их даже и тогда не получают через те же интерфейсы, с которыми работают сотрудники «отделов продаж».
sshikov
03.02.2022 18:43+1Искать номера карточек регуляркой — это неправильно. По-хорошему, там контрольная сумма, и надо бы проверить, что она совпадает. Тогда это номер, а если нет — пока хрень непонятная.
Mingun
03.02.2022 20:03Полагаю, что выбранный в выпадающем списке Метод валидации=Номер карты это и делает
sshikov
03.02.2022 20:57Ну, наверное. Но все же:
Создаём правило, которое поможет находить и помечать информацию, содержащую ПДн. В условиях прописываем регулярное выражение для «номера карты» и устанавливаем порог входа (50 цепочек).
вот тут явно регулярка. И алгоритм Луна на регулярках по-моему написать нельзя.Mingun
03.02.2022 23:07Ну алгоритм Луна вам не поможет найти номер карты в произвольном тексте, только проверить, что уже найденный номер может быть номером карты
sshikov
04.02.2022 07:29Я и не имел в виду, что он поможет. Именно, чтобы проверить, что найденное это реально номер. А иначе ложных срабатываний может быть много.
Gvatgor
04.02.2022 08:08+3Тоесть, если бы он не сразу понес базу продавать, а выждал бы пару месяцев, то хрен бы доказали ? Остатки файлов на винчестере за это время были бы перезаписаны, корзины очищены, искать в логах неизвестно что на неизвестно какую глубину -та еще задача.
mess9
04.02.2022 17:48+2проверять файлы только указанных расширений это конечно оптимизирует поиск.
но как тогда проверится jpeg в 6 гб, который будет вполне открываться как картинка а в метаданных у него будет искомый архив.
более того, можно разбить 6 гб, на фоточки по 8 мб, в которых 4 будет фотка, 4 зашифрованные данные.
и всё это вообще спокойно можно передавать. или такие кейсы анализатор файлов поймает?
был ещё сервис darkjpeg вроде, тот в шум сжатия данные сохранял
RalphMirebs
А чем банку опасна утечка базы? Регуляторы могут наказать руководство за утечку персональных данных или вопрос лишь в теоретической потере клиентов и их денег ?
Fox_exe
В данном случае, как я понял, выгрузили не только ФИО, но и номера кредиток, счетов, пароли, а может и ещё чего полезного.
Известны случаи, когда угоняли деньги с карт, имея на руках только её номер, ФИО владельца, да ещё пару перс. данных, вроде даты рождения (Далее, методами соц. инженерии хакер представлялся владельцем карты и получал доступ к деньгам на ней)
vilgeforce
Пароли? Они их там в открытом виде хранили?
mayorovp
Да даже если в "солёном" — всё равно надо все пароли принудительно менять. А пользователям это обычно не нравится.
Shaman_RSHU
Попахивает нарушениями PCI DSS
Olgeir
Тоже первое, что пришло в голову, что по PCI DSS не должны хранится полные номера карт. Но с другой стороны, я видел массу промышленных систем в банках, где номера карт хранились целиком.
Shaman_RSHU
К сожалению compliance иногда не имеет ничего общего с реальной безопасностью.
И, насколько я понимаю, в России соблюдение PCI DSS не так сильно требуют, как СТО БР.
Olgeir
А разве для подключение к VISA и MASTERCARD не требуется соблюдение PCI DSS? Я всегда считал что это обязательное условие.
K0styan
И то, и то. Притом штраф за утечку ПД может быть умножен на количество утекших учёток, так что там могут на круг очень приличные суммы набежать.
Плюс есть ещё вопрос - а чьи именно данные утекли? Если я плюну на этот банк и перейду в другой, убыток невелик. Если владелец нескольких компаний перетащит ещё и их обслуживание - это уже будет неприятно.