Я всё чаще замечаю, что компании управляют уязвимостями, но почти не управляют security debt.

Найденные недостатки попадают в разные системы:

уязвимости — в vulnerability management;

архитектурные проблемы — в отчёты архитекторов;

исключения — в GRC;

технический долг — в backlog разработки;

legacy — в инфраструктурные roadmap.

Формально всё учтено. Но никто не видит совокупный эффект.

А он проявляется не только в вероятности инцидента.

Накопленный security debt начинает ограничивать бизнес: - критический компонент нельзя быстро обновить; - выпуск продукта зависит от ручных проверок; - интеграция с новой платформой требует поддержки старых протоколов; - изменение архитектуры становится слишком дорогим; - расследование невозможно провести без нескольких людей, которые «знают систему»; - исключение, согласованное на три месяца, действует третий год.

Классический пример — Equifax.

Инцидент часто сводят к незакрытой уязвимости Apache Struts. Но расследование показало более глубокую проблему: неполную инвентаризацию активов, слабую управленческую вовлечённость, неэффективный контроль обновлений и недостаточную наблюдаемость. В результате атакующие оставались внутри инфраструктуры 78 дней. (Congress.gov)

WannaCry продемонстрировал, как технологический долг превращается в риск непрерывности. В английской системе здравоохранения заражённые организации использовали необновлённые или неподдерживаемые версии Windows, а централизованного механизма проверки выполнения рекомендаций не существовало. (National Audit Office (NAO))

Моя позиция: security debt не нужно автоматически считать ошибкой.

Бизнес всегда работает с ограничениями. Иногда разумнее принять риск, чем немедленно перестраивать систему. Иногда продукт необходимо вывести на рынок. Иногда миграция действительно не окупается.

Но зрелое принятие долга требует ответов на несколько вопросов: - Что именно мы откладываем? - Какой бизнес-процесс зависит от этого решения? - Кто владеет риском? - Какие меры временно его снижают? - Как быстро растёт стоимость исправления? - Какое событие заставит нас погасить долг?

Особенно важен пятый вопрос.

Два недостатка могут иметь одинаковую трудоёмкость устранения, но разную процентную ставку риска.

Отсутствие второстепенного security header во внутреннем сервисе и неподдерживаемый компонент на внешнем периметре — это не равнозначные элементы backlog.

Поэтому security debt нужно включать не только в техническую, но и в управленческую отчётность.

Не в виде тысячи CVE.

Руководству важно видеть: - какие ограничения уже замедляют изменения; - где стоимость исправления растёт быстрее всего; - какие компенсирующие меры перестают работать; - какие элементы долга связаны с критическими процессами; - где компания фактически утратила свободу архитектурного выбора.

Security debt — это не перечень недостатков. Это стоимость решений, последствия которых были перенесены в будущее.

На мой взгляд, проблема начинается не тогда, когда компания принимает компромисс.

Она начинается, когда временное решение становится постоянным, а никто уже не помнит, кто и на каких условиях его принял.

Ведётся ли в вашей организации единый реестр security debt — или долг по-прежнему распределён между несколькими backlog и отчётами?