Как правильно выделить и оценить архитектурные риски?

Question

[Gudsaf]

Есть одна простая задача: обменяться данными.

Решить эту задачу можно тремя способами:

1. через сайт, на котором можно эти данные разместить;
   
2. через сайт, на котором можно эти маркеры разместить и подписаться под этими данными, что они мои;
   
3. через блокчейн, где автоматически мы подписываемся что эти данные мои.
   

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

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

Приведу пример подобной задачи, но более просто: я хочу сравнить риски использования двух типов велосипедов, трехколесного и двухколесного. Архитектуры велосипедов разные, но решают одну задачу - перевезти меня из точки А в точку Б. Соответственно есть и свои риски, которые не зависят вообще от того какая резина у меня на велосипеде, а зависят например от того, что в первой архитектуре у тебя три колеса, а во второй два.
Тогда сходу можно выделить риск общий для двух этих решений: риск падения с велосипеда.
В случае первой архитектуры, где 3 колеса, риск будет меньше, например 0,1.
В случае второй архитектуры, где 2 колеса, риск будет больше, например 0,9.

Соответственно можно как-то выделить общие архитектурные риски для данных решений и сравнить их в пределах этих рисков. Если вернуться от велосипедов, к системам обмена данными, то я не хочу рассматривать детали системы:

1. то какая у меня субд стоит на сервере, какие у нее уязвимости;
   
2. то, какая у меня ос стоит у пользователся, какие у нее уязвимости;
   
3. то, что прошивка биоса может быть подделана китайцами и тогда данным в БД беда;
   
4. и прочие мелочи.
   

А рассматривать риски архитектуры:

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

Как правильно выделить и оценить подобные архитектурные риски? Есть какая-то методика, примеры?

Comments

[sim3x]

Почитайте уже про ассиметричную крипту и не постите ерунду

[Gudsaf]

sim3x, да причем тут крипта?! я не понимаю, я ее всуну везде и что, будет счастье? это смахивает на какой-то троллинг. Крипта не решит риск отказа системы, крипта не решит риск уязвимости субд позволяющей утянуть данные с него - вы это понимаете?

Мне кажется вы не понимаете сути вопроса: я говорю про риски архитектурные, а не что-то одно.

[⚡ Kotobotov ⚡]

все просто, если ты задаешь вопрос, нужен ли в проекте блокчейн - значить он там гарантированно не нужен

[Gudsaf]

дима кубитский, нет, как раз таки я то знаю зачем он там нужен, но надо как-то обосновать, чтобы и другие понимали почему он нужен. Как идея - обосновывать через известное всем понятие, т.е. риск

[zvonok1337]

Соглашусь с джентельменом выше. Какая-то ерунда абстрактная написана, даже рассуждать не над чем.

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

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

Таким образом, исполнив RCE на сайте, злоумышленник сможет скачать ваш сертификат ЦП, дальше войти на сайт по ЦП, получить права пользователя ЭЦП и передать ложные данные.

В этой схеме уязвимое место: при эксплуатации RCE можно получить ЭЦП и вход только по ЦП.
В этом случае надо добавить авторизацию по одноразовому паролю, какому-нибудь Google Authenticator для владельца ЭЦП. И спрятать сертификаты куда-то в другое место, где нельзя их "просто так" достать. Например, вместо хранения на сайте ЦП, хранить их дайджесты.

Появляется новое уязвимое место: брутфорс одноразового пароля и атаки на хеши.

Решаем так: в случае если код с GA не совпал 10 раз - блокируем сертификат пользователя и передаём информацию безопасности, а она в свою очередь обратиться к владельцу ЦП с вопросом: "почему вы 10 раз не смогли войти?".

А решение атак с хешами - целый раздел в криптографии

до паранойи доводить конечно не надо, ну вот пример, показывающий, что зная векторы атак - знаешь как и защититься от них

Answer 1

[Алекс]

Есть общая методика в ИБ , называетс это 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 надо обновлять два раза в год.

И так дале..
И да ты правильно мыслиш что Риск так или иначе должен быть высчитан в виде чисел.