Автоматизация мониторинга и расследования инцидентов в DLP-системе

Автор: Галина Рябова,
Руководитель аналитического отдела
компании Solar Security

Введение

Работа любой DLP-системы строится на инцидентной модели. Это определяется самим назначением системы: выявление случаев нарушения правил хранения, обработки и передачи конфиденциальной информации (политики информационной безопасности) или, другими словами, событий и инцидентов информационной безопасности.

На практике поток событий информационной безопасности (далее – ИБ), зарегистрированных системой, может достигать нескольких тысяч в день на человека. Возникает необходимость не только в средствах регистрации событий и инцидентов, но и в средствах управления ими.

Развитие современных DLP-систем идет в направлении автоматизации этого процесса. Уже сейчас многие системы умеют собирать, хранить и категорировать события ИБ, выявлять критичные инциденты, уведомлять о них всех необходимых лиц, предоставляют удобный инструмент сбора дополнительной информации и расследования инцидентов, позволяют строить различные отчеты (по конкретному событию, по конкретному работнику или группе работников) предоставлять сводную информацию о всех инцидентах и многое другое. Отдельно стоит отметить, что современные системы DLP хранят архивы всех передаваемых сообщений, что позволяет проводить более результативные расследования и строить корреляции между различными событиями безопасности.

Единой методики расследования инцидентов не существует, каждая компания должна «затачивать» под себя общие рекомендации. Детали процесса выявления и реагирования будут зависеть от многих факторов, например, от общей культуры и политики ИБ в компании, роли и места подразделения ИБ в системе безопасности компании, наименования, версии и настроек используемой системы DLP, допустимого уровня рисков, критичности обрабатываемой информации и многого другого. Однако, проанализировав многие «лучшие практики» по построению процесса управления инцидентами (например, ISO/IEC 27002:2013 (A.16), ISO/IEC 27035:2011, NIST SP 800-61 Rev. 2, соответствующие процессы в ITIL и COBIT5), мы предлагаем ориентироваться на следующую последовательность шагов при работе с системой DLP Solar Dozor:

1. Обнаружение и регистрация событий ИБ
2. Категорирование событий, сбор дополнительной информации и выявление инцидентов ИБ
3. Оперативное реагирование на инцидент (предотвращение или устранение последствий инцидента)
4. Разбор (расследование) инцидента
5. Реагирование на инцидент (дисциплинарные взыскания, уголовное преследование нарушителей, управленческие решения и другое)
6. Анализ причин инцидента и «полученных уроков», подготовка рекомендаций по повышению общего уровня ИБ (при необходимости)

Именно про них мы и расскажем в этой статье.

1. Обнаружение и регистрация событий ИБ

В соответствии с «лучшими практиками» в системе разделены понятия «событие» и «инцидент». Вот определение этих терминов по ГОСТ 27000-2012:

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

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

На первом этапе DLP система Solar Dozor в соответствии с заданными политиками контентного и контекстного анализа выявляет именно события ИБ и проводит их начальную классификацию. Такими событиями могут быть отправка информационных сообщений определенного содержания, нарушение правил хранения файлов с информацией ограниченного доступа, «подозрительная переписка» и другое. Сразу производится регистрация, архивация и первичная классификация событий.

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

Рис. 1 – Список событий с примененными фильтрами

По умолчанию, рекомендуется хранить все события не менее 6 месяцев, так как это предельный срок для дисциплинарных взысканий по ТК РФ, но при желании этот срок можно и увеличить. В отличие от большинства решений этого класса DLP система Solar Dozor начала свое развитие не с системы оповещений об утечках, а именно с почтового архива. Поэтому система отлично справляется с большими объемами хранения и обработки данных.

2. Категорирование событий, сбор дополнительной информации и выявление инцидентов

Одним из ежедневных действий офицера безопасности является мониторинг событий ИБ. Самые важные из них отображаются на рабочем столе офицера безопасности (рис.2), помимо этого, система позволяет настроить автоматическое уведомление о критичных событиях.

Рис. 2 – Рабочий стол офицера безопасности

Офицер безопасности может просматривать поток событий или выделенную его часть (см. Рис. 1) и по каждому проводить экспресс-оценку:

• реальность нарушения (действительно ли это нарушение, ошибочное срабатывание, чья-то некомпетентность);
• потенциальный ущерб для компании;
• возможность дальнейшего негативного развития ситуации;
• наличие признаком умышленных противоправных действий;
• необходимость принятия экстренных мер.

По результатам экспресс-оценки офицер безопасности может принять одно из следующих решений:

• принять событие к сведению и отметить, как просмотренное. Это позволит избежать повторного анализа уже просмотренного события;
• отметить событие, как ошибочное срабатывание. Это позволит получить статистику по неправильным срабатываниям политики и быстро выявить правила, требующие донастройки;
• создать инцидент, если нарушение существенное и/или требует дальнейшего анализа.

Чтобы зафиксировать свое решение в системе, офицер безопасности меняет статус события в карточке события (рис.3).

Рис. 3 – Карточка события. Изменение статуса события

Если событие переводится в статус «Инцидент», то на его разбор (расследование) назначается ответственный. У инцидентов в системе есть 3 статуса: «открыт», «закрыт» и «не инцидент».

3. Оперативное реагирование на инцидент

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

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

Разбирая инцидент, офицер безопасности может оповестить о нем заинтересованных лиц, приложив к уведомлению информацию об инциденте или указав на него ссылку. Для этого в системе есть стандартная функция уведомления (рис.4).

Рис. 4 – Уведомление об инциденте

Или, например, включить причастного к инциденту сотрудника в группу особого контроля, коммуникации которой контролируются более полно и жестко (рис.5).

Рис. 5 – Перевод сотрудника на особый контроль

4. Разбор (расследование) инцидента

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

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

В Solar Dozor офицеру безопасности для проведения расследования доступны такие инструменты, как:

• карточка инцидента, содержащая всю информацию по нарушению и связанная с карточкой сообщения;
• карточка сообщения, содержащая перехваченное сообщение, структуру его частей, подробную техническую информацию о сообщении и ходе его обработки;
• досье, содержащее агрегированную информацию о персоне и ее коммуникациях, - профиль поведения персоны;
• граф связей, позволяющий выявить контакты, в том числе «через одного»;
• развитая система поиска, с действительно большим количеством поисковых атрибутов, с возможностью автоматически создавать контекстные поисковые запросы, с автоматическим определением критериев «похожести», с большой библиотекой готовых поисковых запросов;
• развитая система отчетности, позволяющая рассмотреть данные в разных срезах.

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

5. Реагирование на инцидент

В зависимости от тяжести инцидента можно предложить 3 группы дальнейших действий с нарушителем.

Группа А. По решению ответственного за ИБ	Группа Б. По решению руководства и сотрудников отдела персонала	Группа В. По решению руководства, сотрудников отдела персонала, юристов и ответственного за ИБ
1. Перевод в группу «Особый контроль» 2. Получение объяснительной 3. Профилактическая беседа	4. Лишение благ и привилегий (в т.ч. и лишение избыточных прав доступа) 5. Дисциплинарные взыскания в виде замечания или выговора	6. Дисциплинарные взыскания в виде увольнение по соответствующим основаниям 7. Увольнение по инициативе работника/ по соглашению сторон 8. Возмещение ущерба 9. Уголовное преследование

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

6. Анализ причин инцидента и «полученных уроков», подготовка рекомендаций по повышению общего уровня ИБ

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

• Что необходимо сделать, чтобы такие инциденты не происходили в будущем (или их количество сократилось)?
• Как можно улучшить процедуру реагирования на инциденты?

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

Не обязательно проводить такой анализ после каждого инцидента, но делать это следует достаточно регулярно.

7. Практика применения

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

Итак, в информере «Мои инциденты» на рабочем столе офицер безопасности видит инциденты, за которые он ответственен (Рис. 6).

Рис. 6 – Информер «Мои инциденты»

В настоящий момент на офицера безопасности назначен один инцидент, связанный с копированием на съемный носитель (Рис. 7).

Рис. 7 – Краткая карточка инцидента

Подробности события безопасности можно посмотреть в полной карточке инцидента (Рис. 8).

Рис. 8 – Полная карточка инцидента

Из карточки можно узнать следующую важную информацию по инциденту:

• на USB-носитель скопирован инкрементальный бэкап продуктивной БД (по названию файла);
• инцидент произошел в 07:43, хотя рабочий день с 9:00;
• сотрудник, нарушивший политику безопасности, является начальника отдела информационных технологий и входит в группу особого контроля «На увольнение».

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

Рис. 9 – Все сообщения о копировании на съемный носитель

В списке видим копирование полного бэкапа, произошедшее еще до увольнения сотрудника (и являвшееся легитимным на тот момент), и еще несколько фактов копирований файлов (Рис. 10).

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

Рис. 10 – Сообщение о факте копирования полного бэкапа.

Отсупление

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

Разбор непосредственно инцидента на этом заканчивается. Тот факт, что удалось предотвратить кражу информации, свидетельствует об адекватных мерах защиты. Возможно, стоит подумать об ужесточении правил использования съемных носителей, если это не повредит бизнес-процессу.

Однако для повышения ИБ имеет смысл повнимательнее присмотреться к нарушителю. Для этого открываем его досье (Рис. 11):

Рис. 11 – Досье. Карточка персоны

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

Возвращаемся в Досье. Строим граф связей Бубнова (Рис. 12).

Рис. 12 – Граф связей

На графе видно, что среди его активных контактов есть человек, не связанный с Бубновым должностными обязанностями, контакты с которым явно носят личный характер, - Яндукин Аристарх Макарович, начальник отдела управления банковской ликвидностью.

Достраиваем на графе связи Яндукина и видим, что он вел активную переписку с Золиным Евгением Артемьевичем, уволившимся некоторое время назад вице-президентом банка. Ходят слухи, что Золин перешел на должность директора нового банка, специализирующегося на кредитовании населения. В этом свете факт копирования бэкапа надежных заемщиков банка заиграл новыми красками.

Ищем дополнительную информацию на Золина в интернете и видим, что онд ействительно получил эту должность месяц назад.

Выбрав на графе связей Бубнова и возможного посредника Яндукина, строим запрос их переписки за последний месяц (Рис. 13):

Рис. 13 – Построение поискового запроса

Результат поиска выдает слишком много сообщений (переписывались они активно). Сужаем поиск, добавив условие полнотекстового поиска, содержащее адрес банка, в котором в настоящий момент работает Золиным. По более строгим критериям поиска находится сообщение скайпа, в котором Ядукин сообщает Бубнову, по какому адресу приехать на собеседование на должность начальника ИТ отдела (Рис. 14).

Рис. 14 – Карточка сообщения

Теперь с большой долей уверенности можно связать все известные нам факты в общую схему:

1. Золин увольняется с целью открыть свой собственный банк.
2. Через доверенное лицо – Яндукина выходит на подумывающего о смене работы Бубнова, имеющего доступ к бэкапам БД бизнес-приложений, в том числе бэкапам БД надежных заемщиков.
3. Бубнов встречается с Золиным, который предлагает ему более высокую должность и очевидно, одним из условий перехода на нее является информация, доступ к которой имеет Бубнов.

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

Заключение

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