@Gudsaf
Школьник

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

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

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

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

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

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


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

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


Как правильно выделить и оценить подобные архитектурные риски? Есть какая-то методика, примеры?
  • Вопрос задан
  • 255 просмотров
Пригласить эксперта
Ответы на вопрос 1
asilonos
@asilonos
Программист
Есть общая методика в ИБ , называетс это 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 надо обновлять два раза в год.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы