# Security Incident Response

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

- Skill: `fbakiyev/security-incident-response` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fbakiyev/security-incident-response`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fbakiyev/security-incident-response/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: fbakiyev (https://skillmd.com/u/fbakiyev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/fbakiyev/security-incident-response

---


# Реагирование на инцидент безопасности

## Установи и сохрани доказательства

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

## Сдерживай инцидент в его границах

1. Определи наименее разрушительную эффективную границу вмешательства: идентичность, сессию, нагрузку, сетевой путь или раскрытый ресурс. Укажи ожидаемую пользу, влияние на бизнес и условие отката или восстановления.
2. Выполняй сдерживание в пределах уже имеющихся полномочий пользователя и политики реагирования. Не превращай событие, связанное с одной идентичностью, в отключение всей организации без доказательств или соответствующего решения.
3. Если затронут секрет доступа, до ротации или отзыва установи его потребителей. Замена секрета в хранилище может оставить действующими существующие сессии или ранее выданные учётные данные. Явно проверь соответствующий жизненный цикл.
4. Проверяй продолжение несанкционированной активности по путям, подтверждённым доказательствами. Отсутствие событий может означать отсутствие логирования, поэтому само по себе не доказывает ни сдерживание, ни отсутствие раскрытия данных.
5. Восстанови систему из доверенного состояния, проверь законное поведение сервиса и защитные меры, наблюдай за ранее обнаруженными индикаторами. В статусе различай сдерживание, устранение компрометации и восстановление.

## Результат

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

Не публикуй чувствительные индикаторы или данные клиентов. Уведомление и раскрытие информации определяются полномочиями пользователя и политикой реагирования. Когда нужна более полная схема реагирования, используй [рекомендации NIST](https://csrc.nist.gov/pubs/sp/800/61/r3/final). Технический статус не устанавливает юридические обязанности по уведомлению.