План реагирования на инциденты при передаче файлов

Инцидент при передаче файлов не ждёт вашей готовности. Когда в 2023 году MOVEit допустил массовую утечку, сотни организаций потеряли данные за часы до того, как узнали о векторе атаки. В России операторы персональных данных обязаны по 152-ФЗ и последующим разъяснениям Роскомнадзора (Роскомнадзор) уведомлять регулятора об инцидентах в течение 24 часов с момента обнаружения нарушения, связанного с персональными данными, и устранять последствия в течение 72 часов. По GDPR Статье 33 — та же логика: 72 часа до надзорного органа. Работающий план реагирования следует жизненному циклу NIST SP 800-61 Rev. 2, адаптированному к конкретным рискам обмена файлами: подготовка, обнаружение и анализ, сдерживание, ликвидация последствий и восстановление, а также действия после инцидента. В нём поимённо называется руководитель реагирования, определяются уровни серьёзности, перечисляются действия по сдерживанию — отзыв ссылки, ротация ключей — и требуется захват криминалистических доказательств с последующим постмортемом, хранящимся не менее трёх лет.

Распространённые типы инцидентов при передаче файлов

Инциденты при передаче файлов группируются по паттернам. Ошибочные передачи: отправитель вводит неверный адрес электронной почты и отправляет 30-мегабайтный экспорт PHI не тому получателю. Компрометация учётных данных: учётная запись отправителя взломана фишингом, и злоумышленник использует её для загрузки или получения файлов. Утечка ссылки: общедоступный URL размещается публично или пересылается за пределы предполагаемого получателя. Взлом поставщика: сама платформа передачи файлов скомпрометирована (MOVEit в 2023, GoAnywhere в 2023 — показательные примеры). Внутренняя эксфильтрация: авторизованный пользователь злоупотребляет доступом для передачи конфиденциальных файлов вовне. План должен адресовать каждый паттерн конкретными сигналами обнаружения и действиями по реагированию.

Подготовка: что нужно до инцидента

Подготовка — это невидимая работа, ускоряющая реагирование. Назначьте руководителя реагирования на инциденты и его заместителя с контактной информацией, основным и резервным способами связи. Опубликуйте внутренний адрес security@ и телефонное дерево эскалации, доступное 24/7. Предварительно авторизуйте конкретные действия по реагированию: руководитель может отключить учётную запись пользователя, отозвать ссылки передачи и ротировать API-ключи, не ожидая дополнительного разрешения.

Поддерживайте актуальный список субпроцессоров и контакты поставщиков, чтобы вы могли связаться с командой безопасности поставщика услуг передачи файлов в течение часа. Держите шаблоны уведомлений об инцидентах заранее подготовленными и согласованными юристами для каждого регулятора, которому вы отчитываетесь (Роскомнадзор, CNIL, ICO, HHS OCR). Проводите настольные учения не реже двух раз в год.

Сигналы обнаружения, за которыми нужно следить

Эффективное обнаружение сочетает автоматизированные оповещения и сообщения пользователей. Автоматические сигналы: необычные объёмы загрузок от одного пользователя или по одной ссылке, загрузки из неожиданных географических регионов или IP-адресов, всплески неудачной аутентификации к учётным записям передачи, крупные исходящие передачи в нерабочее время, файлы, загружаемые во внешние инструменты, не должные получать данные компании.

Правила SIEM в Splunk, Sentinel или Elastic используют журналы передачи файлов и применяют эти паттерны. Сообщения пользователей также важны: получатель, сообщающий «я получил этот файл, но не знаю почему», — часто первый признак ошибочной передачи. Опубликованный канал для сообщений с быстрым ответом побуждает пользователей сообщать об инцидентах на ранних этапах.

Действия по сдерживанию в течение минут

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

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

Сбор криминалистических доказательств

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

Для учётной записи пользователя: журналы аутентификации, история сессий, недавняя активность в системах через корреляцию SIEM. Сохраняйте экспорты журналов в хранилище с защитой от записи для предотвращения фальсификации. В серьёзных случаях привлекайте специалистов по криминалистике из таких компаний как Mandiant, CrowdStrike Services или Kroll Cyber на ранних этапах.

Сроки уведомления и обязательства

Регуляторы устанавливают жёсткие сроки. По 152-ФЗ и разъяснениям Роскомнадзора: уведомление об утечке персональных данных в течение 24 часов, отчёт о ликвидации последствий в течение 72 часов. GDPR Статья 33: 72 часа надзорному органу для нарушений персональных данных, вероятно создающих риск. HIPAA: 60 дней для нарушений PHI, затрагивающих людей, с уведомлением HHS и возможно СМИ при более 500 случаях. GLBA Safeguards Rule: 30 дней FTC при нарушениях, затрагивающих 500+ потребителей. NIS2 Статья 23: 24 часа для раннего предупреждения о значимых инцидентах, 72 часа для полного уведомления.

В плане указывается: кто составляет уведомления, кто их утверждает, и механизм распределения. Пропустите окно — и штрафы возрастают, поэтому отсчёт времени начинается при обнаружении, а не по завершении анализа.

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

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

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

Постинцидентный анализ и документация

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

Распространяйте в команде реагирования на инциденты, руководстве по безопасности и юридическом отделе. При значимых инцидентах информируйте совет директоров или комитет по аудиту. Архивируйте постмортем в хранилище с возможностью поиска. Регуляторы, расследующие жалобу годы спустя, его запросят. Аудиторы SOC 2 Type II будут выборочно проверять постмортемы как доказательство контроля реагирования на инциденты.

Учения без прикрас

Настольные учения часто страдают от вежливого участия. Реальные учения вводят неоднозначность (частичная информация, противоречивые сигналы), временное давление (симулированные 72-часовые часы GDPR, которые идут) и пробелы в межкомандной координации (юридический отдел не может связаться с руководителем реагирования на инциденты). Варьируйте сценарии по распространённым паттернам: внутренняя эксфильтрация, взлом поставщика, ошибочная передача PHI, программа-вымогатель, затронувшая файловое хранилище. После учения проводите такой же строгий постмортем, как после реального инцидента.

HexaTransfer поддерживает отзыв ссылки на уровне передачи, публикует подход к реагированию на инциденты и использует клиентское шифрование, поэтому компрометация сервера не может раскрыть файлы в открытом тексте. Попробуйте на hexatransfer.com — бесплатно, без регистрации, максимум 10 ГБ.

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