Есть общая методика в ИБ , называетс это Risk Management. То что ты хочеш сделать тоже можно расчитать используя приемы этой методики. Это скажем будет Risk management на этапе проэктироввания ТЗ к некой инф. системме.
Посмотри на :
Risk Management Framework NIST SP800-37
Оценки риска по методу Quantitative vs Qualitative
Разработка Threat Analysis т.е. исходя из известных угроз, например если это передача данных по открытому каналу- то максимальная угроза это перехват и анализ трафика за XX время.
Asset Classification - Архитектор конечно не совсем в курсе значимости\стоимости данных которыми его ИС будет оперировать. но он в курсе, например если это Ключ шифрования (это ассет) - то это ресурс №1 который нужно защищать. значит нужно затратить больше времени на разработку ТЗ по его защите в пямяти, хранении и передаче.
MTD метрику например можно взять как - сколько твоя ИС спобона функционировать при потере канала связи \ с сервером \ отказа БД? При компрометации Ключа Шифрования - сколько у тебя времени перед тем как им смогут воспользоватья ?
ARO - это могут быть средние значения по последним случаям Взломов\Проникновений, которые показывают частоту экспуатации тех или иных типов уязвимостей. Скажем если ты собрался использовать библиотеку OpenSSL - то за всю ее историю в ней находили много различного типа тяжести уязвимостей -
https://www.openssl.org/news/vulnerabilities.html
это примерно 2 в год (тяжких в среднем). Можеш смело заложить в свою формулу в ТЗ этот параметр :)
ALE = SLE X ARO
Это урон который нанесет твоей ИС закономерное появление уязвимостей в OpenSSL = SLE * 0.5
Далее SLE - это что надо предпринять чтобы закрыть брешь ? (разовые затраты на выход из конкретной ситуации vulnerable IS когда твоя IS будет в эксплуатации) - Обновить OpenSSL . А Установленная копия твоей ИС готова пережить мажорное обновление OpenSSL ?? Как архитектор оцени от 0 до 10 эту готовность по возможным проблемам\затратам\зависимостям в твоих протоколах шифрования.
Соответственно если твой "архитектурный" SLE ближе к 10 то ALE будет большим и можно уже на этапе Проэктирования спрогнозировать затраты на эксплуатацию твоей системмы в условиях когда OpenSSL надо обновлять два раза в год.
И так дале..
И да ты правильно мыслиш что Риск так или иначе должен быть высчитан в виде чисел.