Как добиться выполнения требований ИБ ИТ-командой

«ИБ не заставляет инженеров приказами». Устойчивое выполнение строится на мандате руководства, владельцах риска, понятной очереди, выполнимых изменениях и проверяемом результате. Ниже — практическая модель, которая снижает конфликт между безопасностью и эксплуатацией.

Мандат и ответственность
Руководство утверждает владельцев сервисов и рисков, правила приоритизации, целевые сроки, порядок исключений и лестницу эскалации. ИБ формулирует риск и проверяет результат; ИТ выбирает техническую реализацию и отвечает за внедрение.
Для каждой находки назначьте одного accountable-владельца. Владелец сервиса ведёт план, владелец риска принимает остаточный риск, а change/SRE организует тестирование и откат. Просроченное исключение возвращается владельцу и руководству.
Очередь вместо спора о срочности
Сроки задаёт организация с учётом критичности актива, внешней доступности, влияния на бизнес, наличия исправления и компенсирующих мер. CVSS — только один вход: добавляйте контекст, EPSS и наличие CVE в каталоге CISA KEV. Не обещайте одинаковый SLA для всех находок.
P0 — подтверждённая эксплуатация, критичный внешний сервис или обязательное требование; немедленно ограничьте воздействие и назначьте владельца. P1 — высокий риск с коротким сроком и ежедневным контролем.
Задача, которую можно выполнить
Одна карточка связывает проблему с активом, сервисом, процессом и владельцем. Укажите доказательство, сценарий атаки, затронутые версии, сетевую доступность, CVSS с контекстом, EPSS/KEV при наличии, варианты исправления и временные меры.
Зафиксируйте срок, критерий приёмки, план тестирования и отката. Используйте состояния: подтверждение → назначение → планирование → исправление → проверка → закрытие или принятие риска. Инженер выбирает реализацию: обновление, настройку, изоляцию, ограничение доступа или замену компонента.
Исключения, эскалация и измерение
Если исправление невозможно в срок, владелец риска оформляет принятие остаточного риска: причина, активы, компенсирующие меры, срок действия, дата пересмотра и критерий досрочного отзыва. ИБ вправе рекомендовать отказ и эскалировать, но не принимает риск молча за бизнес.
Руководители ИТ и ИБ заранее определяют, кто разрешает конфликт приоритета и когда изменения временно останавливаются.
Российские требования проверяйте по сфере
152-ФЗ
регулирует обработку персональных данных: статья 19 требует от оператора правовых, организационных и технических мер. 187-ФЗ
и приказ ФСТЭК № 239
применяются к субъектам и значимым объектам КИИ в пределах своей сферы.
Что почитать и попробовать
• DefectDojo
— Открытый реестр находок с дедупликацией, триажем, SLA, назначением владельцев и формальным принятием риска.
• Dependency-Track
— Инвентаризация компонентов по SBOM, оценка уязвимостей и контроль политики цепочки поставок.
• Open Policy Agent
— Проверяемые политики как код для CI/CD и инфраструктуры, с единым решением для допуска изменений.
Я в соцсетях
TG · TikTok · Сетка · MAX