Как добиться выполнения требований ИБ ИТ-командой
«ИБ не заставляет инженеров приказами». Устойчивое выполнение строится на мандате руководства, владельцах риска, понятной очереди, выполнимых изменениях и проверяемом результате. Ниже — практическая модель, которая снижает конфликт между безопасностью и эксплуатацией. Мандат и ответственность Руководство утверждает владельцев сервисов и рисков, правила приоритизации, целевые сроки, порядок исключений и лестницу эскалации. ИБ формулирует риск и проверяет результат; ИТ выбирает техническую реализацию и отвечает за внедрение. Для каждой находки назначьте одного 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