Прямой ответ
Ведите весь инцидент под одним идентификатором. Сначала подтвердите сигнал, затем определите тип, серьёзность и область воздействия. Сдержите вред, сохраните доказательства и выполните необходимые уведомления. После устранения первопричины повторите испытание системы в тех же условиях. Нельзя закрывать инцидент только потому, что «мы внесли изменение». Для закрытия нужны доказательства исправления затронутых поверхностей, отсутствия новой ошибки и работы мер против повторения.
Простыми словами
Представьте протечку воды в здании. Вытереть пол недостаточно. Нужно перекрыть вентиль, найти все пострадавшие помещения, починить трубу, проверить проводку и стены, а затем убедиться, что в том же месте больше не течёт.
Почему это важно
Один неточный ответ мог распространиться в другие языки, кеши, наборы данных, решения клиентов или внешние платформы. Исправление только видимого примера не предотвращает новые инциденты из той же первопричины.
Не путать
- Ошибка — отклонение от ожидаемого поведения; не каждая ошибка является инцидентом безопасности.
- Инцидент безопасности затрагивает или угрожает конфиденциальности, целостности либо доступности.
- Нарушение приватности или персональных данных может требовать отдельной правовой и операционной оценки.
- Инцидент представления существенно показывает сущность неточно, неполно, устарело или без доказательств.
- Почти произошедший инцидент — опасное условие, обнаруженное до вреда; известное ограничение — заранее зафиксированная граница системы.
Что делать
- Откройте сигнал под одним идентификатором и запишите время первого обнаружения, источник, систему, версию и сообщившего.
- Определите тип, серьёзность, затронутых людей и поверхности, не скрывая неопределённость.
- При необходимости ограничьте вред остановкой, карантином, отзывом доступа или безопасной альтернативой.
- Сохраните записи событий, запросы, ответы, данные, модели, инструменты, версии и доказательства решения.
- Где применимо, вовремя уведомите затронутых людей, клиентов, поставщиков или компетентные органы.
- Устраните первопричину и исправьте производные записи, кеши, векторные хранилища и нижестоящие поверхности.
- Повторите исходный тест, проверьте регрессии, превратите урок в контроль и закройте инцидент с обоснованием.
Как проверить
- Есть ли у инцидента один идентификатор, владелец и полная временная линия?
- Определены ли тип, серьёзность и охват воздействия по доказательствам?
- Снизило ли сдерживание вред, не создавая лишней потери услуги?
- Сохранены ли доказательства в форме, пригодной для разбора?
- Записаны ли решение об уведомлении, получатели, сроки и причины?
- Отличена ли первопричина от видимого симптома?
- Не закрыт ли инцидент без доказательств исправления, живого повторного теста, проверки регрессий и предотвращения повторения?
Ограничение
Не каждый неверный ответ ИИ является киберинцидентом, нарушением персональных данных или серьёзным инцидентом, подлежащим уведомлению по закону. Классификация, адресат и срок требуют специальной оценки по последствиям, роли системы, договору, отрасли и применимому праву.
Запомните одной фразой
Инцидент закрыт не тогда, когда исчез симптом, а когда устранена причина и проверен результат.
Источники этой записи
- S35W3C, *PROV-O: The PROV Ontology*Стандарты
- S36W3C, *Trace Context*Стандарты
- S37OpenTelemetry, *General Trace Semantic Conventions*Стандартная и проектная документация
- S38NIST AI 600-1, *Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile*Добровольное институциональное руководство в области стандартов
- S41NCSC и агентства-партнеры, *Руководства по разработке безопасной системы ИИ*Официальное руководство по безопасности для различных ведомств
- S42NIST SP 800-61 Rev. 3, *Incident Response Recommendations and Considerations for Cybersecurity Risk Management*Добровольное институциональное руководство в области стандартов
- S44NIST, * AI Risk Management Framework Playbook* и AI RMF CoreНаправления по добровольному осуществлению

