Аннотация: В лекции приводятся краткие описания ряда распространенных методик анализа рисков и программных продуктов оценки рисков. Среди наиболее распространенных методик анализируются: CRAMM; FRAP; OCTAVE; Risk Watch; Microsoft.
Ниже приведены краткие описания ряда распространенных методик анализа рисков. Их можно разделить на:
- методики, использующие оценку риска на качественном уровне (например, по шкале «высокий», «средний», «низкий»). К таким методикам, в частности, относится FRAP;
- количественные методики (риск оценивается через числовое значение, например размер ожидаемых годовых потерь). К этому классу относится методика RiskWatch;
- методики, использующие смешанные оценки (такой подход используется в CRAMM, методике Microsoft и т.д.).
Методика CRAMM
Это одна из первых методик анализа рисков в сфере ИБ — работа над ней была начата в середине 80-х гг. центральным агентством по компьютерам и телекоммуникациям (CCTA) Великобритании.
Управление рисками. Семь простых шагов
В основе метода CRAMM лежит комплексный подход к оценке рисков, сочетающий количественные и качественные методы анализа. Метод является универсальным и подходит как для крупных, так и для малых организаций, как правительственного, так и коммерческого сектора. Версии программного обеспечения CRAMM, ориентированные на разные типы организаций, отличаются друг от друга своими базами знаний (profiles). Для коммерческих организаций имеется Коммерческий профиль (Commercial Profile), для правительственных организаций — Правительственный профиль ( Government profile). Правительственный вариант профиля, также позволяет проводить аудит на соответствие требованиям американского стандарта ITSEC (» Оранжевая книга «).
Исследование ИБ системы с помощью СRAMM проводится в три стадии [9,10,11].
На первой стадии анализируется все, что касается идентификации и определения ценности ресурсов системы. Она начинается с решения задачи определения границ исследуемой системы: собираются сведения о конфигурации системы и о том, кто отвечает за физические и программные ресурсы, кто входит в число пользователей системы, как они ее применяют или будут применять.
Проводится идентификация ресурсов: физических, программных и информационных, содержащихся внутри границ системы. Каждый ресурс необходимо отнести к одному из предопределенных классов. Затем строится модель информационной системы с позиции ИБ. Для каждого информационного процесса, имеющего, по мнению пользователя, самостоятельное значение и называемого пользовательским сервисом, строится дерево связей используемых ресурсов. Построенная модель позволяет выделить критичные элементы.
Ценность физических ресурсов в CRAMM определяется стоимостью их восстановления в случае разрушения.
Ценность данных и программного обеспечения определяется в следующих ситуациях:
- недоступность ресурса в течение определенного периода времени;
- разрушение ресурса — потеря информации, полученной со времени последнего резервного копирования, или ее полное разрушение;
- нарушение конфиденциальности в случаях несанкционированного доступа штатных сотрудников или посторонних лиц;
- модификация — рассматривается для случаев мелких ошибок персонала (ошибки ввода), программных ошибок, преднамеренных ошибок;
- ошибки, связанные с передачей информации: отказ от доставки, недоставка информации, доставка по неверному адресу.
Для оценки возможного ущерба CRAMM рекомендует использовать следующие параметры:
Система управления рисками за 5 шагов
- ущерб репутации организации;
- нарушение действующего законодательства;
- ущерб для здоровья персонала;
- ущерб, связанный с разглашением персональных данных отдельных лиц;
- финансовые потери от разглашения информации;
- финансовые потери, связанные с восстановлением ресурсов;
- потери, связанные с невозможностью выполнения обязательств;
- дезорганизация деятельности.
Для данных и программного обеспечения выбираются применимые к данной ИС критерии, дается оценка ущерба по шкале со значениями от 1 до 10.
В описаниях CRAMM в качестве примера приводится в [9] такая шкала оценки по критерию «Финансовые потери, связанные с восстановлением ресурсов»:
- 2 балла — менее $1000;
- 6 баллов — от $1000 до $10 000;
- 8 баллов — от $10 000 до $100 000;
- 10 баллов — свыше $100 000.
При низкой оценке по всем используемым критериям (3 балла и ниже) считается, что рассматриваемая система требует базового уровня защиты (для этого уровня не требуется подробной оценки угроз ИБ) и вторая стадия исследования пропускается.
На второй стадии рассматривается все, что относится к идентификации и оценке уровней угроз для групп ресурсов и их уязвимостей. В конце стадии заказчик получает идентифицированные и оцененные уровни рисков для своей системы. На этой стадии оцениваются зависимость пользовательских сервисов от определенных групп ресурсов и существующий уровень угроз и уязвимостей, вычисляются уровни рисков и анализируются результаты.
Ресурсы группируются по типам угроз и уязвимостей. Например, в случае существования угрозы пожара или кражи в качестве группы ресурсов разумно рассмотреть все ресурсы, находящиеся в одном месте (серверный зал, комната средств связи и т. д.). Оценка уровней угроз и уязвимостей производится на основе исследования косвенных факторов.
Программное обеспечение CRAMM для каждой группы ресурсов и каждого из 36 типов угроз генерирует список вопросов, допускающих однозначный ответ. Уровень угроз оценивается, в зависимости от ответов, как очень высокий, высокий, средний, низкий и очень низкий. Уровень уязвимости оценивается, в зависимости от ответов, как высокий, средний и низкий.
На основе этой информации рассчитываются уровни рисков в дискретной шкале с градациями от 1 до 7. Полученные уровни угроз, уязвимостей и рисков анализируются и согласовываются с заказчиком.
CRAMM объединяет угрозы и уязвимости в матрице риска. Рассмотрим, как получается эта матрица , и что каждый из уровней риска означает.
Основной подход, для решения этой проблемы состоит в рассмотрении [12]:
- уровня угрозы (шкала приведена в табл. 4.1);
- уровня уязвимости (шкала приведена в табл. 4.2);
- размера ожидаемых финансовых потерь (пример на рис. 4.1).
| инцидент происходит в среднем, не чаще, чем каждые 10 лет | очень низкий |
| инцидент происходит в среднем один раз в 3 года | низкий |
| инцидент происходит в среднем раз в год | средний |
| инцидент происходит в среднем один раз в четыре месяца | высокий |
| инцидент происходит в среднем раз в месяц | очень высокий |
| В случае возникновения инцидента, вероятность развития событий по наихудшему сценарию меньше 0,33 | низкий |
| В случае возникновения инцидента, вероятность развития событий по наихудшему сценарию от 0,33 до 0,66 | средний |
| В случае возникновения инцидента, вероятность развития событий по наихудшему сценарию выше 0,66 | высокий |
Исходя из оценок стоимости ресурсов защищаемой ИС, оценок угроз и уязвимостей, определяются «ожидаемые годовые потери». На рис. 4.1 приведен пример матрицы оценки ожидаемый потерь [12]. В ней второй столбец слева содержит значения стоимости ресурса, верхняя строка заголовка таблицы — оценку частоты возникновения угрозы в течение года (уровня угрозы), нижняя строка заголовка — оценку вероятности успеха реализации угрозы (уровня уязвимости).
Рис. 4.1. Матрица ожидаемых годовых потерь
Значения ожидаемых годовых потерь (англ. Annual Loss of Expectancy ) переводятся в CRAMM в баллы, показывающие уровень риска, согласно шкале, представленной на рис. 4.2 (в этом примере размер потерь приводится в фунтах стерлингов).
Рис. 4.2. Шкала оценки уровня рисков
В соответствии с приведенной ниже матрицей, выводится оценка риска ( рис. 4.3)
Рис. 4.3. Матрица оценки риска
Третья стадия исследования заключается в поиске адекватных контрмер. По существу, это поиск варианта системы безопасности, наилучшим образом удовлетворяющей требованиям заказчика.
На этой стадии CRAMM генерирует несколько вариантов мер противодействия, адекватных выявленным рискам и их уровням. Контрмеры можно объединить в три категории: около 300 рекомендаций общего плана; более 1000 конкретных рекомендаций; около 900 примеров того, как можно организовать защиту в данной ситуации.
Таким образом, CRAMM — пример методики расчета, при которой первоначальные оценки даются на качественном уровне, и потом производится переход к количественной оценке (в баллах).
Методика FRAP
Методика » Facilitated Risk Analysis Process (FRAP)» предлагаемая компанией Peltier and Associates ( сайт в Интернет http://www.peltierassociates.com/) разработана Томасом Пелтиером (Thomas R. Peltier) и опубликована в [13] (фрагменты данной книги доступны на сайте, приведенное ниже описание построено на их основе). В методике, обеспечение ИБ ИС предлагается рассматривать в рамках процесса управления рисками. Управление рисками в сфере ИБ — процесс, позволяющий компаниям найти баланс между затратами средств и сил на средства защиты и получаемым эффектом.
Управление рисками должно начинаться с оценки рисков: должным образом оформленные результаты оценки станут основой для принятия решений в области повышения безопасности системы.
После завершения оценки, проводится анализ соотношения затрат и получаемого эффекта (англ. cost/benefit analysis ), который позволяет определить те средства защиты, которые нужны, для снижения риска до приемлемого уровня.
Ниже приведены основные этапы оценки рисков. Данный список во многом повторяет аналогичный перечень из других методик, но во FRAP более подробно раскрываются пути получения данных о системе и ее уязвимостях.
- Определение защищаемых активов производится с использованием опросных листов, изучения документации на систему, использования инструментов автоматизированного анализа (сканирования) сетей.
- Идентификация угроз . При составлении списка угроз могут использоваться разные подходы:
- заранее подготовленные экспертами перечни угроз ( checklists ), из которых выбираются актуальные для данной системы;
- анализ статистики происшествий в данной ИС и в подобных ей — оценивается частота их возникновения; по ряду угроз, например, угрозе возникновения пожара, подобную статистику можно получить у соответствующих государственных организаций;
- «мозговой штурм», проводимый сотрудниками компании.
Оценка производится для вероятности возникновения угрозы и ущерба от нее по следующим шкалам.
Вероятность (Probability):
- Высокая (High Probability) — очень вероятно, что угроза реализуется в течение следующего года;
- Средняя (Medium Probability) — возможно угроза реализуется в течение следующего года;
- Низкая (Low Probability) — маловероятно, что угроза реализуется в течение следующего года.
Ущерб ( Impact ) — мера величины потерь или вреда, наносимого активу:
- Высокий (High Impact ): остановка критически важных бизнес-подразделений, которая приводит к существенному ущербу для бизнеса, потере имиджа или неполучению существенной прибыли;
- Средний (Medium Impact ): кратковременное прерывание работы критических процессов или систем, которое приводит к ограниченным финансовым потерям в одном бизнес-подразделении;
- Низкий (Low Impact ): перерыв в работе, не вызывающий ощутимых финансовых потерь.
Оценка определяется в соответствии с правилом, задаваемым матрицей рисков, изображенной на рис. 4.4. Полученная оценка уровня риска может интерпретироваться следующим образом:
- уровень A — связанные с риском действия (например, внедрение СЗИ) должны быть выполнены немедленно и в обязательном порядке;
- уровень B — связанные с риском действия должны быть предприняты;
- уровень C — требуется мониторинг ситуации (но непосредственных мер по противодействию угрозе принимать, возможно, не надо);
- уровень D -никаких действий в данный момент предпринимать не требуется.
Рис. 4.4. Матрица рисков FRAP
- стоимость реализации проекта, включая дополнительное программное и аппаратное обеспечение;
- снижение эффективности выполнения системой своих основных задач;
- внедрение дополнительных политик и процедур для поддержания средства;
- затраты на найм дополнительного персонала или переобучение имеющегося.
Источник: intuit.ru
ПО для управления рисками
Текущий бизнес-ландшафт в высшей степени непредсказуем и чрезвычайно конкурентен. Большие и малые организации имеют дело с множеством внутренних и внешних рисков, и поиск эффективных способов их обнаружения, оценки и смягчения стал ключевым элементом в достижении последовательного роста бизнеса.
По данным всемирной американской консалтинговой компании McKinsey https://visuresolutions.com/ru/risk-management-software» target=»_blank»]visuresolutions.com[/mask_link]
Управление рисками: рабочие методы контроля над проектом
Кто не рискует, тот не запускает проектов. Ведь создавать что-то новое — это всегда небезопасно. Всегда есть шанс, что изначальный план предусмотрел не все, потребуется больше ресурсов для достижения результата или появятся новые факторы извне.
Поэтому в управление проектами всегда должна входить работа с рисками. Поиск их причин и вариантов предотвращения. Иначе одно непредвиденное обстоятельство может погубить весь ваш проект.
Риски: определение и классификация
Для начала разберемся с терминологией.
Риск — это возможность возникновения события, которое окажет негативное влияние на ход проекта или компанию.
Обратите внимание, что речь не про само событие, а о вероятности того, что оно случится. Ведь хоть закон Мерфи и гласит, что не так пойдет все, что может пойти не так, на практике все не так печально. Однако при этом ни один проект не может обойтись без рисков. Просто события, которых мы опасаемся, не случаются.
Какие бывают риски?
На самом деле, на этот вопрос нет однозначного ответа. Ведь риски бывают любые, вот лишь самые универсальные из них:
- Производственный риск, когда производство или команда не справляется с поставленными задачами. Например, из-за плохого планирования, неверного подбора персонала или некорректного использования ресурсов.
- Естественные риски, например, стихийные бедствия. Сложно вести проект, если у всей команды нет света.
- Партнерские риски: возможность того, что контрагент не сможет выполнить обязательства: поставить материал или своевременно расплатиться.
- Политические риски связаны с изменением законодательства. Скажем, вы разрабатываете приложение для такси, а в стране запретили машины.
- Валютные риски связаны со скачками курсов валют. Наиболее подвержены ему те компании, где нужно закупать материалы или оборудование за границей. Чтобы их избежать, можно использовать фиксированный курс и мультивалютность в вашей системе финансового учета.
«Риски есть всегда, но вот какие — зависит от проекта. Есть универсальные, например, шанс, что конкурент выпустит что-то раньше тебя. Риск, что твой продукт не будет востребован, не окупится, что команда не уложится в срок. Или что используемые технологии, программы, оборудование для разработки проекта станут резко недоступны, так тоже бывает».
Анастасия Дорошенко, ведущий продакт-менеджер Аспро
Какие-то риски актуальны для всех, другие — частные. Классифицировать их можно бесконечно, поскольку для каждой сферы деятельности они будут свои. Поэтому важно выделить наиболее релевантные для вашего проекта. Например, если ваша команда не зависит от других людей, то партнерским риском можно пренебречь.
Черные лебеди
Отдельно при классификации рисков выделяют «черных лебедей», маловероятные и труднопрогнозируемые события, которые имеют значительные последствия. Это необязательно что-то плохое. Например, распространение интернета считается «черным лебедем», поскольку подпадает под критерии, которые выделил автор теории, Нассим Николас Талеб:
- Событие было неожиданным для эксперта.
- Последствия у события внушительные.
- Ретроспективно кажется, что предсказать событие было возможно.
И хотя считается, что глобализация повышает шанс появления «черных лебедей», отыскивать и готовиться к ним смысла нет. В самом определении указано, что для эксперта такой риск непредсказуем. Скажем, ваш главный разработчик выиграет в лотерею и уйдет с работы. Да, вы видели его пару раз покупающим билеты, но каков был шанс?
В управлении проектами нужно учитывать реалистичные сценарии, а не один на миллион. А подготовка замены разработчику отняла бы слишком много ресурсов и ухудшила отношение с ним.
Впрочем, последствия этого «черного лебедя» могла смягчить база знаний, где команда бы хранила всю документацию по проекту. Так даже уход ключевого сотрудника не заставит вас свернуть работу.
Определение рисков
Чтобы определить, каким рискам подвержен проект, нужно заранее провести аналитику. Начать стоит с анализа документов по проекту: плана, контрактов, технического задания. Дополнительно можно проанализировать конкурентов и проблемы, с которыми они сталкивались. Если есть возможность, то стоит использовать опыт из предыдущих проектов команды.
«Да, стоит начать с предыдущего опыта, если он есть. Вспомнить, какие там были трудности и переложить их на новый проект. Потом попытаться самим накидать возможные риски: написать что-то универсальное: оттолкнуться от конкурента или опереться на специфику проекта. Например, законодательство может измениться, придется подстраиваться. Анализ рынка поможет выявить возможные возражения потребителей».
Анастасия Дорошенко, ведущий продакт-менеджер Аспро
Для дальнейшей идентификации рисков потребуется использовать методы сбора информации. Привлеките команду к этому процессу, чтобы получить более полный взгляд на возможные проблемы. Можно также добавить в эту группу несколько человек извне, чтобы получить новую перспективу.
Мозговой штурм
Самый простой подход — это собрать всю команду и устроить мозговой штурм. Когда ваша цель — сгенерировать как можно больше разных идей на поставленную задачу. Для поиска рисков можно использовать метод обратного мозгового штурма и спросить: «Что мы можем сделать, чтобы провалиться?». Такой вопрос изначально разряжает обстановку и помогает мыслить нестандартно.
В ходе мозгового штурма важно:
- Генерировать максимум идей, даже самых бредовых.
- Не критиковать других.
- Развивать не только свои, но и чужие идеи.
- Дать всем высказаться, не перебивать. У штурма должна быть структура и все должны быть услышаны.
- Результаты необходимо фиксировать.
Задача состоит не в том, чтобы придумать одну идеальную идею, а набросать сразу и много. На этапе обсуждения идей важно, чтобы руководитель смог направить беседу в нужное русло. Ведь докручивать «черных лебедей» интереснее, чем что-то реалистичное, но пользы от этого нет.
Частично эту проблему может решить теневой мозговой штурм, где команда делится на три группы: одна генерирует идеи, вторая их оценивает, а третья наблюдает и фиксирует результаты. Так «эксперты» смогут привнести рациональности в креатив.
Фрирайтинг
Если вы еще не начали проект, не набрали команду, а риски хочется оценить, есть вид мозгового штурма на одну персону. Фрирайтинг — это процесс непрерывного написания текста с целью ответить на какой-то вопрос, решить задачу. Главная фишка в том, чтобы писать так быстро, как получается. Неважно, насколько грамотно или сколько там опечаток. Вы просто фиксируете свои мысли на бумаге и не обдумываете их.
Сессия фрирайтинга длится порядка 15 минут, после чего нужно изучить текст, подчеркнуть интересные мысли или сформулировать новые важные вопросы. Повторять можно, пока не найдете достаточное количество ответов.
То есть вы задаетесь вопросом: «Какие риски есть у нашего проекта?» и начинаете писать все, что приходит в голову. Из-за высокой скорости письма у вас отключается внутренний редактор, который отметает большинство идей на ранних этапах.
В ходе фрирайтинга соблюдаются все правила мозгового штурма: всех участников слышат, никого не критикуют, идеи развивают, а результаты фиксируют.
Метод Дельфи
Метод Дельфи позволяет идентифицировать и оценить риски для проекта. Для этого потребуется собрать две группы: эксперты и аналитики. Сам процесс напоминает мозговой штурм, но при этом анонимен и имеет более четкую структуру:
- Составление опросника для экспертов. Сюда входят вопросы о внешних, внутренних, политических рисках. Список можно составить в формате мозгового штурма.
- Опрос экспертов на заданную тему.
- Анализ результатов опроса, их обобщение. От самых редких результатов предлагают отказаться. Опросник дополняется более конкретными вопросами.
- Опросник возвращается к экспертам для их дальнейших комментариев. Они могут согласиться убрать маловероятные риски или наоборот.
- Цикл передачи результата между группами продолжается, пока не будет достигнут консенсус.
Метод Дельфи позволяет сфокусироваться на самых важных рисках, отсеивая излишние опасения. Однако всегда есть шанс упустить какой-то редкий риск.
Стоит отметить, что метод Дельфи немного сложнее мозгового штурма, поскольку требует более тщательной подготовки, в особенности разработки опросника. Также для эффективного выявления рисков нужны люди с конкретными компетенциями.
SWOT-анализ
SWOT уже содержит в себе угрозы (threats), которые отобразят риски. Может показаться, что остальные квадраты нам не нужны, но это не так. Они помогают видеть полную картину, наталкивают команду на новые мысли.
Но самое главное, если задать вопрос: «Почему мы выделяем эту угрозу? Какие слабые стороны нашего проекта позволят ей случиться?», можно найти не только риск, но и его источник.
Реестр рисков и оценка их важности
Неважно, каким путем вы получили результаты, в итоге из них должен сформироваться список. В нем мы описываем причины и эффект события. У каждого риска есть источник, и найти его — это первоочередная задача.
Риск
Ведущий разработчик выиграет в лотерею.
Осенью начнется сезон простуды, периодически сотрудники будут выбывать.
Причина
Ему повезло, а нам нет.
Эффект
Срочно придется искать нового разработчика, возможно, придется переделывать продукт с нуля. Разработка сильно замедлится.
Если для получения этого списка вы использовали метод Дельфи, то ничего больше делать не нужно. В вашем реестре остались только важные угрозы. В остальных случаях пока нет пользы от списка рисков, картина не становится ясней. Чтобы понять, к чему готовиться, нужно дать каждому событию оценку. Для этого попросите экспертов оценить вероятность и влияние на проект каждого риска по шкале от 1 до 10.
На основе этих значений можно рассчитать важность события. Формула простая:
Важность риска = Вероятность x Влияние
Получится уже вот такая таблица. Как мы видим, выигрыш разработчика в лотерею хоть и повлияет на проект, но осенние простуды важнее.
Риск
Ведущий разработчик выиграет в лотерею.
Осенью начнется сезон простуды, периодически сотрудники будут выбывать.
Причина
Ему повезло, а нам нет.
Эффект
Срочно придется искать нового разработчика, возможно, придется переделывать продукт с нуля. Разработка сильно замедлится.
Вероятность
Влияние на проект
Важность
Необходимо выделить события с большими значениями и составить из них реестр рисков. По сути, шортлист из события, куда попадают только самые важные возможные исходы. Собираем табличку, сохраняем все значения и идем дальше.
Методы риск-менеджмента
Управление рисками состоит из 4 этапов:
- Идентификация: выявляем риски, которые могут нам помешать.
- Анализ: определяем влияние и опасность событий для проекта.
- Планирование: просчитываем сценарий наперед, думаем, что можно сделать в каждой конкретной ситуации.
- Мониторинг: поддерживаем реестр рисков актуальным и следим, чтобы проект продвигался согласно плану.
К этому моменту мы уже выявили риски и проанализировали. Другими словами, нагенерировали себе целый список проблем. Что же с ними делать?
PMBoK советует использовать 4 стратегии управления рисками:
- Передать. Ответственность можно переложить на кого-то еще. Например, страховую компанию или партнера. Стратегия подходит, когда невозможно повлиять на риск, но есть на кого переложить ответственность.
- Принимать. То есть готовиться к тому, что это произойдет, и понимать, что избежать этого невозможно. Стратегия подойдет, когда на риск повлиять невозможно и переложить ответственность не на кого. Поэтому закладываем под это резерв в бюджете.
- Снижать. На этот риск команда может повлиять, но лишь частично. Поэтому делаем все, что можем, чтобы событие не случилось или не ударило по проекту так сильно.
- Избегать. Самый кардинальный способ, подразумевает крупные изменения в проекте. Например, релокация всей команды в другую страну. Имеет смысл, если вероятность и влияние исхода высокие, а остальные стратегии невозможны. Снизить риск нельзя, передать некому, а если его принять, то проект провалится.
Чтобы понять, как работать с каждым риском, нам нужно понимать, какой ущерб он нанесет проекту. Самый простой способ — взять значение важности из нашей таблички. Похожий вариант — спрогнозировать финансовые потери от риска и затем умножить его на вероятность.
Другой популярный подход используют, когда у события есть несколько исходов. Например, мы потеряем 15 рублей с вероятностью 75% или 100 с вероятностью 15. Так для сравнения нескольких рисков можно использовать такую формулу:
То есть тоже умножаем вероятность на потери, но при этом суммируем результаты нескольких исходов.
Для примера мы все же используем показатель важности из нашей таблицы. Стратегии управления рисками, конечно, зависят от конкретного события, но можно оттолкнуться от такого графика:
На нем видно, что риски с малой важностью можно принять или передать, критических необходимо избегать, а все, что между — постараться снизить. На основе этого мы можем внести стратегию и конкретный план действий.
Риск
В правительстве рассматривают законопроект о запрете приложений вроде нашего.
Конкурент выпустит продукт на рынок быстрее нас.
Осенью начнется сезон простуды, периодически сотрудники будут выбывать.
Ведущий разработчик выиграет в лотерею.
Причина