Комментарии 2
По ходу чтения статьи возникло два вопроса.
На первый из них автор успел ответит ещё в статье в лайфхаке номер 3 - за это спасибо. Кмк, использование "прокси" ИБ архитекторов будет весьма и весьма оправдано. Особенно, если у продуктов уже есть ИТ архитекторы - как будто в их стек компетенций некоторый уровень ИБ архитекторы ложится очень удачно. Когда разработка выходит на плато и нет такого, что каждую неделю к продукту приделывают новый костыль, задачи становятся типовыми. А к типовым задачам можно применять типовые решения. Тогда и ИБ архитектора можно привлекать реже, ведь такие вопросы закроет и его "прокси".
Второй вопрос остался актуальным. В статье говорится о том, что надо очерчивать зоны ответственности и стараться вписать активности безопасной разработки в существующий продуктовый флоу. На практике часто возникает дилемма, мол, безопасники - они просто рекомендуют или согласовывают/запрещают? Вот видит ИБ архитектор критичный риск, а его фикс может быть сложным/дорогим и владелец продукта не готов заносить его в бэклог. Как быть? Ладно, с критами ещё может быть попроще, но как быть с менее судьбоносными задачами?
Опять же, на практике у вас могут быть процессы, роли и общее согласие по применению концепции безопасной разработке. Но в моменте бизнес часто использует аргумент "мы зарабатываем бабки, значит мы правы". Что в таком случае делать ИБ архитектору? Имеет ли он право вето? Исходя из опыта автора.
Тут многое зависит от того, какая в компании/продуктах культура релизов – если она всегда требует аппрува со стороны ИБ, то тут, очевидно, рычаг есть и безопасность будет согласующей/запрещающей. Если же различных ПСИ, приёмок и официальных согласований перед выкаткой в продакшен нет, то безопасность будет рекомендательной.
Но, в любом случае, если климат в компании между IT и ИБ здоровый, то даже вне зависимости от двух форматов, описанных выше, всё всегда будет решаться определенным компромисом с обеих сторон. Если ИБ нашло что-то критичное (а еще и смогло посчитать импакт в деньгах), то это будет требовать фиксов до выхода фичи/обновления в продакшен – и в этом будут заинтересованы все, включая бизнес. Если же была обнаружена уязвимость или слабость в безопасности, которую можно временно прикрыть какими-то наложенными средствами защитами и мониторингом, чтобы не нарушать релизные циклы, то так и нужно сделать, так как иначе это правда может помешать бизнесу зарабатывать деньги и доносить пользу до пользователей.
Но во всех случаях будет требоваться какая-то экспертная оценка, взвешивание рисков и подсчет импакта. И да, порой нужно будет прибегать к той самой процедуре принятия рисков.
Надеюсь, что ответил на вопрос.
Безопасность «на берегу»: опыт внедрения подхода Secure by Design в ИТ-компании