Как реагировать на кибератаку: пошаговый план действий

Введение

Большинство компаний узнают о взломе не от своих систем мониторинга, а от хакеров, когда те уже зашифровали данные или выставили их на продажу.

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

Когда атака всё-таки обнаружена, у команды нет времени разбираться, кто за что отвечает. Есть только план — или его отсутствие.

В этом материале пошаговый план для ИТ-команд, у которых нет выделенного операционного центра безопасности (SOC), зато есть задача: остановить атаку, сохранить доказательную базу и вернуть бизнес в строй.

Главное

• Среднее время присутствия злоумышленника в сети российской компании — 42 дня. За это время атакующий успевает повысить привилегии, скопировать данные и установить бэкдоры.
• Первые минуты инцидента определяют масштаб ущерба. Минимальное зафиксированное время от первоначального проникновения до полного шифрования инфраструктуры составляет 12,5 минуты.
• Реагирование — это последовательность, а не импровизация. Подготовка → обнаружение → сдерживание → форензика → устранение → восстановление → разбор. Пропуск или перестановка шагов уничтожает улики и открывает путь для повторного проникновения.
• Форензика начинается до любых изменений в системе. Дамп оперативной памяти — в первую очередь. Каждый артефакт документируется по цепочке хранения: кто собрал, когда, на каком носителе.
• Восстановление — только из чистого бэкапа, только после закрытия уязвимости. Восстановление из заражённой резервной копии или через незакрытый вектор атаки — прямой путь к повторному инциденту.
• Уведомление регуляторов — обязанность с жёсткими сроками. При утечке персональных данных — РКН в течение 24 часов (152-ФЗ). Субъекты КИИ — НКЦКИ в течение 3–24 часов (187-ФЗ, Приказ ФСБ № 546). Нарушение сроков — самостоятельный состав правонарушения.
• Компрометация учётных данных — сквозной риск на каждом этапе. Слабые пароли открывают первоначальный доступ, общие логины распространяют компрометацию, незакрытые учётки уволенных сотрудников становятся точкой повторного входа. Централизованное управление паролями закрывает этот риск системно.
• Разбор инцидента обязателен. Разбор — единственный способ превратить инцидент в данные для улучшения защиты. Без разбора компания платит дважды.

Почему скорость реакции решает всё

В 2025 году число киберинцидентов в России выросло на 42% — до 22 тысяч за год. Более 50% компаний в 2025 году столкнулись с кибератаками (CNews, 2026, ТАСС, 2025). По словам зампреда правления Сбербанка Станислава Кузнецова, озвученным на ВЭФ-2025, совокупный ущерб экономике за первые восемь месяцев 2025 года мог составить около 1,5 трлн рублей (Интерфакс, 2025).

"По нашей оценке, в 2025 году уже было атаковано не менее 53% российских компаний, при этом 8 из 10 столкнулись с серьезными последствиями, четверть этих компаний признала, что они понесли существенные репутационные риски, еще одна четверть призналась в больших финансовых потерях. Ну и 48% признались, что у них были простои, из бизнес, сайты, деятельность приостановились" — зампред правления Сбербанка Станислав Кузнецов

Каждая четвёртая атака заканчивается серьёзными последствиями: финансовый ущерб или длительный простой. Доля инцидентов с утечкой конфиденциальных данных выросла с 53% до 64%, а доминирующей схемой остаётся двойное вымогательство: шифрование инфраструктуры с одновременным похищением данных (Positive Technologies, 2026).

Эти цифры описывают операционную реальность. И главная переменная в ней — время: как быстро атака обнаружена и как быстро остановлена.

Как атакуют: векторы, которые нужно знать

В 2025 году 64% успешных атак на организации заканчивались утечкой конфиденциальных данных (Positive Technologies, 2026). Понять, откуда пришла атака, — значит понять, где была брешь. Большинство инцидентов начинаются с одного из пяти векторов.

Фишинг и социальная инженерия

Самый массовый вектор. 80% целевых атак начинаются с электронного письма, в 70% случаев почта — канал доставки вредоносного ПО (Positive Technologies, 2026).

Фишинг давно перестал быть письмом с ошибками от «нигерийского принца». Современные атаки приходят с взломанных легитимных аккаунтов — коллег, партнёров, подрядчиков. Письмо выглядит достоверно, отправитель знаком, контекст правдоподобен. Вредоносная нагрузка прячется внутри многоступенчатых контейнеров: архив → документ → макрос, или HTML-вложение, или QR-код, ведущий на фишинговую страницу.

Отдельная тенденция — phishing-as-a-service (PhaaS): готовые панели управления атаками, шаблоны писем и механизмы обхода почтовых фильтров доступны на теневых площадках. Порог входа для злоумышленника снизился до минимума.

Компрометация учётных данных

Второй по частоте вектор. Атакующий не взламывает систему, он входит в неё с валидными учётными данными. Источники скомпрометированных паролей:

• Утечки из сторонних сервисов. Сотрудник использует один пароль для корпоративного сервиса и личного интернет-магазина. Магазин взломали — пароль оказался в открытом доступе.
• Подбор по словарям. Слабые или предсказуемые пароли на привилегированных учётных записях взламываются за минуты.
• Инфостилеры. Вредоносное ПО, попавшее на рабочую станцию через фишинг, вытаскивает сохранённые пароли из браузеров и менеджеров паролей операционной системы.
• Общие логины. Несколько сотрудников или подрядчиков используют одну учётную запись — компрометация одного открывает доступ всем.

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

Эксплуатация уязвимостей

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

Особую опасность представляют устройства и сервисы, о существовании которых ИТ-команда не знает: теневая ИТ-инфраструктура, поднятая сотрудниками в обход регламентов.

Атаки через подрядчиков

Атакующий компрометирует не саму компанию, а её поставщика — интегратора, аутсорсера, разработчика ПО. Через доверенный канал он получает доступ к инфраструктуре заказчика, минуя периметровую защиту. Этот вектор особенно опасен тем, что действия атакующего неотличимы от легитимной работы подрядчика: те же учётные данные, те же системы, те же часы работы.

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

Вредоносное ПО: шифровальщики и инфостилеры

Вредоносное ПО применялось в большинстве успешных атак на организации в 2025 году (Positive Technologies, январь 2025). Два наиболее распространённых класса:

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

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

Векторы кибератак и меры защиты

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

Сколько времени злоумышленник остаётся в сети незамеченным

Среднее время обнаружения (Mean Time to Detect, MTTD) — среднее время между моментом проникновения и его обнаружением. Чем выше этот показатель, тем глубже атакующий укоренился в инфраструктуре до того, как его заметили.

Среднее время обнаружения для российских компаний составляет 42 дня. За это время злоумышленник, как правило, успевает:

• изучить топологию сети и определить пути к критичным системам
• повысить привилегии до уровня администратора домена
• скопировать или проиндексировать ценные данные
• установить бэкдоры для повторного доступа после «устранения» инцидента

При этом минимальное зафиксированное время от первоначального проникновения до полного шифрования инфраструктуры составляет 12,5 минуты (BI.ZONE, 2025). Это исключает любые паузы на согласование действий: у команды реагирования нет времени на обсуждение — только на исполнение заранее отработанного плана.

Второй ключевой показатель — среднее время восстановления (Mean Time to Respond/Recover, MTTR): время от обнаружения до полного восстановления операционной деятельности. Сокращение среднего времени восстановления — главная измеримая цель любого плана реагирования на инциденты (Incident Response Plan, IRP).

На практике среднее время восстановления складывается из нескольких последовательных этапов:

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

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

Разрыв между MTTD и MTTR — это и есть зона наибольшего риска. Компании, у которых нет задокументированного плана реагирования, тратят первые часы инцидента не на сдерживание угрозы, а на выяснение того, кто за что отвечает. Именно поэтому план реагирования измеряется не качеством документа, а скоростью исполнения в условиях реального давления.

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

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

Пошаговый план реагирования на кибератаку

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

Шаг 1. Подготовка — действия до инцидента

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

• Разработайте и задокументируйте план реагирования на инциденты. Документ должен содержать: классификацию инцидентов по типу и критичности, цепочку эскалации с конкретными именами и контактами, роли и зоны ответственности каждого участника, резервные каналы связи на случай компрометации корпоративной почты.
• Сформируйте команду реагирования заранее. В зависимости от масштаба компании в неё входят: специалист по форензике, юрист с опытом в области ИБ и защиты данных, ИТ-безопасность, операционный менеджер, представитель PR или коммуникаций. Если собственных ресурсов недостаточно — определите подрядчиков и заключите договоры до инцидента, а не во время него.
• Проведите инвентаризацию активов и данных. Знайте, где хранятся персональные данные, какие системы являются критичными, кто и с каким уровнем доступа работает с чувствительной информацией. Без этой карты локализация инцидента занимает в разы больше времени.
• Настройте централизованное логирование и мониторинг. SIEM без настроенных правил корреляции — дорогой архив. Убедитесь, что логи с ключевых систем собираются, хранятся достаточный срок и доступны для анализа в момент инцидента.
• Регулярно проверяйте резервные копии. Бэкап, который никто не восстанавливал в тестовом режиме — ненадёжный инструмент. Проверяйте восстановление не реже раза в квартал.
• Проведите учения. Разыграйте сценарий атаки с командой. Это единственный способ выявить пробелы в плане до того, как они проявятся в реальной ситуации.

Шаг 2. Обнаружение и идентификация

Признаки компрометации (Indicators of Compromise, IoC) — артефакты, указывающие на то, что система была скомпрометирована. Это могут быть сетевые аномалии, подозрительные процессы, изменения в файловой системе или нетипичная активность учётных записей.

Сетевые аномалии

• Исходящий трафик на нетипичные адреса или в нетипичное время — особенно ночью и в выходные
• Резкий рост объёма передаваемых данных без видимой причины (возможная эксфильтрация)
• Соединения с известными вредоносными IP или доменами
• DNS-запросы к случайно выглядящим доменам — признак DGA-активности (генерация доменов вредоносным ПО)
• Нетипичные протоколы или порты: например, RDP наружу, SMB во внешнюю сеть

Подозрительные процессы и активность на хостах

• Неизвестные процессы с высоким потреблением CPU или памяти, особенно запущенные от имени системных учётных записей
• Процессы, запущенные из нетипичных директорий: %TEMP%, %AppData%, корень диска
• Отключение или остановка антивирусных агентов, EDR, служб логирования
• Появление новых задач в планировщике или служб с неизвестными именами

Изменения в файловой системе

• Появление новых исполняемых файлов в системных директориях или директориях пользователей
• Массовое переименование или изменение расширений файлов — прямой признак работы шифровальщика
• Изменение системных файлов с неожиданными временными метками
• Появление файлов с именами типа README_DECRYPT.txt, HOW_TO_RESTORE.html — записки с требованием выкупа
• Удаление теневых копий (vssadmin delete shadows) — стандартный шаг шифровальщика

Аномалии в учётных записях

• Входы в систему в нерабочее время, особенно с привилегированных учётных записей
• Аутентификация с нетипичных географических локаций или IP-адресов
• Множественные неудачные попытки входа с последующим успешным — признак брутфорса или подбора по утечке
• Создание новых учётных записей, особенно с административными правами
• Горизонтальное перемещение: один аккаунт последовательно аутентифицируется на множестве хостов за короткое время
• Использование учётных записей уволенных сотрудников

Признаки в журналах событий

• Очистка журналов безопасности Windows (Event ID 1102) или системных логов — злоумышленники заметают следы
• Массовый экспорт данных из корпоративных систем: почта, файловые хранилища, базы данных
• Обращения к файлам с паролями, конфигурационным файлам, ключам SSH — целенаправленный сбор учётных данных

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

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

• Проверьте сервис-провайдеров и подрядчиков. Если внешние поставщики имеют доступ к вашей инфраструктуре или данным, немедленно оцените объём их прав и при необходимости ограничьте или отзовите доступ. Убедитесь, что они также не скомпрометированы — цепочка поставок остаётся одним из наиболее уязвимых векторов.
• Опросите тех, кто обнаружил инцидент. Зафиксируйте показания: что именно заметили, когда, на каком оборудовании. Эти данные критичны для восстановления хронологии атаки. Если в компании есть служба поддержки — предупредите её о необходимости фиксировать и передавать любые аномальные обращения пользователей.

Шаг 3. Сдерживание

Цель этого шага — остановить распространение угрозы и минимизировать ущерб, не уничтожив улики. Сдерживание всегда предшествует устранению: пока периметр не стабилизирован, любые попытки «вылечить» систему бессмысленны.

Краткосрочное сдерживание — немедленные действия

• Изолируйте поражённые хосты на уровне сети: отключите сетевой кабель или заблокируйте порты на коммутаторе
• Заблокируйте скомпрометированные учётные записи. Если установить конкретные аккаунты невозможно — временно заблокируйте все привилегированные учётные записи и переиздайте их с новыми паролями
• Отзовите активные сессии и токены доступа на поражённых системах
• Заблокируйте на межсетевом экране IP-адреса и домены, замеченные в атаке
• Отключите или ограничьте внешние подключения: RDP, открытые порты — всё, что может служить каналом управления для злоумышленника

Среднесрочное сдерживание — стабилизация периметра

• Проверьте сегментацию сети: убедитесь, что изоляция поражённого сегмента реально работает и атака не распространилась на смежные зоны
• Переведите критичные системы в режим усиленного мониторинга — даже те, которые выглядят незатронутыми
• Разверните чистые резервные образы на изолированных машинах, если необходимо поддерживать непрерывность бизнес-процессов. Это временная мера — не восстановление
• Ограничьте доступ сервис-провайдеров и подрядчиков до выяснения обстоятельств инцидента

Что фиксировать на этом шаге

Каждое действие по сдерживанию документируйте: что именно изолировано, когда, кем и на каком основании. Эти записи понадобятся при взаимодействии с регуляторами и при восстановлении хронологии инцидента.

Шаг 4. Сбор доказательств (форензика)

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

Что собирать и в каком порядке

Приоритет — данные, которые исчезнут первыми:

• Дамп оперативной памяти — в первую очередь. Содержит активные процессы, сетевые соединения, расшифрованные ключи, фрагменты вредоносного кода.
• Сетевые логи — активные соединения, таблицы маршрутизации. Необходимо снимать до изоляции хоста от сети, так как после отключения активные сессии будут разорваны
• Образ диска — побитовая копия (работайте только с копией)
• Журналы событий — Windows Event Log (Security, System, Application), syslog, auth.log. Экспортируйте целиком, не фильтруйте на месте
• Логи SIEM и EDR — выгрузите за период, охватывающий предполагаемое время проникновения с запасом минимум в две недели

Цепочка хранения доказательств

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

Храните артефакты на изолированном носителе, не подключённом к корпоративной сети. Доступ — только у участников расследования.

Что проверить дополнительно

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

Шаг 5. Устранение угрозы

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

• Принудительный сброс паролей охватывает все привилегированные учётные записи, сервисные аккаунты и учётки пользователей, работавших на поражённых хостах. Скомпрометированные учётные данные остаются вектором повторного проникновения до полного сброса.
• Проверьте сегментацию сети. Убедитесь, что изначально выстроенная сегментация сработала и сдержала распространение атаки. Если нет, зафиксируйте, где именно периметр был нарушен, и устраните эти точки до восстановления систем. Это не задача «на потом»: незакрытая брешь в сегментации — готовый маршрут для следующей атаки.
• Удалите скомпрометированные данные из открытого доступа. Если в результате инцидента конфиденциальная информация оказалась опубликована немедленно инициируйте её удаление. Поисковые системы кэшируют страницы: направьте запросы на удаление кэша параллельно с удалением источника.

Закройте уязвимость, через которую произошло проникновение: патч, отключение сервиса, изменение конфигурации. Без этого восстановление бессмысленно.

Шаг 6. Восстановление систем

Восстановление — это контролируемый процесс возврата систем в производственную среду с постоянным мониторингом на предмет повторной активности атакующего.

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

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

Безопасное развёртывание из бэкапов

Перед восстановлением ответьте на три вопроса:

1. Бэкап чистый? Определите временную точку компрометации (когда атакующий впервые появился в сети) и убедитесь, что резервная копия создана до этого момента. Восстановление из заражённого бэкапа — распространённая ошибка, приводящая к повторному инциденту.
2. Уязвимость закрыта? Восстанавливать систему через тот же вектор атаки бессмысленно.
3. Среда восстановления изолирована? Поднимайте системы в изолированном сегменте, проверяйте их чистоту и только потом возвращайте в продуктивную среду.

Приоритетный порядок восстановления

1. Инфраструктурные сервисы (AD, DNS, DHCP)
2. Системы резервного копирования и мониторинга
3. Критичные бизнес-приложения (ERP, CRM, финансовые системы)
4. Рабочие места пользователей
5. Некритичные сервисы

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

• Разворачивайте системы из эталонных образов с заранее настроенными политиками безопасности, а не из снапшотов, которые могут быть заражены
• Принудительно смените все пароли пользователей и сервисных учётных записей после восстановления Active Directory
• Включите расширенное логирование на всех восстановленных системах
• Проверьте целостность восстановленных файлов по хэш-суммам

Мониторинг после восстановления

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

Что мониторить после восстановления:

• Все входы в систему, особенно в нерабочее время
• Сетевые соединения с внешними адресами
• Изменения в файловой системе в критичных директориях
• Попытки обращения к ранее выявленным C2-адресам (даже заблокированным — это сигнал о повторной активности)
• Активность сервисных учётных записей

Рекомендуемый период усиленного мониторинга — не менее 30 дней после восстановления. Атакующие нередко выжидают, пока компания расслабится, и возвращаются через скрытые точки повторного входа, которые не были обнаружены при устранении.

Шаг 7. Извлечённые уроки

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

Разбор инцидента

Разбор инцидента (Post-Incident Review, PIR) — обязательная встреча команды, которая работала над инцидентом. Следует провести встречу в течение 24-72 часов (но не позднее 7 дней) после закрытия инцидента, пока детали свежи в памяти.

Структура разбора инцидента

1. Хронология. Восстановите полную цепочку событий: проникновение → закрепление → горизонтальное перемещение → финальный ущерб. Покажет, где были слепые пятна в мониторинге.
2. Анализ атаки. Где атакующий мог быть остановлен, но не был? Какие средства защиты сработали, какие нет?
3. Оценка реагирования. Насколько быстро обнаружили инцидент и провели изоляцию? Какие решения оказались верными, какие нет? Где регламент не работал или отсутствовал?
4. Финансовый ущерб. Зафиксируйте прямые и косвенные потери — это основа для обоснования бюджета на ИБ.

Корректировка политик безопасности

По итогам разбора инцидента сформируйте конкретный список изменений с ответственными и дедлайнами. Без этого разбор остаётся разговором.

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

• Управление доступом: ревизия привилегированных учётных записей, внедрение принципа минимальных привилегий, ограничение доступа подрядчиков по времени и периметру.
• Мониторинг: расширение покрытия SIEM, добавление источников логов, которые оказались «слепыми зонами».
• Бэкапы: проверка соответствия правилу 3-2-1, тестирование восстановления.
• Обучение персонала: фишинг остаётся основным вектором кибератак.
• Парольная политика: часто в пострадавших компаниях сотрудники использовали одинаковые пароли для разных сервисов.

Обновлённые политики эффективнее документировать, согласовывать с руководством и разъяснять сотрудникам лично — письмо в почте не работает.

Матрица этапов реагирования

Уведомление регуляторов: требования 2025–2026 годов

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

Роскомнадзор (утечка персональных данных)

С 30 мая 2025 года действуют новые штрафы за утечку персональных данных и непредставление уведомления в РКН. Порядок уведомления:

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

Уведомление подаётся в электронном виде через портал персональных данных Роскомнадзора. Отсутствие уведомления в срок — самостоятельный состав правонарушения, независимо от факта утечки.

ГосСОПКА / НКЦКИ (субъекты КИИ)

Для субъектов критической информационной инфраструктуры обязательна передача информации об инцидентах в ГосСОПКА через НКЦКИ:

С 30 января 2026 года вступил в силу Приказ ФСБ России № 546, утверждающий новый порядок обмена информацией о кибератаках для субъектов КИИ. Документ уточняет форматы и каналы передачи данных в НКЦКИ.

ФСТЭК

Субъекты КИИ дополнительно взаимодействуют с ФСТЭК в части категорирования объектов и выполнения требований по защите. При инциденте на значимом объекте КИИ уведомление обязательно.

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

Кризисные коммуникации: что говорить клиентам и сотрудникам

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

Принципы кризисных коммуникаций

• Говорите первыми. Сообщение от компании должно выйти раньше, чем информация появится из других источников. Пустота заполняется слухами.
• Сообщайте факты, а не предположения. «Мы обнаружили несанкционированный доступ к системам и расследуем инцидент» — лучше, чем молчание или непроверенные детали.
• Давайте конкретные инструкции. Клиентам, чьи данные могли быть затронуты: смените пароль, включите двухфакторную аутентификацию, отслеживайте подозрительную активность.
• Обновляйте статус. Одно сообщение — недостаточно. Регулярные обновления снижают тревожность и демонстрируют контроль над ситуацией.
• Разделяйте аудитории. Сотрудники, клиенты, партнёры и регуляторы получают разные сообщения — по содержанию и каналу доставки.

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

Как предотвратить повторный взлом

Скомпрометированные учётные данные — главный вектор атак. По данным исследования Positive Technologies за 2026 год, кража учётных данных составила 19% от всех инцидентов 2025 года, а доля атак с утечкой конфиденциальной информации достигла 64%. Слабая парольная политика открывает дверь для следующей атаки — даже после полного восстановления инфраструктуры.

Управление паролями и доступом

• Уникальные сложные пароли для каждой системы — без исключений
• Принудительная смена паролей после любого инцидента
• Немедленный отзыв доступа при увольнении или компрометации аккаунта
• Разграничение привилегий по принципу минимально необходимых прав

Защита от фишинга

• Многофакторная аутентификация на всех привилегированных учётных записях
• Обучение сотрудников распознаванию фишинговых писем — с регулярными симуляциями
• Фильтрация входящей почты и блокировка подозрительных вложений

Мониторинг и обнаружение

• SIEM с настроенными правилами корреляции для раннего обнаружения аномалий
• EDR на всех конечных точках
• Регулярный аудит учётных записей и прав доступа

Резервное копирование

• Правило 3-2-1: три копии, два разных носителя, одна — офлайн
• Регулярная проверка восстановления из бэкапов — не реже раза в квартал

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

Как Пассворк помогает при реагировании на инциденты

Управление учётными данными — задача, которая влияет на каждый этап реагирования: от сдерживания до восстановления.

До инцидента

Пассворк разворачивается на серверах компании и интегрируется с Active Directory и LDAP. Все учётные данные хранятся в зашифрованном хранилище внутри вашей инфраструктуры. Доступ к паролям разграничен по ролям: каждый сотрудник и подрядчик видит только то, что нужно для его задач.

Это исключает два распространённых сценария компрометации: общие логины на несколько человек и избыточные права, которые никто не пересматривал годами.

Во время инцидента

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

После инцидента

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

Заключение

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

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

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

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

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

Часто задаваемые вопросы

Что делать в первые минуты после обнаружения кибератаки?

Изолируйте поражённые системы от сети, не выключая питание. Зафиксируйте время и симптомы инцидента. Смените пароли привилегированных учётных записей с незатронутого устройства. Уведомьте ответственную команду по резервному каналу связи. Не трогайте подозрительные файлы до начала форензики.

Как понять, что атака завершена и можно восстанавливаться?

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

Нужно ли уведомлять регуляторов при кибератаке?

Зависит от типа инцидента и статуса организации. Субъекты КИИ обязаны уведомить ФСБ (через НКЦКИ) в течение 24 часов по 187-ФЗ. При утечке персональных данных — уведомить Роскомнадзор в течение 24 часов с момента обнаружения (152-ФЗ, статья 21). Рекомендуется заранее подготовить шаблоны уведомлений и согласовать их с юристом.

Что такое ГосСОПКА и кто обязан туда сообщать?

ГосСОПКА — Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак. Уведомлять НКЦКИ обязаны субъекты критической информационной инфраструктуры: организации из сфер энергетики, финансов, здравоохранения, транспорта и ряда других.

Как восстановить системы после атаки шифровальщика?

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

Нужно ли сообщать клиентам о взломе?

Да — особенно если затронуты их персональные данные. Это требование закона и вопрос репутации: по данным Сбербанка, каждая четвёртая атакованная компания понесла существенные репутационные потери (ВЭФ-2025). Сообщение от компании должно выйти раньше, чем информация появится из других источников.

Как защититься от атак через подрядчиков?

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

Хэширование паролей: соль, перец и выбор алгоритма

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

Блог ПассворкаАнастасия Лебедева

Приказ ФСТЭК № 117: разбор изменений, Кзи и штрафов

С 1 марта 2026 года Приказ ФСТЭК № 17 утратил силу. Его заменил Приказ № 117 с числовыми метриками КЗИ и ПЗИ, жёсткими сроками устранения уязвимостей и расширенной зоной ответственности. В статье рассмотрим, что изменилось и как подготовиться.

Блог ПассворкаИлья Шелыгин

Киберугрозы марта 2026: инциденты, штрафы и защита данных

Первые оборотные штрафы за утечки. Zero-click уязвимость в Telegram. Каскадная атака через Trivy. Шифровальщик в европейском порту. Новые требования ФСТЭК и КИИ. В статье — разбор ключевых инцидентов, изменений в законодательстве и конкретных шагов по защите корпоративных доступов.

Блог ПассворкаАнастасия Лебедева