Мы продолжаем серию публикаций, посвященную своду знаний по кибербезопасности - Cybersecurity Body of Knowledge (CyBOK). В Главе 2 данного свода знаний объясняются принципы оценки и управления киберрисками, описывается ряд методик оценки рисков и показывается, как и почему эффективное управление киберрисками позволяет обеспечивать кибербезопасность, а также обсуждается важность корректного реагирования на киберинциденты в случае, если реализацию риска не удалось предотвратить. Сегодня – вторая часть обзора Главы 2 CyBOK, в которой описываются принципы оценки и управления рисками.
Руслан Рахметов, Security Vision
Предыдущие главы и части:
Глава 2 часть 1
2.6. Принципы оценки и управления рисками.
2.6.1. Компонентный и системный взгляды на управление рисками.
Управление рисками может быть рассмотрено с позиции технических компонентов информационных систем (подход «снизу вверх», bottom up) и с позиции рассмотрения информационных систем в целом (подход «сверху вниз», top down). Главное отличие этих позиций в том, что компонентный подход сфокусирован на специфических рисках для отдельных компонентов систем (угрозы и уязвимости программного и аппаратного обеспечения, данных, персонала), а системный подход сфокусирован на больше на целях работы всех системы в целом - это требует обозначения высокоуровневого предназначения системы и последующего понимания работы всех подсистем и их взаимосвязей и взаимодействия.
Иерархия уровней абстракции позволяет понять, как компонентный и системный подходы к оценке риска дополняют друг друга. Цели и предназначение системы, потоки данных внутри системы, принципы управления системой, процессы и взаимодействие компонентов находятся на более высоком системном уровне. На более низком компонентном уровне находятся технические возможности, функционал, оборудование, компоненты системы и её физические характеристики (размеры, местоположение, окружение) - все они могут быть объектами вредоносных действий или событий. Системный подход позволяет лучше понять сложные связи между системами, подсистемами, компонентами и субкомпонентами, включая технологии, персонал и процессы, взаимосвязи которых могут быть достаточно сложными. Системный подход, являющийся более ресурсоемким по сравнению с компонентным подходом из-за выявления взаимосвязей и взаимодействий, необходим только в случае оценки рисков в действительно сложных системах. Там, где взаимосвязи и взаимозависимости менее сложны (например, в типовых офисных ИТ-инфраструктурах), применение компонентного подхода может быть более целесообразно.
Компонентный подход опирается на работу с отдельными активами, для которых понятен функционал и требования к их безопасности. Оценка риска на компонентном уровне более важна для рядовых сотрудников, которые заинтересованы в надежной работе всех компонентов системы в своей зоне ответственности. Оценка риска на системном уровне более важна для руководителей, которые заинтересованы в достижении заданных бизнес-целей системы в целом и не вдаются в подробности работы всех её компонентов. Задачей управления рисками становится работа со всеми заинтересованными лицами и на компонентном, и на системном уровнях.
Основные особенности и отличия компонентного и системного взглядов на управление рисками таковы:
· Компонентный подход больше подходит для анализа рисков отдельных компонентов системы, при декомпозиции небольших систем с понятными взаимосвязями между их компонентами, при работе на более низких уровнях абстракции, когда высокоуровневые цели и предназначение работы системы были уже согласованы руководителями.
· Системный подход подходит при оценке рисков несанкционированного доступа как следствия сложных взаимодействий между многими частями большой системы, при формировании высокоуровневых требований по кибербезопасности системы, при определении целей и задач системы с точки зрения различных групп заинтересованных лиц (бизнеса, юристов, безопасников и т.д.).
2.6.2. Составные части киберриска.
Для конструктивного обсуждения вопросов оценки и управления рисками важно определиться с основными понятиями:
· Уязвимость используется для атак на систему или некорректного использования системы, что может привести к нежелательным последствиям. Эксплуатация уязвимости может привести к негативному влиянию на процесс или систему. Уязвимости могут быть различных типов: технические (например, программный интерфейс, уязвимый для подачи некорректных входных данных), кадровые (нехватка кадров приводит к простою бизнеса), организационные (неправильно организованные внутренние процессы приводят к утечкам данных), юридические (штрафы за невыполнение требований законодательства) и т.д.
· Угроза - это субъект, событие или действие, которые обладают возможностью эксплуатации уязвимости. Угрозы также могут иметь различную социотехническую природу и причины возникновения - это могут быть хакеры, нелояльные или халатные работники, плохо спроектированное ПО, незрелый и непродуманный операционный процесс в компании и т.д.
· Вероятность выражает степень уверенности в том, что угроза сможет проэксплуатировать уязвимость, следствием чего станет нежелательный исход, негативно влияющий на систему и создаваемые ей бизнес-ценности. Вероятность может выражаться в качественных и количественных величинах.
· Воздействие - это результат эксплуатации уязвимостей угрозой, который негативно влияет на достижение целей. В системном подходе негативным эффектом будет, например, невозможность своевременного производства товара, а в компонентном подходе - выход из строя определенного производственного элемента.
2.6.3. Методы оценки и управления рисками.
Существует ряд методов, описанные в том числе в международных стандартах и рекомендациях, которые позволяют сформировать список рисков для приоритизации и обработки. В большинстве методик управления рисками есть некоторые общие этапы:
· Подготовка - формирование границ оценки риска, определение заинтересованных лиц, сбор информации;
· Оценка - анализ причин и последствий риска, разработка базы знаний рисков и способов их обработки;
· Характеризация - процесс принятия решения, оценка опасности и допустимости риска;
· Управление - выбор и согласование плана обработки рисков и способов его внедрения;
· Коммуникация, вовлечение и определение контекста являются сопутствующими элементами всех перечисленных этапов.
Например, в специальной публикации NIST SP 800-30 «Руководство по проведению оценок риска» описаны следующие этапы оценки риска:
1. Подготовка к оценке рисков:
1.1. Идентификация цели оценки рисков;
1.2. Идентификация области оценки рисков;
1.3. Идентификация специфичных предположений и ограничений;
1.4. Идентификация источников предварительной информации, источников угроз и уязвимостей;
1.5. Идентификация модели рисков, способа оценки рисков и подхода к анализу.
2. Проведение оценки рисков:
2.1. Идентификация и характеризация актуальных источников угроз;
2.2. Идентификация потенциальных событий угроз, релевантности этих событий, а также источников угроз;
2.3. Идентификация уязвимостей;
2.4. Определение вероятности того, что актуальные события угроз приведут к негативному влиянию;
2.5. Определение негативного влияния, порожденного источниками угроз;
2.6. Определение риска от реализации актуальных событий угроз.
3. Коммуницирование результатов оценки и передачу информации внутри организации:
3.1. Коммуницирование результатов оценки рисков лицам, принимающим решения, для реагирования на риски;
3.2. Передача заинтересованным лицам информации, касающейся рисков, выявленных в результате оценки.
4. Поддержание достигнутых результатов:
4.1. Проведение непрерывного мониторинга факторов риска;
4.2. Актуализация оценки рисков с использованием результатов процесса непрерывного мониторинга факторов риска.
В международном стандарте ISO/IEC 27005 «Руководство по управлению рисками информационной безопасности. Требования и руководства» перечислены следующие этапы управления рисками:
1. Определение контекста.
2. Оценка рисков:
2.1 Идентификация рисков (инвентаризация активов, угроз и имеющихся мер защиты, определение уязвимостей, выявление последствий реализации угроз);
2.2 Анализ рисков (с применением методов качественного или количественного анализа);
2.3 Оценка опасности рисков (сравнение полученных уровней рисков с критериями сравнения рисков и критериями принятия рисков).
3. Выбор варианта обработки рисков ИБ:
3.1. Модификация (минимизация) риска;
3.2. Сохранение (принятие) риска;
3.3. Избежание риска;
3.4. Передача риска.
4. Согласование рисков (сравнение величины остаточного риска с ранее определенным приемлемым уровнем риска).
5. Внедрение разработанного плана обработки рисков.
6. Непрерывный мониторинг и пересмотр рисков.
7. Поддержка и улучшение процесса управления рисками ИБ.
Кроме описанного стандарта ISO/IEC 27005 и серии публикаций NIST SP 800-39/37/30/137, авторы книги приводят также ряд других методологий по управлению рисками с применением компонентного подхода:
· Методология IRAM2 от Information Security Forum (ISF) предоставляется членам ISF за плату и требует наличие подготовленной команды риск-менеджеров. Она включает в себя оценку влияние рисков на бизнес с учетом угроз, уязвимостей, негативного воздействия.
· Методология FAIR (и Open FAIR) предлагает таксономию факторов риска и соответствующий фреймворк для их объединения. Рассматриваемая совокупность угроз может быть очень широкой, а методология подразумевает оценку частоты инцидентов и возможностей источников угроз с учетом мер защиты и ущерба от инцидентов. Методология поддерживает сценарную модель для формирования профилей ущерба и финансовую оценку инцидентов.
· Методология Octave Allegro ориентирована на операционные риски и практики ИБ, использует метод качественной оценки с ориентацией на достижение бизнес-целей, применяет сценарный анализ для выявления рисков и анализа угроз и негативного воздействия. Данная методика охватывает персонал, технологии и элементы физической безопасности, её можно применять внутри корпоративной риск-команды без привлечения внешних консультантов.
· Методология STRIDE-LM была разработана в Microsoft и разделяет угрозы на 6 категорий: обман (Spoofing), фальсификация (Tampering), отказ от авторства (Repudiation), разглашение информации (Information Disclosure), отказ в обслуживании (Denial of Service), повышение привилегий (Elevation of Privilege), горизонтальное перемещение (Lateral Movement). Данная методология может применяться даже небольшими внутренними командами для оценки рисков.
· Методология деревьев атак (Attack Trees) позволяет выстроить цепочку между конечной целью атакующего и промежуточными звеньями. Данный метод ориентирован на способах реализации атак, он подразумевает итеративную работу внутренней риск-команды с хорошей технической экспертизой.
Авторы публикации приводят также список методологий по управлению рисками с применением системного подхода:
· Методология STAMP (Systems-Theoretic Accident Model and Process, модель и процесс теоретических аварий в системах) - это группа методов, используемых для моделирования причин различных аварий и опасных ситуаций. Её преимуществом является возможность выявить риски, возникающие при взаимодействии подсистем.
· Методология TOGAF (The Open Group Architectural Framework, архитектурный фреймворк открытой группы) - это стандарт для разработки корпоративных архитектур с поддержкой компонентного и системного подходов для управления рисками. Методология охватывает все бизнес-действия и возможности, информацию, технологии, способы управления компанией, с возможностью расширения на партнеров, поставщиков, покупателей. В ней используется метод качественной оценки рисков и учитывается структурированная архитектурная модель компании.
· Моделирование зависимостей (Open Dependency Modelling) - это метод моделирования рисков с подходом «сверху вниз», с фокусом на цели работы и зависимости системы и компании. Преимуществом данной методики является оценка взаимозависимостей между абстрактными верхнеуровневыми целями и обеспечивающими их достижение бизнес-процессами.
· Методология SABSA (Sherwood Applied Business Security Architecture, прикладная архитектура бизнес-безопасности Шервуда) заключается в работе с рисками при декомпозиции бизнес-процессов на различных архитектурных уровнях - от высокоуровневых возможностей к логическим и физическим аспектам и компонентам применяемых технологий.
2.6.4. Управление уязвимостями.
Одним из ключевых результатов оценки рисков будет выявление уязвимостей в программном обеспечении. Известно, что много успешных кибератак происходит из-за несовременной установки обновлений безопасности (патчей), поэтому важно минимизировать временной разрыв между выходом патчей и их применением в инфраструктуре. Для управления уязвимостями следует использовать средства автоматизации, такие как системы Vulnerability Management (VM), которые сканируют инфраструктуру, инвентаризируют активы, обнаруживают уязвимости и предоставляют инструменты для их устранения. Работа с уязвимостями должна быть выстроена по принципам риск-менеджмента - с принятием обоснованного решения по способу обработки каждой уязвимости (установка патча, переконфигурирование), с установкой приоритета и сроков. Если обновления безопасности не могут быть применены, то это должно быть обосновано, задокументировано и согласовано владельцем риска системы, на которой была выявлена эта уязвимость. При приоритизации уязвимостей важно учитывать их свойства - влияние на системы и бизнес-процессы, легкость эксплуатации уязвимости, расположение системы в инфраструктуре (доступна ли она из интернета).
2.6.5. Оценка и управление рисками в киберфизических системах и в OT-инфраструктурах.
В стандартных офисных ИТ-инфраструктурах управление рисками сосредоточено на обеспечении целостности, конфиденциальности и доступности, но в киберфизических системах и в OT-инфраструктурах (Operational Technology) более важно обеспечивать их надежность и безопасность людей и окружающей среды. Для оценки рисков в таких системах предпочтительнее использовать системный подход, который позволяет абстрагироваться от отдельных компонентов системы и сосредоточиться на главных целях (избежание смертей или вреда здоровью, соответствие законодательству). Следует также оценивать риски объединения (конвергенции) сетей IT и OT, что встречается всё чаще из-за роста уровня цифровизации в промышленности и удобства удаленного контроля АСУТП. Кроме того, важно защищать IIoT/IoT-устройства, которые могут также послужить точкой входа внешних атакующих в OT-среду. В контексте управления уязвимостями важно оценивать риски автоматизированного сканирования OT-инфраструктуры и вероятности последующей остановки оборудования и всего технологического процесса.
2.6.6. Метрики кибербезопасности.
При оценке степени защищенности и уровня киберрисков часто требуется какое-либо количественное или качественное характеризующее значение. Авторы книги указывают, что хорошие метрики должны быть:
· Объективно измеряемыми, без субъективных критериев;
· Легкими в сборе, предпочтительно - автоматизированно;
· Выраженными в абсолютных величинах или в процентах, а не в качественных значениях (при этом можно соотносить качественные значения с количественными, согласовав пороговые значения);
· Выраженными в понятных единицах измерения (в часах/минутах, в количестве единиц, в рублях/валюте);
· Специфичными, релевантными и понятными руководителям, которые их будут читать.
2.7. Непрерывность бизнеса: планирование реагирования на инциденты и восстановления.
Несмотря на предпринимаемые меры защиты, любая компания может быть взломана, поэтому важно заранее готовиться к реагированию на киберинциденты и последующему восстановлению инфраструктуры и процессов. Тенденция к сокрытию фактов взлома во избежание репутационного ущерба характерна для многих компаний, однако, обмен опытом может помочь избежать другим компаниям аналогичных атак в будущем.
Международный стандарт ISO/IEC 27035-1 «Управление инцидентами информационной безопасности» определяет принципы управления киберинцидентами. Он расширяет подход стандарта ISO/IEC 27005 и включает следующие шаги для реагирования на инциденты ИБ:
1. Планирование и подготовка, включая формирование политики управления киберинцидентами и подготовку команды реагирования;
2. Выявление и учет: наблюдение, мониторинг, выявление и учет киберинцидентов;
3. Оценка и принятие решения: определение наличия инцидента и его опасности, выполнение шагов по его обработке;
4. Реагирование, включая форензик-анализ, установку обновлений, сдерживание и устранение активной угрозы;
5. Изучение: получение опыта и использование его для улучшения защиты систем в целях снижения вероятности возникновения инцидентов ИБ в будущем.
Центр национальной компьютерной безопасности Великобритании (NCSC) предлагает следующие 10 шагов для выстраивания процесса управления киберинцидентами:
1. Создание возможностей для реагирования на инциденты, включая финансовое и ресурсное обеспечение;
2. Тренировки, получение опыта в реагировании на инциденты;
3. Назначение ролей и ответственных;
4. Восстановление с контролем того, что важные данные физически изолированы от системы и действительно могут быть восстановлены из бэкапа;
5. Тестирование: проверка сценариев реагирования и восстановления;
6. Отчетность: информация об инцидентах ИБ должна быть передана заинтересованным внутренним (для улучшения процесса риск-менеджмента и совершенствования мер защиты) и внешним (для соблюдения требований законодательства) лицам;
7. Сбор доказательств: сбор и сохранение цифровых доказательств инцидента могут быть необходимы для дальнейших действий в правовом поле или для глубокого форензик-анализа инцидента;
8. Совершенствование: протоколирование выполненных при реагировании действий поможет выявить недостатки в процессе реагирования или в сценариях реагирования;
9. Обучение персонала: бдительность сотрудников очень важна для выявления инцидента или подозрительных событий;
10. Взаимодействие с правоохранительными органами для борьбы с киберпреступниками.
