Иллюзия обмана: как моделируются (не)реальные кейсы из практики DLP

Однажды нас спросили, чьи данные мы показываем на DLP-демостендах во время ИБ-мероприятий. Кто даст согласие делиться своими инцидентами? Подмечено верно – пожалуй, никто. «Тогда почему вы утверждаете, что эти кейсы реальные?»

Давайте разбираться.

Предисловие

Этой статьей мы продолжаем пополнять серию материалов «Как мы создаем наш продукт». Напомним, что в первой части мы рассказали об исследовательской стороне создания Solar Dozor: как мы ищем инновации, создаем киллер фичи и увязываем пожелания заказчиков с собственным роудмапом. Во второй части мы поделились своим опытом внедрения Scrum в разработку B2B продуктов. Третья часть была посвящена рассказу, как устроен процесс разработки на примере модуля для территориально-распределенных компаний MultiDozor и модуля поведенческой аналитики Dozor UBA.

Настало время приоткрыть завесу тайны и рассказать, как мы воссоздаем те самые необычные кейсы на демонстрационных стендах DLP-системы Solar Dozor. Справедливости ради отметим, что это ровно такие же системы, как у наших заказчиков – только они не обрабатывают реальный трафик. А что же они тогда делают?

Сначала кейс, потом стулья

Признаемся, мы долго думали, на примере какого кейса описать все задачи, которые стоят перед нами, когда мы заливаем данные на стенд. Претендент был найден среди последних пилотных проектов. История отчасти ошеломляющая, отчасти душещипательная.

***

Ситуация разворачивается в Перми (город был выбран нами). Как и бывает в тихих городах, здесь все друг друга знают, все стараются друг другу помочь. Сегодня ты кому-то помог, завтра – тебе, вот такой круговорот. Одно крупное предприятие в этом городе ищет автосалон, через который можно продавать устаревшие корпоративные автомобили компании. Бухгалтер хочет подсобить своему знакомому с крупным клиентом и по доброте душевной рекомендует руководству для сбыта корпоративных автомобилей автосалон, в котором тот работает. И все было хорошо, пока по автомобилям, стоящим в автосалоне, не начали приходить штрафы от ГИБДД. Само собой, на адрес предприятия. А получает их кто? Правильно – бухгалтер!

Выяснилось это правда весьма нетривиальным способом – после просьбы бухгалтера удалить переписку с менеджером автосалона, на которую сработал алерт. В виджете DLP-системы появилось многообещающее превью сообщения от главного бухгалтера Летящей Натальи Павловны, отправленное аналитику безопасности ДЗО: «Леееееешенька, а ты не мог бы удалить переписку между мной и Dm?..»

По клику на «Событие» открывается сообщение Летящей Натальи Павловны na.letyashaya@mzprogress.ru, отправленное Специалисту ИТ-отдела ДЗО Золотому Алексею Дмитриевичу al.zolotoy@mzprogress.ru

В тексте письма просьба:

«Леееееешенька, а ты не мог бы удалить переписку между мной и Dmitriicarsale@mail.ru, за прошлые 2,5 месяца все, что касательно штрафов. Мы ситуацию решили, но не хотелось бы премии лишиться. С меня как минимум твой любимый тортик!

Кстати, об удалении сообщения из DLP - аналитик безопасности и офицер безопасности ДЗО не смогут этого сделать, ведь мы заботливо ограничили права на это действие ;)

Не позволить удалять данные – хорошо, но еще лучше – узнать, что сотрудник пытается скрыть от компании. Поэтому мы также добавили срабатывание политики по ключевым словам «удалить сообщения», «Подчисть переписку» и т.п. в адрес сотрудников, работающих с DLP, установив высокий уровень критичности и добавив уведомление об этом прямиком руководителю службы безопасности головного офиса в Москве.

Начинаем расследование. На кону премия, штрафы и самое главное – «как минимум, торт». Переходим в раздел «Поиск» и смотрим сообщения между Летящей Натальей Павловной и адресом Dmitriicarsale@mail.ru за все время.

Видим довольно интересное развитие событий.

Начинается все с письма 07.10.2019, 17:41:00 from na.letyashaya@mzprogress.ru to Dmitriicarsale@mail.ru «Дим, не топи когда машину компании на перепродажу перегоняешь. Со штрафом ты уже знаешь, что делать! И чтобы проблем больше не было. Не превращайте как в прошлый раз машину в аттракцион!» (в электронном сообщении пересылается информация о штрафе и вложено фото с камеры контроля скоростного режима).

Обычно все штрафы на предприятии оплачиваются автоматически (кто его разберет, за что там пришло, автопарк ведь большой). Но в этот раз бухгалтер был обижен до глубины души – ее благим порывом и доверием злоупотребили. И, кажется, что это не впервые («не превращайте, как в прошлый раз, машину в аттракцион»).

	 07.10.2019, 19:07:00 from Dmitriicarsale@mail.ru to na.letyashaya@mzprogress.ru:

 «Прости, гнал в салон, хочу побольше успеть и подзаработать, 
а то денег нет. Не афишируй, пожалуйста»

Читаем далее и видим обещания, что больше такого не будет

	 07.10.2019, 19:44:00 from Dmitriicarsale@mail.ru to na.letyashaya@mzprogress.ru:

 «Наташ, а ты не могла бы выручить и заплатить сама? 
Я переведу ближайшие 2 дня. Больше такое не повторится»

Но не тут-то было. Через неделю главный бухгалтер пересылает Дмитрию новый штраф и новое фото с дорожной камеры.

	 14.10.2019, 09:32:00 from na.letyashaya@mzprogress.ru to Dmitriicarsale@mail.ru:

 Это кто, я так понимаю новый начальник +1 на машине под реализацию катаются? 
Я за них платить не буду!!!!!! 
Я тебе опять помогла и работы подкинула, а ты....Сам плати штрафы!

И дальше мы видим, что ситуация совсем вышла из-под контроля. Даже Дмитрий не знает, кто в машине:

	 14.10.2019, 10:40:00 from Dmitriicarsale@mail.ru to na.letyashaya@mzprogress.ru:

 «Это не начальник. Я даже не знаю кто это. 
Это было на выходных, судя по штрафу… Узнаю, ни за что не плати больше»

Через месяц еще одно пересылаемое сообщение, но так как вся ситуация тянется уже 3 месяца, то сейчас приходят сообщения уже о передаче штрафов в ФССП.

 
        09.12.2019, 15:00:00 from na.letyashaya@mzprogress.ru to Dmitriicarsale@mail.ru

«Что хочешь делай, но вопрос закрой! 
Твое руководство новое, а на машине для перепродажи опять все катаются. 
Это уже слишком! Там штрафов куча!!!»

        From: no-reply@gosuslugi.ru
        Sent: 07.12.2019 12:11
        To: na.letyashaya@mzprogress.ru

Subject: FW: Истечение срока оплаты административного штрафа ГИБДД 

Здравствуйте, Наталья Павловна! 

Истечение срока оплаты административного штрафа ГИБДД. 
Взыскание передается в Федеральную службу судебных приставов. 

В Личном кабинете Портала Госуслуг Вы можете получить подробную информацию. 

Подробная информация> 

С уважением,

Единый портал государственных услуг. 

Данное письмо сформировано автоматически и не предполагает ответа. 
Пожалуйста, не отвечайте на него.

На этом общение Натальи и Дмитрия прекращается.

Проверяем, сколько же за это время накопилось штрафов в адрес Летящей от госуслуг, поставив фильтрацию по ДЗО Пермь.

Узнаём, что с тех пор накопилось 25 неоплаченных штрафов, и срок оплаты некоторых из них почти истёк. ГИБДД уведомило, что передает штрафы для взыскания в ФССП.

Учитывая, что переписка с Дмитрием оборвалась, а через месяц Наталья попыталась попросить своего друга из ИБ удалить переписку, мы можем судить, что ситуация все же решилась, но уже при личном общении, как обычно и бывает, когда масштаб проблем нарастает.

***

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

Чем же в действительности закончился кейс на пилоте? В ходе анализа сообщений и беседы с бухгалтером выяснилось:

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

2. В начале месяца главный бухгалтер оплачивала первые штрафы за собственный счет, просила представителя автосервиса компенсировать траты, но он не предпринимал никаких действий.

3. Нарушения множились, в результате количество штрафов достигло 177. Главный бухгалтер перестала их оплачивать, ожидая ответа из автоцентра.

4. Истек срок уплаты части штрафов, ГИБДД передала их для взыскания в ФССП, что могло привести не только к наложению исполнительского сбора (7 % от суммы взыскания по каждому исполнительному документу, но не менее 10 000 руб.), но и списанию денежных средств со счета или блокировке проведения операций.

В результате проведения расследования ведущий бухгалтер была привлечена к дисциплинарной ответственности, практика лоббирования интересов автоцентра была пресечена, а его руководство оплатило все штрафы и принесло свои извинения.

Backstage

Именно так заказчик видит историю из кейса, потому что мы ее такой создали, подготовили и рассказали. За результатом, который видят на демостенде, стоит не менее интересная история.

Откуда берутся кейсы

Первый вариант (предпочтительный) – это реальные истории с пилотов без добавления сообщений. Они всегда цепляют. Второй вариант – отталкиваемся от функционала и обсуждаем, какие новые фичи будем демонстрировать кейсами, а какие просто показывать на стенде без истории. Для этого проводим брейнштормы, обмениваемся опытом и историями из личной практики расследований. Вместе мы создаем легенду, которая ложится в основу инцидента безопасности.

После того, как определились с идеей кейса, описываем процесс, который протекает в системе. Обсуждаем, на какое действие из кейса сработала система и как дальше раскручивается цепочка действий офицера безопасности на эту сработку.

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

Как мы воссоздаем кейс на демостенде

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

После того, как создали заливочную таблицу с кейсовым трафиком, мы создаем вложения, которые, по замыслу, пересылаются вместе с сообщениями. В случае с описанным кейсом мы использовали реальные снимки со скоростных камер видеонаблюдения ГИБДД (размыв номер автомобиля и отредактировав геоданные камеры в соответствии с кейсом). Часто создание вложений – процесс еще более креативный и скрупулёзный. Чтобы имитировать переписку в WhatsApp, нам приходилось менять имена контактов коллег в телефоне, имитировать переписку, затем фотошопить аватарки, время отправки сообщения и т.д.

Чтобы история ожила на стенде, нам нужно создать компанию, в которой протекает действие, и персон, которые в этом участвуют. С самых ранних версий Solar Dozor, чтобы стенд не пустовал, а выглядел как настоящая инсталляция, мы придумали свою компанию с сотрудниками и их досье - акционерное общество «Машиностроительный завод «Прогресс». Продукт развивался, добавилась возможность поддержки территориально распределённого режима (MultiDozor), и наш выдуманный завод тоже пошел на расширение. В его оргштатной структуре (ОШС) добавился головной офис в Москве и отдел поддержки продаж в Перми.

Начнем с самого начала - для функционирования стенда нам нужно придумать документ с ОШС предприятия и системой подчинения.

Головная группа – это АО «Машиностроительный завод «Прогресс»», в составе которого главный Московский офис, производство и Пермский филиал. В .excel подразделения каждого филиала начинаются со своей цифры: 1,2,3. Каждой группе в структуре предприятия присвоен уникальный ID, а также PID – идентификатор группы, которой она подчиняется. Таким образом, мы расписываем древовидную систему организации оргштатной структуры.

В интерфейсе структура организации выглядит так:

Следующий срез данных – это информация о сотрудниках. Мы придумали компанию, филиалы, департаменты каждого филиала, а теперь придумываем сотрудников, которые в ней работают. Для каждого сотрудника указываем данные, которые есть у наших заказчиков на их инсталляциях Solar Dozor в разделе «Досье»: подразделение, в котором он работает; ФИО; должность; руководителя, дату рождения; email; добавочный номер; ПК; дату принятия на работу; привилегии (доступы); названия файлов с фотографиями для карточек сотрудников (100х100 и 30х30); sid; hostname; аккаунты в мессенджерах; login. Поначалу мы просто брали для ОШС фотографии актеров или публичных лиц, а потом нашли генератор фотографий несуществующих людей и теперь «новичкам на заводе» делаем корпоративные фотографии с помощью него.

Последний лист документа с оргштатной структурой – это персоны, которые необходимо поместить в группы особого контроля.

В интерфейсе это выглядит следующим образом:

После того, как мы разобрались с ОШС организации, переходим к заливочной таблице фонового трафика. На главном листе «Управление» конфигурируем параметры фонового трафика. Стараемся сделать трафик, похожий на тот, что есть во многих компаниях.

Мы обозначаем дату, от которой необходимо генерировать трафик, каким количеством сообщений сотрудники должны обмениваться в день, определяем период, указываем параметры распределения этого трафика. Отмечаем, хотим ли мы, чтобы трафик отправлялся по выходным. В значении указываем, сколько сообщений в процентах от всего, что мы указали, уйдет на утро/день/вечер/ночь. Далее распределяем сообщения по каналам, чтобы на стенде отобразился красивый график с распределением: мессенджеры, входящая и исходящая почта, публикации в сети и т.д. При этом также указываем, чтобы 15% сообщений от всего трафика помимо текста содержали еще и вложения. А дальше распределяем, какие типы вложений содержат эти 15% трафика – архивы, изображения и т.д. На некоторые из этих вложений система будет срабатывать как на события, благодаря чему трафик будет более насыщенным.

Лист «Фон» еще пуст, в нем появится трафик после настройки всех листов и последующего нажатия кнопки «Создать фоновый трафик» на листе «Управление».

Переходим к листу «Словарь Темы сообщений»: прописываем универсальные темы email-писем, которые система потом присвоит произвольно каждому сообщению.

Далее придумываем содержание сообщений фонового трафика на листе «Словарь Тексты сообщений». Ранее мы использовали парсинг текста из книг, потом в погоне за совершенством придумали тексты сообщений: рассылка новостей компании, «Коллеги, у меня д.р., угощайтесь пиццей на кухне», «В какие сроки нужно выполнить эту задачу?» и т.д.

Далее лист «Вложения» (их процент в трафике мы указывали на первом листе). В нем приводим более детальную информацию о тех вложениях, которые должны быть в трафике. Каждый тип файла мы соотносим с настроенными на стенде графическими объектами, информационными объектами, настройками политик и соответствующими им уровнями критичности и типами угрозы. Под каждую строчку в excel в папке на компьютере лежит файл с соответствующим названием, то есть для фонового трафика мы подготовили 100 файлов соответствующего типа. Логика шапки, как и во всей заливочной таблице: id файла, формат, название, название информационного объекта (io name), на которое система должна сработать в случае необходимости. Следом – пометка, уровень критичности и тип угрозы.

В следующем листе прописываем внутренние адреса, которым сообщения и вложенные файлы будут отправляться. Если мы хотим сделать универсальный фоновый трафик сразу на всю компанию, то копируем в этот лист все адреса сотрудников из оргштатной структуры.

Если мы хотим создать трафик общения сотрудников компании с людьми из других организаций, придумываем и записываем электронные адреса с недоменным адресом компании в «Словарь Внешние адреса».

Как только мы закончили заполнять нужные нам данные в таблице, возвращаемся в «Управление», нажимаем «Создать фоновый поток».

В листе «Фон» генерируется тот трафик, который мы указали на других листах.

Как мы заливаем кейсы на стенд

Заливочный документ из excel переводим в формат CSV. Полученный файл CSV в кодировке UTF-8 помещаем на сервер Solar Dozor. Далее запускаем скрипт заливки данных data-loader, в качестве параметра указывая путь к файлу CSV. Таким образом, инструмент начинает автоматически лить сообщения в базу данных системы.

Для заливки данных на стенд мы создали несколько инструментов – для сообщений, событий, документов – data-loader, загрузки оргштатной структуры – ad-loader, скиншотов – agent-media , данных раздела «Досье» – ab-loader, контроля рабочего времени – tc-loader, для эмуляции работы Dozor Endpoint Agent - agent-demo, создания кривой уровня доверия - CtlHistory. На загрузку всех необходимых документов требуется время, так как системы должны обработать данные из таблиц в более 1500 строк.

Каждый стенд обладает уникальной историей и нюансами создания. Для демостенда Solar webProxy мы использовали собственный скрипт, который эмулирует активность пользователя при работе через браузер в сети интернет (загружает в БД информацию о том, к каким веб-ресурсам отправлялся трафик).

После заливки всех файлов на стенд мы видим результат нашей большой работы в системе, в первую очередь на так сказать ситуационном центре - рабочем столе аналитика. Виджет «События» теперь содержит сообщения из кейсового или фонового трафика заливочных таблиц, на которые сработали настроенные под АО «Машиностроительный завод «Прогресс» политики системы и с которыми офицеру безопасности нужно разобраться в первую очередь. Виджет «Информационные объекты» отображает данные по количеству событий с динамикой по информационным объектам, контролируемым на предприятии. Виджеты «События по типу угроз» и «Все события по каналам коммуникаций» теперь тоже наполнены данными. В центре – динамика событий по группам особого контроля, которые указывали в созданной ОШС, и персоны, которые своими действиями нарушали настроенные политики системы, что автоматически привело к снижению уровню доверия и подсвечиванию их на рабочем столе офицеру безопасности как персон, требующих внимания.

Теперь демостенд готов, и нажав на любой виджет, сообщение, персону, можно попасть либо на кейс, либо на полноценно наполненный данными раздел Solar Dozor, позволяющие пройтись по демостенду словно это боевой стенд с реальными данными.

Послесловие

В этом материале мы рассказали, как создаем демостенды, моделируя реальные кейсы заказчиков на нереальных данных, как выстраиваем имитацию реального фонового трафика и какие инструменты используем для заливки на стенд. Итого в общей сложности мы создали трафик переписки из 114928 сообщений, отправленных в течение трех месяцев в компании, штат которой состоит из 155 сотрудников, и множество событий и инцидентов.

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

Авторы:

Виктория Жаман, бизнес-аналитик компании «Ростелеком-Солар»

Сергей
Ковалев, старший psale-консультант компании «Ростелеком-Солар»