CC BY
193
УГРОЗЫ и БЕЗОПАСНОСТЬ
УДК 004.056:061.68
МЕТОДИКА КОЛИЧЕСТВЕННОЙ ОЦЕНКИ РИСКА В ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ОБЛАЧНОЙ ИНФРАСТРУКТУРЫ ОРГАНИЗАЦИИ*
А. В. ЦАРЕГОРОДЦЕВ,
доктор технических наук, профессор,
заведующий кафедрой информационной безопасности
E-mail: [email protected]
Финансовый университет при Правительстве РФ
Е. В. МАКАРЕНКО,
старший преподаватель научно-учебного комплекса инженерного бизнеса и менеджмента кафедры экономики и организации производства E-mail: [email protected] Московский государственный технический университет им. Н.Э. Баумана
Практически все технологии, входящие сегодня в состав «облачной» парадигмы, существовали и раньше, однако до настоящего времени на рынке не было предложений, которые бы объединяли основные перспективные технологии в едином коммерчески привлекательном решении. И только в последнее десятилетие появились общедоступные облачные сервисы, благодаря которым эти технологии стали, с одной стороны, доступны разработчику, а с другой -понятны для бизнес-сообщества. Однако многие из функций, которые делают привлекательными облачные вычисления, могут вступать в противоречие с традиционными моделями обеспечения информационной безопасности.
В связи с тем, что облачные вычисления несут с собой новые вызовы в области информационной безопасности, для организации крайне важно конт-
* Статья подготовлена по материалам журнала «Национальные интересы: приоритеты и безопасность». 2014. № 44 (281).
ролировать процесс управления информационными рисками в облачной среде. В настоящей работе на основе общей системы оценки уязвимостей, позволяющей определить качественный показатель подверженности уязвимостям информационных систем с учетом факторов окружающей среды, представлена методика оценки рисков для различных типов развертывания облачных сред.
Управление информационными рисками, определение применимости облачных сервисов для организации невозможны без понимания контекста, в котором работает организация, и последствий от возможных видов угроз, с которыми она может столкнуться в результате своей деятельности. В статье предложен подход к оценке рисков, используемый при выборе наиболее приемлемого варианта конфигурации среды облачных вычислений с точки зрения требований безопасности. Применение методики по оценке рисков для различных типов развертывания облачных сред позволит выявить коэффициент противодействия возможным атакам
и соотнести величину ущерба с совокупной стоимостью всей ИТ-инфраструктуры организации.
Предложенный подход к анализу и управлению рисками позволяет провести оценку защищенности облачной среды, функционирующей в условиях воздействия различного класса угроз, а также эффективности комплекса мер и средств противодействия указанным угрозам. На основе полученной оценки появляется возможность найти оптимальный вариант конфигурации среды облачных вычислений.
Ключевые слова: облачные вычисления, угрозы информационной безопасности, анализ информационных рисков, методы управления информационной безопасностью, требования информационной безопасности
Введение
В отечественной и зарубежной литературе имеется немало исследований, посвященных основным угрозам безопасности информации в виртуальных средах и облачных платформах, анализу средств защиты в них и выбору наиболее приемлемых [1, 2, 4, 5, 9, 10, 11, 13, 17-20, 22]. Разработкой систем безопасности озабочены и различные компании, предлагающие свои разработки на различных конференциях, форумах и интернет-порталах [6-8, 12, 21]. Все это свидетельствует об актуальности проблемы, один из путей к решению которой предлагается в настоящей статье.
Одной из серьезных угроз информационной безопасности (ИБ) облачных сред является использование со стороны злоумышленников известных, но не исправленных уязвимостей [3]. Успешная реализация эксплойта1 потенциально может привести к значительному финансовому ущербу для клиента, потере репутации облачного провайдера и компрометации используемых механизмов защиты [18]. Принимая во внимание тот факт, что поддержка конфигурации облачной среды, управление уязвимостями и обновлением зависит от модели предоставления облачного сервиса, ответственность за своевременное выполнение этих задач частично или полностью лежит на стороне облачного провайдера [22].
В связи с этим одними из основных задач обеспечения информационной безопасности информационных систем, функционирующих на основе технологии облачных вычислений, становятся рас-
1 Эксплойт (англ. exploit—эксплуатировать) — компьютерная программа, фрагмент программного кода или последовательность команд, использующие уязвимости в программном обеспечении и применяемые для проведения атаки на информационную систему.
смотрение и классификация уязвимостей облачных сред и возможность использования этой информации при проведении количественной оценки риска. Предлагаемая авторами методика позволит принять решение при выборе систем защиты информации, программного обеспечения для компонентов информационных систем (ИС), функционирующих на основе технологии облачных вычислений.
В то время как количественная оценка финансового риска широко распространена в таких областях, как финансы и кредит, количественная оценка рисков информационной безопасности часто сопровождается рядом ограничений, особую роль среди которых занимает отсутствие данных для проверки этих методов [14].
Основные этапы методики количественной оценки риска
Для возможности проведения количественной оценки и построения риск-модели облачной среды необходимо решить следующие задачи:
1) определить и описать возможные технические риски использования облачных сред в их взаимосвязи с уязвимостями и активами организации;
2) сформировать перечень уязвимостей для каждого риска, построить для них базовые векторы системы общего учета уязвимостей (CVSS);
3) разработать методику оценки уровня риска, где под риском будет пониматься комбинация частоты появления и соответствующего влияния потенциального нежелательного события, которое чаще всего связано с угрозой информационной безопасности или нецелевого (злонамеренного) использования объекта оценки. Показатели частоты и урона будут рассчитываться на основе показателей CVSS-метрик: базовой, временной и инфраструктурной. Это потребует детального рассмотрения как текущих положений CVSS, так и их адаптации для задачи расчета частоты и возможного влияния (урона);
4) определить риск-модель на основе полученных уровней влияния рассматриваемых уязвимос-тей. Группировка уязвимостей по принципу принадлежности одному уровню влияния позволит ввести новый показатель — сервисный уровень. Для этого необходимо формализовать задачу определения сервисного уровня, отражающего величину потенциального риска, в виде Марковского процесса с непрерывным временем. Совокупное представление возможных
Таблица 1
Методика оценки риска
Шаг Описание процесса/действия Содержание процесса/действия
1-й Идентификация контекста оценки риска 1.1. Идентификация цели и масштаба оценки
1.2. Описание объекта цели, бизнес-требований и среды безопасности
1.3. Определение владельцев процесса
1.4. Идентификация активов и классификация активов со стороны владельцев
1.5. Описание графа активов и владельцев
1.6. Описание политики безопасности
1.7. Идентификация и описание критериев принятия рисков
2-й Идентификация риска 2.1. Идентификация угроз безопасности и их влияния на активы
2.2. Идентификация уязвимостей объекта оценки, принципов обеспечения, процессов, процедур и среды безопасности
2.3. Документирование сценариев злонамеренного использования и их группировка
3-й Анализ риска 3.1. Оценка уровня влияния злонамеренного использования
3.2. Оценка частоты злонамеренного использования
4-й Оценивание риска 4.1. Определение уровня риска для каждого набора частоты и влияния
4.2. Оценивание риска и сравнение с критериями принятия риска
4.3. Категоризация риска для обработки в наборы рисков
4.4. Определение внутренних взаимосвязей между наборами рисков
4.5. Идентификация конфликтов между наборами риска
4.6. Назначение приоритетов наборов и рисков
4.7. Решение найденных конфликтов
5-й Обработка риска 5.1. Идентификация альтернативных решений по обеспечению безопасности и группировка их в наборы
5.2. Идентификация эффекта и цели альтернативных систем защиты информации (СЗИ)
5.3. Моделирование СЗИ
5.4. Оценка и поиск оптимальной СЗИ или набора решений по обеспечению безопасности
сервисных уровней и интенсивности переходов между ними позволит прогнозировать уровни риска в определенный момент времени. Приведем определения ключевых понятий, использованных в методике. Под уязвимостью будем понимать дефект программного обеспечения или слабость в системе безопасности, которые могут быть использованы заинтересованными лицами в целях нанесения ущерба или вреда организации. Под известными уязвимостями будем понимать те из дефектов, которые либо не имеют патчей2 с исправлениями, либо патчи применяются с временной задержкой. Угроза безопасности - это потенциальное нежелательное событие в объекте оценки, которое может привести к успешному использованию эксплойта с нежелательным влиянием на конфиденциальность, целостность, доступность активов объекта оценки. Результатом использования уязвимости некоторой угрозой может стать появление нежелательного события, которое будем называть злонамеренным использованием [20]. Необходимо отметить, что злонамеренные использования могут возникнуть только в
2 Патч (англ. patch — заплатка) — автоматизированное, отдельно поставляемое программное средство, используемое для устранения проблем в программном обеспечении или изменения его функционала.
случае одновременного существования как угрозы, так и уязвимости, и рассматриваемая уязвимость может быть использована конкретной угрозой, как показано на рис. 1.
Это означает, что множество всех потенциальных злонамеренных событий является подмножеством набора уязвимостей и набора потенциальных угроз и, следовательно, Ы = с ST п SV, где Ы— это набор злонамеренных событий, ST — множество угроз, SV — множество уязвимостей.
Представим методику оценки рисков в виде последовательности связанных процессов (табл. 1).
Рис. 2. Показатели для расчета уровня риска в рамках первого этапа методики
На верхнем уровне предлагаемая методика по оценке рисков включает два основных этапа. Первый этап описывает управляемый риском анализ, включающий оценивание набора злонамеренных использований и связанных с ними уровней риска, которые являются результатом шагов 2, 3, 4 описанной методики с последующим сравнением полученных значений с критериями принятия риска, определенных на шаге 1. Результатом этого этапа является набор рисков, требующих обработки [15, 16].
Набор рисков для обработки, набор альтернативных решений и других компромиссных параметров, соответствующих разработке, проекту и финансовому состоянию, являются входными данными для второго этапа методики. Здесь риски информационной безопасности рассматриваются как проблемы и вызовы, требующие решения в виде доступных альтернативных механизмов безопасности.
В рамках первого этапа описанные действия включают в себя ключевые элементы анализа: набор угроз, уязвимости, злонамеренное использование, его частоту и влияние, риск ИБ, критерии принятия риска. Основные сущности первого этапа подхода по оценке риска и их взаимосвязи представлены на рис. 2. Все приведенные элементы необходимы для определения уровня риска объекта оценки и его оценки в целях уяснения, какой из рисков требует обработки.
В данном случае риск рассчитывается для каждого злонамеренного использования путем комбинации его частоты с одним из влияний. Это означает, что злонамеренное использование приводит к появлению одного или нескольких рисков ИБ, зависящих от количества связанных влияний. Оба показателя (частота и влияние) могут быть определены с помощью количест -венного метода оценки на основании данных из общедоступных источников, одним из которых является база данных уязвимостей NVS и система общего учета уязвимостей — CVSS.
Частота злонамеренного использования и его влияние могут быть представлены в виде количественных показателей: определенное число проявлений в течение временного интервала или вероятность появления злонамеренного использования в определенный период времени. Влияние может быть представлено в виде финансовых потерь, потери репутации и пр. [17, 19].
Для риск-модели, представленной на рис. 3, потери, связанные с определенной угрозой ИБ, могут быть представлены в следующем виде:
ОД, W2, F2),...,(In, Fn)}, (1)
где F. — интенсивность потока событий или вероятность появления злонамеренного события, которое может привести к возникновению влияния Ii.
Это приводит к множеству потерь {Z L L3}, которые могут быть представлены в виде статистически ожидаемых потерь SOP:
SOP = {(IF)L + (IF) L +... + (In Fn )Ln}. (2) Используя выражения (1) и (2) в качестве базы для оценки, рассмотрим далее основные положения
Влияние
Потери
Угроза безопасности
Злонамеренное использование
С 11 12 13 V J С N Li L2 L3 ^ У
—>
—>
Рис. 3. Пример риск-модели
общей системы учета уязвимостей CVSS, предоставим их характеристику и интерпретацию показателей применительно к среде облачных вычислений.
Основные положения общей системы учета уязвимостей
Общая система учета уязвимостей CVSS в настоящее время достаточно широко применяется и все больше принимает вид стандарта для определения и оценки уязвимостей [21]. Основная задача системы состоит в оценке уровня серьезности уязвимостей и предоставлении рекомендаций по смягчению последствий проявления связанных угроз. Следует отметить, что общая система учета уязвимостей представляет собой инструмент для анализа характеристик и влияния уязвимостей, независимо от вендора (поставщика) программного обеспечения, поэтому может быть использована для классификации уязвимостей облачных сред. Набор метрик CVSS представлен на рис. 4.
Приведем краткое описание основных групп метрик рассматриваемой системы (для каждого показателя определен вес в соответствии с данными из руководства по CVSS) [21].
Базовая метрика. Показатели базовой группы описывают характеристики уязвимости, которые являются постоянными и не зависят ни от времени, ни от инфраструктуры. В данную группу входят:
а) вектор доступа — отражает, каким доступом должен обладать злоумышленник для эксплуатации уязвимости (табл. 2);
б) сложность доступа — описывает сложность атаки, необходимой для эксплуатации уязвимости, причем, чем ниже уровень сложности, тем выше показатель уязвимости (табл. 3);
в) аутентификация — описывает количество необходимых сеансов аутентификации цели при эксплуатации уязвимости. Показатель не учитывает сложности данного процесса, а лишь характеризует саму необходимость аутентификации для использования уязвимости. Аутентификация происходит только в том случае, если доступ к ресурсу уже получен (табл. 4);
г) воздействие на конфиденциальность — измеряет степень нарушения конфиденциальности в результате успешной эксплуатации уязвимости (табл. 5);
Группа факторов окружающей среды
Потенциальный возможный ущерб
Потери в случае нарушения конфиденциальности
Масштаб атаки
Потери в случае нарушения целостности
Потери в случае нарушения доступности
Группа базовых метрик
Вектор доступа
Влияние на конфиденциальность
Сложность доступа
Влияние на целостность
Аутентификация
Влияние на доступность
Рис. 4. Набор метрик ^88
Группа временных метрик
Доступность эксплойта
Уровень обновлений (восстановления)
Уровень осведомленности о существовании уязвимости
Таблица 2
Показатели вектора доступа
Показатель Описание показателя Вес
Локальный доступ L Уязвимость эксплуатируется только в случае локального доступа, требует от заинтересованного лица физического доступа или локального аккаунта. Применительно к облачным вычислениям локальным доступом обладает только администратор облачного дата-центра 0,395
Сопряженная сеть А Уязвимость требует от заинтересованного лица иметь доступ к широковещательному домену, к домену коллизий. Примерами сопряженной сети могут быть локальная сеть, Bluetooth, IEEE 802.11 и локальный сегмент Ethernet 0,646
Сеть N Уязвимость эксплуатируется удаленно и не требует локального или физического доступа 1,000
Таблица 3 Показатели сложности доступа
Показатель Описание показателя Вес
Высокая H Для эксплуатации уязвимости требуется «особое условие», например привилегии администратора с доступом к управлению гипервизором, виртуальным машинам 0,35
Средняя M Для эксплуатации уязвимости требуется выполнить ряд дополнительных действий. Атака может быть совершена только с определенного аккаунта, требует сбора информации (пассивной разведки) 0,61
Низкая L Не существует особых условий или усложняющих обстоятельств. Уязвимый продукт имеет доступ к большому количеству пользователей, часто анонимных и не доверенных. Показатель характерен для облачных сред с общедоступным типом развертывания, к которому имеет доступ большое количество пользователей. Проведение атаки не требует специальных программных средств 0,71
Таблица 4
Показатели аутентификации
Показатель Описание показателя Вес
Многоразовая аутентификация Эксплуатация уязвимости требует, чтобы пользователь провел аутентификацию несколько раз. Например, пользователю необходимо осуществить вход в ОС, а затем в бизнес-приложение 0,450
Одноразовая аутентификация Эксплуатация уязвимости требует прохождения аутентификации один раз 0,560
Аутентификация отсутствует Эксплуатация уязвимости не требует аутентификации 0,704
д) воздействие на целостность — измеряет степень нарушения целостности в результате успешной эксплуатации уязвимости (табл. 6);
е) воздействие на доступность — измеряет степень нарушения доступности в результате успешной эксплуатации уязвимости (табл. 7). Расчет базовой метрики производится по следующей формуле:
BS = round _ to _1_ decimal {[(0,6imp) + +(0,4Exp) -1,5] + f (imp)}, где BS — базовая метрика;
Таблица 5
Показатели воздействия на конфиденциальность
Показатель Описание показателя Вес
Отсутствует N Конфиденциальность не нарушена 0
Частичное P Значительное раскрытие информации и доступ на чтение к некоторым системным файлам, к данным определенного клиента. При этом конфиденциальность других клиентов облака не нарушена 0,275
Полное C Полное раскрытие конфиденциальной информации всех клиентов облака, при котором все пользовательские и системные файлы известны злоумышленнику 0,660
Таблица 6 Показатели воздействия на целостность
Показатель Описание показателя Вес
Отсутствует N Целостность не нарушена 0
Частичное P Возможно изменение некоторых системных или информативных файлов, но атакующий либо не имеет возможности выбирать, что изменять, либо часть файлов, которые злоумышленник может менять, - небольшая 0,275
Полное C Полная компрометация целостности системы. Полная потеря систем защиты, атакующий может изменить любой файл 0,660
Таблица 7 Показатели воздействия на доступность
Показатель Описание показателя Вес
Отсутствует N Нет влияния на доступность облачной ИС, все компоненты облака функционируют в штатном режиме 0
Частичное P Возможно уменьшение производительности, требуется дополнительное подключение облака разрыва 0,275
Полное C Полная потеря доступности всех компонентов облачной ИС. Запросы пользователей не обрабатываются, бизнес-приложения недоступны 0,660
imp — общее влияние (урон), определяемое как
imp = 10,41[1 — (1 — Confimp)x х(1 — Intimp\(1 — Avimp)] , где Confimp — урон конфиденциальности; Intimp — урон целостности; Avimp — урон доступности; Exp — доступность использования эксплойта, определяемая как Exp = 20AccVecAccComAut , где AccVec — вектор доступа, AccCom — вектор сложности; Aut — аутентификация;
f(imp) = 0, если imp = 0, в других случаях f = 1,176.
Временная метрика. Временная метрика описывает показатели угрозы, реализующие рассматриваемую уязвимость, и включает следующие показатели:
а) доступность кода и техники эксплойта — характеризует доступность и технику (код) экс-плойта. Общедоступность рабочего эксплойта (открытого кода) резко повышает количество потенциальных злоумышленников (табл. 8);
б) степень готовности решения для ликвидации последствий уязвимости. В общем случае уязвимость после ее появления в течение определенного времени не имеет исправлений в виде патча или официального обновления. В связи с этим существует ряд временных решений, которые могут быть использованы в данный период для частичной ликвидации последствий или полного их устранения (табл. 9);
в) степень достоверности информации об уязвимости — отражает степень достоверности источников о существовании самой уязвимости, а также возможности использования технических деталей эксплойта (табл. 10). Расчет временной метрики включает веса временных показателей с их комбинацией с базовой оценкой, при этом результат находится в диапазоне 0 10. Итоговая оценка временной метрики не превышает базовой оценки, но должна быть не меньше 33% от нее:
TempSc = round _ to _1_ dec х х (BaseSc • Exp • Rem • Rep), где TempSc — временная метрика; BaseSc — базовая метрика; Exp — доступность кода и техники эксплой-та;
Rem — степень готовности решения; Rep — достоверность информации.
Таблица 8 Показатели доступности кода и техники эксплойта
Показатель Описание показателя Вес
Теория (нет доказательств) и Возможность использования эксплой-та существует только в теории, реальных практических реализаций нет 0,85
Эксперимент РОС Использование эксплойта было реализовано в виде эксперимента, где практически была доказана возможность проведения атаки. Разработан код, который требует высокого уровня подготовки 0,90
Функциональная Р Уязвимостью может воспользоваться атакующий с помощью готового и доступного эксплойта 0,95
Высокая Н Эксплойт реализован в виде функционального, независимо действующего модуля. Код эксплойта работает в любой ситуации, реализуется с помощью автономных мобильных агентов («черви» или вирус) 1,00
Не определена ND Информации нет, показатель не влияет на общую оценку учета уязвимостей 1,00
Таблица 9
Показатели степени готовности решения
Показатель Описание показателя Вес
Официальный патч ОР Производитель ПО выпустил окончательный официальный патч для закрытия уязвимостей 0,87
Временное решение ТР Производитель ПО выпустил временный, но официальный патч для закрытия уязвимостей 0,90
Решение на основе советов и рекомендаций Ж Существует неофициальное решение, пользовательский патч 0,95
Отсутствует и Решения нет или им невозможно воспользоваться 1,00
Не определена ND Информации нет, показатель не влияет на общую оценку учета уязвимостей 1,00
Таблица 10 Показатели степени достоверности информации
Показатель Описание показателя Вес
Носит предположительный хараетер иС Информация об эксплойте противоречива, ряд источников противоречит друг другу 0,90
Не проработана ия Информацию об эксплойте комментируют исследовательские антивирусные компании 0,95
Подтверждена С Уязвимость была подтверждена производителем ПО 1,00
Не определена ND Информации нет, показатель не влияет на общую оценку учета уязвимостей 1,00
Метрики среды эксплуатации (инфраструктуры). К данной группе метрик относятся следующие показатели:
а) сопутствующий потенциальный ущерб — описывает возможные потери (финансовые) в результате успешной эксплуатации уязвимости (табл. 11);
б) распределение целевых систем — описывает, какая часть компонентов облачной ИТКС подвержена уязвимости (табл. 12);
в) требования к безопасности — позволяет специалисту по ИБ определить приоритет и важность ключевых требований безопасности: конфиденциальность, целостность, доступность. При этом особое внимание уделяется тому, насколько критично для существующих бизнес-функций поддержание на необходимом уровне одного из требований.
Общий эффект инфраструктурного показателя зависит от соответствующих значений частных показателей из базовой метрики — урона для конфиденциальности, целостности и доступности. Следует принять во внимание, что если в базовой метрике урон для конфиденциальности отсутствует, то требование к обеспечению конфиденциальности не будет оказывать никакого влияния на расчет совокупного инфраструктурного показателя. Увеличение требования конфиденциальности со «среднего» до «высокого» не изменит инфраструктурного показателя, если базовый показатель урона конфиденциальности принимает значение «полный», потому что промежуточный показатель (часть базового показателя урона конфиденциальности) уже принял максимальное значение. Значения показателей для конфиденциальности, целостности и доступности описаны в табл. 13.
Расчет инфраструктурной метрики проводится по формуле
EnvSc = round _ to _1_ dec х х [(AdTem+(10 - AdTem) ■ CollDamPot)TarDis] , где EnvSc — инфраструктурная метрика; TarDis — распределение целевых систем; CollDamPot — сопутствующий потенциальный ущерб;
AdTem — скорректированная оценка временной метрики, пересчитанная с учетом требований безопасности и урона из базовой метрики (Adjimp):
Adjimp = min [10,41(1 - Confimp • ConfReq)x x(1 - Intimp • IntReq)(1 - Avimp • AvReq))], где ConfReq, IntReq, AvReq — требования к конфиденциальности, целостности, доступности.
Таблица 11 Показатели сопутствующего потенциального ущерба
Показатель Описание показателя Вес
Отсутствует N В результате успешной эксплуатации уязвимости потерь нет 0
Низкий L В результате успешной эксплуатации уязвимости происходит незначительное снижение производительности, ущерб минимальный 0,1
Низкий -средний ЬМ В результате успешной эксплуатации уязвимости происходит снижение производительности облачной ИС, запросы пользователей обрабатываются дольше, чем определено в SLA, что может повлечь снижение дохода от использования облачных сервисов 0,3
Средний -высокий МН В результате успешной эксплуатации уязвимости происходит существенное снижение производительности, финансовый ущерб серьезный 0,4
Высокий Н В результате успешной эксплуатации уязвимости клиенту облачной ИС наносится катастрофический ущерб 0,5
Не определен ND Информации нет, показатель не влияет на общую оценку учета уязви-мостей 0
Таблица 12
Показатели распределения целевых систем
Показатель Описание показателя Вес
Нет распределения N Ни один из компонентов облачной информационно-телекоммуникационной системы не подвержен уязвимости 0
Низкое Ь 1-25% компонентов облачной ИС подвержены уязвимости 0,25
Среднее М 26-75% компонентов облачной ИС подвержены уязвимости 0,75
Высокое Н 76-100% компонентов облачной ИС подвержены уязвимости 1,00
Не определено ND Информации нет, показатель не влияет на общую оценку учета уязвимостей 1,00
Таблица 13 Показатели требований к безопасности
Показатель Описание показателя Вес
Низкие L Урон конфиденциальности (целостности, доступности) имеет ограниченный эффект для организации 0,50
Средние M Урон конфиденциальности (целостности, доступности) имеет серьезный эффект для организации 1,00
Высокие H Урон конфиденциальности (целостности, доступности) имеет катастрофический эффект для организации 1,51
Не определены ND Значение метрики не определено, и на общий счет не влияет 1,00
Таблица 14
Показатели требований к безопасности
Группа метрик Вектор
Базовая А^, А, К]/АС: [Н, М, L]/Au:[M, 8, К]/С:[Ы, Р, С]Л:[1Ч, Р, С]/А:[1Ч, Р, С]
Временная Е:[и, РОС, ^ Н, Т^ W, и, :Ш]ЖС:[иС, Ш, С, КБ]
Инфраструктурная СБР:[]Ч, L, LM, МН, Н, КБ]/ТБ:[К, L, М, Н, Ж>]/СЯ:^, М, Н, КБ]/ !Я:[Ь, М, Н, Ж>]/АК^, М, Н, КБ]
Таким образом, получаем базовый, временной и инфраструктурный векторы, соответствующие группе метрик, приведенной в табл. 14.
Определение уровня риска на основе показателей частоты злонамеренного использования и урона
Используя базовый, временной и инфраструктурный векторы, определим два основных интегральных показателя, влияющих на оценку риска. Чем выше уровень подверженности уязвимости (т.е. применения эксплойта), тем больше шансов у злоумышленника провести успешную атаку и тем больше значение показателя частоты злонамеренного использования F. Расчет этого показателя для каждой уязвимости, представленной в риск-модели облачной среды, основывается на положении, что основные характеристики уязвимости описываются базовой метрикой, а учет показателей временной метрики позволяет уменьшить вероятность успешного применения эксплойта. Тот же принцип относится и к урону (влиянию): потенциальное влияние определяется как урон, зависящий от показателей уязвимости в базовой метрике. В то же время оно может быть увеличено или уменьшено в зависимости от требований к конфиденциальности, доступности и целостности, определенных в инфраструктурной метрике.
Далее для измерения уровня риска вводится понятие уровня сервиса, представленного в виде Марковского процесса с непрерывным временем. Сервисные уровни зависят от проектного решения и варианта реализации ИС, структуры ИС и набора приложений, другими словами, от способа использования информационной системы.
Построение риск-модели достигается за счет выполнения двух последовательных шагов:
1) определение состояния модели исходя из оценки урона при успешной реализации эксплой-та;
2) определение состояния модели из оценки частоты применения эксплойта.
На первом шаге определяется список уязви-мостей на основании общедоступных данных, например из официальных сообщений об уязви-мостях, состояния баз данных (NVD) или путем запуска специализированных сканеров (Nхssus). Если же по ряду технических причин (например, запрет открытия нужных портов в брандмауэре, затруднительное определение местоположения ИС) применение специализированных сканеров затруднено, тогда необходимо произвести расчет частоты применения эксплойта и возможного урона для каждой уязвимости.
Урон от успешного применения эксплойта описывает серьезность уязвимости, но это вовсе не означает, что две уязвимости, приводящие к одинаковому урону, имеют схожий уровень влияния для рассматриваемой среды и приводят к соразмерному уменьшению сервисного обслуживания. В связи с этим необходимо решить задачу определения интервалов уровней влияния уязвимостей с последующим определением для них сервисных уровней. В результате получается набор уровней сервиса: от уровня без предоставления сервисов до полного набора сервисов, описанных в виде модели состояний.
Далее, на втором шаге, исследуется модель переходов состояний, полученная на первом шаге, и дополняется интенсивностью переходов. Интенсивность переходов определяет, с какой вероятностью возможен переход из одного состояния в другое и с какой вероятностью возможно нахождение в этом состоянии в определенный интервал времени В модели оценки уровней риска каждое состояние ссылается на совокупный уровень влияния набора уязвимостей. Таким образом, модель переходов состояний описывает различные уровни риска, характерные для рассматриваемой среды в момент времени Для определения интенсивности переходов учитывается агрегированная частота использования эксплойта в определенный интервал времени.
Заключение
Анализ возможных угроз и анализ рисков служат основой для обоснования выбора мер по обеспечению информационной безопасности информационных систем облачных вычислений, которые необходимы для снижения риска до приемлемого уровня.
На базе общей системы оценки уязвимостей (СУ88), позволяющей определить качественный показатель подверженности уязвимостям с учетом факторов окружающей среды, разработана методика количественной оценки потенциальных
уязвимостей для различных типов развертывания облачных сред.
Предложенный подход к анализу и управлению рисками позволяет провести оценку защищенности облачной среды, функционирующей в условиях воздействия рассматриваемого класса угроз, а также эффективности комплекса мер и средств противодействия этим угрозам. На основе полученной оценки появляется возможность сделать выбор между различными вариантами конфигурации среды облачных вычислений и выбрать наиболее приемлемый вариант с точки зрения требований безопасности.
^исок литературы
1. Астахов А. Особенности обеспечения безопасности виртуальных сред. URL: http://iso27000.ru/ blogi/aleksandr-astahov/osobennosti-obespecheniya-bezopasnosti-virtualnyh-sred.
2. Васильев В. Безопасность облачных сред. URL: http://pcweek.ru/security/article/detail. php?id=139185.
3. Вдовин И. COBIT 4.1. М.: Аудит и контроль информационных систем, 2008. 240 c.
4. Вернер О. «Облака», виртуальная инфраструктура и безопасность информации. URL: http://elvis.ru/upload/iblock/980/elvis_verner_oblaka-virtualizaciya-i-bezopasnost.pdf.
5. Власов А. Обзор средств защиты в виртуальных средах // Jet Info. 2012. № 3.
6. Защита «облаков». URL: http://jet.msk. su/services_and_solutions/information_security/ solutions_catalog/zashchita_oblakov_i_gadzhetov.
7. Как обеспечить безопасность в облачных хранилищах. URL: http://topobzor.com/kak-obespechit-bezopasnost-v-oblachnyx-xranilishhax/.html.
8. Проблемы безопасности облачных сред. URL: http://dehack.ru/news/2012_06_30_10_29_00.
9. Радин П.К., Зубарев И.В. Основные угрозы безопасности информации в виртуальных средах и облачных платформах // Вопросы кибербезопас-ности. 2014. № 2 (3).
10. Самойленко А. Защита облачных инфраструктур сервис-провайдеров с помощью vGate R2.
URL: http://vmgu.ru/articles/vgate-r2-cloud-security-for-vmware-1.
11. Сидорова М. Противоречивые «облака». URL: http://itsec.ru/articles2/oborandteh/ protivorechivie-oblaka.
12. Угрозы облачных вычислений и методы их защиты. URL: http://habrahabr.ru/post/183168.
13. Уинклер В. Облачные вычисления: вопросы безопасности в виртуальных облаках. URL: http:// technet.microsoft.com/ru-ru/magazine/hh641415 .aspx.
14. Царегородцев А.В. Анализ рисков безопасности данных в корпоративных сетях кредитно-финансовых организаций на основе облачных вычислений // Национальные интересы: приоритеты и безопасность. 2013. № 39. С. 35-44.
15. Царегородцев А.В., Качко А.К. Обеспечение информационной безопасности на облачной архитектуре организации // Национальная безопасность.
2011. № 5. С. 25-34.
16. Царегородцев А.В., Качко А.К. Один из подходов к управлению информационной безопасностью при разработке информационной инфраструктуры организации // Национальная безопасность.
2012. № 1. С. 46-59.
17. Accorsi R., Wonnemann C. Auditing Workflow Execution against Dataflow Policies. In Proc. BIS. 2010. P. 207-217.
18. Bell D.E., LaPadula L.J. Secure Computer System: Unified Exposition and Multics Interpretation. Tech report ESD-TR-75-306. Mitre Corp. Bedford, Ma, 1976.
19. BishopM. Computer Security: art and science. Addison Wesley Publ., 2002. 1084 p.
20. Mell P., Grance T. The NIST Definition of Cloud Computing, Version 15, September, 2011. URL: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
21. NVD Common Vulnerability Scoring System Support. Vol. 2. URL: http://nvd.nist.gov/cvss.cfm?ca lculator&version=2.
22. Trope R.L., Power E.M., Polley V.I., Morley B.C. A Coherent Strategy for Data Security through Data Governance // IEEE Security & Privacy. 2007. Vol. 5. № 3. Р. 32-39.
Digest Finance ISSN 2311-9438 (Online) ISSN 2073-8005 (Print)
Threats and security
METHOD OF MEASUREMENT OF INFORMATION SECURITY RISK OF CLOUD INFRASTRUCTURE OF AN ORGANIZATION
Anatolii V. TSAREGORODTSEV, Elena V. MAKARENKO
Abstract
Almost all of the technologies that are now part of the cloud paradigm existed before, but so far the market was lacking the proposals that bring together emerging technologies in a single commercially attractive solution. Only in the last decade, there appeared cloud services open to public, through which these technologies, on the one hand, became available to developer, and on the other hand, they were clear to business community. But many of the features that make cloud computing attractive, may be in conflict with the traditional models of ensuring the information security. Due to the fact that cloud computing brings new challenges in the field of information security, it is imperative to organizations to control the information risk management process in the cloud environment. On the basis of common vulnerability scoring system, which allows determining the qualitative indicator of exposure to information systems vulnerabilities, and taking into account the environmental factors, we propose a method of risk assessment for different types of cloud environment deployment. Information risk management, defining of the cloud services applicability for an organization is impossible without understanding the context in which organization operates, and also the consequences of the possible types of threats that it may face as a result of their activities. Our paper proposes a risk assessment approach that is used for choosing the most appropriate configuration options of cloud computing environment from the point of view of safety requirements. The risk assessment technique application for different types of cloud environment deployment will enable to reveal the ratio of countering of possible attacks and to correlate the amount of damage to the total cost of ownership of entire IT infrastructure of an organization. The proposed approach to analysis and risk management allows the cloud security assessment, operating under the impact of various classes of threats, as well as the effectiveness of set of measures and means to counter those threats. Based on this assessment, it is possible to find an optimal configuration option of cloud computing environment.
Keywords: cloud computing, information, security, threats, risk analysis, management, methods, requirements
References
1. Astakhov A. Osobennosti obespecheniya bezopas-nosti virtual 'nykh sred [Specifics of ensuring the security of virtual environment]. Available at: http://iso27000. ru/blogi/aleksandr-astahov/osobennosti-obespecheniya-bezopasnosti-virtualnyh-sred. (In Russ.)
2. Vasil'ev V. Bezopasnost 'oblachnykh sred [Security of cloud environment]. Available at: http://pcweek. ru/security/article/detail.php?id=139185. (In Russ.)
3. Vdovin I. KOBIT 4.1 [COBIT 4.1]. Moscow, Audit i kontrol' informatsionnykh sistem Publ., 2008, 240 p.
4. Verner O. "Oblaka ", virtual 'naya infrastruktura i bezopasnost 'informatsii [Clouds, virtual infrastructure and information security]. Available at: http://elvis.ru/ upload/iblock/980/elvis_verner_oblaka-virtualizaciya-i-bezopasnost.pdf. (In Russ.)
5. Vlasov A. Obzor sredstv zashchity v virtual 'nykh sredakh [Review of protection means in virtual environment]. Jet Info, 2012, no. 3.
6. Zashchita "oblakov" [Securing clouds]. Available at: http://jet.msk.su/services_and_solutions/in-formation_security/solutions_catalog/zashchita_obla-kov_i_gadzhetov. (In Russ.)
7. Kak obespechit' bezopasnost' v oblachnykh khranilishchakh [How to ensure the security in cloud storages]. Available at: http://topobzor.com/kak-obespechit-bezopasnost-v-oblachnyx-xranilishhax/.html. (In Russ.)
8. Problemy bezopasnosti oblachnykh sred [Security challenges of cloud environment]. Available at: http://dehack.ru/news/2012_06_30_10_29_00. (In Russ.)
9. Radin P.K., Zubarev I.V. Osnovnye ugrozy bezopasnosti informatsii v virtual'nykh sredakh i oblachnykh platformakh [The main threats to information security in virtual environment and cloud platforms].
Voprosy kiberbezopasnosti = Issues of cybersecurity, 2014, no. 2 (3).
10. Samoilenko A. Zashchita oblachnykh infrastruktur servis-provaiderov s pomoshch'yu VGATE R2 [Protection of cloud infrastructure of service providers using VGATE R2]. Available at: http://vmgu.ru/articles/ vgate-r2-cloud-security-for-vmware-1. (In Russ.)
11. Sidorova M. Protivorechivye "oblaka" [Controversial clouds]. Available at: http://itsec.ru/articles2/ oborandteh/protivorechivie-oblaka. (In Russ.)
12. Ugrozy oblachnykh vychislenii i metody ikh zashchity [Threats to cloud computing and the ways to protect it]. Available at: http://habrahabr.ru/ post/183168. (In Russ.)
13. Winkler W. Oblachnye vychisleniya: voprosy bezopasnosti v virtual'nykh oblakakh [Cloud computing: security issues in the virtual clouds]. Available at: http://technet.microsoft.com/ru-ru/magazine/ hh641415.aspx. (In Russ.)
14. Tsaregorodtsev A.V. Analiz riskov bezopasnosti dannykh v korporativnykh setyakh kreditno-finan-sovykh organizatsii na osnove oblachnykh vychislenii [Risk analysis of data safety in corporate networks of credit and financial organizations based on cloud computing]. Natsional'nye interesy: prioritety i bezo-pasnost' = National interests: priorities and security, 2013, no.39, pp. 35-44.
15. Tsaregorodtsev A.V., Kachko A.K. Obespechenie informatsionnoi bezopasnosti na oblach-noi arkhitekture organizatsii [Ensuring the information security in cloud-based architecture of an organization]. Natsional 'naya bezopasnost ' = National security, 2011, no. 5, pp. 25-34.
16. Tsaregorodtsev A.V., Kachko A.K. Odin iz pod-khodov k upravleniyu informatsionnoi bezopasnost'yu pri razrabotke informatsionnoi infrastruktury organi-zatsii [An approach to information security manage -ment in the information infrastructure development].
Natsional 'naya bezopasnost' = National security, 2012, no. 1, pp. 46-59.
17. Accorsi R., Wonnemann C. Auditing Workflow Execution against Dataflow Policies. In Proc. BIS, 2010, pp. 207-217.
18. Bell D.E., LaPadula L.J. Secure Computer System: Unified Exposition and Multics Interpretation. Tech report ESD-TR-75-306. Mitre Corp., Bedford, Ma, 1976.
19. Bishop M. Computer Security: Art and Science. Addison Wesley Publ., 2002, 1084 p.
20. Mell P., Grance T. The NIST Definition of Cloud Computing, Version 15, September, 2011. Available at: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
21. NVD Common Vulnerability Scoring System Support, vol. 2. Available at: http://nvd.nist.gov/cvss. cfm?calculator&version=2.
22. Trope R.L., Power E.M., Polley V.I., Morley B.C. A Coherent Strategy for Data Security through Data Governance. IEEE Security & Privacy, 2007, vol. 5, no. 3, pp. 32-39.
Anatolii V. TSAREGORODTSEV
Financial University under Government
of Russian Federation, Moscow, Russian Federation
Elena V. MAKARENKO
Bauman Moscow State Technical University, Moscow, Russian Federation [email protected]
Acknowledgments
The article is adapted from the journal of "National interests: priorities and security", 2014, no. 44 (281).
