Главная мысль
Создавайте план как рабочий документ: он должен показывать, кто и когда принимает решения, как сохраняются доказательства и как восстанавливаются сервисы.
Назначение плана и ожидаемые результаты
План определяет, кому сообщать о подозрительном событии, как оценивать сигнал, ограничивать ущерб и восстанавливать работу. Подготовка решает семь задач: сократить ущерб и потери, укрепить защиту, поддержать работу по соответствию требованиям, ускорить восстановление, сохранить репутацию и доверие клиентов, лучше понимать угрозы и повысить готовность сотрудников. Свяжите каждую задачу с ответственным, процедурой и сценарием учений.
Более последовательные решения
Заранее согласованные роли, приоритеты и критерии эскалации упрощают принятие решений под давлением.
Восстановление сервисов
Если критические сервисы и зависимости известны, можно спланировать порядок восстановления и допустимый простой.
Доверие и информирование
Утверждённые внутренние каналы и полномочия на уведомление снижают риск ошибочных, запоздалых или противоречивых сообщений.
Обучение и готовность
Учения, записи об инцидентах и разборы выявляют сбои при передаче задач между командами и отсутствие необходимых прав доступа.
Как соотносить модели NIST и SANS
Распространённая шестиступенчатая модель SANS включает подготовку, выявление, сдерживание, устранение, восстановление и извлечённые уроки. Более ранняя NIST SP 800-61 Rev. 2 (2012) группировала работу в четыре этапа: подготовка; обнаружение и анализ; сдерживание, устранение и восстановление; деятельность после инцидента. Это полезные исторические операционные модели. NIST SP 800-61 Rev. 3 опубликована в апреле 2025 года и заменяет Rev. 2: реагирование встроено в управление рисками по NIST CSF 2.0, а не задано как отдельная линейная последовательность из четырёх фаз. В руководстве подчёркнута связь функций Detect, Respond и Recover с подготовкой Govern, Identify и Protect.
| Модель | Что даёт | Как применять |
|---|---|---|
| Шесть этапов SANS | Последовательность действий: от подготовки до разбора инцидента и улучшения процесса. | Согласуйте термины с пошаговыми инструкциями и правилами эскалации. |
| NIST SP 800-61 Rev. 2 | Четыре сгруппированные фазы; в 2025 году заменена Rev. 3. | Учитывайте ссылки в действующих документах; не выдавайте её за актуальное руководство NIST. |
| NIST SP 800-61 Rev. 3 / CSF 2.0 | Связывает реагирование с общим управлением киберрисками организации. | Планируйте управление, выявление и защиту вместе с обнаружением, реагированием и восстановлением. |
Основные элементы плана
План должен опираться на актуальный перечень активов, зависимости систем и работающие каналы связи. Назначьте заместителя для каждой роли и укажите, кому передаются полномочия, если ответственный недоступен. Определите категории и уровни серьёзности в терминах вашей команды и объясните, как технический сигнал переводится в оценку влияния на бизнес.
Активы и приоритеты
Составьте перечень серверов, сетей, приложений, учётных записей, типов данных, облачных сред, поставщиков и зависимостей критических сервисов. Укажите владельца сервиса и порядок восстановления.
Роли и полномочия
Определите руководителя реагирования и специалистов по техническому расследованию, владельцев систем, руководство, специалистов по праву и конфиденциальности, HR и коммуникации по мере необходимости. Зафиксируйте, кто утверждает изоляцию, отключение учётных записей, внешние уведомления и восстановление.
Коммуникация и эскалация
Определите внутренние каналы, запасной способ связи, цепочку вызова, периодичность обновлений и уполномоченного представителя. При подозрении на компрометацию не полагайтесь на корпоративную почту и средства совместной работы, которые могут быть ненадёжны.
Записи и доказательства
Фиксируйте хронологию, решения, согласования, источники наблюдений, действия и местонахождение доказательств. Платформа управления инцидентами, например Jira Service Management, может автоматизировать эскалацию, если организация настроила и проверила интеграцию. Связывайте журналы расследования, форензики и восстановления; порядок хранения и передачи доказательств определяйте с профильными специалистами.
Рабочая последовательность при инциденте
После классификации инцидента работа может идти параллельно: анализ, сдерживание, коммуникация, сохранение доказательств и планирование восстановления. Эта последовательность переводит знакомые этапы SANS в практические действия; применяйте её вместе с подходом управления рисками NIST Rev. 3.
Подготовка и активация
Подготовьте обученную группу, пошаговые инструкции, мониторинг, резервные копии и контактные списки. При выполнении критерия инцидента назначьте руководителя, откройте запись и согласуйте источники времени.
Обнаружьте, проверьте и оцените влияние
Проверьте оповещения, сообщения пользователей и системные записи в контексте. Определите затронутые активы, учётные записи, данные, возможное распространение и бизнес-сервисы; неизвестные обстоятельства фиксируйте отдельно.
Сдерживайте и сохраняйте доказательства
Примите утверждённые меры для ограничения распространения: отключите устройство от сети, ограничьте учётную запись, отзовите сессию или поместите файл в карантин. Учитывайте влияние на сервис, доказательства и расследование; необоснованное выключение или удаление может уничтожить данные.
Устраните угрозу и восстановите работу
Выявите и удалите вредоносное ПО, бэкдоры и механизмы закрепления, устраните использованную уязвимость и обновите учётные данные. Восстанавливайте из проверенного источника; проверьте штатную работу систем и ведите мониторинг признаков оставшейся угрозы.
Обновите план и повторите учение
Сведите хронологию, влияние, действия и открытые риски. Определите, что сработало, каких данных и доступов не хватало и задержалась ли эскалация; обновите план и меры контроля, назначив ответственных и сроки.
Влияние, коммуникация и цели восстановления
Оцените чувствительность данных, критичность сервиса, возможные финансовые и операционные последствия, зависимость от поставщиков и вероятность распространения. Для каждой важной функции целевое время восстановления (RTO) показывает допустимую длительность простоя, а целевая точка восстановления (RPO) — допустимый интервал потери данных. Это целевые показатели, а не гарантия; их нужно связать с владельцами, приоритетами, резервными копиями и проверками. Обязанности по юридическим и регуляторным уведомлениям оценивайте со специалистом с учётом фактов инцидента и применимой юрисдикции.
Внешние уведомления
Определите ответственного за связь с клиентами, партнёрами, страховщиком, регулятором и правоохранительными органами, порядок подтверждения фактов и последовательность коммуникации.
Зависимости восстановления
Зафиксируйте порядок восстановления службы идентификации, DNS, сети, каталогов резервных копий, облачных аккаунтов и критических поставщиков. Убедитесь, что источники восстановления не затронуты инцидентом.
Точно определите MTTR
MTTR может означать среднее время до ремонта или восстановления; некоторые команды используют эту аббревиатуру для времени до реагирования или устранения. В отчёте точно укажите начальное и конечное события, охват инцидентов и формулу. Например, если три сбоя дали шесть часов простоя, среднее время ремонта составляет два часа. Рассматривайте среднее вместе с серьёзностью, влиянием на сервис и RTO: оно может скрывать тяжесть отдельных инцидентов.
Выбор внешнего партнёра по реагированию
Сначала определите пробелы: нужна ли круглосуточная поддержка, форензика, сдерживание, устранение, восстановление, учения или разбор после инцидента. В договоре должны быть ясны границы услуги, контакты для эскалации, часы работы и способ измерения времени реакции, доступ к системам, хранение данных и содержание отчётов. Письменно уточните заявления поставщика о доступности и скорости реагирования.
Потребности и опыт
Проверьте опыт в ваших технологиях, отрасли и сценариях, состав команды, актуальность сертификатов и методику работы на примере. Запрашивайте рекомендации клиентов сопоставимого размера и сложности.
Охват, доступность и интеграция
Уточните часы мониторинга, географический и технический охват, дежурную связь, интеграции, глубину расследования и условия выездной поддержки. Выясните, является ли доступность обязательством SLA и какие есть исключения.
Коммуникация и отчётность
Уточните, кто руководит инцидентом, как часто даются обновления, как согласуются решения, запросите пример отчёта и проверьте наличие хронологии, охвата, методов, выводов, ограничений и рекомендаций.
Стоимость и последующая поддержка
Сравните модели ретейнера, оплаты за инцидент и подписки, дополнительные расходы, условия отмены и продления. Уточните разбор причин, план исправлений, учения и порядок возврата или удаления данных после оказания услуги.
Проверка плана и отчёт об инциденте
Пересматривайте план не реже одного раза в год и после существенных изменений в технологиях, команде или бизнесе; частоту и глубину выбирайте по риску. При обсуждении учебного сценария за столом участвуют назначенные ответственные — от руководства до системных команд; проверьте резервные каналы и полномочия. Отчёт должен описывать не только ход событий, но и влияние и ответственных за дальнейшие действия.
Что такое план и зачем он нужен?
План документирует роли, процедуры реагирования, коммуникацию и последующий разбор. Даже под давлением команда знает полномочия, путь эскалации и следующий шаг.
Как часто обновлять и проверять план?
Пересматривайте план и проводите учения не реже раза в год. После существенных изменений инфраструктуры, поставщиков, команды или бизнеса, а также после инцидента обновляйте процедуры и проверяйте изменения.
Что включить в отчёт об инциденте?
Укажите тип инцидента, затронутые системы и хронологию; способ обнаружения, анализ и использованную уязвимость; меры сдерживания, устранения и восстановления; известные последствия для данных, финансов и репутации; неопределённости; выводы и конкретные действия с ответственными и сроками. Неподтверждённые цифры не представляйте как факты.
Сколько этапов должно быть в плане?
Единого обязательного числа нет. Распространённая модель SANS включает шесть этапов; прежняя NIST SP 800-61 Rev. 2 использовала четыре группы и была заменена Rev. 3 в 2025 году. Согласуйте актуальный план с управлением рисками NIST CSF 2.0 и адаптируйте выбранные этапы к своим ролям, полномочиям и потребностям восстановления.