Регламент реагирования на инциденты информационной безопасности
Внутренний порядок, который определяет, что происходит в организации с момента, когда кто-то заметил подозрительное. Кто фиксирует, кто оценивает, кто принимает решение об уведомлении регулятора и за какое время.
Зачем нужен документ
Инцидент отличается от любой другой ситуации в защите данных тем, что решения принимаются в дефиците времени и информации. Через час после обнаружения непонятно ни что произошло, ни насколько это серьёзно, а закон уже отсчитывает двадцать четыре часа до уведомления регулятора. Регламент существует, чтобы в этот час никто не выяснял, кому звонить и кто вправе принять решение.
Документ описывает процесс, а не сценарий: как инцидент попадает в поле зрения, как классифицируется, кто его ведёт, при каких признаках он эскалируется до руководства и кто в итоге нажимает кнопку отправки уведомления в Роскомнадзор. Один и тот же процесс обслуживает и потерянный ноутбук, и открытый наружу бэкап, и выгрузку базы уволенным работником.
Отдельная задача регламента — обеспечить, чтобы к моменту разбора было с чем работать. Установить причину за двое суток можно только там, где события фиксируются и хранятся: логи входов, действия администраторов, выгрузки данных. Организация без журналирования физически не способна выполнить требование о результатах расследования — и обнаруживает это в худший момент.
Чем грозит отсутствие
Прямого штрафа за отсутствие регламента нет. Но реагирование — это часть мер защиты по ст. 19 152-ФЗ, а его отсутствие проявляется через просрочку уведомления, у которой собственный состав.
Как ещё называют этот документ
Что должно быть в документе
Жёсткой формы нет. Проверка содержательности одна: по регламенту незнакомый человек в три часа ночи должен понять, что делать первым.
Требования законодательства
Как связан с другими документами
Регламент — центр инцидентного кластера: он задаёт процесс, остальные документы дают ему форму и следы.
Когда обновлять документ
Регламент живёт не датами, а событиями: любое изменение в людях, системах или сроках делает часть его текста неверной.
Что спросит проверяющий
Регламент проверяют не чтением, а вопросами к людям: работает процедура или существует только на бумаге, видно за три вопроса.
Разбор эксперта
Регламент реагирования — тот документ, который чаще всего пишут «чтобы был», и заметно это по одному признаку: в тексте нет ни одного имени и ни одного числа. Роли обозначены как «ответственное подразделение», сроки — как «незамедлительно». В аварийной ситуации такой текст бесполезен: незамедлительно означает «кто-нибудь когда-нибудь», а ответственное подразделение в полночь недоступно.
Мы советуем строить регламент от внешних сроков назад. Есть двадцать четыре часа на первое уведомление — значит решение об уведомлении принимается не позже двенадцатого часа, значит первичная оценка масштаба должна быть готова к четвёртому, значит фиксировать обнаружение нужно сразу и без обсуждений. То же с расследованием: внешний срок семьдесят два часа от выявления, внутренний дедлайн отчёта — сорок восемь. Так получаются числа, которые действительно работают.
И главное, о чём предупреждаем всегда: реагирование упирается не в документы, а в наличие следов. Организации, у которых логи хранятся сутки или не собираются вовсе, не смогут установить причину ни за двое суток, ни за месяц. Поэтому первый вопрос при подготовке регламента не «как опишем процедуру», а «что мы вообще сможем узнать, когда это случится». Ответ на него обычно и запускает нормальную настройку журналирования.
Впишите в регламент конкретные должности, телефоны и заместителей, а не «ответственных лиц» — и проверьте, что список актуален, минимум раз в год. Поставьте внутренние сроки с запасом к 24 и 72 часам, отдельно опишите фиксацию момента обнаружения и порядок сохранения следов до перезаливки систем. И один раз проведите учебный прогон в неудобное время: он покажет о готовности больше, чем весь текст регламента.
Частые вопросы
Отдельной нормы «иметь регламент реагирования» в 152-ФЗ нет, но выявление инцидентов и реагирование на них входят в состав мер защиты по приказу ФСТЭК № 21, а сроки уведомления регулятора установлены жёстко. Без описанной процедуры уложиться в 24 часа организация обычно не может.
Инцидент ИБ — любое нарушение безопасности: вирус, подбор пароля, потерянный ноутбук. Утечка в смысле закона — неправомерная или случайная передача данных, повлёкшая нарушение прав субъектов. Уведомление Роскомнадзора требуется только во втором случае, и регламент должен помогать различать эти ситуации.
Считать от внешних назад: фиксация обнаружения — сразу, первичная оценка — в первые часы, решение об уведомлении — примерно к половине суточного срока, отчёт о расследовании — к сорока восьми часам. Запас нужен на согласование и подачу.
Ответственный за обеспечение безопасности ПДн в ИСПДн, а решение об уведомлении регулятора принимает руководитель либо специально уполномоченное лицо. Важно, чтобы у каждой роли был заместитель: инциденты случаются в отпусках и по ночам.
Если инцидент связан с компьютерной атакой, добавляется взаимодействие с государственной системой обнаружения и ликвидации последствий атак. У отдельных отраслей — банков, субъектов критической инфраструктуры — свои каналы и более короткие сроки. Всё это перечисляется в регламенте заранее.
Достаточно долго, чтобы расследование было возможно: практический ориентир — от нескольких месяцев. Срок хранения меньше пары недель означает, что причину утечки установить не удастся, а второе уведомление окажется пустым.
Можно, но неудобно: регламент описывает постоянный процесс и роли, а план — пошаговый сценарий с таймлайном. В комплекте это отдельные позиции, и на практике план чаще прикладывают к регламенту приложением.