Разбор громких инцидентов с Road Show SearchInform на Хабре имеет шансы стать традицией. В прошлом году я представил реконструкцию инцидента, связанного с выносом базы данных за пределы одной финансовой компании. Его главным и единственным организатором был ловкий и умелый инсайдер «Иван Денисович». В этот раз источником вдохновения послужило не менее любопытное дело. Оно также связано с утечкой информации, но уже с другими героями в главных ролях. Решил реконструировать инцидент. Как и в прошлый раз: «все выдумано, а совпадения случайны».    Итак, представляю участников: Карл – сотрудник-инсайдер; Клара – сотрудница-жертва; Кораллы – содержимое корпоративного почтового ящика Клары. Под катом рассказываю, как Карлу удалось украсть «кораллы» и нанести компании ущерб в 100+ млн рублей, каким образом его вычислили и как он оправдывал себя в суде. И самое главное – показываю, какими инструментами компания могла бы упростить себе поиски виновного и предотвратить инцидент. История началась с того, что Карл пришел работать на предприятие, где попал в отдел продаж под руководство Клары. И, наверное, в самом начале у сотрудника и мысли не было что-то украсть, однако политика компании, по сути, развязала ему руки. Что я имею ввиду? В компании, скажем так, не особо приветствовали удаленную работу. Поэтому на рабочем месте использовали в основном стационарные компьютеры. Получить же ноутбук можно было при командировке. Но на время больничного, отгула или отпуска – нет. Вот на этом моменте и начиналась «схватка двух ёкодзун»: безопасность VS бизнес. Понятное дело, что клиенту можно объяснить, почему на его письмо не отвечали несколько дней (из-за политики безопасности), но кому такие объяснения нужны? Поэтому Клара в своем отделе придумала тривиальный способ обхода ограничений, установленных службой безопасности. Все сотрудники должны были знать учетные данные друг друга, чтобы в случае отсутствия кого-либо на рабочем месте была возможность включить его компьютер, загрузить почту и оперативно реагировать на письма. В основном интерес был у Клары. Она просила Карла просматривать ее почту. И Карл смотрел… Через какое-то время пути наших главных героев разошлись. Карл перешел в другой отдел. Но кое-что их все-таки связывало... Наш инсайдер, видимо, настолько привязался к почтовому ящику бывшей начальницы, что не захотел его терять, и настроил к нему доступ в своем почтовом клиенте (Outlook). С этого и начался преступный путь Карла. План по монетизации был прост: сливать за вознаграждение (а может и за переход в штат в будущем) партнерам информацию, которая даст им преимущество в переговорном процессе и позволит выбить себе наилучшие условия сделки. Дело в том, что компания, в которой работал Карл с Кларой, продавала как напрямую, так и через посредников. Последние были заинтересованы в различной инсайдерской информации: остатках продукции на складе, о стоимости товаров, объеме производства и т.п. Да легко – через настройку учетных записей в почтовом клиенте. Для этого нужно было ввести адрес электронной почты и пароль к почтовому ящику (который совпадал с паролем от учетки в AD). И то, и другое, как мы знаем, было ему доступно. Получив доступ к ящику Клары, Карл иногда отправлял информацию с него на свой внешний почтовый. Количество пересланных писем за все время составило 5. Так сказать, редко, но метко. У руководителей компании закрались подозрения, что кто-то имеет доступ к внутренней информации. Уж больно выделялась одна из компаний-партнеров, представители которой будто бы знали, когда лучше заказывать поставку товара, сколько может стоить продукт и т.д. Отрабатывая различные версии, решили проверить и такую: кто-то в компании смотрит не только в свой корпоративный почтовый ящик, но и в ящики коллег. Идея оказалась верной. Путем долгого и упоротого упорного труда удалось найти Карла и определить, какую информацию он отправил партнерам. Увы, из материалов дела не особо много конкретики можно достать. Тем не менее, ниже будут приведены размышления на тему, как могло бы идти расследование. Организация подала иск против Карла и выиграла дело в суде. Но инсайдер не сдался, в ответной апелляции он настаивал на том, что документы не содержали меток «коммерческая тайна». А если метки не было, как он мог знать, что информация является коммерческой тайной? Но на этот случай есть чудесная поговорка: «незнание законов не освобождает от ответственности», тем более, если был введен режим КТ и ты подписывал все необходимые бумаги. И вот еще пара дел (для информации), где такая отговорка тоже не сработала. Можно почитать их на досуге: Дело № 33-44248/2015 г. АПЕЛЛЯЦИОННОЕ ОПРЕДЕЛЕНИЕ от 26 ноября 2015 года г. Москва. Судебная коллегия по гражданским делам Московского городского суда. Решение № 2-11976/2014 2-11976/2014~М-10846/2014 М-10846/2014 от 6 ноября 2014 г. Мещанский районный суд (Город Москва). На этапе апелляции подсудимый также пытался доказать свою невиновность тем, что переслал документы самому себе. А самому себе – это не нарушение, а всего лишь рабочие моменты. Но и здесь «не прокатило, вычеркиваем»: Дело № 33-12211/17 АПЕЛЛЯЦИОННОЕ ОПРЕДЕЛЕНИЕ 30 марта 2017 года. Судебная коллегия по гражданским делам Московского городского суда. Дело № 33-39235/2018 АПЕЛЛЯЦИОННОЕ ОПРЕДЕЛЕНИЕ 12 сентября 2018 года Судебная коллегия по гражданским делам Московского городского суда. Вот вроде бы и все – инсайдер пойман и наказан. Однако я свой рассказ заканчивать не спешу. Задача по поиску нарушителя разделяется на две: Найти того, кто имеет доступ не только к своему ящику, но и к чужому. Определить, пересылалась ли информация из чужого ящика куда-то дальше. Начнем по порядку. Сперва стоит определиться с инструментами. В моем арсенале SIEM, DLP и DCAP. Казалось бы, все очевидно – бери SIEM, анализируй логи почтового сервера и почивай на лаврах. И дело даже не в том, что информации из логов может оказаться недостаточно. Правила вроде «Доступ к ящику не владельцем» вычитывают настройки сервера. То есть если бы админ легально дал доступ Карлу к ящику Клары, настроив соответствующие правила, мы бы все увидели в SIEM. Но в нашем рассказе Карл никого не спрашивал и настроил доступ сам. В логах мы, конечно, могли бы увидеть доступ с разных IP-адресов. Но это если заранее знать, где искать. В реальности же автоматически выявить подобное нарушение вряд ли получится. Поэтому попробуем другой путь. Когда мы создаем ящик для пользователя, Outlook создает еще и хранилище. Причем сколько ящиков, столько и хранилищ. Хранилище по умолчанию расположено в определенном месте под определенным именем, совпадающим с именем почты. Например, если это karl@company.ru, то Outlook создаст хранилище karl@company.ru.ost. Таким образом, если пройтись по каждому компьютеру и посмотреть, у кого хранилищ более одного, можно выявить подозреваемых. В DLP-системах для этой задачи подходит функционал e-discovery, с его помощью можно работать с данными в покое. Вот только есть нюанс. Как правило, работа модулей e-discovery в DLP подразумевает аудит вместе с индексацией найденного содержимого. Это чревато тем, что система сначала «протащит» все хранилища по сети, а потом добросовестно положит в базу данных. Найденный OST-файл может весить и 1Гб, и 2Гб – и все эти данные останутся у вас в СХД. Нерационально. Поэтому нужен… Про DCAP-системы и их возможности уже не раз было рассказано на страницах этого блога. Например, не так давно делился здесь способом контроля аддонов в браузере с помощью DCAP, или вот мой коллега Алексей Парфентьев размышлял о будущем систем в эфире AM Live. Для решения задачи, сформулированной в предыдущем разделе, DCAP подойдет лучше всего, ведь при формировании правила в нем можно выбрать режим аудита. Сначала настраиваем правило. В принципе, можно было бы обойтись и одним условием: поиск по расширению .OST. Но если мы уверены, что никто из пользователей не будет перемещать хранилище из изначального места, можно дополнительно указать его. Пример получившегося правила показал на скриншоте ниже. Для исключения ложных сработок в правило можно было бы добавить «системные» ящики info@, pr@ и т.п. После того, как правило отработает, мы увидим всех пользователей, у которых нашелся хотя бы 1 файл с расширением OST. И в «ручном» режиме разбираться с этим – так себе удовольствие. Для одного компьютера все выглядит красиво. Но если у нас 1000 пользователей, нужна какая-нибудь автоматизация. На помощь приходит консоль работы с инцидентами AlertCenter. Здесь можно и внешний скрипт для обработки прикрутить, и одним движением руки события отсортировать. Если сделать сортировку по компьютерам, будет легко увидеть, у кого привязан 1 ящик, а у кого больше. На этом DCAP складывает свои полномочия. Первая задача завершена: определен подозреваемый и найден ящик, к которому он подключался. Но теперь нужно понять, какие из входящих писем Клары Карл отправлял на свою почту. Задача сродни поиску иголки в стоге сена. Сколько входящих писем обычно у менеджера за год? Допустим, 1000. А исходящих? Допустим, 500. Получается, надо проверить пересечение двух множеств. Вручную таким точно лучше не заниматься (конечно, если вы не хотите кого-нибудь наказать такой работой). Подобрать правильный инструмент поможет правильная постановка задачи. Давайте взглянем на схему и подумаем, что Карл мог отправлять. Отправлял экспортированное письмо Клары целиком (например, перетаскивал мышкой сообщение из Outlook на рабочий стол). Письмо автоматически сохранялось в виде «имя_файла.msg». Отправлял вложение, которое предварительно экспортировал из письма Клары. Отправлял кусок текста, который копировал из письма или вложения. У всех трех подходов есть одна общая черта: Карл ни разу не модифицировал содержимое. Лишь копировал и вставлял. Это подсказка, чтобы использовать поиск по цифровым отпечаткам. Сильной стороной цифровых отпечатков является то, что сравниваются не оригиналы документов, а результаты их преобразований. Поясню идею, приведя аналогию (наши алгоритмы работают сложнее, но идея со сравнениями хешей лежит в основе). Итак, сначала система снимает с документа «цифровой отпечаток» – набор хешей. Грубо говоря, хеш – это строчка, состоящая из цифр и букв (к примеру, хеш слова «MD5» для алгоритма MD5 имеет вид 1BC29B36F623BA82AAF6724FD3B16718). Особенность хешей в том, что они уникальны для каждого «куска» информации. Даже небольшое изменение входного сообщения приводит к полному изменению хеша. Еще одна особенность алгоритмов хеширования – они могут быть «необратимыми». То есть, зная хеш, нельзя восстановить исходную информацию. На этих свойствах и работают цифровые отпечатки. Если посчитать хеш с одного документа, потом с другого, и окажется, что хеши одинаковые, значит можно точно утверждать, что документы полностью идентичны. Но так мы получаем 2 состояния: либо 100%, либо 0% схожести. Если же мы хотим оперировать всей шкалой от 0 до 100, нужно больше хешей. Например, в текстовых документах можно снимать хеш с каждого абзаца или с каждого предложения. Чем больше хешей снято с одного документа, тем лучше (вроде бы). Но возникает проблема: операция хеширования требует ресурсов для вычисления хешей. Чем больше хешей надо «снять», тем дольше будет обрабатываться один документ. Разработчикам приходится искать «золотую середину». В общем, использование поиска по цифровым отпечаткам применяется тогда, когда предполагается, что при «сливе» документов, они НЕ будут сильно модифицироваться/изменяться. И еще один важный момент. Т.к. необходимо сравнивать каждое отправленное Карлом письмо с каждым входящим письмом Клары, в библиотеку цифровых отпечатков нужно загружать не хранилище целиком (.ost), а письма по отдельности. Это напрямую влияет на релевантность (в поиске по цифровым отпечаткам она считается как процент вхождения искомого куска информации ко всему документу). Теперь остается правильно настроить политику безопасности в AlertCenter. Первое условие – процент обязательного совпадения с библиотекой цифровых отпечатков (или релевантность). Я поставил 80 (потому что гладиолус) и указал в условии, что проверять нужно не всю библиотеку цифровых отпечатков, а только ту директорию, в которую были загружены входящие письма Клары. Второе условие – выбрать тип сообщения, то есть, его направление. У нас это исходящая почта. Политика может настраиваться на любые каналы передачи данных, которые мы хотим проверить: почту, флешку, облако и др. Условия «за» скобками связаны с тем, кого проверяют и по какому каналу. В качестве источника данных для проверки подключен индекс почтового перехвата. А чтобы инцидентом считалась только отправка письма от Карла, через механизм черных списков была добавлена его учетка. Таким образом, инцидентом будет считаться исходящее письмо, отправленное от учетки Карла, если его содержимое совпало на 80% или больше с любым из входящих писем Клары. Стоит отметить, что 100% инцидентов с помощью данной политики можно и не выявить. Все дело в релевантности. Например, если в оригинальном письме Клары было вложение на 200 страниц, а Карл скопировал и переслал из него 2 абзаца и 1 таблицу, то релевантность будет явно меньше 80%. Следовательно, инцидента не будет, потому что не были выполнены заданные условия. К чему мы пришли? Знайте, как работает та или иная технология. Знайте, как работает тот или иной инструмент. Читайте инструкции и будет вам счастье. Ну или по крайней мере меньше головной боли и ручного труда.     Типа серьёзный специалист