Если вы занимаетесь информационной безопасностью, то живете в мире рисков, угроз и уязвимостей, используете эти понятия повседневно. Мы часто подменяем эти понятия, в результате чего не всегда видна грань между тем, что такое риск, а что угроза информационной безопасности.
С одной стороны мы строим модели угроз, следуя отечественной регуляторике, а с другой создаем реестры и планы обработки рисков, ориентируясь на международные стандарты по СМИБ.
Как риски связаны с угрозами, это разные вещи или одно и то же? - рассмотрим в статье.
Если коротко - угроза это часть риска, но давайте разберем.
У понятия риск существует множество определений, только в стандартах и нормативах по информационной безопасности на русском языке их нашлось 6 штук.
Определения риска информационной безопасности
Существуют различные определения риска, вот часть из них:
риск (risk): Сочетание вероятности события и его последствий
ГОСТ Р 51901.1-2002 Менеджмент риска. Анализ риска технологических систем
Риск нарушения безопасности сети электросвязи: Вероятность причинения ущерба сети электросвязи или ее компонентам вследствие того, что определенная угроза реализуется в результате наличия определенной уязвимости в сети электросвязи.
ГОСТ Р 52448-2005 Защита информации. Обеспечение безопасности сетей электросвязи. Общие положения
Риск информационной безопасности (information security risk): Потенциальная возможность того, что уязвимость будет использоваться для создания угрозы активу или группе активов, приводящей к ущербу для организации.
ГОСТ Р ИСО/МЭК 27005-2010 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности
Риск - влияние неопределенности на цели.
Влияние - это отклонение от ожидаемого - положительное или отрицательное.
Неопределенность - это состояние, даже частичное, недостатка информации, относящейся к событию, его последствиям или вероятности, пониманию или знанию о нем.
Риск часто характеризуется ссылкой на потенциальные «события» и «последствия» или их комбинацию.
Риск часто выражается в виде комбинации последствий события (включая изменения обстоятельств) и связанной с ними «вероятности» наступления.
В контексте систем менеджмента информационной безопасности риски информационной безопасности могут быть выражены как влияние неопределенности на цели информационной безопасности.
Риск информационной безопасности связан с возможностью того, что угрозы будут использовать уязвимости информационного актива или группы информационных активов и тем самым причинить вред организации.
ГОСТ ИСО/МЭК 27000-2012 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и терминология
риск (risk): Потенциальная опасность нанесения ущерба организации в результате реализации некоторой угрозы с использованием уязвимостей актива или группы активов.
Примечание - Определяется как сочетание вероятности события и его последствий.
ГОСТ Р ИСО/МЭК 13335-1-2006 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Часть 1. Концепция и модели менеджмента безопасности информационных и телекоммуникационных технологий
риск: Сочетание вероятности нанесения ущерба и тяжести этого ущерба.
ГОСТ Р 51898-2002 Аспекты безопасности. Правила включения в стандарты
Чуть конкретнее обстоят дела с понятиями угроза и уязвимость
Определения угрозы
угроза (threat): Потенциальная причина нежелательного инцидента, результатом которого может быть нанесение ущерба системе или организации.
угроза безопасности информации: Совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации
ГОСТ Р 50.1.056-2005, Методический документ ФСТЭК России от 05.02.2021 "Методика оценки угроз безопасности информации"
Под угрозами безопасности ПДн при их обработке в ИСПДн понимается совокупность условий и факторов, создающих опасность несанкционированного, в том числе случайного, доступа к персональным данным, результатом которого может стать уничтожение, изменение, блокирование, копирование, распространение персональных данных, а также иных несанкционированных действий при их обработке в информационной системе персональных данных.
угроза (threat): Потенциальный источник опасности, вреда и т.д.
Определения уязвимости
уязвимость (vulnerability): Слабость одного или нескольких активов, которая может быть использована одной или несколькими угрозами.
уязвимость (информационной системы); брешь: Свойство информационной системы, предоставляющее возможность реализации угроз безопасности обрабатываемой в ней информации.
уязвимость (информационной системы); брешь: Свойство информационной системы, обусловливающее возможность реализации угроз безопасности обрабатываемой в ней информации.
Уязвимость: недостаток (слабость) программного (программно-технического) средства или системы и сети в целом, который(ая) может быть использован(а) для реализации угроз безопасности информации.
Методический документ ФСТЭК России от 05.02.2021 "Методика оценки угроз безопасности информации"
Из этих определений можно сделать один простой но важный вывод - нет единого общепринятого определения для таких ключевых в отрасли информационной безопасности понятий как риск и угроза. Следовательно, верным или ошибочным суждение о них будет исходя лишь из той регуляторики и терминологии, на базе которой ведется спор.
Но в целом если отойти от формулировок то просматривается и закономерность в определениях, позволю себе ее выявить и обобщить:
Риск это возможность реализации угрозы через использование уязвимости в активе.
Таким образом риск, технически, это ничто иное как комбинация 3х сущностей:
Риск = Угроза + Уязвимость + Актив
Где
Угроза – что то плохое
Уязвимость – особенность актива
Актив – любой объект
Если совсем уж перефразировать, то можно сказать что риск это когда что то плохое происходит из за какой то особенности чего то.
При таком расщеплении на атомы все становится на свои места, ясна связь между угрозами и рисками безопасности.
Угроза просто описывает нам что-то плохое, в то время как Риск еще сообщает из-за чего это плохое может произойти.
Несколько примеров рисков, сформулированных по такой конструкции:
-
Раскрытие ключей (паролей) доступа из-за возможности атаки SMB Relay в ОС Windows
Тут у насУгроза – Раскрытие ключей (паролей) доступа
Уязвимость – Возможности атаки SMB Relay
Актив – ОС Windows
Боковое перемещение злоумышленника по локальной сети из-за возможности удаленного подключения через RDS Shadow в ОС Windows
Закрепление злоумышленника в ОС из-за возможности распространения скриптов через Network Logon Scripts в доменных службах Active Directory
Заражение вредоносным программным обеспечением из-за реагирования на мошеннические, фишинговые письма работником
// В качестве актива выступает человекНеработоспособность серверного оборудования из-за нарушения температурного режима в серверном помещении
// классический ИТ риск на доступность активовНедоступность ИТ/ИБ персонала из-за отсутствия квалифицированной кадровой политики в компании
// Это тоже не про ИБ, скорее про кадровые и управленческие риски компании, но влияет на функционирование системы информационной безопасности. Активом выступает компания как юридическое лицо.
Риск в такой формулировке не просто говорит о чем то плохом, но поясняет почему это может произойти, указывая на источник проблемы.
Все элементы риска (угроза, уязвимость, тип актива) могут объединяться друг с другом в любых адекватных комбинациях, образуя новые риски безопасности.
Преимущества у такого подхода формулировки рисков безопасности:
Нет необходимости дублировать одни и те же угрозы, уязвимости и активы в составе разных рисков, мы просто ведём 3 отдельных реестра, а реестр рисков это ничто иное как их комбинация.
Взгляд на проблемы безопасности становится шире. Мы можем смотреть не только на реестр рисков, но и на реестры угроз, уязвимостей, активов, рассчитывая величину риска с учетом каждого из элементов.
Из 3х-звенной формулировки рисков вытекает простой и понятный алгоритм реагирования - снижать величину ущерба от реализации угрозы, устранять уязвимость или снижать вероятность ее использования.
Тут мы ведем community реестр рисков по такой 3х-звенной схеме, за основу берем MITRE ATT&CK, БДУ ФСТЭК, лучшие практики и личный опыт. Пока набралось ~ 250 рисков и и работа по наполнению базы в процессе. Если перед вами стоит задача ведения реестра рисков - можете использовать нашу community базу за основу и поучаствовать в ее пополнении.
Хотелось бы завершить статью слоганом что не важно как вы учитываете проблемы компании, что называете риском а что угрозой. Но нет, это важно, т.к. от этого зависит полнота и эффективность создаваемых систем ИБ, возможность понять друг друга в ИБ сообществе. Буду рад если поделитесь в комментариях тем как вы ведете учет проблем ИБ в своих компаниях, как описываете риски безопасности.
P.S.
В статье не рассмотрены такие сущности как объект атаки/воздействия, нарушитель, нежелательные последствия, сценарии атак - все это важные элементы в процессах моделирования угроз и управления рисками. Если будет интерес - разложим их на атомы в следующих статьях.
Комментарии (6)
user5239
08.11.2021 13:09Честно говоря, я запутался в том, что Вы хотели довести. Из приведённых цитат я вижу, что риск - это, в первую очередь, вероятность [реализации угрозы (частный случай - реализация уязвимости)]. То есть вероятностная величина. По логике, я бы её измерял в % реализации за период. Дополнительно многие определения добавляют к риску ущерб. То есть величина должна измеряться в (процент*рубль)/год. Но, поскольку измерять таким методом - дело гиблое, то риск переводится в термины "приемлемо-неприемлемо" и чаще всего считается в баллах с учётом компенсирующих мер.
Отступление для пошутить. В ряде организаций риск измеряется по двухбалльной шкале: "риск высокий - риск очень высокий".
Так вот. Прочитал я статью и вижу: "Тут мы ведем community реестр рисков по такой 3х-звенной схеме, за основу берем MITRE ATT&CK, БДУ ФСТЭК...". Вы ведёте реестр ВЕРОЯТНОСТЕЙ, а в основе Банк данных УГРОЗ? Сложно =(
Собственно, я к чему это всё. Не является ли переусложнением считать риски как произведение угроза-уязвимость-актив? Разве это не ведёт к комбинаторному взрыву и избыточному числу рисков, которые нужно анализировать? Разве не будет проще считать, что угроза уже включает узявимость? Можно пример расчётов с использованием вашей базы? Можно отдельной статьёй.
Nic_Kazantsev Автор
08.11.2021 13:20В статье не идет речь про расчет рисков, это действительно отдельная большая тема, заслуживающая отдельного внимания. Хотел статьей навести резкость именно в формулировании рисков (возможно "плюсы" в формуле ввели в заблуждение).
Как вы предлагаете (включать уязвимость в угрозу) сделано в БДУ ФСТЭК, когда у нас под угрозой скрывается несколько абзацев описывающих как она может быть реализована и к чему привести. Поэтому такой подход не то что имеет место, но в каком то роде "узаконен" нашими регуляторами. Но в нем вижу проблему, ведь угроза может реализовываться множеством способов (через различные уязвимости) и каждая из этих уязвимостей может приводить к разным угрозам, так зачем копипастить уязвимости в карточках различных угроз если можно на техническом уровне разбить понятие риск на 3 составляющие (угроза, уязвимость и актив).
user5239
08.11.2021 15:06Насколько я понимаю, основная идея при включении уязвимости в угрозу в том, что уязвимости включаются предельно обобщённо, большей частью - как пример, а вообще говоря конкретные уязвимости нас не очень интересуют. Какая при выборе противодействия практическая разница, через какую именно уязвимость будет реализовываться угроза? Никакой же.
Когда нас интересуют конкретные уязвимости, мы читаем гайды по противодействию именно уязвимостям, типа OWASP, но там совершенно не про риски.
Практическим выхлопом из работы с терминологией всегда является применение выбранного термина. Что-то в Вашей идее интуитивно любопытное есть, но никак не могу сформулировать, что именно. В общем, очень жду от Вас прикладную статью и сравнение Вашего метода/термина со стандартным.
Nic_Kazantsev Автор
08.11.2021 15:26Нам важно понимать как будет реализовываться угроза (через какую уязвимость), потому что один из вариантов снижения риска это влияние на уязвимость, а не на угрозу.
Тут речь не про программные уязвимости типа CVE/NVD а про свойства активов, позволяющие угрозе реализоваться. Например:Заражение ВПО из-за реагирования на фишинговые письма пользователем
Заражение ВПО из-за неработоспособности АВЗ на ОС Windows
Угроза одна, а уязвимости в разных активах, воздействие в каждом случае будет свое. При этом мы можем (если чутка касаться темы с расчетом рисков) смотреть как на атомарные риски так и, например, совокупную величину рисков связанных с угрозой Заражения ВПО.
Условно говоря угрозы - это короткие (и желательно понятные руководству) проблемы, а уязвимости в активах это то, почему эти проблемы могут произойти.
... и мы тут еще не касаемся темы с сценариями (цепочками угроз), это вообще вырви мозг =)
Базу и сервис на которые ссылался мы используем как раз на практике, для построения реестра рисков и расчетов, в том числе оценки влияния защитных мер, постараюсь описать поподробнее в новых статьях, спасибо за интерес.
BMBM
К сожалению в приведённых формулировках понятия угроза и уязвимость эквивалентно, это всегда сбивает с толку.
На мой взгляд - угроза это возможность использования уязвимости, в том числе нарушителями, внутренним или внешним.
А вот уязвимость - это архитектурная особенность (допущение) системы, которая может привести к сбоям (ускорение, снижение энергопотребление и т.п), однако для многих уязвимостей нет релевантных угроз в силу криптографической и, или физической обертки.
Формула верна, если угрозу мерять в вероятности возможности использования уязвимости, а это не просто - померяй вероятность доступа хакера к руту.
И вот тут возникает самый большой фейл - как считать риски зависимых угроз. Маленькая угроза может повлечь каскад других, или наоборот. Какие риски получатся в результате?
Ну и оценка активов под угрозой та ещё катавасия.
Борьба с этими проблемами ведётся по разным направлениям, но об этом в другой раз.
Nic_Kazantsev Автор
Согласен с вами, угрозы и уязвимости часто путают. Взять ту же БДУ ФСТЭК, в которой половина угроз это по сути уязвимости. Сюда же можно добавить ментальную ошибку, приучившую нас под уязвимостью понимать какую-нибудь CVE, которую надо устранить сканером уязвимостей и патчами. Хотя в широком смысле уязвимость это, как вы сказали, архитектурная особенность системы, т.е. любое ее свойство.