Иными словами, пока каналы поступления доходов (ручейки бюджета) не изменятся, расчитывать на трансформации бизнес-моделей наивно. Потому что текущие бизнес-модели крупных компаний оптимально подстроены под текущий рынок (так как у нас всё сложилось).

Слышал еще такую точку зрения, что у нас по законам и регуляторам ИБ будут дрючить за то, что они не провели каких-либо обязательных защитных мер, а не за факт или масштаб утечки. Отсюда часто такой подход к делу.

Именно так. Так вот, если погрузить ИБ в команды/продукты, то они будут думать, как соблюсти законы без сильного ущерба для решения. В идеале даже больше - как при этом реально защитить решение.

Но чаще, обычно, идут по пути наименьшего сопротивления - прикрывают свои тылы. И будут так делать, если нет мотивации (часто сверху) работать как-то иначе.

Бюрократия, в чистом виде. Да, бюрократия мешает поставлять ценность.

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

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

Для контроля лучше всего вообще заказать аудит и пен. тесты.

А сейчас так: вы (разработчики) спроектируйте ИБ, разработайте стопку документов, а мы (ИБ) эти документы проверим. В основном, не всегда. Где здесь ИБ? Это факен бюрократия

Привет.
У кого нибудь есть опыт (или ссылка на  опыт, например на статью), по реализации фичей-экспериментов?
Например, когда пилим обычные фичи, надо выдерживать SLA,  писать тесты и так далее, т.е. соблюдать определенный уровень качества.
А если делаем фичи-эксперименты, то уровень качества другой (главное что бы не падало).
И вот интересно, как это организовать на уровне кода и инфраструктуры.

Особенно интересен кейс, когда фича-эксперимент использует уже существующую бд (в обратном случае все достаточно просто).

Ну так-то я вообще не понимаю идеи, когда предметку проектирует не спец в предмете.

Т.е. проектирование иб без участия ИБшника - это бред какой-то по-моему.

Выглядит нелогично, да. Но это так.

Есть другой подход. ИБшники активно участвуют в защите инфры (проектировании и защите контуров), но софт как бы сам по себе.

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

смотря что понимать под проектированием ИБ и участием ИБшника. Если на вход приходит набор НФТ security at rest,  security in transit, МФА и т.д., то что дальше будет делать ИБшник внутри проекта? Как имплементировать эти требования на конкретной платформе он не знает. Об этом должны думать архитекторы конкретного решения. Другое дело, что, если при реализации обнаруживается неприменимость каких-то требований к конкретному решению, то начинается диалог и поиск каких-то других вариантов - тут участвуют и команда проекта и ИБ.

Вместе с архитекторами работать, в диалоге.

Я не эксперт в ИБ. И всё же, в моём понимании, чтобы защитить решение, нужно хорошо понимать процессы и модели данных. Это понимание позволяет правильно сформулировать модель угроз. Да и в целом, много вопросов возникает в процессе, вплоть до анализа кода на уязвимости.

Плюс фобии конкретных бизнес людей (стейкхолдеров) с которыми нужно работать.

Все требования ИБ обычно делятся на категории (причем распределение разное для каждого решения):
1. Реализуются внутри прикладного и платформенного кода решения
2. Реализуются настройками системного ПО/оборрудования в составе поставки решения (которое и так требуется для работы прикладного кода)
3. Реализуются дополнительным к решению  ПО, которое ни зачем, кроме ИБ, не нужно
4. Реализуются существующим ПО и оборудованием компании за рамками решения
5. Реализуются организационными процедурами.
...
В идеале архитектор ИБ делает само распределение требований, архитектор решения проектирует первый пункт, пункты 2-5 в разных комбинациях архитекторами ИБ, решения, инфраструктуры.

В моём понимании, близко к идеалу, и в то же время, в одном вопросе наши точки зрения расходятся.

Первый пункт проектируют архитекторы ПО (не Архитектор решения).

Архитектор решения "организует" архитектурную работу (этой команды) и разрешает противоречия.

Архитектор решения - это Архитектор решения "целиком". Архитектор ИБ - участник Арх команды, лидер которой - Архитектор решения

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

я всё же не понимаю, зачем ты вместо одного солюшен-архитектора продвигаешь целую прорву специализированных архитекторов?

Потому что эти люди компетентнее меня (Архитектора решений в прошлом) в рамках своих специализаций. Я хочу чтобы они совместно проектировали сбалансированное решение.

При этом, концепты, решения, верхнеуровневые коммуникации, разрешение противоречий, защита архитектуры, постановка командной Арх работы, Арх надзор - ответственность Архитектора решений.

Спасибо! Мне очень отозвалась ваша формулировка.