Работа с инцидентами и извлечение уроков
С инцидентами столкнётся любая компания. Вопрос не в том, будут ли они, — а в том, как вы на них отреагируете и что из них вынесете. Компании, которые умеют работать с инцидентами, после каждого становятся сильнее. Те, кто не умеет, повторяют одни и те же ошибки.
Эта глава — о практической стороне реагирования: что на самом деле происходит во время инцидента, как проводить ретроспективы без поиска виноватых, как документировать уроки и как устраивать учебные тревоги, чтобы не репетировать во время реального пожара.
Эта глава предполагает, что план реагирования на инциденты у вас уже есть (разработан в главе Политики и процедуры ИБ). Здесь мы говорим об исполнении и обучении, а не о создании плана.
Лидер безопасности — сотрудник, который берёт на себя вопросы информационной безопасности в команде как дополнительную зону ответственности. Далее по тексту — «лидер безопасности».
Что на самом деле происходит во время инцидента
ПРИ (план реагирования на инциденты) даёт структуру. Вот как это ощущается на практике и как управлять хаосом.
Первые 30 минут
Первые полчаса определяют всё. Большинство инцидентов либо локализуются быстро, либо превращаются в многодневный кошмар — в зависимости от того, что произошло в самом начале.
Что идёт не так:
- Никто не берёт ответственность («я думал, ты занимаешься»)
- Время уходит на выяснение, кому звонить
- Доказательства уничтожают «из лучших побуждений»
- Паническое принятие решений без прод умывания последствий
- Пробелы в коммуникации (руководство узнаёт последним — или из соцсетей)
Как должно быть:
Минуты 0–5: Обнаружение и первичная оценка
- Получено оповещение или поступило сообщение
- Быстрая оценка: реально ли это, насколько серьёзно?
- Назначение руководителя инцидента
- Решение: эскалировать или тихо разобраться
Минуты 5–15: Мобилизация
- Создать канал инцидента:
#инцидент-ГГГГ-ММ-ДД-краткое-название - Оповестить команду реагирования
- Начать журнал инцидента (время, действие, ответственный, примечания)
- Оценить: нужна ли немедленная локализация?
Минуты 15–30: Первый отклик
- При необходимости выполнить локализацию (заблокировать учётную запись, изолировать систему)
- Сохранить доказательства до внесения любых изменений
- Краткое обновление для руководства (для высокого / критического уровня)
- Распределить задачи расследования
Роль руководителя инцидента
Кто-то должен владеть инцидентом. Обычно это лидер безопасности, но может быть и любой старший технический сотрудник.
Обязанности руководителя инцидента:
| Обязанность | Что это означает |
|---|---|
| Координация | Убедиться, что каждый знает, что делать |
| Принятие решений | Принимать решения при неопределённости |
| Коммуникация | Держать заинтересованных лиц в курсе |
| Документирование | Обеспечить ведение журнала инцидента |
| Управление временем | Ставить контрольные точки, не допускать зацикливания |
| Эскалация | Знать, когда вызывать внешнюю помощь |
Что руководитель инцидента НЕ делает:
- Глубокое техническое расследование (делегируется)
- Написание кода для исправления (делегируется)
- Коммуникация с клиентами (делегируется)
- Всё сразу (вы координируете, остальные выполняют)
Работа в канале инцидента
Канал в корпоративном мессенджере (VK Teams, eXpress, Compass) — это командный пункт. Держите его сфокусированным.
Правила канала:
Правильное поведение:
- Обновления статуса с временны́ми метками
- Чёткие задания: «@Алексей проверь журналы аудита за последние 24 часа»
- Задокументированные решения: «Решение: меняем все API-ключи.
Причина: не можем точно определить масштаб.»
- Явные вопросы: «ВОПРОС: У нас есть резервные копии до 1 марта?»
Неправильное поведение:
- Домыслы без доказательств
- Разговоры не по теме
- Несколько человек делают одно и то же
- Обновления без контекста
Периодические сводки:
Каждые 30–60 минут руководитель инцидента публикует краткое резюме:
Все шаблоны — в библиотеке шаблонов.
Когда эскалировать
Не каждый инцидент требует CEO в 2 ночи. Но некоторые — да.
| Эскалировать немедленно | Можно до утра | Разрешить внутри |
|---|---|---|
| Активный атакующий в системах | Локализованная утечка, небольшой масштаб | Нарушение политики без ущерба для данных |
| Подтверждена утечка данных клиентов | Подозрительная активность расследуется | Компрометация одной учётной записи (не административной) |
| Шифровальщик или деструк тивное ПО | Уязвимость обнаружена (не эксплуатирована) | Отражённая атака без последствий |
| Публичное раскрытие неизбежно | Стороннее нарушение, затрагивающее нас | Инцидент-«почти» без реального ущерба |
| Юридические / регуляторные последствия | Вредоносное ПО на одном endpoint (локализовано) | Плановые оповещения от систем защиты |
Шаблон эскалации:
Все шаблоны — в библиотеке шаблонов.
Ретроспектива без обвинений
Ретроспектива (постмортем) — место, где происходит настоящее обучение. Проведёте её неправильно — люди будут скрывать ошибки. Правильно — выстроите культуру постоянного улучшения.
Почему «без обвинений» — это серьёзно
Когда люди боятся осуждения:
- Не сообщают о проблемах («может, никто не заметит»)
- Скрывают свою причастность («это бы л не я»)
- Замалчивают детали («просто починим и забудем»)
- Избегают ответственности («я не буду касаться этой системы»)
Когда люди чувствуют безопасность:
- Сообщают о проблемах рано («кажется, я что-то сломал»)
- Открыто делятся деталями («вот что именно произошло»)
- Предлагают улучшения («вот как это предотвратить»)
- Берут ответственность («я исправлю и задокументирую процесс»)
«Без обвинений» не означает «без ответственности». Это означает, что мы фокусируемся на системах, а не на людях. Вопрос не «кто облажался?», а «что позволило этому случиться и как это предотвратить?»
Когда проводить ретроспективу
Не каждый инцидент требует формальной ретроспективы:
| Тип инцидента | Ретроспектива? | Формат |
|---|---|---|
| Критический уровень | Да, обязательно | Полная встреча + документ |
| Высокий уровень | Да | Полная или сокращённая |
| Средний уровень | Обычно | Сокращённая или асинхронная |
| Низкий уровень | По ситуации | Краткие заметки, без встречи |
| «Почти-инцидент» с уроками | Да | Сокращённая |
Также проводите ретроспективы когда:
- Само реагирование было проблематичным (даже при незначительном инциденте)
- Есть системные уроки для извлечения
- Кто-то запрашивает ретроспективу
- Это новый тип инцидента, которого раньше не было
Структура встречи-ретроспективы
Сроки: в течение 1 недели после устранения (воспоминания стираются)
Продолжительность: 45–90 минут
Участники:
- Все, кто участвовал в реагировании
- Заинтересованные стейкхолдеры (не вся компания)
- Фасилитатор (желательно не руководитель инцидента — тот должен участвовать)
П овестка:
Все шаблоны — в библиотеке шаблонов.
Техника «Пяти почему»
Продолжайте спрашивать «почему», пока не дойдёте до корневых причин, которые реально можно исправить.
Пример:
Инцидент: база данных клиентов стала доступна через публичное хранилище
Почему хранилище было публичным?
→ Разработчик сделал его публичным во время тестирования и забыл изменить.
Почему он сделал его публичным?
→ Ему нужен был внешний доступ для демонстрации, и он не знал другого способа.
Почему он не знал другого способа?
→ У нас нет задокументированных паттернов для безопасного внешнего обмена файлами.
Почему таких паттернов нет?
→ Никто не взял ответственность за документацию облачной безопасности.
Почему никто не взял?
→ Обязанности по облачной безопасности не распределены явно.
Корневые причины:
1. Нет документации по безопасному внешнему обмену файлами
2. Ответственность за облачную безопасность не закреплена
3. Нет проверки прав доступа к хранилищу перед вводом в продакшн
Задачи:
1. Задокументировать паттерны безопасного внешнего обмена
2. Закрепить ответственность за облачную безопасность за командой DevOps
3. Добавить проверку прав доступа в чек-лист перед выпуском
Обратите внимание: мы перешли от «разработчик допустил ошибку» к системным проблемам, которые реально можно исправить.
Как фасилитировать без обвинений
Задача фасилитатора — поддерживать продуктивность и безопасность обсуждения.
Как говорить:
| Не говорите | Говорите |
|---|---|
| «Кто внёс это изменение?» | «Посмотрим, какие изменения вносились и когда.» |
| «Почему вы это не поймали?» | «Что помогло бы обнаружить это раньше?» |
| «Это была ошибка.» | «Вот где начали развиваться проблемы. Что к этому привело?» |
| «Вы должны были знать.» | «Какая информация была бы полезна в этот момент?» |
| «Чья это вина?» | «Какие системы или процессы можно улучшить?» |
Перенаправление обвинений:
Участник: «Николай не должен был так делать.»
Фасилитатор: «Сосредоточимся на системе. Если один человек мог допустить эту ошибку, другие могут тоже. Что не даст никому совершить её впредь?»
Шаблон документа ретроспективы
Все шаблоны — в библиотеке шаблонов.
Контроль выполнения задач
Задачи бесполезны, если их не выполняют.
Процесс кон троля:
- Назначайте конкретных людей — не команды, а конкретных сотрудников
- Ставьте реалистичные сроки — поспешные исправления порождают новые инциденты
- Ведите в системе задач — не только в документе ретроспективы
- Проверяйте прогресс еженедельно — лидер безопасности отслеживает открытые пункты
- Замыкайте петлю — при выполнении обновляйте документ ретроспективы
- Сообщайте о завершении — расскажите команде, что задача закрыта
Ежемесячный обзор задач:
Все шаблоны — в библиотеке шаблонов.
Создание базы знаний по безопасности
Инциденты — дорогостоящие уроки. Не тратьте их впустую — не позволяйте знаниям исчезнуть.
Что документировать
| Тип документа | Назначение | Пример |
|---|---|---|
| Ретроспективы | Детальный анализ инцидентов | Утечка данных через S3 — март 2024 |
| Рунбуки | Пошаговые процедуры реагирования | Как реагировать на шифровальщик |
| Плейбуки | Схемы принятия решений для сценариев | Когда уведомлять клиентов |
| Паттерны | Безопасные способы выполнения типовых задач | Как организовать внешний обмен файлами |
| Антипаттерны | Типичные ошибки, которых нужно избегать | Типичные ошибки конфигурации хранилища |
| Руководства по инструментам | Как использовать инструменты безопасности | Использование аудит-логов для расследования |
Структура базы знаний
база-знаний-иб/
├── README.md # Оглавление и инструкция
├── инциденты/
│ ├── 2024-03-15-утечка-хранилище.md
│ ├── 2024-02-28-фишинг-компрометация-учетки.md
│ └── шаблон.md
├── рунбуки/
│ ├── скомпрометированная-учетная-запись.md
│ ├── шифровальщик.md
│ ├── утечка-данных.md
│ └── утечка-секретов-в-коде.md
├── плейбуки/
│ ├── решение-об-уведомлении-клиентов.md
│ ├── классификация-критичности.md
│ └── критерии-эскалации.md
├── паттерны/
│ ├── безопасный-внешний-обмен-файлами.md
│ ├── управление-секретами.md
│ └── настройка-контроля-доступа.md
└── инструменты/
├── работа-с-аудит-логами-облака.md
├── анализ-журналов.md
└── быстрая-проверка-безопасности.md
Как сделать базу знаний рабочей
Лучшая база знаний бесполезна, если её нельзя найти.
Сделайте доступной для поиска:
- Единые соглашения об именовании
- Теги или категор ии
- Включайте типичные поисковые запросы в тексты документов
- Создайте индексную страницу со ссылками
Поддерживайте актуальность:
- Ежеквартальный пересмотр устаревшего контента
- Обновление после каждого инцидента
- Явная маркировка устаревших материалов
- Дата последнего обновления в каждом документе
Обеспечьте доступность:
- Храните там, где люди уже работают (корпоративная вики, GitFlic/GitVerse, self-hosted Gitea)
- Ссылайтесь из каналов инцидентов
- Включайте в онбординг
- Упоминайте на обучениях
Обучение на чужих инцидентах
Не обязательно переживать каждый инцидент самим — можно учиться на публичных случаях.
Российские и международные источники:
- Блог Positive Technologies (ptsecurity.com/research)
- Securelist от Лаборатории Касперского (securelist.ru)
- Отчёты Solar JSOC (rt-solar.ru)
- Аналитика F.A.C.C.T. (facct.ru)
- Anti-Malware.ru — но вости и разборы инцидентов
- BI.ZONE блог — технические разборы атак
Ежемесячный разбор публичного инцидента:
Выберите один значимый публичный инцидент в месяц. Разберите его как будто он произошёл с вами:
- Каков был вектор атаки?
- Могло ли это случиться у нас?
- Что мы сделали бы иначе?
- Что можем внедрить проактивно?
Учебные тревоги (табблтоп-упражнения)
Учебные тревоги — симулированные инциденты, где вы отрабатываете реагирование без давления реальной атаки. Считайте их пожарными учениями для безопасности.
Почему учебные тревоги важны
- Тестирование плана — обнаружить пробелы до того, как их обнаружит реальный инцидент
- Мышечная память — практика делает реагирование автоматическим
- Обучение команды — новые сотрудники узнают, как вы реагируете
- Выявление неясностей — кто что делает? Теперь вы будете знать
- Снижение стресса — знакомые ситуации менее пугающие
Планирование учебной тревоги
Периодичность: минимум раз в квартал, лучше раз в месяц
Продолжительность: 1–2 часа
Участники:
- Команда реагирования на инциденты
- Руководство (хотя бы иногда)
- Все, кто будет вовлечён в реальные инциденты
Роли:
| Роль | Обязанность |
|---|---|
| Фасилитатор | Ведёт упражнение, предоставляет сценарные обновления |
| Наблюдатель | Делает заметки о процессе, не участвует |
| Участники | Реагирую т на сценарий так, как в реальности |
Формат учебной тревоги
1. Подготовка (Фасилитатор)
- Написать сценарий с реалистичными деталями
- Подготовить 3–4 «инъекции» (новая информация, раскрываемая в ходе упражнения)
- Уведомить участников о временны́х затратах
- Создать выделенный канал / комнату
2. Структура упражнения
Введение (10 мин): объяснить правила («реагируйте, как в реальности»), подчеркнуть, что это практика, а не оценка, зачитать начальный сценарий.
Фаза реагирования 1 (20–30 мин): команда обсуждает первичный отклик. Фасилитатор задаёт уточняющие вопросы. Инъекция 1: новая информация меняет ситуацию.
Фаза реагирования 2 (20–30 мин): команда корректирует действия. Фасилитатор проверяет допущения. Инъекция 2: эскалация или усложнение.
Разрешение (15–20 мин): команда работает к завершению. Инъекция 3: финальный пово рот (по желанию). Закрытие сценария.
Разбор (20–30 мин): что сработало? Что было неясно? Что сделали бы иначе? Задачи для улучшения.
Пример сценария: утечка данных
Начальный сценарий:
Полный сценарий с тремя инъекциями для отработки реагирования на утечку данных.
Все шаблоны — в библиотеке шаблонов.
Инъекция 1 (через 20 мин):
Инъекция 2 (через 40 мин):
Инъекция 3 (через 60 мин):
Другие сценарии для учебных тревог
Атака шифровальщика:
- Понедельник, 8:00 — сотрудники не могут открыть файлы
- Требование: [сумма] в течение 48 часов
- Инъекции: резервные копии двухнедельной давности; атакующие угрожают опубликовать данные
Скомпрометирована учётная запись директора:
- Из почты финансового директора рассылаются зап росы на переводы
- Финансовый отдел уже обработал один платёж
- Инъекции: CFO в командировке с ограниченной связью; атакующий отвечает на попытки верификации
Внутренняя угроза:
- Увольняющийся сотрудник скачал клиентскую базу перед уходом
- Он переходит к конкуренту
- Инъекции: юридические ограничения на ваши действия; данные уже на личных устройствах
Атака через цепочку поставок:
- Ключевой поставщик объявил об инциденте
- У него был доступ к вашей производственной среде
- Инъекции: поставщик не отвечает; в журналах вы находите несанкционированные API-вызовы
Вопросы для разбора
После упражнения обсудите:
-
Процесс:
- Все ли знали свои роли?
- Была ли коммуникация чёткой?
- Следовали ли мы нашему ПРИ?
- Где застревали?
-
Решения:
- Принимались ли решения достаточно быстро?
- Была ли у нас необходимая информация?
- Кто имел полномочия для каких решений?
-
Коммуникация:
- Довольно ли руководство обновлениями?
- Учли ли мы всех заинтересованных лиц?
- Как справились с внешней коммуникацией?
-
Ресурсы:
- Были ли задействованы нужные люди?
- Каких инструментов или информации не хватало?
- Нужна ли внешняя помощь, которой у нас нет?
-
Улучшения:
- Что нужно изменить?
- Что добавить в ПРИ?
- Какое обучение требуется?
После упражнения
Сразу:
- Задокументировать выводы, пока свежи в памяти
- Поделиться сводкой с участниками
- Поблагодарить всех за время
В течение 1 недели:
- Создать задачи по выявленным пробелам
- Обновить ПРИ или рунбуки при необходимости
- Запланировать следующее упражнение
Отслеживайте динамику:
- Становится ли реагирование быстрее?
- Повторяются ли одни и те же проблемы?
- Растёт ли участие команды?
Типичные ошибки
- Ретроспектива как наказание — люди перестают сообщать, если боятся осуждения
- Невыполнение задач — уроки не усвоены, если ничего не меняется
- Усталость от ретроспектив — не каждый инцидент требует полного формата
- «Сейчас не до учений» — практика предотвращает дорогостоящие ошибки
- Документирование для галочки, а не для обучения — пишите для будущего себя, не для аудитора
- Одни и те же люди на каждой ретроспективе — ротируйте руководителей упражнений
- Нереалистичные сценарии — стройте учебные тревоги на ваших реальных рисках
- Нет базы знаний — изобретаете велосипед при каждом инциденте
- Руководство не участвует — топ-менеджмент должен время от времени присутствовать
- Совершенствование плана вместо практики — проверенный достаточно хороший план лучше непроверенного идеального
Управленческое задание: практика реагирования на инциденты
Поручите лидеру безопасности организовать регулярные учебные тревоги. Ваша роль — участвовать хотя бы раз в год и убедиться, что выводы воплощаются в изменения.
Часть 1: Создание документации (1 час для лидера безопасности)
Что поручить:
- Адаптировать шаблон ретроспективы под структуру компании
- Создать шаблон журнала инцидента
- Настроить структуру папок базы знаний
Что вам нужно сделать:
- Убедиться, что лидер безопасности имеет полномочия отслеживать и закрывать задачи из ретроспектив
Часть 2: Проведение учебной тревоги (2 часа)
Что поручить:
- Подготовить сценарий, актуальный для ваших рисков
- Пригласить ключевых участников (включая вас)
- Подготовить 2–3 инъекции
Что вам нужно сделать:
- Участвовать как «куратор от руководства»
- После упражнения поддержать выделение времени на выполнение задач
Ожидаемые артефакты
- Адаптированный шаблон ретроспективы
- Шаблон журнала инцидента
- Структура базы знаний настроена
- Первая учебная тревога проведена
- Задачи из учебной тревоги в системе отслеживания
- Расписание следующих упражнений
- Команда реагирования знает свои роли (не только теоретически)
- Учебные тревоги проводятся минимум раз в квартал
- После каждого значимого инцидента — ретроспектива в течение недели
- Задачи из ретроспектив действительно выполняются
- База знаний существует и обновляется
- Есть измеримые показатели реагирования (время обнаружения, время устранения)
- Среднее время обнаружения и устранения не растёт от квартала к кварталу
Ключевой вопрос к лидеру безопасности: «Назовите три самых важных вещи, которые мы изменили после последнего инцидента. Они внедрены?»
См. также
- Плейбуки реагирования — что делать во время инцидента
- Политики безопасности — план реагирования как документ
- Коммуникации по безопасности — как рассказать команде о выводах
Что дальше
Следующая глава — измерение эффективности программы безопасности: как от слеживать, работает ли всё это на самом деле.