Сигнализация не делает автомобиль безопасным. Автомобиль оснастили дорогой сигнализацией: она распознает взлом, передает координаты и блокирует запуск. Но у машины слабая силовая структура кузова, ненадежные тормоза и почти отсутствует диагностика.

Такой автомобиль трудно угнать, но его нельзя назвать безопасным. Сигнализация не компенсирует ошибки конструкции и эксплуатации. С цифровыми продуктами происходит то же самое. Компания устанавливает средства защиты, проводит проверку на проникновение перед выпуском — и делает вывод, что продукт защищен. Но это еще не означает, что система сохранит критические функции при атаке и ограничит ущерб.

Безопасность — свойство продукта, а не последнее дополнение Защита от проникновения и безопасность продукта — не равные понятия. Первая снижает вероятность отдельных действий злоумышленника. Вторая отвечает на более сложный вопрос: что произойдет, если защита будет преодолена или уязвимый компонент попадет в выпуск?

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

Рекомендации Национального института стандартов и технологий США по безопасной разработке связывают снижение уязвимостей с практиками всего жизненного цикла. А проектирование киберустойчивых систем — со способностью предвидеть неблагоприятные условия, выдерживать их, восстанавливаться и адаптироваться. Защитить вход недостаточно: нужно спроектировать поведение системы до, во время и после атаки.

Директор по ИБ проектирует не каждый компонент, а систему решений Директор по ИБ не должен проверять каждую строку кода или владеть всеми продуктовыми рисками. Его задача — организовать систему, в которой вопросы задаются вовремя, решения принимают уполномоченные владельцы, а исключения не становятся нормой.

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

Ключевой вопрос — не «какое средство еще купить?», а «какие решения компания должна принимать повторяемо, чтобы выпускать продукт с приемлемым риском?». Ответом может стать изменение архитектуры, испытаний, порядка обновления или ответственности за риск.

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

На каком этапе безопасность реально входит в ваш продукт: при выборе архитектуры, в процессе разработки или перед финальным согласованием выпуска?