Цель модуля
Научить работника участвовать в разборе инцидента, отличать корневую причину от её следствий и доводить защитные меры до проверенного результата.
Цель разбора
Разбор нужен не для поиска виновного, а для устранения причины. Если разбор превращается в поиск крайнего, работники начинают скрывать ошибки, и компания теряет сведения об уязвимостях. Поэтому разбор ведётся по фактам и без обвинений.
Этапы разбора
- Сбор фактов: журналы, снимки состояния, показания участников, время каждого события.
- Восстановление последовательности: что произошло, в каком порядке, что этому способствовало.
- Определение корневой причины: не «сотрудник ошибся», а почему ошибка стала возможной.
- Формулирование мер: что изменить в процессе, доступах, коде или обучении.
- Назначение ответственных и сроков по каждой мере.
- Проверка: убедиться, что мера действительно предотвращает повторение.
Корневая причина против следствия
| Пример следствия | Вероятная корневая причина | Мера |
|---|---|---|
| Работник отправил выгрузку не тому получателю | Нет контроля адресата и учёта выдачи выгрузок | Проверка адресата перед отправкой, реестр выгрузок |
| Пароль попал в историю хранилища кода | Нет защитного списка и проверки при загрузке | Запрет загрузки файлов с секретами в настройках хранилища |
| Утечка через тестовую среду | В тестовую среду передаются рабочие данные | Обязательное обезличивание при подготовке данных для тестов |
| Доступ остался после увольнения | Нет связи кадровых процедур с управлением доступами | Автоматическое закрытие доступов по кадровому событию |
Меры, которые не работают
- «Провести беседу и предупредить» без изменения процесса — причина сохраняется.
- Обучение без проверки знаний — неизвестно, дошло ли требование до людей.
- Запрет без технической поддержки — люди обходят неудобное требование.
- Мера без назначенного ответственного и срока не выполняется.
- Мера, не прошедшая проверку, считается невыполненной.
Работа над ошибками в продукте
Если инцидент связан с продуктом, выводы разбора превращаются в задачи разработки: доработка проверки входных данных, разделение прав, дополнительные журналы, автоматические проверки в конвейере сборки. Без такой задачи инцидент, скорее всего, повторится.
Проверочный список перед выходом на работу
- Разбор ведётся по фактам, без поиска виновного.
- Установлена корневая причина, а не только следствие.
- По каждой причине назначена мера с ответственным и сроком.
- Технические меры закреплены в продукте или в процессе, а не только в обучении.
- Проверено, что принятые меры действительно работают.
- Выводы разбора доступны тем, кто выполняет связанные работы.
Вопросы для самопроверки
- Чем корневая причина отличается от следствия? Следствие — то, что заметили; корневая причина — почему это стало возможным. Устранять нужно причину.
- Почему разбор не должен превращаться в поиск виновного? Тогда работники начинают скрывать ошибки, и компания теряет сведения, необходимые для устранения причин.
- Как убедиться, что мера работает? Проверить результат на практике: воспроизвести сценарий и убедиться, что он больше не приводит к инциденту.
Основание и что делать при сомнении
Модуль опирается на: Федеральный закон от 27.07.2006 № 152-ФЗ (статьи 18.1, 19, 21), приказ ФСТЭК России от 11.02.2013 № 17, ГОСТ Р 56939-2016.
Если ситуация не описана в модуле и вы не уверены в правильном действии, не принимайте решение самостоятельно: обратитесь к руководителю и в службу информационной безопасности до того, как выполнить операцию с данными или доступами.