Введение
Облачные вычисления стали популярной темой в прессе и в ИТ-индустрии. Преимущества, которыми обладают облачные вычисления, огромны, но только если удастся верно рассчитать риски при переходе к облачной модели, которые должны учитывать пользователи и поставщики [1; 4; 7]. В связи с этим не так давно возник новый класс рисков, присущих деятельности организаций и отличных от уже существовавших, - риски, связанные с угрозой нарушения информационной безопасности. Чтобы управлять этими рисками, предприятию необходимо выбрать методику, по которой рассчитывалась бы оценка рисков.
Неизбежно устаревают одни методики, другие - возникают и совершенствуются, в связи с чем очень важно работать по максимально актуальной на данный момент. В результате на рынке программ и методологий оценивания рисков формируется лишь несколько лидеров, заслоняющих собой редко обновляющиеся или неэффективные аналоги, а у самих методик появляются отличия, на которых и основаны все достоинства и недостатки программных комплексов. Рассмотрим и сравним основные, пользующиеся наибольшей популярностью методы анализа информационных рисков. Цель данной статьи - проанализировать возможности моделей Octave, RiskWatch, Cramm по оценке рисков ИТ для применения их к облачным сервисам.
Риск-модель OCTAVE. Суть этой модели заключается в том, что процесс анализа риска производится только сотрудниками предприятия без помощи консультантов внешних организаций. Для этого необходимо создать смешанную группу, которая будет включать и технических специалистов, и руководителей всех уровней. Это позволит всесторонне оценить все последствия для бизнеса из-за возможных инцидентов в области информационной безопасности, а также разработать контрмеры. Данная методика предлагает 3 фазы анализа:
1) разработать профиль угроз, которые связаны с активом;
2) идентифицировать инфраструктурные уязвимости;
3) разработать стратегию и планы безопасности.
В методике предлагается использовать дерево вариантов. Важная задача первой фазы - упорядоченно описать сочетание ресурса и угрозы. Вторая стадия исследования системы - идентификация инфраструктурных уязвимостей. В ходе этого этапа определяется инфраструктура, которая поддерживает существование актива и все то, что позволяет получить к ней доступ. Здесь рассматриваются такие компоненты классов, как серверы, персональные компьютеры, сетевое оборудование, домашние ПК, которые работают удаленно, но имеют доступ к сети предприятия, системы хранения, мобильные компьютеры, беспроводные устройства и др. Выбранная группа, которая проводит анализ для определенного сегмента сети, отмечает, какие в нем компоненты будут проверяться на наличие уязвимостей. Проверка уязвимостей ведется различными специализированными сканерами, тестовыми скриптами, с помощью списков уязвимостей. Для каждого определенного компонента определяются:
1) списки уязвимостей, которые надо немедленно устранить;
2) списки уязвимостей, которые надо устранить в ближайшее время;
3) списки уязвимостей, в плане которых не нужно незамедлительных действий.
По итогам стадии готовится отчет, где указывается, какие были обнаружены уязвимости, какое они могут оказать влияние на выделенные активы предприятия, какие меры необходимо предпринять для устранения этих уязвимостей. Третья стадия по исследованию системы - это разработка стратегии и планов безопасности. Эта стадия начинается с оценивания рисков, проводится на основе отчетов предыдущих двух этапов. При оценке риска в OCTAVE делается только оценка ожидаемого ущерба, без оценивания его вероятности. Оценивается по шкале: высокий, средний, низкий финансовой ущерб и ущерб репутации компании, жизни и здоровья сотрудников и клиентов, ущерб, который может спровоцировать судебное преследование из-за какого либо инцидента. Здесь описываются те значения, которые соответствуют каждой градации шкалы.
Далее идет разработка планов по снижению рисков нескольких типов: долговременные, среднесрочные, задачи на ближайшее время.
В методике для определения мер противостояния угрозам предлагаются каталоги средств. В случае если организация использует частное облако, данная модель может быть использована для оценки риска. Поскольку предприятие сохраняет контроль над оборудованием и данными, то оно может использовать эту модель без внесения в нее поправок. Иначе, если физически облако находится вне юрисдикции организации и работники предприятия не имеют доступа к оборудованию, то эту методику нельзя применить, так как нет возможности провести полный учет всех инфраструктурных уязвимостей [2; 6; 8].
Риск-модель CRAMM. В основе данной модели лежит комплексный подход к оцениванию рисков, который сочетает в себе качественные и количественные методы анализа. Эта модель универсальна и подходит для крупных и малых предприятий, правительственного и коммерческого сектора. Версии программных продуктов CRAMM ориентированы на различные типы предприятий и отличаются имеющимися у них базами знаний. Анализ информационной безопасности систем с помощью этой модели проводится в три стадии.
На первой стадии происходит анализ всего того, что касается определения ценности ресурсов системы и идентификации. Этот этап должен начинаться с решения задачи по определению границ системы, а именно собираются сведения о самой конфигурации системы и о том, кто будет отвечать за программные и физические ресурсы и кто является пользователем системы, как ее будут применять. Далее должна проводиться идентификация ресурсов, которые содержатся внутри границ системы (физических, программных и информационных). Затем строят модель исследуемой информационной системы с позиции информационной безопасности. Для всех информационных процессов, которые, по мнению пользователя, имеют самостоятельное значение, строится дерево связей использования ресурсов. Такая модель позволит выделить критические элементы.
Ценность программного обеспечения и данных определяется в ситуациях:
1) недоступность ресурса в течение какого-либо промежутка времени;
2) потеря либо полное разрушение информации, которая была получена с последнего резервного копирования;
3) нарушение конфиденциальности в момент несанкционированного доступа посторонних лиц или штатных сотрудников;
4) модификация (рассматривается для случаев небольших ошибок, связанных с вводом информации, программными ошибками)
5) ошибки, которые связаны с передачей информации (это отказ от доставки, доставка к неверному адресату, недоставка информации).
Чтобы оценить возможный ущерб, в CRAMM рекомендуется использовать такие параметры: нарушение действующего законодательства; ущерб репутации предприятия; ущерб для здоровья сотрудников; ущерб от разглашения информации, персональных данных; потери, которые связаны с восстановлением ресурсов и невозможностью выполнения обязательств.
Для программного обеспечения и данных выбираются критерии, применимые к данной ИС. Далее оценивается ущерб по шкале со значениями от 1 до 10. Если будет низкая оценка по всем используемым критериям (3 балла и ниже), то будет считаться, что исследуемая система требует базового уровня защиты, и тогда вторая стадия опускается.
На второй стадии исследуется то, что принадлежит к идентификации, а также к оценке уровня угрозы для ресурсов и их уязвимостей. По окончании этой стадии заказчик может получить идентифицированные и оцененные уровни рисков для исследуемой системы. Здесь оценивается зависимость всех сервисов от некоторой группы ресурсов, существующий уровень уязвимостей и угроз, а также анализируются результаты и вычисляются уровни рисков. Эта методика объединяет уязвимости и угрозы в матрице риска. Главный подход для решения этой проблемы заключается в том, чтобы рассмотреть уровни угроз и уязвимостей, размер ожидаемых потерь.
Третья стадия метода заключается в поиске контрмер. Как правило, это поиск системы безопасности, которая будет наилучшим образом удовлетворять требованиям заказчика. CRAMM генерирует некоторое количество вариантов мер по противодействию, которые адекватны выявленным рискам. Эти меры объединяют в три категории: примерно 300 рекомендаций основного общего плана; больше 1000 конкретных рекомендаций; примерно 900 примеров того, как возможно организовать защиту в этой ситуации. Таким образом, в модели CRAMM первоначальные оценки делаются на качественном уровне, а потом переходят на количественную оценку (балльную).
При использовании частного облака, если организация сохраняет контроль над данными и физическими компонентами системы, данная модель не нуждается во внесении поправок на облачную природу. Однако следует сказать о некоторых недостатках данной модели. Если организация не имеет контроля над оборудованием, то невозможно использовать ни один из стандартных сценариев данной модели, ни одна из стадий исследования не может быть полностью законченной, т.е., модель не может быть использована без внесения ряда поправок. Однако остается возможность использовать в анализе данные провайдера и использовать модель без корректировок.
Сильная сторона этой модели заключается в идентификации элементов риска, а именно: нематериальные и материальные активы, а также их ценность, угрозы, величина потенциального ущерба, мер безопасности и вероятность реализации угрозы.
Модель CRAMM имеет весомые недостатки. В ней нет процесса взаимодействия способа управления и описания назначения какого-либо способа; мониторинга эффективного использования способов управления остаточными рисками; перерасчета допустимой величины рисков; процесса реагирования на получившиеся инциденты [2; 3; 6; 8]. Также в ней нет расчета по возврату инвестиций на внедрение мероприятий по безопасности, хотя решение о применении того или иного мероприятия должно опираться не только на величину риска, но и на стоимость реализации этого мероприятия.
Риск-модель RiskWatch. Компанией RiskWatch была разработана собственная модель анализа рисков и семейство программных продуктов, в которых она реализуется. В комплекс RiskWatch входит программное обеспечение для проведения различных видов аудита безопасности.
В этой модели в качестве критериев для управления и оценки рисков используются ROI (оценка возврата инвестиций) и ALE (ожидаемые годовые потери). RiskWatch ориентируется на количественную оценку соотношения потери от угрозы безопасности и затраты на создание системы защиты. В основе продукта RiskWatch лежит метод анализа рисков, который включает в себя четыре этапа.
Первый этап. Определяется предмет исследования. Здесь описываются следующие параметры: тип предприятия, в общих чертах состав системы исследования, а также основные требования, которые предъявляются к безопасности.
Второй этап - это ввод данных, которые описывают конкретные характеристики исследуемой системы. На этом этапе подробно описывают потери, ресурсы и классы инцидентов, которые получаются путем сопоставления категории потерь с категориями ресурсов.
Чтобы выявить возможные уязвимости, используется вопросник, содержащий в себе более 600 вопросов. Эти вопросы имеют связь с категориями ресурсов. Также здесь устанавливается частота появления каждой из определенных угроз, степень уязвимостей и ценность ресурсов. Если для выбранных угроз имеются LAFE и SAFE (среднегодовые оценки возникновения), то они и используются. Все это нужно для расчета эффективности от внедрения этих средств защиты.
Третий этап - это уже количественная оценка рисков. На этом этапе производится расчет профиля рисков и выбираются меры по обеспечению безопасности. Сначала необходимо установить связь между ресурсами, потерями, угрозами и уязвимостями, которые были выделены на предыдущих шагах анализа. По большей степени риск здесь вычисляется при помощи математического ожидания потери за год. Когда будут определены и собраны вместе все воздействия и активы, то будет возможно оценивать общие риски для ИС, т.е. суммировать все частные значения.
Дополнительно также исследуются сценарии «что, если...», позволяющие описывать аналогичные ситуации внедрения средств защиты. Если сравнивать возможные потери при внедрении мер защиты и без них, то можно оценить эффективность от этих мер.
Четвертый этап - это генерация отчетов. Таким образом, данное средство позволяет оценивать не только такие риски, которые имеются на предприятии, но и ту выгоду, которую можно получить благодаря внедрению технических, физических, программных и других средств и механизмов защиты. Подготовленные такие отчеты и графики представляют материал, который будет достаточным для принятия решений об изменении системы безопасности организации.
Из недостатков следует отметить:
1) этот метод можно применить, если потребуется провести оценку риска на программно-техническом уровне защиты, не учитывая административных и организационных факторов;
2) получаемые оценки рисков (математическое ожидание потерь) не исчерпывают понимание риска с системных позиций - метод не позволяет учитывать комплексный подход к информационной безопасности;
3) программное обеспечение RiskWatch существует только на английском языке. Очень высокая стоимость лицензии [2; 3; 6; 8].
Заключение
Важно отметить, что если частное облако находится в собственности организации и физически существует внутри ее юрисдикции, то возможно абстрагироваться от идеи облака и считать, что фирма его не использует. При использовании частного облака можно считать клиентом работников организации, а ее саму провайдером услуг. Исходя из особенностей природы частного облака, можно сказать, что оценка риска для данной модели не имеет сильных отличий от стандартной модели размещения данных. Таким образом, можно использовать существующие модели оценки рисков использования ИТ [2].
Заметим, что ни одна из моделей полностью не подходит для случая облачных вычислений. Т.к. ни в одной из них не учитывается специфика модели взаимодействия, присущая облачным средам. Эта специфика заключается в возможности удалённого доступа к предоставляемым сервисам. В связи с этим появляется необходимость рассматривать следующие возможные риски:
- неблагоприятные последствия неправильного управления данными;
- неоправданные расходы на обслуживание;
- финансовые или юридические проблемы поставщика;
- эксплуатационные проблемы или простои поставщика;
- проблемы восстановления данных и конфиденциальности;
- общие проблемы безопасности;
- атаки на систему извне.
В случае использования частного облака рассмотренные модели могут быть использованы для управления риском с внесением ряда поправок [5]. При использовании частного облака можно считать клиентом работников организации, а ее саму провайдером услуг. Однако к открытым и гибридным облачным структурам данные модели применить не получится, т.к. организация не имеет контроля над оборудованием. Эти методы могут служить базисом для создания новой модели, способной удовлетворить возникшую потребность в оценивании рисков от применения облачных сервисов.
Рецензенты:
Мицель А.А., д.т.н., профессор кафедры автоматизированных систем управления, Томский государственный университет систем управления и радиоэлектроники, г. Томск.
Сапожков С.Б., д.т.н., заведующий кафедрой естественно-научного образования, профессор, Юргинский технологический институт (филиал) национального исследовательского Томского политехнического университета, г. Юрга.
Библиографическая ссылка
Разумников С.В. АНАЛИЗ ВОЗМОЖНОСТИ ПРИМЕНЕНИЯ МЕТОДОВ OCTAVE, RISKWATCH, CRAMM ДЛЯ ОЦЕНКИ РИСКОВ ИТ ДЛЯ ОБЛАЧНЫХ СЕРВИСОВ // Современные проблемы науки и образования. – 2014. – № 1. ;URL: https://science-education.ru/ru/article/view?id=12197 (дата обращения: 21.11.2024).