Управление инцидентами ИБ через ServiceDesk: 187-ФЗ и ГосСОПКА

Чем СИБ-инцидент отличается от IT-инцидента

На первый взгляд процессы похожи — регистрация, реакция, восстановление. Но цели и приоритеты принципиально разные:

• Цель IT-инцидента — как можно быстрее восстановить услугу. Перезагрузил, починил, поехали дальше.
• Цель СИБ-инцидента — сначала локализовать и сохранить следы, и только потом восстанавливать. Поспешная «починка» (перезагрузка, переустановка) может уничтожить улики и помочь атакующему замести следы.

Отсюда первое правило: при подозрении на инцидент ИБ нельзя бросаться «чинить» по привычке IT-поддержки. Заражённую машину чаще нужно изолировать (отключить от сети, но не выключать — в памяти важные артефакты), а не перезагрузить. Поэтому СИБ-инциденты идут по отдельному процессу с участием специалистов по безопасности, даже если первой их регистрирует служба поддержки.

187-ФЗ, КИИ и кого это касается

187-ФЗ «О безопасности критической информационной инфраструктуры РФ» распространяется на субъектов КИИ — организации в сферах здравоохранения, науки, транспорта, связи, энергетики, банков и финансов, ТЭК, атомной, оборонной, ракетно-космической, горнодобывающей, металлургической и химической промышленности.

Ключевые обязанности субъекта КИИ применительно к инцидентам:

• Категорирование объектов КИИ и обеспечение их безопасности.
• Реагирование на компьютерные инциденты по установленному регламенту.
• Информирование ГосСОПКА о компьютерных инцидентах в установленные сроки.

Даже если ваша организация не субъект КИИ, требования к процессу реагирования на СИБ-инциденты полезны как best practice и часто пересекаются с защитой персональных данных по 152-ФЗ. Это смежные, но разные режимы: 187-ФЗ — про критическую инфраструктуру, 152-ФЗ — про персональные данные.

ГосСОПКА и сроки уведомления

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

Практический вывод для процесса: таймер уведомления начинается в момент обнаружения, а не в момент, когда «разобрались». Это означает, что регистрация СИБ-инцидента должна быть мгновенной и точной по времени — иначе нарушаются регуляторные сроки. Здесь ServiceDesk незаменим: он даёт точную временную метку обнаружения, аудит действий и единое место для фиксации хронологии (которая потом войдёт и в отчёт регулятору, и в постмортем).

Важно: конкретные сроки и форматы уведомления ГосСОПКА регулируются приказами ФСБ и подзаконными актами и периодически уточняются. Это не юридическая консультация — сверяйтесь с актуальной нормативной базой и регламентом вашей организации.

Роль ServiceDesk: что он делает, а что нет

ServiceDesk — не замена SIEM и не средство защиты. Его роль в процессе СИБ-инцидента — организационная:

• Единая точка регистрации с точной временной меткой и категорией «инцидент ИБ» — отдельной от обычных IT-инцидентов.
• Маршрутизация на команду ИБ по специальному процессу, минуя обычную очередь L1.
• Хронология и аудит. Кто, что и когда сделал — критично для отчёта регулятору и расследования.
• Чек-лист реагирования как модель инцидента: изолировать, уведомить ответственного по ИБ, не «чинить» до решения специалиста, зафиксировать следы.
• Контроль сроков через SLA/таймеры на этап уведомления.

Чего ServiceDesk делать не должен: автоматически «решать» СИБ-инциденты, давать L1 закрывать их по обычному регламенту, или давать рядовым операторам доступ к деталям расследования. Здесь жёстко работает разграничение прав — карточки СИБ-инцидентов видит только команда безопасности. ServiceDesk дисциплинирует процесс и обеспечивает доказуемость, но решения принимают люди и средства защиты.