Разбор громких инцидентов с 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 года Судебная коллегия по гражданским делам Московского городского суда.

Вот вроде бы и все – инсайдер пойман и наказан. Однако я свой рассказ заканчивать не спешу.

Как могли бы найти инсайдера

Задача по поиску нарушителя разделяется на две:

1. Найти того, кто имеет доступ не только к своему ящику, но и к чужому.

2. Определить, пересылалась ли информация из чужого ящика куда-то дальше.

Начнем по порядку. Сперва стоит определиться с инструментами. В моем арсенале SIEM, DLP и DCAP. Казалось бы, все очевидно – бери SIEM, анализируй логи почтового сервера и почивай на лаврах.

К SIEM пойдешь, не факт, что найдешь

И дело даже не в том, что информации из логов может оказаться недостаточно. Правила вроде «Доступ к ящику не владельцем» вычитывают настройки сервера. То есть если бы админ легально дал доступ Карлу к ящику Клары, настроив соответствующие правила, мы бы все увидели в SIEM. Но в нашем рассказе Карл никого не спрашивал и настроил доступ сам. В логах мы, конечно, могли бы увидеть доступ с разных IP-адресов. Но это если заранее знать, где искать. В реальности же автоматически выявить подобное нарушение вряд ли получится. Поэтому попробуем другой путь.

К DLP пойдешь, слишком много данных нагребешь

Когда мы создаем ящик для пользователя, Outlook создает еще и хранилище. Причем сколько ящиков, столько и хранилищ. Хранилище по умолчанию расположено в определенном месте под определенным именем, совпадающим с именем почты. Например, если это karl@company.ru, то Outlook создаст хранилище karl@company.ru.ost. Таким образом, если пройтись по каждому компьютеру и посмотреть, у кого хранилищ более одного, можно выявить подозреваемых.

В DLP-системах для этой задачи подходит функционал e-discovery, с его помощью можно работать с данными в покое. Вот только есть нюанс. Как правило, работа модулей e-discovery в DLP подразумевает аудит вместе с индексацией найденного содержимого. Это чревато тем, что система сначала «протащит» все хранилища по сети, а потом добросовестно положит в базу данных. Найденный OST-файл может весить и 1Гб, и 2Гб – и все эти данные останутся у вас в СХД. Нерационально. Поэтому нужен…

Путь DCAP

Про DCAP-системы и их возможности уже не раз было рассказано на страницах этого блога. Например, не так давно делился здесь способом контроля аддонов в браузере с помощью DCAP, или вот мой коллега Алексей Парфентьев размышлял о будущем систем в эфире AM Live. Для решения задачи, сформулированной в предыдущем разделе, DCAP подойдет лучше всего, ведь при формировании правила в нем можно выбрать режим аудита.

Сначала настраиваем правило. В принципе, можно было бы обойтись и одним условием: поиск по расширению .OST. Но если мы уверены, что никто из пользователей не будет перемещать хранилище из изначального места, можно дополнительно указать его. Пример получившегося правила показал на скриншоте ниже.

Для исключения ложных сработок в правило можно было бы добавить «системные» ящики info@, pr@ и т.п. После того, как правило отработает, мы увидим всех пользователей, у которых нашелся хотя бы 1 файл с расширением OST. И в «ручном» режиме разбираться с этим – так себе удовольствие. Для одного компьютера все выглядит красиво.

Но если у нас 1000 пользователей, нужна какая-нибудь автоматизация. На помощь приходит консоль работы с инцидентами AlertCenter. Здесь можно и внешний скрипт для обработки прикрутить, и одним движением руки события отсортировать. Если сделать сортировку по компьютерам, будет легко увидеть, у кого привязан 1 ящик, а у кого больше.

На этом DCAP складывает свои полномочия. Первая задача завершена: определен подозреваемый и найден ящик, к которому он подключался. Но теперь нужно понять, какие из входящих писем Клары Карл отправлял на свою почту. Задача сродни поиску иголки в стоге сена. Сколько входящих писем обычно у менеджера за год? Допустим, 1000. А исходящих? Допустим, 500. Получается, надо проверить пересечение двух множеств. Вручную таким точно лучше не заниматься (конечно, если вы не хотите кого-нибудь наказать такой работой).

И вновь DLP

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

1. Отправлял экспортированное письмо Клары целиком (например, перетаскивал мышкой сообщение из Outlook на рабочий стол). Письмо автоматически сохранялось в виде «имя_файла.msg».

2. Отправлял вложение, которое предварительно экспортировал из письма Клары.

3. Отправлял кусок текста, который копировал из письма или вложения.

У всех трех подходов есть одна общая черта: Карл ни разу не модифицировал содержимое. Лишь копировал и вставлял. Это подсказка, чтобы использовать поиск по цифровым отпечаткам.

И еще один важный момент. Т.к. необходимо сравнивать каждое отправленное Карлом письмо с каждым входящим письмом Клары, в библиотеку цифровых отпечатков нужно загружать не хранилище целиком (.ost), а письма по отдельности. Это напрямую влияет на релевантность (в поиске по цифровым отпечаткам она считается как процент вхождения искомого куска информации ко всему документу).

Теперь остается правильно настроить политику безопасности в AlertCenter.

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

Второе условие – выбрать тип сообщения, то есть, его направление. У нас это исходящая почта. Политика может настраиваться на любые каналы передачи данных, которые мы хотим проверить: почту, флешку, облако и др.

Условия «за» скобками связаны с тем, кого проверяют и по какому каналу. В качестве источника данных для проверки подключен индекс почтового перехвата. А чтобы инцидентом считалась только отправка письма от Карла, через механизм черных списков была добавлена его учетка.

Таким образом, инцидентом будет считаться исходящее письмо, отправленное от учетки Карла, если его содержимое совпало на 80% или больше с любым из входящих писем Клары.

Стоит отметить, что 100% инцидентов с помощью данной политики можно и не выявить. Все дело в релевантности. Например, если в оригинальном письме Клары было вложение на 200 страниц, а Карл скопировал и переслал из него 2 абзаца и 1 таблицу, то релевантность будет явно меньше 80%. Следовательно, инцидента не будет, потому что не были выполнены заданные условия.

Конец. Просто конец какой-то

К чему мы пришли? Знайте, как работает та или иная технология. Знайте, как работает тот или иной инструмент. Читайте инструкции и будет вам счастье. Ну или по крайней мере меньше головной боли и ручного труда.