Если вендор не предоставляет воркэраунд для исправления инфраструктурной уязвимости, возможно ли выработать его внутри организации? Если да, то кто должен за это отвечать? RedTeam? Infra­Sec? Совместно?

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

1. В рамках этого исследования для начала нужно получить рабочий эксплоит, чтобы можно было оценить результативность workaround‑а. Хорошо если эксплоит доступен публично и работоспособен. Или хотя бы есть подробное описание уязвимости. А если нет? В любом случае это скорее задача RedTeam. Без эксплоита рассуждения о workaround-ах становятся чисто теоретическими.

2. Когда есть рабочий инструмент для атаки, можно продумывать какой workaround можно применить. Заниматься этим вероятнее всего должны сотрудники Infra­Sec вместе с системными администраторами и владельцами уязвимых систем. Компенсирующие меры могут повлиять на функциональность систем, поэтому одни только безопасники этот вопрос решить не смогут.

3. На тестовом скоупе применяем workaround. Проверяем на хостах из этого скоупа, что эксплуатация уязвимости с помощью нашего эксплоита там больше невозможна. С помощью RedTeam подтверждаем, что легкого способа обойти это исправление нет. Принимаем решение о массовом применении workaround‑а.

Всё это сложно, трудозатратно, очень плохо масштабируется и по определению является ненадежным временным решением. Посмотрите, например, сколько раз MS меняли рекомендуемый workaround для Prox­yNot­Shell. А у них там лучшие эксперты работают и занимаются этим на фулл-тайм. Поэтому если есть возможность исправить уязвимость обновлением, лучше обновиться. Workaround‑ы и компенсирующие меры лучше брать готовые от вендора или регулятора (для многих уязвимостей они есть прямо в БДУ!) и применять их только на время, пока обновление недоступно.