Алгоритм «0-24-72»: что делать после утечки данных

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

Кого нужно уведомить

Список тех, кого важно проинформировать об инциденте, различается от компании к компании:

• Роскомнадзор — уведомить регулятора следует в любом случае.
• Национальный координационный центр по компьютерным инцидентам (НКЦКИ) — если организация является субъектом критической информационной инфраструктуры (КИИ).
• Центробанк — если организация относится к финансовому сектору.
• Партнёры — как клиенты, так и подрядчики организации. Будет намного лучше, если о потенциальном инциденте партнёр узнает именно от представителя компании, а не из Telegram-каналов, с форумов или из СМИ.

24 и 72 часа — почему именно эти цифры

В течение суток после инцидента идёт сбор первичной информации о том, что же произошло. Через 24 часа у компании возникает точка невозврата, когда необходимо в любом случае уведомить Роскомнадзор. В противном случае можно получить штраф.

Эти 24 часа важно изначально рассматривать как максимальный срок. Не стоит действовать расслабленно, полагая, что завтра команда придёт на работу и у неё будет ещё 4 часа — все успеют всё собрать. Начинать стоит сразу же, а через 24 часа уже нажимать кнопку отправки уведомления регулятору.

Следующий важный этап — 72 часа, в течение которых проводится подробное расследование инцидента. По его результатам составляется акт, он направляется в Роскомнадзор. Акт важно отправить даже в том случае, если инцидент не подтвердился. Он будет доказательством проведённого компанией расследования.

Три команды: кто работает над расследованием инцидента

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

Техническая команда для ответов на важные вопросы

Её участники разбираются, что, как и когда случилось. Они собирают логи, делают анализ сетевой активности, анализируют отчёты средств защиты, ищут цифровые следы.

Примерный перечень того, что должна собирать техническая команда:

1. логи корпоративной почты;
2. журналы доступа к базам данных;
3. логи межсетевых экранов и WAF;
4. данные DLP-систем;
5. записи систем контроля доступа (СКУД);
6. логи файловых серверов и облачных хранилищ;
7. мониторинг через Threat Intelligence платформы.

Юридическая команда для подготовки документов

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

В задачи этой команды также входит классификация: под какую статью попадает произошедшее, какие именно категории персональных данных утекли и какой вред может быть причинён пострадавшим субъектам персональных данных. «Юристы» занимаются контролем доказательной базы — они должны обеспечить корректность всей предоставляемой регулятору информации.

Команда коммуникаций и партнёрского взаимодействия для работы с репутацией

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

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

Ключевой задачей команды остаётся управление репутационными рисками. Если партнёр узнает об инциденте от самой компании, это будет сигнал о том, что она действительно заботится о безопасности и сохранности обрабатываемых данных.

Как обеспечить взаимодействие команд

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

Созвоны и совещания стоит проводить каждые 30 или 60 минут, не дожидаясь, когда удастся собрать полный комплект информации. Может возникнуть ситуация, когда техническая команда попросит больше времени, чтобы собрать и предоставить все данные. Однако лучше всё же обмениваться информацией через равные промежутки времени, организуя встречи буквально по таймеру.

Основной вопрос, на который отвечают участники такого созвона или встречи: «У кого что есть на данный момент?». Техническая команда может сказать, что видит в логах выгрузку 15 тысяч записей из базы клиентов, нашла упоминание корпоративной БД на форуме Х или заблокировала подозрительные сессии доступа. Юридическая команда может запрашивать у технической необходимую информацию для документов, например, характер утечки, выписки логов для приложения к акту или предварительную оценку количества затронутых субъектов персональных данных. Команда коммуникаций определяет партнёров, которых могла затронуть утечка, и запрашивает у коллег информацию, которую нужно срочно им сообщить.

Что отправить регулятору и партнёрам

Работа по реагированию на инцидент сводится к трём документам:

1. Первичное уведомление в Роскомнадзор — это не итоговый отчёт, а заявка о произошедшем. Компания уведомляет регулятора, что инцидент, вероятно, был и теперь она выполняет определённые действия.
2. Акт внутреннего расследования, для отправки которого в Роскомнадзор даётся 72 часа, должен быть максимально полным. Это главный козырь компании, в котором она либо подтверждает утечку и описывает масштаб, либо опровергает её и прикладывает доказательства. Акт не освобождает от ответственности, но служит сигналом для регулятора, что в организации не бездействуют и принимают необходимые меры.
3. Уведомление для партнёров, которое при идеальном сценарии развития событий стоит отправить в первые 4–8 часов после инцидента.

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

Выводы: что важно помнить и как подготовиться

• Не бывает исключений, при которых не нужно уведомлять Роскомнадзор. Если есть какой-то индикатор компрометации или триггер, сначала надо отправить уведомление, а после — разбираться. Если инцидент в итоге не подтвердится, всегда можно так и пояснить регулятору в дальнейшем.
• При расследовании инцидента важна параллельная работа команд (не последовательная) с периодической синхронизацией имеющихся данных.
• Начать расследование как можно быстрее поможет заранее разработанный регламент действий для первых 4 часов. Этот интервал обычно закладывает основной фундамент. А регламент нужен, чтобы все начали работу сразу же, а не ждали, например, пока коллеги придут с утра в офис.
• Учебная тревога поможет убедиться, что регламент действительно работает. Важно реально провести созвоны и попробовать заполнить шаблоны всех документов. Участников команд также стоит заранее научить задавать правильные вопросы. Так они смогут максимально быстро собрать необходимые сведения в случае реального инцидента.