Роль корпорации Майкрософт в управлении рисками
advertisement
Группа разработки решений Майкрософт по безопасности и соответствию регулятивным нормам и Центр Microsoft Security Center of Excellence Руководство по управлению рисками безопасности © Корпорация Майкрософт, 2006. На данную работу распространяются требования указания авторства и некоммерческого использования, предусмотренные лицензией Creative Commons. Чтобы ознакомиться с текстом этой лицензии, посетите веб-страницу организации http://creativecommons.org/licenses/by-nc/2.5/ либо направьте письмо по адресу: Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. Руководство по управлению рисками безопасности iii Оглавление Глава 1. Обзор руководства по управлению рисками безопасности ........... 1 Основные положения ..................................................................................... 1 Проблемы, вызываемые средой.................................................................... 1 Лучший способ ........................................................................................... 1 Роль корпорации Майкрософт в управлении рисками безопасности ................ 2 Обзор руководства ...................................................................................... 2 Критические факторы успеха ....................................................................... 3 Дальнейшие шаги ....................................................................................... 3 Для кого предназначено это руководство ........................................................ 3 Вопросы, рассмотренные в этом руководстве ................................................... 4 Обзор содержания....................................................................................... 4 Глава 1. Обзор руководства по управлению рисками безопасности ........... 4 Глава 2. Обзор рекомендаций по управлению рисками безопасности......................................................................................... 4 Глава 3. Обзор управления рисками безопасности ................................... 4 Глава 4. Оценка рисков ......................................................................... 5 Глава 5. Поддержка принятия решений ................................................... 5 Глава 6. Реализация контроля и оценка эффективности программы .......... 5 Приложение А. Оперативная оценка рисков ............................................ 6 Приложение Б. Типичные активы информационных систем ...................... 6 Приложение В. Типичные угрозы ............................................................ 6 Приложение Г. Уязвимости ..................................................................... 6 Средства и шаблоны ................................................................................... 6 Условия успешной реализации........................................................................ 7 Поддержка руководства............................................................................... 7 Полный перечень заинтересованных лиц для процесса управления рисками ...................................................................................................... 8 Зрелость организации с точки зрения управления рисками ............................ 8 Атмосфера открытого обмена информацией .................................................. 8 Дух командной работы ................................................................................ 9 Целостное представление организации ........................................................ 9 Распределение полномочий в процессе ........................................................ 9 Термины и определения ................................................................................. 9 Условные обозначения ..................................................................................11 Получение поддержки по данному руководству ..............................................11 Дополнительные сведения .............................................................................11 Глава 2. Обзор рекомендаций по управлению рисками безопасности ............................................................................................... 13 Сравнение подходов к управлению рисками ...................................................13 Реактивный подход ....................................................................................13 Проактивный подход ..................................................................................16 Подходы к приоритизации рисков ..................................................................17 Количественная оценка рисков ...................................................................17 Подробное рассмотрение количественного подхода ................................18 iv Содержание Качественная оценка рисков ......................................................................21 Сравнение двух подходов ...........................................................................22 Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт..................................................................................................23 Глава 3. Обзор управления рисками безопасности .................................... 25 Четыре этапа процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт ..............................................................................25 Уровень усилий ....................................................................................27 Основа процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт .....................................................................28 Различия между управлением рисками и оценкой рисков .............................28 Информирование о рисках ..........................................................................29 Определение уровня зрелости используемой в организации системы управления рисками...................................................................................31 Самостоятельная оценка уровня зрелости системы управления рисками в организации .........................................................................33 Распределение ролей и обязанностей ..........................................................35 Создание группы управления рисками безопасности ..............................37 Заключение ..................................................................................................38 Глава 4. Оценка рисков ............................................................................... 39 Обзор...........................................................................................................39 Входные данные, необходимые для оценки рисков ......................................41 Участники этапа оценки рисков ..................................................................41 Средства оценки рисков .............................................................................41 Результаты этапа оценки рисков .................................................................42 Планирование ..............................................................................................42 Согласование.............................................................................................42 Определение сферы действия .....................................................................43 Одобрение заинтересованных лиц...............................................................43 Подготовка к внедрению: формирование ожиданий .....................................44 Преодоление субъективности ......................................................................44 Координированный сбор данных ....................................................................44 Условия успешного сбора данных ...............................................................45 Получение поддержки ..........................................................................45 Обсуждения и опросы ...........................................................................45 Обеспечение доброжелательности .........................................................46 Подготовка к обсуждению рисков................................................................46 Определение входных данных для оценки рисков ..................................46 Выявление и классификация активов ..........................................................47 Активы.................................................................................................47 Классы активов ....................................................................................48 Упорядочивание информации о рисках ........................................................50 Упорядочивание по уровням многоуровневой защиты .............................50 Определение угроз и уязвимостей .........................................................51 Оценка подверженности актива воздействию .........................................52 Оценка вероятности угроз .....................................................................53 Руководство по управлению рисками безопасности v Проведение обсуждений рисков ..................................................................53 Подготовка встречи ..............................................................................54 Проведение обсуждений .............................................................................54 Задача 1. Определение активов организации и сценариев ......................55 Задача 2. Выявление угроз ...................................................................56 Задача 3. Выявление уязвимостей .........................................................56 Задача 4. Оценка подверженности актива воздействию ..........................57 Задача 5. Выявление существующих элементов контроля и вероятности взлома ..............................................................................57 Подведение итогов обсуждения рисков ..................................................57 Определение формулировок влияний ..........................................................58 Сбор данных: подведение итогов ................................................................59 Приоритизация рисков ..................................................................................60 Основные задачи и этапы ...........................................................................61 Подготовка к выполнению ..........................................................................62 Приоритизация рисков безопасности ...........................................................63 Приоритизация рисков на обобщенном уровне .......................................63 Приоритизация рисков на уровне детализации .......................................67 Количественная оценка рисков ...................................................................75 Задача 1. Сопоставление денежной стоимости классам активов ...............76 Использование существенности .............................................................77 Задача 2. Определение стоимости актива ...............................................78 Задача 3. Определение степени ожидаемого разового ущерба (ОРУ) .......78 Задача 4. Определение ежегодной частоты возникновения (ЕЧВ) ............79 Задача 5. Определение ожидаемого годового ущерба (ОГУ) ....................80 Заключение ..................................................................................................80 Помощь на этапе поддержки принятия решений ...........................................80 Глава 5. Поддержка принятия решений ..................................................... 81 Обзор...........................................................................................................81 Требуемые входные данные для этапа поддержки принятия решений ...........83 Участники этапа поддержки принятия решений............................................83 Средства поддержки принятия решений ......................................................85 Требуемые выходные данные этапа поддержки принятия решений ...............85 Анализ вариантов поддержки принятия решений .........................................85 Принятие текущего риска......................................................................86 Реализация контроля для снижения рисков ............................................86 Условия успешной реализации ....................................................................87 Достижение единогласия ......................................................................87 Избежание обструкционизма .................................................................87 Выявление и сравнение элементов контроля ..................................................87 Шаг 1. Определение функциональных требований .......................................88 Шаг 2. Поиск решений для контроля ...........................................................91 Организационные элементы контроля ....................................................92 Операционные элементы контроля ........................................................93 Технологические элементы контроля .....................................................94 Шаг 3. Проверка соответствия решений требованиям ...................................96 vi Содержание Шаг 4. Оценка снижения риска ...................................................................96 Шаг 5. Оценка стоимости решения ..............................................................98 Затраты на приобретение ......................................................................99 Затраты на внедрение...........................................................................99 Текущие затраты ................................................................................ 100 Затраты на информирование ............................................................... 100 Затраты на обучение ИТ-персонала ..................................................... 100 Затраты на обучение пользователей .................................................... 100 Затраты на обеспечение удобства и производительности ...................... 101 Затраты на аудит и проверку эффективности ....................................... 101 Шаг 6. Выбор решения по нейтрализации риска......................................... 104 Заключение ................................................................................................ 105 Глава 6. Реализация контроля и оценка эффективности программы ..... 107 Обзор......................................................................................................... 107 Реализация контроля .................................................................................. 107 Входные данные, необходимые для этапа реализации контроля ................. 108 Участники этапа реализации контроля....................................................... 108 Средства для этапа реализации контроля .................................................. 109 Требуемые выходные данные этапа реализации контроля .......................... 109 Организация решений для контроля .......................................................... 109 Защита сети ....................................................................................... 111 Защита узлов ..................................................................................... 112 Защита приложений............................................................................ 113 Защита данных ................................................................................... 114 Оценка эффективности программы .............................................................. 114 Требуемые входные данные для этапа оценки эффективности программы ............................................................................................... 115 Участники этапа оценки эффективности программы ................................... 116 Предоставляемые средства оценки эффективности программы ................... 116 Требуемые выходные данные этапа оценки эффективности программы ....... 117 Разработка системы показателей рисков безопасности ............................... 117 Измерение эффективности контроля ......................................................... 118 Повторная оценка новых и измененных активов и рисков безопасности ...... 120 Заключение ................................................................................................ 121 Выводы из руководства ............................................................................... 121 Приложение А. Оперативная оценка рисков ............................................ 123 Приложение Б. Типичные активы информационных систем ................... 125 Приложение В. Типичные угрозы ............................................................. 131 Приложение Г. Уязвимости ....................................................................... 133 Участники проекта..................................................................................... 136 Глава 1. Обзор руководства по управлению рисками безопасности Основные положения Проблемы, вызываемые средой Большинство организаций осознает, насколько высока роль информационных технологий (ИТ) в достижении поставленных бизнес-целей. Однако современные ИТ-инфраструктуры тесно связаны между собой и работают в среде с постоянно возрастающим уровнем опасности, характеризующимся непрерывным увеличением частоты атак и постоянно ужесточающимися требованиями к времени реакции. Зачастую организации неспособны реагировать на новую угрозу безопасности раньше, чем она повлияет на их бизнес. Управление безопасностью инфраструктуры организации (и создаваемой благодаря этой инфраструктуре бизнес-ценностью) стало одной из основных задач ИТ-подразделений. Кроме того, новые законы, относящиеся к корпоративному управлению, сохранению конфиденциальности и выполнению финансовых обязательств, заставляют организации уделять больше внимания управлению ИТ-инфраструктурами и повышать эффективность управления. Для многих правительственных учреждений и работающих с ними организаций в законодательном порядке определен минимальный уровень безопасности. Отсутствие системы проактивного управления безопасностью может подвергать риску как руководство организаций, так и сами организации вследствие нарушений правовых и фидуциарных требований. Лучший способ Подход к управлению рисками безопасности, предлагаемый корпорацией Майкрософт, является проактивным и способен помочь организациям любого размера в решении проблем, возникающих в процессе обеспечения соответствия регулятивным нормам при работе с существующими в организациях средами. Формальный процесс управления рисками безопасности позволяет организациям добиться сочетания максимальной экономической эффективности с известным и приемлемым уровнем бизнесриска и предоставляет пользователям понятный и непротиворечивый метод организации и приоритизации ограниченных ресурсов для реализации управления рисками. Реализация управления рисками безопасности позволяет организациям внедрить экономически эффективный контроль, снижающий риск до приемлемого уровня. Определение приемлемого риска и подход к управлению рисками зависят от конкретной организации, поскольку не существует универсального решения, а разные организации используют различные модели управления рисками. Каждая модель предлагает собственное сочетание точности, ресурсов, времени, сложности и субъективности. Инвестиции в процесс управления рисками, основанный на проверенной концепции и четком определении ролей и обязанностей, подготавливают организацию к определению приоритетов, планированию нейтрализации угроз и связи угроз и уязвимостей с бизнесом. Кроме того, эффективная программа управления рисками поможет компании обеспечить соблюдение ужесточающихся законодательных требований. 2 Глава 1. Обзор руководства по управлению рисками безопасности Роль корпорации Майкрософт в управлении рисками безопасности Данный документ представляет собой первое подробное руководство корпорации Майкрософт, полностью посвященное управлению рисками безопасности. Это руководство основано на опыте специалистов корпорации Майкрософт и ее заказчиков, а содержащиеся в нем сведения и рекомендации проверены в процессе разработки заказчиками, партнерами и техническими рецензентами. Целью составления данного документа является предоставление заказчикам понятного и действенного руководства по реализации процесса управления рисками безопасности, обеспечивающего следующие возможности. Переход к проактивному управлению безопасностью и отказ от трудоемкого реактивного процесса. Возможность оценки уровня безопасности путем демонстрации ценности проектов по безопасности. Помощь заказчикам в использовании ограниченных ресурсов для эффективного снижения основных рисков, позволяющая не растрачивать эти ресурсы на все возможные риски. Обзор руководства Данное руководство использует отраслевые стандарты для объединения существующих моделей управления рисками в интерактивный четырехэтапный процесс, направленный на достижение баланса затрат и эффективности. В процессе оценки рисков быстро выполняется качественное определение наиболее важных рисков, а затем осуществляется количественная оценка, основанная на четко определенных ролях и обязанностях. Данный подход учитывает множество деталей и позволяет получить полное представление об основных рисках. Совместное использование качественных и количественных шагов в процессе оценки рисков позволяет сформировать основу для принятия решений о рисках и их нейтрализации, сопутствующих интеллектуальным бизнес-процессам. Примечание. Новые понятия, упомянутые в данном разделе, подробно рассматриваются в следующих главах настоящего документа. Например, в главе 2 «Обзор рекомендаций по управлению рисками безопасности» рассматриваются различия между качественным и количественным подходом к оценке рисков. Предлагаемый корпорацией Майкрософт процесс управления рисками позволяет организациям внедрить и использовать в своей ИТ-среде процессы выявления и приоритизации рисков. Переход от реактивного процесса к проактивному управлению безопасностью значительно повышает защищенность сред заказчиков, что, в свою очередь, повышает доступность ИТ-инфраструктуры и увеличивает бизнес-ценность. Процесс управления рисками безопасности, разработанный корпорацией Майкрософт, использует сочетание различных подходов, включая чистый количественный анализ, анализ уровня возврата инвестиций в безопасность, качественный анализ и подходы на основе передового опыта. Необходимо отметить, что данное руководство относится только к процессу управления рисками и не требует использования конкретных технологий. Руководство по управлению рисками безопасности 3 Критические факторы успеха Для успешной реализации программы управления рисками безопасности в организации необходимо выполнение целого ряда условий. Наиболее важные из них рассматриваются в этом разделе, а остальные описаны далее в этой главе в разделе «Условия успешной реализации». Во-первых, реализация системы управления рисками безопасности невозможна без одобрения и поддержки руководства организации. Если реализация системы управления рисками безопасности осуществляется сверху вниз, организация может сформулировать требования к безопасности в терминах бизнес-ценности. Следующим необходимым условием успешной реализации является строгое распределение ролей и обязанностей. Руководители организаций должны определить влияние рисков. Кроме того, именно руководители могут наилучшим образом определить бизнесценность активов, необходимых для выполнения их задач. Группа по информационной безопасности должна определить вероятность возникновения соответствующих рисков путем анализа существующих и предлагаемых элементов контроля. Если вероятность взлома превышает допустимый уровень риска, группа по информационным технологиям должна реализовать элементы контроля, выбранные организационным комитетом по обеспечению безопасности. Дальнейшие шаги Инвестирование в программу управления рисками безопасности, основанную на проверенном и выполнимом процессе и определении ролей и ответственностей, подготавливает организации к определению приоритетов, планированию нейтрализации угроз и борьбе с наиболее существенными угрозами и уязвимостями, возникающими при работе компании. Данное руководство позволяет компаниям оценить свой уровень готовности и содержит рекомендации по использованию системы управления рисками. Компании, которым необходимо или желательно получить дополнительную поддержку, должны обратиться в подразделение корпорации Майкрософт по работе с заказчиками или к партнеру корпорации Майкрософт по предоставлению услуг. Для кого предназначено это руководство Данное руководство в первую очередь предназначено для консультантов, специалистов по безопасности, системных архитекторов и ИТ-специалистов, несущих ответственность за планирование разработки и развертывание инфраструктуры и приложений в различных проектах. Как правило, эти функции выполняют следующие специалисты. Разработчики и проектировщики, ответственные за вопросы, связанные с максимизацией архитектуры в организации. Специалисты по информационной безопасности, ответственные за обеспечение межплатформенной безопасности в рамках организации. Аудиторы ИТ-систем и систем безопасности, ответственные за соблюдение организацией необходимых элементов контроля важных бизнес-активов. Сотрудники, принимающие деловые решения, бизнес-аналитики и руководители, бизнес-цели и должностные обязанности которых требуют активного использования информационных технологий. Консультанты и партнеры, которым необходимы средства передачи информации корпоративным заказчикам и партнерам. 4 Глава 1. Обзор руководства по управлению рисками безопасности Вопросы, рассмотренные в этом руководстве В руководстве приводятся рекомендации по планированию, внедрению и сопровождению процесса управления рисками безопасности в организациях всех типов и размеров. В нем рассматривается каждая стадия проекта по управлению рисками и показывается, как превратить проект в постоянный процесс, обеспечивающий более результативные и экономически эффективные элементы контроля для снижения рисков безопасности. Обзор содержания Данное руководство включает шесть глав, содержание которых кратко изложено ниже. Каждая глава основана на комплексных рекомендациях, необходимых для эффективного внедрения и поддержки процесса постоянного управления рисками безопасности в организации. В заключительную часть руководства включено несколько приложений и описаний средств, помогающих упорядочить проекты по управлению рисками безопасности. Глава 1. Обзор руководства по управлению рисками безопасности Эта глава является вводной и содержит обзор каждой главы руководства. Глава 2. Обзор рекомендаций по управлению рисками безопасности В данной главе рассматриваются применявшиеся ранее подходы к управлению рисками безопасности. Эти сведения необходимы, чтобы понять особенности процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. Тем, кто хорошо знаком с управлением рисками безопасности, достаточно будет быстро просмотреть данную главу, а остальным рекомендуется изучить этот материал полностью. В начале главы описаны достоинства и недостатки проактивного и реактивного подходов к управлению рисками, а затем подробно рассматривается концепция зрелости процесса управления рисками в организации, упомянутая в главе 1 «Обзор руководства по управлению рисками безопасности». В заключительной части главы оцениваются и сравниваются два традиционных метода управления рисками — качественный и количественный. Кроме того, в этой главе рассматривается процесс, который предлагается корпорацией Майкрософт и представляет собой альтернативный метод, обеспечивающий баланс двух традиционных методов и доказавший свою эффективность. Глава 3. Обзор управления рисками безопасности В данной главе более подробно рассматриваются процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, а также основные концепции и условия успешного использования данного процесса. Кроме того, в этой главе приводятся рекомендации по подготовке к реализации процесса управления рисками безопасности путем использования эффективного планирования и создания группы управления рисками безопасности с четко определенными ролями и обязанностями. Руководство по управлению рисками безопасности 5 Глава 4. Оценка рисков В данной главе подробно рассматривается этап оценки рисков процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. На этом этапе выполняются планирование, координированный сбор данных и приоритизация рисков. Процесс оценки рисков включает несколько задач, выполнение которых может оказаться крайне трудоемким для крупных организаций. Например, на выявление и оценку стоимостей бизнес-активов может понадобиться слишком много времени, а выявление угроз и уязвимостей потребует больших трудозатрат со стороны технических специалистов. Как подчеркивается в главе 3 «Обзор управления рисками безопасности», решение проблем, возникающих при выполнении перечисленных выше задач, иллюстрирует важность надлежащего планирования и создания квалифицированной группы управления рисками безопасности. В завершение приоритизации рисков группа управления рисками безопасности использует качественный подход для сортировки полного перечня рисков безопасности, что позволяет быстро выявлять наиболее значительные риски, которые в дальнейшем подвергаются подробному анализу с применением количественных методик. Это дает возможность сформировать короткий перечень наиболее опасных рисков с указанием числовых характеристик, которые группа управления рисками безопасности сможет использовать для принятия решений на последующих этапах данного процесса. Глава 5. Поддержка принятия решений На этапе поддержки принятия решений группа управления рисками безопасности определяет наиболее результативные и экономически эффективные меры противодействия основным рискам безопасности. При этом группа определяет элементы контроля и затраты на приобретение, реализацию и поддержку каждого из них, оценивает снижение уровня риска, обеспечиваемое применением каждого элемента контроля, и вместе с организационным комитетом по обеспечению безопасности выбирает элементы контроля, подлежащие реализации. Конечным результатом данного процесса является разработка четкого и реализуемого плана, позволяющего контролировать или принимать каждый из основных рисков, выявленных на этапе оценке рисков. Глава 6. Реализация контроля и оценка эффективности программы В этой главе рассматриваются последние два этапа процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт: реализация контроля и оценка эффективности программы. Название этапа реализации контроля говорит само за себя: чтобы снизить риски, выявленные на этапе оценки, сотрудники, ответственные за нейтрализацию риска, разрабатывают и выполняют планы на основании перечня элементов контроля, сформированного на этапе поддержки принятия решений. В данной главе содержатся ссылки на методические инструкции, которые помогут сотрудникам, ответственным за нейтрализацию риска, уменьшить различные виды рисков. Оценка эффективности программы включает в себя набор операций, которые периодически выполняются группой управления рисками безопасности и позволяют проверить, обеспечивают ли реализованные на предыдущем этапе элементы контроля ожидаемую степень защиты. Кроме того, на данном этапе производится оценка изменения уровня управления рисками в организации в целом. В этой главе вводится понятие системы показателей рисков безопасности, позволяющей отслеживать уровень рисков безопасности в организации. В заключительной части главы рассматривается важность отслеживания изменений в вычислительной среде (таких как добавление и изъятие систем и приложений, а также появление новых угроз и уязвимостей). Подобные изменения могут потребовать от организации выполнения действий, направленных на защиту от новых или изменившихся рисков. 6 Глава 1. Обзор руководства по управлению рисками безопасности Приложение А. Оперативная оценка рисков В приложении А формальный процесс оценки корпоративных рисков сравнивается с оперативным подходом, используемым многими организациями, рассматриваются преимущества и недостатки каждого метода и приводятся рекомендации, помогающие выбрать наиболее подходящий. Приложение Б. Типичные активы информационных систем В приложении Б перечислены типичные активы информационных систем, встречающиеся в организациях различных типов. Приведенный перечень не претендует на полноту и является лишь образцом, который может использоваться в качестве отправной точки. Поскольку маловероятно, что в этом перечне окажутся все активы, входящие в уникальную среду конкретной организации, при оценке рисков в него необходимо внести соответствующие изменения. Приложение В. Типичные угрозы В приложении В перечислены наиболее распространенные угрозы, влияющие на работу широкого круга организаций. Приведенный перечень включает не все угрозы и является лишь образцом, который может использоваться в качестве отправной точки. Кроме того, поскольку данный перечень не обновляется, в нем отсутствуют сведения о последних версиях угроз. Поэтому на этапе оценки необходимо исключить из него угрозы, которые не могут повлиять на работу конкретной организации, и дополнить его новыми обнаруженными угрозами. Приложение Г. Уязвимости В приложении Г перечислены наиболее распространенные уязвимости, влияющие на работу широкого круга организаций. Приведенный перечень включает не все уязвимости и является лишь образцом, который может использоваться в качестве отправной точки. Кроме того, поскольку данный перечень не обновляется, в нем отсутствуют сведения о последних версиях уязвимостей. Поэтому на этапе оценки рисков необходимо исключить из него уязвимости, которые не могут повлиять на работу конкретной организации, и дополнить его обнаруженными уязвимостями. Средства и шаблоны Данное руководство включает набор средств и шаблонов, упрощающих организациям реализацию процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. Эти средства и шаблоны содержатся в файле установщика Windows Security Risk Management Guide Tools and Templates.msi, который находится на веб-узле центра загрузки Майкрософт. При запуске этого файла будет создана следующая папка. \%USERPROFILE%\Мои документы\Security Risk Management Guide Tools and Templates. В данную папку будут помещены следующие средства и шаблоны. Шаблон Data Gathering Template (SRMGTool1-Data Gathering Tool.doc). Данный шаблон можно использовать на этапе оценки рисков при обсуждениях, описанных в главе 4 «Оценка рисков». Рабочий лист Summary Level Risk Analysis (SRMGTool2-Summary Risk Level.xls). Данный файл представляет собой книгу Microsoft® Excel®, которая поможет организациям выполнить начальный этап анализа рисков — анализ общего уровня. Руководство по управлению рисками безопасности 7 Рабочий лист Detail Level Risk Analysis (SRMGTool3-Detailed Level Risk Prioritization.xls). Данный файл представляет собой книгу Excel, которая поможет организациям выполнить подробный анализ основных рисков, выявленных в процессе анализа общего уровня. Sample Schedule (SRMGTool4-Sample Project Schedule.xls). Данный файл представляет собой книгу Excel с общим расписанием проекта для процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, и содержит этапы, шаги и задачи, рассматриваемые в этом руководстве. Условия успешной реализации Всякий раз, когда организация приступает к большому новому проекту, для достижения успеха необходимо наличие ряда основополагающих элементов. Корпорация Майкрософт составила список элементов, которые необходимы для успешной реализации процесса управления рисками безопасности и которые должны сохраняться во время развития проекта. К этим элементам относятся следующие. Поддержка руководства. Наличие полного перечня заинтересованных лиц, участвующих в процессе управления рисками. Зрелость организации с точки зрения управления рисками. Атмосфера открытого обмена информацией. Дух командной работы. Целостное представление организации. Распределение полномочий в рамках процесса. В следующих разделах рассматриваются как перечисленные выше элементы, необходимые на протяжении всего процесса управления рисками безопасности, так и дополнительные элементы, относящиеся только к конкретным этапам (эти элементы обсуждаются в главах, посвященных соответствующим этапам). Поддержка руководства Руководство организации должно безоговорочно поддерживать процесс управления рисками безопасности, поскольку в противном случае попытки использования управления рисками для повышения безопасности организации могут столкнуться с сопротивлением или саботажем со стороны заинтересованных лиц. Кроме того, отсутствие поддержки руководства может привести к тому, что отдельные сотрудники будут игнорировать указания, касающиеся выполнения их работы и помощи в защите активов организации. Существует целый ряд причин, препятствующих совместной работе сотрудников. В число этих причин входят общее неприятие изменений, непонимание важности эффективного управления рисками безопасности, ошибочная уверенность сотрудников в том, что их часть организации никогда не подвергнется атаке, или в том, что они обладают достаточными знаниями для защиты бизнес-активов, даже если их квалификация ниже, чем у группы управления рисками безопасности. Поддержка руководства позволяет реализовать следующие возможности. Делегирование группе управления рисками безопасности прав и обязанностей в рамках четко определенной сферы действия проекта. Возможность организовать совместную работу с участием всех сотрудников. Выделение достаточного объема кадровых, финансовых и других ресурсов. Безусловная поддержка процесса управления рисками безопасности. Участие в изучении выводов и рекомендаций, полученных в результате реализации процесса управления рисками безопасности. 8 Глава 1. Обзор руководства по управлению рисками безопасности Полный перечень заинтересованных лиц для процесса управления рисками В данном руководстве часто используется термин «заинтересованные лица». В контексте настоящего руководства этот термин применяется для обозначения членов организации, заинтересованных в результатах процесса управления рисками безопасности. Группа управления рисками безопасности должна иметь представление обо всех заинтересованных лицах, включая членов самой группы, ответственных руководителей, владельцев оцениваемых бизнес-активов и сотрудников ИТ-подразделения, ответственных за проектирование, развертывание и сопровождение бизнес-активов. Необходимо сформировать перечень заинтересованных лиц и обеспечить их участие в процессе управления рисками безопасности, а группа управления рисками безопасности должна помочь этим людям понять суть данного процесса и его возможности по долговременной экономии средств и защите активов заинтересованных лиц. Зрелость организации с точки зрения управления рисками Если организация не использует управление рисками безопасности, то полная реализация процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, может потребовать единовременного внесения значительных изменений. Даже если в организации применяются некоторые неформальные процессы (например, оперативные мероприятия, выполняемые в ответ на отдельные проблемы с безопасностью), данный процесс может оказаться чрезмерно трудоемким. Однако в организациях, обладающих большей зрелостью с точки зрения управления рисками, этот процесс будет эффективен. В данном случае зрелость определяется наличием четко определенных процессов безопасности, а также глубоким пониманием и одобрением применения управления рисками безопасности на многих уровнях организации. Концепция зрелости системы управления рисками безопасности и методика определения уровня зрелости конкретной организации рассматриваются в главе 3 «Обзор управления рисками безопасности». Атмосфера открытого обмена информацией Многие организации считают, что для успешной работы им достаточно минимального необходимого объема знаний, что зачастую приводит к неправильной оценке возможностей по реализации решений и снижению эффективности работы групп, реализующих эти решения. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, основан на открытом и дружественном обмене информацией с членами рабочей группы и другими заинтересованными лицами. Свободный обмен информацией не только снижает риск неправильного понимания и непроизводительной траты усилий, но и гарантирует, что все члены рабочей группы смогут принять участие в разъяснении вопросов, касающихся проекта. Открытое и дружественное обсуждение выявленных рисков и элементов контроля является необходимым условием успешной реализации рассматриваемого процесса. Руководство по управлению рисками безопасности 9 Дух командной работы Эффективность проводимых мероприятий в значительной степени зависит от взаимоотношений между людьми, вовлеченными в процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, поскольку хорошие взаимоотношения между группой обеспечения безопасности, управленческим персоналом и другими сотрудниками организации являются важнейшим условием успешной реализации этого процесса независимо от поддержки руководства организации. Очень важно, чтобы группа управления рисками безопасности культивировала дух командной работы во взаимоотношениях с представителями всех участвующих в проекте подразделений. Чтобы облегчить решение этой задачи, группа может продемонстрировать деловую ценность управления рисками безопасности отдельным менеджерам этих подразделений и показать сотрудникам, каким образом данный проект поможет повысить эффективность работы сотрудников в долгосрочной перспективе. Целостное представление организации Все участники процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт (особенно члены группы управления рисками безопасности), в процессе работы должны учитывать влияние данного процесса на всю организацию. То, что является оптимальным для отдельного сотрудника, может не устраивать организацию в целом, а то, что обеспечивает преимущества одному подразделению, может негативно отражаться на работе всей организации. Рядовые сотрудники и руководители отдельных подразделений склонны искать решения, приносящие выгоду им лично и их подразделениям. Распределение полномочий в процессе Участники процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, должны выявлять и контролировать наиболее значительные риски безопасности в рамках организации. Чтобы эффективно противостоять этим рискам с помощью адекватных элементов контроля, требуются полномочия, позволяющие вносить необходимые изменения. Поэтому члены группы управления рисками безопасности должны обладать правами, позволяющими выполнять возложенные на группу обязательства. Для этого нужно, чтобы члены группы имели в своем распоряжении ресурсы, необходимые для выполнения их работы, несли ответственность за решения, влияющие на их работу, и знали пределы своих полномочий и порядок действий в случае возникновения проблем, выходящих за рамки этих полномочий. Термины и определения Некоторые термины, используемые в сфере управления рисками безопасности, могут оказаться сложными для понимания, а широко распространенные термины могут по-разному истолковываться разными людьми. Поэтому необходимо четко определить основные термины, используемые в настоящем руководстве. Большая часть перечисленных ниже терминов приведена в документах, опубликованных Международной организацией по стандартам (International Standards Organization, ISO) и инженерной группой по развитию Интернета (Internet Engineering Task Force, IETF). Веб-адреса этих организаций указаны в разделе «Дополнительные сведения» этой главы. Ниже перечислены основные термины, используемые в сфере управления рисками безопасности. Ожидаемый годовой ущерб (ОГУ). Общие потери, которые организация понесет в течение года, если не будет осуществлена нейтрализация риска. Ежегодная частота возникновения (ЕЧВ). Ожидаемое количество проявлений риска на протяжении года. Актив. Нечто, обладающее ценностью для организации (например, оборудование, программное обеспечение, данные, люди и документация). 10 Глава 1. Обзор руководства по управлению рисками безопасности Доступность. Свойство системы или системного ресурса, гарантирующее, что полномочный пользователь системы сможет обратиться к данной системе или ресурсу и воспользоваться ими. Доступность является одной из основных характеристик системы безопасности. КЦД. См. «Конфиденциальность», «Целостность» и «Доступность». Конфиденциальность. Свойство, гарантирующее, что информация недоступна несанкционированным лицам, субъектам и процессам (ISO 7498-2). Контроль. Организационное, процедурное и технологическое понимание управления рисками. Данный термин является синонимом терминов «мера безопасности» и «контрмера». Анализ выгод и затрат. Оценка и сравнение относительных выгод и затрат для каждого предлагаемого элемента контроля с целью реализации наиболее эффективных. Поддержка принятия решений. Приоритизация рисков на основе анализа выгод и затрат. Затраты на решение для контроля, позволяющее нейтрализовать риск, сравниваются с выгодами от его нейтрализации. Многоуровневая защита. Подход, основанный на использовании нескольких уровней безопасности для защиты от сбоев одиночного компонента системы безопасности. Взлом. Использование уязвимости для нарушения информационной безопасности или бизнес-деятельности. Подверженность воздействию. Угроза, приводящая к тому, что несанкционированные субъекты получают прямой доступ к важным данным (RFC 2828). Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, сужает это определение, чтобы сконцентрировать внимание на степени ущерба, наносимого бизнес-активам. Влияние. Суммарный ожидаемый ущерб в результате использования угрозой уязвимости с целью воздействия на актив. Целостность. Свойство, характеризующее защиту информации от несанкционированного изменения и удаления (ISO 7498-2). Нейтрализация риска. Смягчение риска путем выполнения операций, направленных на противостояние угрозам, лежащим в его основе. Решение по нейтрализации риска. Реализация контроля, представляющая собой организационные, процедурные или технологические меры, направленные на управление риском безопасности. Вероятность. Вероятность возникновения события. Качественное управление рисками. Подход к управлению рисками, при котором участники процесса определяют относительную ценность активов, рисков, элементов контроля и влияний. Количественное управление рисками. Подход к управлению рисками, при котором участники процесса сопоставляют активам, рискам, элементам контроля и влияниям объективные числовые значения (например, денежные суммы). Репутация. Мнение людей об организации. Хотя репутация является нематериальной величиной и ее тяжело оценить, для большинства организаций она представляет собой значительную ценность. Окупаемость инвестиций в обеспечение безопасности (ОИОБ). Общий объем средств, которые организация планирует сэкономить в течение года за счет управления безопасностью. Риск. Сочетание вероятности события и его последствий (ISO Guide 73). Оценка риска. Процесс выявления риска и определения его влияния. Управление риском. Процесс определения приемлемого уровня риска, оценки текущего уровня риска, выполнения операций по снижению величины риска до приемлемого уровня и поддержанию этого уровня. Ожидаемый разовый ущерб (ОРУ). Общая сумма прибыли, потерянная вследствие единичного проявления риска. Руководство по управлению рисками безопасности 11 Угроза. Потенциальная причина нежелательного влияния на систему или организацию (ISO 13335-1). Уязвимость. Слабое место, действие, административный процесс или физическая подверженность воздействию, делающие информационный актив чувствительным к угрозе. Условные обозначения В данном руководстве использованы следующие условные обозначения и термины. Элемент Значение Примечание Обращает внимание читателя на дополнительные сведения Пример банка Woodgrove Обращает внимание читателя на пример, основанный на работе вымышленной компании Woodgrove Bank Получение поддержки по данному руководству Данное руководство призвано подробно описать процесс, позволяющий организациям внедрить и поддерживать программу управления рисками безопасности. Для получения помощи в реализации программы управления рисками безопасности обратитесь в центр работы с заказчиками корпорации Майкрософт. Поддержка по телефону для этого документа не предоставляется. Вопросы и отзывы относительно данного документа направляйте по адресу secwish@microsoft.com. Дополнительные сведения На момент составления данного руководства в перечисленных ниже источниках содержалась наиболее свежая информация по вопросам управления рисками безопасности. Решение Microsoft Operations Framework (MOF) предоставляет организациям рекомендации, позволяющие обеспечивать надежность, доступность, поддерживаемость и управляемость важных систем на основе продуктов и технологий Майкрософт. Предоставляемые MOF руководства поставляются в виде технических документов, руководств по использованию, средств оценки, рекомендаций, примеров реализации, шаблонов, средств поддержки и служб, позволяющих решать проблемы, которые возникают при работе сотрудников, а также при использовании процессов, технологий и элементов контроля в сложных, распределенных, гетерогенных ИТ-средах. Дополнительные сведения о MOF см. по адресу www.microsoft.com/mof. Решение Microsoft Solutions Framework (MSF) помогает в выполнении планов действий, разработанных в ходе реализации процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. MSF представляет собой тщательно продуманный, последовательный подход к технологическим проектам, основанный на определенных наборах принципов, моделях, концепциях, руководствах, порядках действия и проверенных рекомендациях корпорации Майкрософт. Применение MSF помогает организациям реализовывать высококачественные технологические решения в заданные сроки и в пределах выделенного бюджета. Дополнительные сведения о MSF см. по адресу www.microsoft.com/msf. 12 Глава 1. Обзор руководства по управлению рисками безопасности Центр безопасности Майкрософт содержит исчерпывающую упорядоченную подборку документов, посвященных различным вопросам безопасности. Материалы центра безопасности см. по адресу www.microsoft.com/security/guidance/default.mspx. «Решение по защите сервера Microsoft Windows 2000 Server» представляет собой подробное руководство, призванное помочь уменьшить уязвимость системы безопасности и снизить затраты на управление безопасностью в среде Microsoft Windows® 2000. Главы 2, 3 и 4 указанного документа содержат первое руководство по управлению рисками безопасности, которое было выпущено корпорацией Майкрософт и называлось «Дисциплина управления рисками, связанными с безопасностью». Настоящее руководство заменяет материал по управлению рисками безопасности, изложенный в руководстве «Решение по защите сервера Microsoft Windows 2000 Server». Чтобы ознакомиться с руководством Решение по защите сервера Microsoft Windows 2000 Server, обратитесь по адресу http://go.microsoft.com/fwlink/?LinkId=14837. Национальный институт стандартов и технологий (NIST) разработал Руководство по управлению рисками для ИТ-систем (июль 2002 г.). Данное руководство отличается очень хорошим качеством и доступно по адресу http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf. Кроме того, NIST разработал Руководство по самостоятельной оценке безопасности ИТ-систем (ноябрь 2001 г.). Данное руководство доступно по адресу http://csrc.nist.gov/publications/nistpubs/800-26/sp800-26.pdf. Стандарт ISO предлагает обобщенный свод правил под названием Информационные технологии — практические правила управления информационной безопасностью (или ISO 17799). Данный стандарт можно заказать по адресу www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=33441&ICS1= 35&ICS2=40&ICS3= (заказ является платным). Организация ISO опубликовала целый ряд прочих стандартов, некоторые из которых упоминаются в данном руководстве. Стандарт ISO можно получить по адресу www.iso.org (заказ является платным). Группа CERT (Computer Emergency Response Team), находящаяся в институте разработки программного обеспечения университета Carnegie-Mellon, создала методику самостоятельной оценки рисков и планирования OCTAVE® (Operationally Critical Threat, Asset, and Vulnerability EvaluationSM). Дополнительные сведения о методике OCTAVE см. по адресу www.cert.org/octave. Стандарт COBIT (контрольные показатели для информационных и связанных с ними технологий) предлагает применяемые многими организациями стандарты безопасности ИТ-систем и рекомендации по управлению, позволяющие сформулировать основные правила управления и выполнения аудита информационных систем, а также правила работы пользователей и специалистов по безопасности. Стандарт COBIT можно заказать на веб-узле ISACA (Information Systems Audit and Control Association) по адресу www.isaca.org/cobit (заказ является платным). Группа IETF опубликовала глоссарий Request for Comments (RFC) 2828, называющийся Internet Security Glossary и содержащий стандартные определения большого числа терминов, используемых в сфере обеспечения безопасности информационных систем. Данный глоссарий находится по адресу www.faqs.org/rfcs/rfc2828.html. Глава 2. Обзор рекомендаций по управлению рисками безопасности В начале главы описаны достоинства и недостатки проактивного и реактивного подхода к управлению рисками безопасности, а затем дается оценка и приводится сравнение двух традиционных методов управления рисками безопасности — качественного и количественного. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, представляет собой альтернативный метод, обеспечивающий баланс этих двух традиционных методов и доказавший свою высокую эффективность при использовании в корпорации Майкрософт. Примечание. В данной главе рассматриваются применявшиеся ранее подходы к управлению рисками безопасности. Эти сведения необходимы, чтобы понять особенности процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. Тем, кто хорошо знаком с управлением рисками безопасности, достаточно быстро просмотреть данную главу, а остальным рекомендуется изучить материал полностью. Сравнение подходов к управлению рисками Многие организации были вынуждены внедрить управление рисками безопасности в силу необходимости реагирования на относительно небольшие проблемы в сфере безопасности (например, при заражении одного из компьютеров вирусом офисменеджеру приходится учиться удалять вирус, не повреждая хранящиеся на компьютере данные). По мере возникновения новых проблем в сфере безопасности, отрицательно влияющих на работу организации и требующих постоянного внимания, приходит понимание того, что организации необходимо новое решение, основанное не на реактивном подходе, а на уменьшении вероятности повторного возникновения проблем. Организации, внедрившие эффективную систему управления рисками, в большей степени используют проактивный подход, однако, как будет показано ниже, данный подход представляет собой лишь часть решения. Реактивный подход В настоящее время многие ИТ-специалисты испытывают колоссальное давление со стороны пользователей, требующих как можно быстрее выполнять все задачи и при этом причинять как можно меньше неудобств. В результате многие ИТспециалисты считают, что при возникновении проблем с безопасностью они должны только обеспечить контроль над ситуацией, выяснить, что случилось, и как можно быстрее восстановить работоспособность систем, затронутых проблемой. Некоторые из них могут попытаться определить основную причину проблемы, однако в условиях крайне ограниченных ресурсов даже это может оказаться непозволительной роскошью. Хотя реактивный подход может стать тактически эффективным ответом на риски безопасности, которые были использованы злоумышленниками и привели к нарушению безопасности, наложение некоторых ограничений на реактивный подход может помочь организациям всех типов лучше использовать свои ресурсы. 14 Глава 2. Обзор рекомендаций по управлению рисками безопасности Прежние проблемы с безопасностью могут помочь организациям спрогнозировать появление проблем в будущем и подготовиться к их возникновению. Это означает, что организация, которая реагирует на инциденты с использованием взвешенных и рациональных методик, определяя причины, которые привели к возникновению инцидента, будет лучше защищена от возникновения подобных проблем в будущем и сможет быстрее реагировать на другие возникающие проблемы. Подробное рассмотрение реагирования на инциденты выходит за пределы данного руководства, однако следующие шесть шагов помогут повысить скорость и эффективность реагирования. 1. Оберегайте жизнь людей и заботьтесь об их безопасности. Эта задача всегда должна являться первоочередной. Например, если подверженные проблеме компьютеры являются частью системы жизнеобеспечения, вместо их отключения рекомендуется логически изолировать эти системы в сети путем изменения конфигурации маршрутизаторов и коммутаторов, не нарушая работоспособности систем помощи пациентам. 2. Ограничьте повреждения. Ограничение причиненных атакой повреждений помогает уменьшить дополнительный ущерб. Быстро обеспечивайте защиту важных данных, программных продуктов и оборудования. Крайне важно уменьшить ущерб, причиненный вычислительным ресурсам, однако поддержание работоспособности систем во время атаки может привести, в конце концов, к более широкому распространению проблемы. Например, обнаружив в среде программу-червь, можно попытаться уменьшить причиняемый ею ущерб, отключив серверы от сети. Однако в некоторых случаях отключение серверов принесет больше вреда, чем пользы. Чтобы сделать правильный выбор, используйте здравый смысл и знания об используемых системах и сетях. Если при нарушении системы безопасности отключение от сети пораженных систем не окажет неблагоприятного воздействия или неблагоприятный эффект будет меньше, чем получаемые выгоды, следует как можно быстрее предпринять соответствующие меры. Если изоляция серверов не позволяет уменьшить наносимый ущерб, обеспечьте активный мониторинг действий злоумышленника, чтобы как можно быстрее устранить последствия атаки. Перед завершением работы любого сервера сохраните все файлы журналов. Информация, содержащаяся в этих файлах, в дальнейшем может использоваться сотрудниками и юристами организации в качестве доказательств. 3. Оцените ущерб. При атаке сервера немедленно сделайте копию информации, хранящейся на жестких дисках сервера, и сохраните эту копию для дальнейшего судебного разбирательства. Оцените причиненный ущерб. Размер причиненного атакой ущерба необходимо определить как можно быстрее (сразу после взятия ситуации под контроль и создания копий данных, хранящихся на жестких дисках), поскольку это позволит ускорить восстановление работоспособности организации, а копии жестких дисков следует сохранить для дальнейшего анализа. Если оценить ущерб в сжатые сроки не представляется возможным, необходимо ввести в действие план работ в аварийной ситуации, который позволит восстановить нормальную работу и эффективность бизнеса. На этом этапе организация может счесть целесообразным начать судебное расследование инцидента. Поэтому необходимо заблаговременно (до возникновения инцидентов) наладить сотрудничество с соответствующими правовыми органами, чтобы при возникновении серьезных проблем знать, к кому следует обращаться и что необходимо делать. Кроме того, необходимо немедленно обратиться в юридическую службу организации, чтобы она определила, может ли быть возбуждено преследование в гражданском порядке по факту нанесения выявленного ущерба. Руководство по управлению рисками безопасности 15 4. Определение причины ущерба. Чтобы обнаружить источник атаки, необходимо выявить подвергшиеся атаке ресурсы и найти уязвимости, которые были использованы для получения доступа или нарушения работы служб. Для этого следует изучить конфигурацию систем, перечень установленных обновлений, системные журналы и журналы аудита как в системах, непосредственно подвергшихся атаке, так и на сетевых устройствах, передававших трафик этим системам. Зачастую это помогает выявить как источник атаки, так и пострадавшие в результате атаки ресурсы. Эти действия должны выполняться на находящихся в эксплуатации компьютерных системах, а не на копиях дисков, созданных на шаге 3. Эти копии необходимо сохранить без изменений для возможного судебного разбирательства, что позволит правоохранительным органам или юридической службе организации использовать их для выявления злоумышленников и привлечения к ответственности. При необходимости создания резервных копий для тестирования и определения причин ущерба создайте еще одну копию данных исходной системы, но не используйте копии, созданные на шаге 3. 5. Исправление повреждений. В большинстве случаев необходимо как можно быстрее устранить нанесенные повреждения и восстановить нормальную работу организации и данные, потерянные в результате атаки. План и процедуры обеспечения непрерывной работы организации должны включать стратегию восстановления. Кроме того, группа реагирования на инциденты должна быть в состоянии выполнить операции по восстановлению работоспособности или предоставить ответственному подразделению необходимые рекомендации. В процессе восстановления работоспособности выполняются мероприятия, позволяющие ограничить распространение проблемы и изолировать ее. Перед вводом восстановленных систем в эксплуатацию необходимо позаботиться, чтобы они не подверглись повторному заражению. Для этого необходимо устранить уязвимости, использованные в ходе инцидента. 6. Анализ результатов и изменение политик. После документирования и восстановления необходимо тщательно проанализировать процесс. Вместе с рабочей группой определите правильно выполненные операции и допущенные ошибки. В большинстве случаев окажется, что для повышения эффективности действий при возникновении инцидентов в будущем необходимо изменить существующие процессы. Кроме того, в плане реагирования на инциденты неизбежно обнаружатся изъяны. На этом этапе необходимо выявить возможности усовершенствования. Все обнаруженные недочеты должны быть устранены в ходе очередного этапа процесса планирования действий при инцидентах, что позволит повысить эффективность реагирования на инциденты в будущем. 16 Глава 2. Обзор рекомендаций по управлению рисками безопасности Эта методика показана на рис. 2.1. Рис. 2.1. Процесс реагирования на инциденты Проактивный подход Проактивный подход к управлению рисками безопасности обладает многими преимуществами по сравнению с реактивным. Вместо того чтобы начинать что-то делать лишь после возникновения проблем, организация уменьшает вероятность их появления (в том числе вероятность появления проблем, не возникавших ранее). Для этого разрабатываются планы обеспечения безопасности важных активов организации путем применения элементов контроля, уменьшающих риск использования уязвимостей вредоносными программами и злоумышленниками или случайного злоупотребления. Чтобы лучше понять эту идею, приведем следующую аналогию. Грипп — это смертельно опасное респираторное заболевание, которым в США ежегодно заболевают миллионы людей. Более 100 000 из них нуждаются в госпитализации, а около 36 000 умирают. Чтобы справиться с этой угрозой, человек может или ничего не предпринимать, пока не заболеет, а затем обращаться к врачам и лечиться, или же пройти предварительную вакцинацию до начала эпидемии. Разумеется, организации не должны полностью отказываться от реагирования на инциденты. Эффективность проактивного подхода поможет организациям уменьшить число нарушений системы безопасности, которые могут возникнуть, однако не обеспечит их полного устранения. Поэтому организациям необходимо продолжить развитие процессов реагирования на нарушения системы безопасности наряду с разработкой долгосрочных проактивных мероприятий. Руководство по управлению рисками безопасности 17 В последнем разделе этой главы и в оставшихся главах данного руководства проактивный подход к управлению рисками безопасности будет рассмотрен более подробно. Все методики управления рисками безопасности используют ряд общих высокоуровневых процедур. 1. Выявление бизнес-активов. 2. Определение ущерба, который может понести организация в результате атаки на актив. 3. Выявление уязвимостей в системе безопасности, которые могут быть использованы при атаке. 4. Поиск методов минимизации риска атаки путем реализации соответствующих элементов контроля. Подходы к приоритизации рисков В данном руководстве часто используются термины управление рисками и оценка рисков, которые связаны друг с другом, но не являются взаимозаменяемыми. В процессе управления рисками безопасности, предлагаемом корпорацией Майкрософт, под управлением рисками понимаются общие усилия по снижению риска до приемлемого для бизнеса уровня. Под оценкой рисков понимается процесс выявления и приоритизации рисков для бизнеса. Несмотря на то что существует большое число методик оценки и приоритизации рисков, большая часть этих методик основана на качественном или количественном подходе к управлению рисками или использует сочетание этих подходов. Ссылки на ряд других методик оценки рисков см. в списке ресурсов, приведенном в разделе «Дополнительные сведения» в конце главы 1 «Обзор руководства по управлению рисками безопасности». Следующие несколько разделов данной главы содержат общие сведения о качественном и количественном подходе к управлению рисками и сравнение этих подходов, а также краткое описание процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, демонстрирующее, каким образом данный процесс сочетает возможности обоих подходов. Количественная оценка рисков Целью количественной оценки рисков является вычисление объективных числовых значений каждого компонента, выявленного в ходе оценки рисков и анализа выгод и затрат. Например, организация может оценить реальную стоимость каждого бизнесактива с точки зрения затрат на его замену, ущерба в показателях снижения производительности, ущерба в показателях снижения деловой репутации и других прямых и непрямых бизнес-ценностей. Этот же подход следует применять при определении подверженности актива воздействию, стоимости элементов контроля и других величин, выявленных в ходе управления рисками. Примечание. Данный раздел призван в обобщенном виде продемонстрировать некоторые этапы количественного управления рисками и не является подробным руководством по использованию количественного подхода в проектах по управлению рисками безопасности. Данный подход содержит несколько изъянов, которые нелегко преодолеть. Во-первых, не существует эффективного формализованного метода, позволяющего точно определить стоимости активов и элементов контроля. Другими словами, несмотря на кажущуюся точность полученных характеристик, финансовые показатели фактически основываются на оценках. Как, например, точно определить влияние проблемы с безопасностью, получившей широкую огласку, на имидж фирмы? В некоторых случаях этого можно добиться, проанализировав статистические данные, однако зачастую это невозможно. 18 Глава 2. Обзор рекомендаций по управлению рисками безопасности Во-вторых, организации, пытавшиеся скрупулезно реализовать все аспекты количественного подхода к управлению рисками, обнаружили, что это требует слишком больших затрат. Как правило, завершение первого полного цикла подобных проектов требует длительного времени, а в сами проекты вовлечено большое число сотрудников, которые не могут согласовать принципы вычисления конкретных финансовых показателей. В-третьих, организации, в которых подверженность воздействию дорогостоящих бизнес-активов может приводить к очень большим убыткам, могут посчитать целесообразным выделить значительные дополнительные средства на снижение всех рисков, которые могут возникнуть (хотя данная ситуация маловероятна — организация не будет тратить весь бюджет на защиту одного актива или даже пяти основных активов). Подробное рассмотрение количественного подхода На данном этапе следует составить общее представление о преимуществах и недостатках количественного подхода к оценке рисков. В оставшейся части данного раздела рассматриваются некоторые факторы и значения, которые обычно определяются при использовании количественного подхода: стоимости активов, затраты на элементы контроля и уровень возврата инвестиций в безопасность (УВИБ), а также рассчитанные значения ожидаемого разового ущерба (ОРУ), ежегодной частоты возникновения (ЕЧВ) и ожидаемого годового ущерба (ОГУ). Приведенный материал не содержит полного описания всех аспектов количественной оценки рисков, а включает лишь общие сведения об этом подходе и демонстрирует, что числовые показатели, лежащие в основе всех расчетов, представляют собой субъективные характеристики. Оценка активов Определение денежной стоимости актива является важным этапом управления рисками безопасности. Эта характеристика часто используется руководителями коммерческих подразделений организации для определения объема средств, который может быть выделен на обеспечение безопасности соответствующего ресурса. Во многих организациях перечни стоимостей активов (СА) являются составной частью планов обеспечения непрерывной работы организации. Обратите внимание, что полученные значения фактически представляют собой субъективные оценки, поскольку не существует средств и методов объективного определения стоимости активов. Чтобы назначить активу стоимость, определите следующие основные факторы. Общая стоимость актива для организации. Рассчитайте или оцените стоимость актива с финансовой точки зрения. Для примера рассмотрим влияние на работу организации временного выхода из строя веб-узла электронной торговли, обрабатывающего заказы покупателей. Предположим, этот веб-узел работал ежедневно и круглосуточно и в среднем приносил доход в размере 2000 долларов США в час. В этом случае можно утверждать, что с точки зрения объемов продаж годовая стоимость данного веб-узла составляет 17 520 000 долларов США. Непосредственное финансовое влияние потери актива. Если упростить приведенный выше пример и считать, что веб-узел каждый час приносит одинаковую прибыль и что этот веб-узел отключается на шесть часов, то уровень подверженности воздействию составляет 0,000685, или 0,0685%, в год. Умножив эту величину на годовую стоимость данного актива, можно спрогнозировать, что прямые потери в данном случае составят 12 000 долларов США. На самом деле величина прибыли, приносимой большинством веб-узлов электронной торговли, может изменяться в широком диапазоне и зависит от времени дня, дня недели, сезона, маркетинговых мероприятий и других факторов. Кроме того, часть заказчиков могут найти другой веб-узел, которым и будут пользоваться в дальнейшем, что приведет к постоянной потере части покупателей. Поэтому точная оценка убытков, учитывающая все виды ущерба, является очень сложным процессом. Руководство по управлению рисками безопасности 19 Косвенное бизнес-влияние ущерба, нанесенного активу. Предположим, в приведенном выше примере компания решила потратить 10 000 долларов США на рекламные акции, чтобы преодолеть негативные изменения общественного мнения, возникшие вследствие данного инцидента. Кроме того, компания ожидает снижения годового объема продаж на 1% (или 175 200 долларов США). Сложив величину уменьшения объема продаж и дополнительных затрат на рекламу, можно получить величину косвенных потерь, равную 185 200 долларам США. Определение ожидаемого разового ущерба (ОРУ) Ожидаемый разовый ущерб представляет собой общую сумму прибыли, потерянную вследствие единичного проявления риска. Данное значение представляет собой денежную величину, сопоставленную одиночному событию и характеризующую потенциальный ущерб, который понесет компания, если конкретная угроза сможет использовать уязвимость (данное значение схоже с величиной влияния, определяемой в ходе качественного управления рисками). ОРУ вычисляется путем умножения стоимости актива на величину фактора подверженности воздействию (ФПВ). Фактор подверженности воздействию представляет собой выраженную в процентах величину ущерба от реализации угрозы определенному активу. Если стоимость актива (например, веб-фермы) составляет 150 000 долларов США и пожар причинит данному активу ущерб в размере 25% его стоимости, то величина ОРУ в данном случае составит 37 500 долларов США (этот пример крайне упрощен, поскольку может потребоваться учесть другие затраты). Определение ежегодной частоты возникновения (ЕЧВ) Ежегодная частота возникновения представляет собой ожидаемое число проявлений риска на протяжении одного года. Получение этих оценок является очень сложным процессом в силу недостаточности страховых данных — страховые компании не разглашают информацию о подобных случаях. Чтобы получить оценочное значение ЕЧВ, проанализируйте опыт работы своей организации и проконсультируйтесь со специалистами по управлению рисками, безопасности и ведению бизнеса. ЕЧВ подобна вероятности, используемой при качественном управлении рисками, и может изменяться от 0% (никогда) до 100% (всегда). Определение ожидаемого годового ущерба (ОГУ) Ожидаемый годовой ущерб — это величина, характеризующая общие потери, которые организация понесет в течение одного года, если не будет предпринято действий по снижению риска. Для определения ОГУ следует умножить ЕЧВ риска на величину ОРУ. ОГУ схож с относительным уровнем, используемым при качественном управлении рисками. Например, если в приведенном выше примере пожар причинит веб-ферме ущерб в сумме 37 500 долларов США, а вероятность (или ЕЧВ) возникновения пожара составляет 0,1 (что соответствует одному пожару в 10 лет), то значение ОГУ в данном случае составит 3750 долларов США (37 500 x 0,1 = 3750). Рассчитав величину ОГУ, организация может использовать ее для определения величины затрат на элементы контроля (или меры защиты) для предотвращения соответствующего ущерба (в данном случае — 3750 долларов США в год или менее) и обеспечение надлежащего уровня защиты. Чтобы определить объемы средств, которые целесообразно выделять на защиту от потенциальных последствий рассматриваемой угрозы, необходимо получить численную оценку фактической вероятности возникновения риска и финансовой величины возможного ущерба, который может быть вызван данной угрозой. 20 Глава 2. Обзор рекомендаций по управлению рисками безопасности Определение затрат на элементы контроля Определение затрат на элементы контроля требует точной оценки затрат на разработку, тестирование, развертывание, использование и поддержку каждого элемента контроля. К подобным затратам могут относиться затраты на приобретение, разработку, развертывание, настройку и поддержку решений для контроля, на распространение информации о новых политиках и процедурах среди пользователей, на обучение пользователей и ИТ-персонала правилам применения и поддержки нового элемента контроля, на обеспечение его мониторинга, а также на предотвращение снижения удобства и эффективности работы, связанного с ним. Например, чтобы снизить риск повреждения веб-фермы, рассмотренная выше вымышленная организация может установить автоматическую систему пожаротушения. Этот шаг может повлечь за собой необходимость оплаты услуг специалистов по проектированию и установке подобной системы, затраты на обеспечение мониторинга и поддержание работоспособности системы, а также потребовать периодической проверки системы и замены используемых в ней химических веществ. Уровень возврата инвестиций в безопасность (УВИБ) Для оценки затрат на элементы контроля используйте следующее равенство. (ОГУ до контроля) – (ОГУ после контроля) – (годовые затраты на контроль) = УВИБ Например, предположим, что ОГУ для угрозы вывода злоумышленником из строя веб-сервера составляет 12 000 долларов США и что после реализации рекомендованной меры защиты ОГУ составил 3000 долларов США, а ежегодные затраты на обеспечение работоспособности меры защиты составляют 650 долларов США. В этом случае УВИБ составит 8350 долларов в год, как видно из следующего равенства: 12000 – 3000 – 650 = 8350. Результаты количественного анализа рисков Входные данные количественного анализа рисков содержат четко определенные цели и результаты. Перечисленные ниже параметры, как правило, определяются на основе результатов выполненных ранее действий. Назначение активу денежной стоимости. Полный перечень существенных угроз. Вероятность возникновения каждой угрозы. Возможный ущерб для компании от каждой угрозы на протяжении 12 месяцев. Рекомендуемые действия, элементы контроля и меры защиты. Выше было показано, что все эти величины основаны на субъективных оценках. Основные числовые показатели, используемые при формировании этих результатов, определяются исходя из мнения лиц, выполняющих оценку, а не вычисляются с помощью объективных формул или на основе общедоступной статистической информации. Поэтому значения стоимости актива, ожидаемого разового ущерба, ежегодной частоты возникновения и затрат на элементы контроля самостоятельно определяются участниками процесса (как правило, после длительного обсуждения и взаимных компромиссов). Руководство по управлению рисками безопасности 21 Качественная оценка рисков Качественный подход к оценке рисков отличается от количественного тем, что при использовании качественного подхода не нужно определять точные финансовые показатели стоимости активов, ожидаемого ущерба и стоимости элементов контроля. Вместо этого рассчитываются относительные стоимости. Как правило, анализ рисков выполняется путем заполнения опросных листов и проведения совместных обсуждений с участием представителей различных групп организации, таких как эксперты по информационной безопасности, менеджеры и сотрудники ИТ-подразделений, владельцы и пользователи бизнес-активов и старшие менеджеры. Если используются опросные листы, то они распространяются в срок от нескольких дней до нескольких недель до начала первого обсуждения. Опросные листы призваны помочь составить перечень уже развернутых активов и элементов контроля. Собранные сведения могут оказаться очень полезными при проведении последующих обсуждений. В ходе обсуждений участники формируют перечень активов и определяют их относительные стоимости. После этого им необходимо выяснить, с какими угрозами может столкнуться каждый актив и какие типы уязвимостей могут быть использованы этими угрозами в будущем. Как правило, ИТ-специалисты и системные администраторы предлагают группе управления рисками безопасности перечень элементов контроля для снижения рисков и указывают ориентировочную стоимость каждого элемента контроля. По завершении результаты предоставляются руководству компании в ходе анализа выгод и затрат. Как видно, основной процесс оценки качественных характеристик очень похож на процесс, используемый в количественном подходе. Отличия заключаются в деталях. При сравнении стоимостей различных активов используются относительные значения, и участникам не приходится тратить много времени на попытки точно вычислить финансовые стоимости активов. Аналогичная ситуация наблюдается при определении возможного влияния риска и затрат на реализацию элементов контроля. Преимущества качественного подхода состоят в том, что данный подход выдвигает меньше требований к сотрудникам и позволяет отказаться от сложных процедур определения точной стоимости актива, затрат на элемент контроля и т. п. Проекты, основанные на качественном подходе к управлению рисками, позволяют добиться заметных результатов уже через несколько недель, в то время как организации, использующие количественный подход, могут не получить сколько-нибудь значительных результатов, затрачивая усилия в течение месяцев или даже лет. Недостаток качественного подхода состоит в том, что полученные результаты не имеют однозначной интерпретации, а относительные величины, определенные в ходе качественной оценки рисков, могут не удовлетворять некоторых сотрудников, ответственных за принятие деловых решений (особенно сотрудников, работающих в сфере учета или финансов). 22 Глава 2. Обзор рекомендаций по управлению рисками безопасности Сравнение двух подходов Как количественный, так и качественный подход к управлению рисками безопасности имеет свои преимущества и недостатки. В некоторых случаях организациям выгоднее использовать количественный подход, а качественный подход может лучше подойти организациям небольшого размера или обладающим ограниченными ресурсами. Достоинства и недостатки обоих подходов перечислены в таблице 2.1. Таблица 2.1. Достоинства и недостатки подходов к управлению рисками Количественный Достоинства Недостатки Качественный Приоритеты рисков определяются на основе финансового влияния; приоритеты активов определяются на основе финансовых стоимостей. Результаты упрощают управление рисками, обеспечивая возврат инвестиций в безопасность. Результаты могут быть сформулированы с использованием управленческой терминологии (например, с помощью финансовых показателей и вероятности, выраженной в процентах). Точность результатов увеличивается по мере накопления организацией статистических данных в процессе работы. Сопоставленные рискам величины влияния основываются на субъективном мнении участников. Поиск решения, удовлетворяющего всех участников, и получение достоверных результатов занимают очень много времени. Расчеты являются очень сложными и требуют значительных затрат времени. Результаты представляются только в денежном выражении, а их интерпретация может вызывать трудности у сотрудников, не имеющих технической подготовки. Процесс требует глубоких знаний, что затрудняет подготовку участников. Обеспечивает наглядность и упрощает понимание процесса ранжирования рисков. Проще найти удовлетворяющее всех решение. Не требуется количественная оценка частоты возникновения угроз. Не нужно определять финансовые стоимости активов. Упрощается вовлечение в процесс сотрудников, не имеющих подготовки в области безопасности или компьютеров. Недостаточное различие между существенными рисками. Трудности с определением размера инвестиций в реализацию контроля вследствие отсутствия данных для анализа выгод и затрат. Результаты зависят от квалификации созданной группы управления рисками. Руководство по управлению рисками безопасности 23 Хотя в последние годы при управлении рисками в основном использовался количественный подход, в настоящее время положение дел стало меняться, поскольку организации все чаще сталкиваются с тем, что скрупулезное следование принципам количественного управления рисками, как правило, приводит к появлению долгосрочных проектов, почти не приносящих существенных выгод. Как будет показано в следующих главах, процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, объединяет достоинства обоих подходов. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, представляет собой комбинированный подход, объединяющий лучшие элементы количественного и качественного методов. Как будет показано в следующих главах, в данном руководстве описан уникальный подход к управлению рисками безопасности, работающий значительно быстрее, чем традиционный количественный подход, и позволяющий получать более подробные и удобные в использовании результаты, чем обычный качественный метод. Объединяя простоту и изящество качественного метода и строгость количественного, данное руководство предлагает уникальный процесс управления рисками безопасности, сочетающий эффективность и удобство использования и призванный обеспечить понимание каждого шага оценки всеми заинтересованными лицами. Рассматриваемый подход значительно проще, чем традиционное количественное управление рисками; он уменьшает противодействие на этапах анализа рисков и поддержки принятия решений, позволяет быстрее найти удовлетворяющее всех решение и легче обеспечивать поддержку на протяжении всего процесса. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, включает четыре этапа. Первым этапом является оценка рисков, сочетающая возможности качественного и количественного подхода. При этом качественный подход используется для быстрого упорядочивания перечня всех рисков безопасности, а количественный подход позволяет в дальнейшем выполнить более глубокий анализ наиболее существенных рисков, выявленных на этом этапе. Это дает возможность сформировать относительно небольшой перечень основных рисков, требующих глубокого изучения. Данный перечень используется на следующем этапе (этапе поддержки принятия решений), в ходе которого предлагаются и оцениваются решения для контроля. В дальнейшем лучшие решения представляются организационному комитету по обеспечению безопасности в качестве рекомендаций по снижению рисков. Третий этап называется этапом реализации контроля. На этом этапе лица, ответственные за нейтрализацию риска, осуществляют фактическое развертывание выбранных решений для контроля. Четвертый этап, этап оценки эффективности программы, позволяет проверять, обеспечивают ли элементы контроля надлежащий уровень безопасности, и отслеживать изменения в среде (например, добавление новых приложений и появление новых угроз), способные изменить профиль риска организации. 24 Глава 2. Обзор рекомендаций по управлению рисками безопасности Поскольку процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, представляет собой непрерывно работающий процесс, этот цикл повторяется при каждой новой оценке рисков. Частота повторения данного цикла зависит от организации. Многие специалисты считают, что если в организации постоянно выполняется проактивный мониторинг новых уязвимостей, угроз и активов, данный цикл достаточно повторять раз в год. Рис. 2.2. Этапы процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт На рис. 2.2 показаны четыре этапа процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. В главе 3 «Обзор управления рисками безопасности» приводится подробное описание данного процесса, а в последующих главах рассматриваются его отдельные этапы. Глава 3. Обзор управления рисками безопасности Эта глава является первой главой руководства, в которой приводится полный обзор процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. После этого обзора обсуждается несколько вопросов, которые помогут читателям в реализации данного процесса и в создании основы для успешного использования программы управления рисками безопасности. В число этих вопросов входят следующие. Различия между управлением рисками и оценкой рисков. Эффективное информирование о рисках. Оценка уровня зрелости используемой в организации системы управления рисками. Распределение ролей и обязанностей. Необходимо отметить, что управление рисками является лишь одной из составляющих большой программы управления, предназначенной для руководства компаний и позволяющей контролировать ведение бизнеса и принимать обоснованные решения. Хотя программы управления широко распространены, для приоритизации и нейтрализации рисков безопасности все они требуют структурированный компонент управления рисками безопасности. Концепции процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, могут использоваться в любой программе управления для определения рисков и их уменьшения до допустимого уровня. Четыре этапа процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт В главе 2 «Обзор рекомендаций по управлению рисками безопасности» приводятся начальные сведения о процессе управления рисками безопасности, предлагаемом корпорацией Майкрософт, и говорится, что управление рисками представляет собой непрерывный процесс, включающий следующие четыре этапа. 1. Оценка рисков. Выявление и приоритизация рисков для бизнеса. 2. Поддержка принятия решений. Поиск и оценка решений для контроля на основе определенных ранее правил анализа выгод и затрат. 3. Реализация контроля. Развертывание и использование решений для контроля, снижающих риск для организации. 4. Оценка эффективности программы. Анализ эффективности процесса управления рисками и проверка того, обеспечивают ли элементы контроля надлежащий уровень безопасности. Четырехкомпонентный цикл управления рисками обобщает рекомендации процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, и используется для упорядочивания материалов данного руководства. 26 Глава 3. Обзор управления рисками безопасности Однако перед изучением рекомендаций в рамках этого процесса необходимо рассмотреть особенности и компоненты более масштабного процесса управления рисками. Каждый этап этого цикла включает несколько шагов, перечисленных в приведенном ниже списке. Данный список поможет организациям понять роль каждого шага в рамках руководства. Этап оценки рисков. Планирование сбора данных. Обсуждение основных условий успешной реализации и подготовка рекомендаций. Сбор данных о рисках. Описание процесса сбора и анализа данных. Приоритизация рисков. Подробное описание шагов по качественной и количественной оценке рисков. Этап поддержки принятия решений. Определение функциональных требований. Определение функциональных требований для снижения рисков. Выбор возможных решений для контроля. Описание подхода к выбору решений по нейтрализации риска. Экспертиза решения. Проверка предложенных элементов контроля на соответствие функциональным требованиям. Оценка снижения риска. Оценка снижения подверженности воздействию или вероятности рисков. Оценка стоимости решения. Оценка прямых и косвенных затрат, связанных с решениями по нейтрализации риска. Выбор стратегии нейтрализации риска. Определение наиболее экономически эффективного решения по нейтрализации риска путем анализа выгод и затрат. Этап реализации контроля. Поиск целостного подхода. Включение персонала, процессов и технологий в решение по нейтрализации риска. Организация по принципу многоуровневой защиты. Упорядочение решений по нейтрализации риска в рамках предприятия. Этап оценки эффективности программы. Разработка системы показателей рисков. Оценка уровня и изменения риска. Оценка эффективности программы. Оценка программы управления рисками для выявления возможностей усовершенствования. Руководство по управлению рисками безопасности 27 Рассмотренные выше этапы и их шаги показаны на рис. 3.1. Рис. 3.1. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт Каждый этап процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, поочередно описан в последующих главах данного руководства. Однако, прежде чем приступить к реализации этого процесса, необходимо учесть несколько факторов. Уровень усилий Организациям, которые не имеют большого опыта в управлении рисками, рекомендуется учесть, какие шаги процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, обычно требуют наибольших усилий со стороны группы управления рисками безопасности. Приведенный ниже график (рис. 3.2) составлен на основе анализа операций по управлению рисками в ИТ-подразделении корпорации Майкрософт и показывает относительную степень усилий в рамках всего процесса. Эти данные могут оказаться полезными при описании процесса в целом и временных ограничений для организаций, которые не имеют большого опыта в управлении рисками. Относительные уровни усилий могут также использоваться как руководство, позволяющее избежать чрезмерных затрат времени в конкретной точке процесса. Из графика видно, что сначала идет этап сбора данных, требующий среднего уровня усилий, затем — этап общего анализа, требующий меньшего уровня усилий, а затем — этапы создания перечня рисков на уровне детализации и поддержки принятия решений, требующие больших уровней усилий. Чтобы ознакомиться с дополнительными представлениями задач и соответствующих им усилий, см. файл SRMGTool4-Sample Project Schedule.xls, находящийся в папке Tools и представляющий собой пример расписания проекта. Каждый показанный ниже шаг подробно описан в следующих главах данного руководства. 28 Глава 3. Обзор управления рисками безопасности Рис. 3.2. Относительный уровень усилий в процессе управления рисками безопасности, предлагаемом корпорацией Майкрософт Основа процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт Для управления рисками безопасности необходимы базовые знания основных принципов и задач процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. В частности, необходимо: знать различия между управлением рисками и оценкой рисков; осуществить информирование о рисках; определить уровень зрелости используемой в организации системы управления рисками; распределить роли и обязанности. Различия между управлением рисками и оценкой рисков Как говорилось в главе 2, термины управление рисками и оценка рисков не являются взаимозаменяемыми. В процессе управления рисками безопасности, предлагаемом корпорацией Майкрософт, под управлением рисками понимаются общие мероприятия по снижению риска в рамках организации до приемлемого уровня. Под оценкой рисков понимается процесс выявления и приоритизации рисков для бизнеса. Как было показано на предыдущей схеме (рис. 3.1), управление рисками включает четыре этапа: оценку рисков, поддержку принятия решений, реализацию контроля и оценку эффективности программы. Термин «оценка рисков» в контексте процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, относится только к этапу оценки рисков цикла управления рисками. Еще одним различием между управлением рисками и оценкой рисков является частота выполнения каждого из этих действий. Управление рисками представляет собой непрерывный процесс, однако, как правило, данный процесс регулярно выполняется заново, чтобы обновить данные на каждом этапе процесса управления. Обычно процесс управление рисками согласовывают с циклом финансового учета организации, чтобы согласовать обычные бизнес-процессы с запросами на выделение из бюджета средств, необходимых для реализации элементов контроля. Для процесса управления рисками чаще всего используется годичный интервал, позволяющий согласовать ежегодные циклы бюджетирования и новые решения для контроля. Руководство по управлению рисками безопасности 29 Хотя оценка рисков является одним из обязательных этапов процесса управления рисками, группа информационной безопасности может многократно выполнять оценку рисков независимо от текущего этапа процесса управления рисками или цикла бюджетирования. Данная процедура может выполняться при внесении любых изменений, потенциально затрагивающих систему безопасности (например, при переходе к использованию новых рекомендаций по ведению бизнеса, при обнаружении уязвимостей или изменении инфраструктуры). Подобная частая оценка рисков получила название оперативной оценки рисков или оценки рисков с ограниченным диапазоном и должна рассматриваться как дополнение к формальному процессу управления рисками. При оперативной оценке рисков, как правило, рассматривается только одна подверженная риску область деятельности организации, что требует меньшего объема ресурсов, чем процесс управления рисками в целом. В приложении A «Оперативная оценка рисков» рассматривается шаблон оперативной оценки рисков. Таблица 3.1. Различия между управлением рисками и оценкой рисков Управление рисками Оценка рисков Цель Поддержание допустимого уровня рисков в рамках организации Выявление и приоритизация рисков Цикл Вся программа, включающая Один этап программы все четыре этапа управления рисками Расписание Постоянный процесс Согласованность Согласовано с циклами бюджетирования При необходимости — Информирование о рисках Различные люди, участвующие в процессе управления рисками, зачастую по-разному толкуют термин «риск». Чтобы обеспечить последовательность на всех этапах цикла управления рисками, процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, требует, чтобы все участники данного процесса использовали единое толкование термина «риск». Как было указано в главе 1 «Обзор руководства по управлению рисками безопасности», риск — это вероятность возникновения события, влияющего на бизнес. Данное определение требует включения формулировки влияния и прогнозирования времени возникновения соответствующего события или, другими словами, вероятности влияния. Если в формулировку риска включены оба компонента риска (вероятность и влияние), она называется полной формулировкой риска. Используйте данный термин, чтобы обеспечить непротиворечивое понимание комбинированного характера риска. Рис. 3.3 изображает риск на наиболее общем уровне. Рис. 3.3. Полная формулировка риска 30 Глава 3. Обзор управления рисками безопасности Необходимо, чтобы все вовлеченные в процесс управления рисками понимали сложность каждого элемента в определении риска. Только глубокое понимание рисков позволит организации осуществлять управление рисками. Например, чтобы определить влияние на бизнес организации, необходимо знать, какой актив был затронут, какой вред ему может быть нанесен и каковы пределы повреждения актива. Чтобы определить вероятность возникновения события, влияющего на бизнес, необходимо знать, каким образом может возникнуть каждое событие и насколько эффективно снижает вероятность риска текущая среда контроля. Следующая формулировка риска использует термины, определенные в главе 1 «Обзор руководства по управлению рисками безопасности», и учитывает как влияние, так и его вероятность. Риск — это вероятность того, что вследствие использования уязвимости в текущей среде пострадают конфиденциальность, целостность или доступность актива. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, предоставляет средства согласованного измерения вероятности и уровня ущерба для каждого риска и передачи соответствующих данных. В данном руководстве последовательно рассматривается процесс формирования каждого компонента полной формулировки риска для выявления и приоритизации рисков в рамках организации. Следующая схема (рис. 3.4) составлена на основе приведенной выше базовой формулировки риска, чтобы продемонстрировать взаимосвязи всех элементов риска. Рис. 3.4. Компоненты полной формулировки риска Чтобы проанализировать величину влияния и вероятности в формулировке риска, процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, следует начать с присвоения рискам приоритетов на основе относительных величин: «высокий», «средний» и «низкий». Хотя эта базовая терминология упрощает выбор уровней риска, полученных с ее помощью данных недостаточно для анализа выгод и затрат при выборе наиболее эффективного варианта нейтрализации риска. Чтобы устранить этот недостаток базового качественного подхода, в данном процессе реализованы средства подробного сравнения рисков, а также в него включены количественные атрибуты, помогающие выполнять анализ выгод и затрат для выбранных элементов контроля. Руководство по управлению рисками безопасности 31 Общий недостаток технологий управления рисками состоит в том, что они не учитывают качественные характеристики рисков для бизнеса, такие как «высокий», «средний» или «низкий». В ходе реализации программы управления рисками безопасности обнаруживается большое число рисков. Хотя процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, содержит рекомендации по последовательному применению количественных и качественных оценок, определение значения каждой величины с использованием указанных бизнес-терминов должно выполняться группой управления рисками безопасности. Например, высокий риск для бизнеса может означать появление в течение одного года уязвимости, способной привести к потере целостности наиболее ценной интеллектуальной собственности организации. Группа управления рисками безопасности должна выработать определения каждого элемента полной формулировки риска. В следующей главе приведено подробное руководство, которое поможет в определении уровней риска в каждой конкретной организации. Рассматриваемый процесс упрощает эту задачу, помогая обеспечить целостность и прозрачность процесса. Определение уровня зрелости используемой в организации системы управления рисками Перед внедрением в организации процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, необходимо проверить уровень зрелости организации с точки зрения управления рисками безопасности. Организациям, в которых отсутствуют формальные политики или процессы, относящиеся к управлению рисками безопасности, будет очень трудно сразу внедрить все аспекты рассматриваемого процесса. Данный процесс может оказаться чрезмерно трудоемким даже для организаций, применяющих некоторые формальные политики и рекомендации, которым следуют большинство пользователей. Поэтому необходимо оценить уровень зрелости организации. Если окажется, что уровень зрелости является достаточно низким, рассматриваемый процесс можно внедрять последовательными этапами на протяжении нескольких месяцев (например, путем эксплуатации пилотного проекта в отдельном подразделении на протяжении нескольких полных циклов данного процесса). Продемонстрировав эффективность процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, на примере этого пилотного проекта, группа управления рисками безопасности может перейти к внедрению данного процесса в других подразделениях, постепенно охватывая всю организацию. Как определить уровень зрелости организации? Модель управления ИТ (IT Governance Maturity Model) описана в документе CobiT (Control Objectives for Information and Related Technology) института управления ИТ (ITGI). Чтобы ознакомиться с подробной методикой определения уровня зрелости организации, приобретите и изучите данный документ. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, обобщает применяемые в CobiT элементы и представляет упрощенный подход, основанный на моделях, которые также разработаны службами корпорации Майкрософт. Представленные здесь определения уровня зрелости основаны на стандарте Международной организации по стандартам (ISO) Information technology — Code of practice for information security management («Информационные технологии — практические правила управления информационной безопасностью»), называемом также ISO 17799. 32 Глава 3. Обзор управления рисками безопасности Для оценки уровня зрелости организации можно воспользоваться таблицей 3.2. Таблица 3.2. Уровни зрелости управления рисками безопасности Уровень Состояние Определение 0 Отсутствует Политика или процесс не документированы. Ранее организация не знала о деловых рисках, связанных с управлением рисками, и не рассматривала данный вопрос 1 Узкоспециализированный Некоторые члены организации признают значимость управления рисками, однако операции по управлению рисками являются узкоспециализированными. Политики и процессы в организации не документированы, процессы не являются полностью повторяемыми. В результате проекты по управлению рисками являются хаотичными и некоординируемыми, а получаемые результаты не измеряются и не подвергаются аудиту 2 Повторяемый Организации известно об управлении рисками. Процесс управления рисками является повторяемым, но развит слабо. Процесс документирован не полностью, однако соответствующие операции выполняются регулярно, и организация стремится внедрить всеобъемлющий процесс управления рисками с привлечением высшего руководства. В организации не проводится формальное обучение и информирование по управлению рисками; ответственность за выполнение соответствующих мероприятий возложена на отдельных сотрудников 3 Наличие Организация приняла формальное решение определенного об интенсивном внедрении управления рисками процесса для управления программой защиты информации. В организации разработан базовый процесс с четко определенными целями и задокументированными процессами достижения и оценки результатов. Проводится обучение всего персонала основам управления рисками. Организация активно внедряет задокументированные процессы управления рисками 4 Управляемый На всех уровнях организации имеется глубокое понимание управления рисками. В организации существуют процедура управления рисками и четко определенный процесс, широко распространена информация об управлении рисками, доступно подробное обучение, существуют начальные формы измерений показателей эффективности. Программе управления рисками выделен достаточный объем ресурсов, результаты управления рисками оказывают положительное влияние на работу многих подразделений организации, а группа управления рисками безопасности может постоянно совершенствовать свои процессы и средства. В организации используются некоторые технологические средства, помогающие в управлении рисками, однако большая часть (если не подавляющее большинство) процедур оценки рисков, определения элементов контроля и анализа выгод и затрат выполняется вручную Руководство по управлению рисками безопасности Уровень Состояние 5 Оптимизированный 33 Определение Организация выделила на управление рисками безопасности значительные ресурсы, а сотрудники пытаются прогнозировать, какие проблемы могут встретиться в течение следующих месяцев и лет и каким образом их нужно будет решать. Процесс управления рисками глубоко изучен и в значительной степени автоматизирован путем применения различных средств (разработанных в организации или приобретенных у сторонних разработчиков). При возникновении проблем в системе безопасности выявляется основная причина возникшей проблемы и предпринимаются необходимые действия для снижения риска ее повторного возникновения. Сотрудники организации могут проходить обучение, обеспечивающее различные уровни подготовки Самостоятельная оценка уровня зрелости системы управления рисками в организации Использование приведенного ниже перечня оценок обеспечивает более точный способ определения уровня зрелости организации. Хотя полученные оценки будут субъективными, однако, тщательно анализируя каждую оценку, можно определить уровень подготовки организации к внедрению процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт. Оцените состояние дел в организации по шкале от 0 до 5, используя приведенные ранее определения уровня зрелости. Политики и процедуры обеспечения защиты информации являются полными, лаконичными, понятными и тщательно задокументированными. Для всех должностей, требующих выполнения задач по обеспечению информационной безопасности, разработаны четко определенные и понятные роли и обязанности. Политики и процедуры обеспечения защиты при доступе сторонних лиц к деловым данным тщательно задокументированы. Например, компании, выполняющие удаленную разработку приложений для внутренних бизнес-средств, имеют права доступа к сетевым ресурсам, позволяющие эффективно организовать совместную работу и завершить выполнение поставленных задач, однако при этом им предоставляются лишь минимально необходимые права. Инвентаризация ИТ-активов (таких как оборудование, программное обеспечение и хранилища данных) выполняется аккуратно и своевременно. Организация использует элементы контроля, обеспечивающие защиту бизнесданных от несанкционированного доступа как изнутри организации, так и снаружи. В организации работает эффективная система оповещения пользователей о политиках и рекомендациях в области информационной безопасности (например, путем проведения тренингов или рассылки новостей). В организации используются эффективные элементы контроля физического доступа к компьютерной сети и другим ИТ-активам. Новые компьютерные системы вводятся в эксплуатацию с соблюдением стандартов безопасности организации и с использованием стандартных методик, основанных на применении образов дисков, сценариев и других автоматизированных средств. Обновление программного обеспечения основных производителей на большей части компьютеров организации осуществляется автоматически, с помощью эффективной системы управления исправлениями. 34 Глава 3. Обзор управления рисками безопасности В организации создана группа реагирования на инциденты, которая разработала и задокументировала эффективные процессы отслеживания нарушений системы безопасности и реагирования на эти нарушения. Все инциденты тщательно анализируются, пока не будет выявлена основная причина инцидента, а все проблемы не будут устранены. В организации используется всеобъемлющая антивирусная система, включающая многоуровневую защиту, обучение пользователей и эффективные методики реагирования на вирусные атаки. Процессы поддержания работы пользователей тщательно задокументированы и хотя бы частично автоматизированы, в результате чего новые сотрудники, поставщики и партнеры своевременно получают необходимый уровень доступа к ИТ-системам организации. Кроме того, эти процессы должны поддерживать временное отключение и удаление учетных записей пользователей, в которых больше нет необходимости. Доступ к компьютерам и сети контролируется с помощью системы авторизации и проверки подлинности пользователей, списков управления доступом к данным и проактивного мониторинга нарушений политики. Разработчики приложений прослушивают учебные курсы и обеспечиваются подробной информацией о стандартах безопасности, применяемых при создании и проверке качества программного обеспечения. В организации разработаны и тщательно задокументированы методы и системы обеспечения непрерывной работы, которые регулярно проверяются путем моделирования и проведения тренировок. В организации внедрены и эффективно работают программы, позволяющие убедиться, что все сотрудники выполняют свои должностные обязанности в соответствии с требованиями законодательства. Для проверки соответствия стандартным рекомендациям по защите бизнес-активов регулярно осуществляются аудит и контроль силами сторонних организаций. Вычислите число баллов для организации, просуммировав баллы, полученные при оценке каждого приведенного выше утверждения. Теоретически организация может набрать от 0 до 85 баллов, однако на практике лишь немногие организации получат самую высокую или самую низкую оценку. Если организация набрала 51 балл или более, это означает, что, по всей видимости, организация хорошо подготовлена к внедрению процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, и использованию всех его возможностей. Если организация набрала от 34 до 50 баллов, это показывает, что организация предприняла значительные усилия по управлению рисками безопасности и готова к постепенному внедрению данного процесса. Подобным организациям рекомендуется рассмотреть возможность использования этого процесса в нескольких подразделениях в течение нескольких месяцев, а лишь потом переходить к внедрению в рамках всей организации. Организациям, набравшим менее 34 баллов, рекомендуется внедрять этот процесс постепенно, начав внедрение с создания группы управления рисками безопасности и использования процесса в одном из подразделений в течение нескольких месяцев. Когда организация убедится в полезности данного процесса, используя его для снижения рисков в выбранном подразделении, этот процесс следует внедрить еще в двух или трех подразделениях. Дальнейшее внедрение процесса может сопровождаться внесением значительных изменений и должно происходить постепенно, чтобы избежать отрицательного влияния на способность организации к выполнению основных бизнес-целей. Поэтому при внедрении данного процесса следует руководствоваться здравым смыслом — каждая оставленная без защиты система повышает риск безопасности и риск наступления правовой ответственности, и лучшим методом предотвращения этих последствий является использование собственных знаний о системе. Если организация не согласна с предложением внедрять данный процесс постепенно и считает, что внедрение должно выполняться безотлагательно, она должна действовать на свое усмотрение. Руководство по управлению рисками безопасности 35 Организация должна тщательно выбрать подразделение для реализации пилотных программ. При выборе следует учитывать, насколько важны вопросы безопасности для данного подразделения и каким образом определяется безопасность с точки зрения доступности, целостности и конфиденциальности услуг и данных. Ниже приводятся примеры вопросов, используемых при выборе подразделений для пилотной программы. Превышает ли уровень зрелости системы управления рисками в выбранном подразделении средний уровень для организации? Будут ли руководители выбранного подразделения активно поддерживать программу? Обеспечивает ли выбранное подразделение высокий уровень наглядности в рамках организации? В случае успешного завершения пилотной программы процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, будет ли полезный опыт данной программы передан остальным подразделениям организации? Этими же критериями необходимо руководствоваться при выборе подразделения для дальнейшего расширения программы. Примечание. Национальный институт стандартов и технологий США опубликовал Руководство по самостоятельной оценке безопасности ИТ-систем, которое может помочь в оценке уровня зрелости организации. Чтобы ознакомиться с данным руководством, обратитесь по адресу http://csrc.nist.gov/publications/nistpubs/800-26/sp800-26.pdf. Распределение ролей и обязанностей В силу требований, предъявляемых к взаимодействию между группами и разделению обязанностей, четкое распределение ролей и обязанностей является важнейшим фактором успеха любой программы управления рисками. В таблице 3.3 описаны основные роли и обязанности, используемые процессом управления рисками безопасности, предлагаемым корпорацией Майкрософт. Таблица 3.3. Основные роли и обязанности в процессе управления рисками безопасности, предлагаемом корпорацией Майкрософт Должность Основные обязанности Ответственный руководитель Руководит всеми операциями по управлению рисками в организации (например, разработка, финансирование, распределение полномочий и поддержка группы управления рисками безопасности). Как правило, эту роль исполняет один из руководителей организации (например, руководитель службы безопасности, руководитель ИТ-подразделения). Данная роль является последней инстанцией принятия решений при определении допустимых рисков для организации Владелец организации Сотрудник, исполняющий данную роль, несет ответственность за материальные и нематериальные активы организации, а также за приоритизацию бизнес-активов и определение уровней влияния на активы. Кроме того, владельцы организаций должны определять допустимый уровень рисков, однако окончательное решение принимается ответственным руководителем на основании отчета группы информационной безопасности Группа информационной безопасности Несет ответственность за более масштабный процесс управления рисками, включая выполнение этапов оценки рисков и оценки эффективности программы, а также разработку функциональных требований к безопасности и измерение эффективности элементов контроля и общей эффективности программы управления рисками безопасности 36 Глава 3. Обзор управления рисками безопасности Должность Основные обязанности Группа информационных технологий Несет ответственность за ИТ-архитектуру, проектирование и эксплуатацию Группа управления рисками безопасности Несет ответственность за общее выполнение программы управления рисками, этап оценки рисков и определение приоритетов рисков для бизнеса. В данную группу в обязательном порядке входят координатор и секретарь Координатор оценки рисков Сотрудник, играющий основную роль в группе управления рисками безопасности и ведущий обсуждение собранных данных. Кроме того, этот сотрудник может руководить всем процессом управления рисками Секретарь оценки рисков Ведет подробные записи в процессе обсуждения собранных данных Ответственные за нейтрализацию риска Сотрудники, несущие ответственность за внедрение и поддержание работоспособности решений для контроля, призванных снизить риски до приемлемого уровня. Данная роль включает группы информационных технологий, а в некоторых случаях — владельцев организаций Организационный комитет по обеспечению безопасности Включает группу управления рисками безопасности, представителей группы информационных технологий и некоторых владельцев организаций. Данный комитет, как правило, возглавляется ответственным руководителем и несет ответственность за выбор стратегий нейтрализации риска и определение допустимого уровня рисков для организации Заинтересованное Общий термин, относящийся к прямым и косвенным участникам лицо процесса или программы; используется процессом управления рисками безопасности, предлагаемым корпорацией Майкрософт. В число заинтересованных лиц могут входить также группы, работающие вне ИТ-отрасли (например, финансовая группа, группа связей с общественностью и отдел кадров) Группа управления рисками безопасности должна учитывать, что новые участники процесса управления рисками могут не полностью понимать свою роль. Всегда предоставляйте участникам процесса общие сведения о процессе. Эти мероприятия призваны помочь найти устраивающее всех решение и подчеркнуть тот факт, что управление рисками входит в обязанности всех участников. На следующей схеме (рис. 3.5) в общем виде показаны основные участники и связи между ними. Данная схема может использоваться для отображения информации об определенных ранее ролях и обязанностях и должна давать общее представление о программе управления рисками. Обобщая приведенный выше материал, можно сказать, что ответственный руководитель несет исключительную ответственность за определение допустимого уровня риска и предоставляет группе управления рисками безопасности указания, основанные на упорядочивании рисков для бизнеса. Группа управления рисками безопасности выполняет оценку рисков и определяет функциональные требования для снижения риска до допустимого уровня, а затем работает вместе с ИТ-группами, несущими ответственность за выбор, внедрение и эксплуатацию решений по нейтрализации риска. Последней связью, показанной на схеме, является связь, соответствующая измерению эффективности элементов контроля, выполняемому группой управления Руководство по управлению рисками безопасности 37 рисками безопасности. Как правило, это осуществляется в форме аудиторских отчетов, которые также передаются ответственному руководителю. Рис. 3.5. Обзор основных ролей и обязанностей, используемых в процессе управления рисками безопасности, предлагаемом корпорацией Майкрософт Создание группы управления рисками безопасности Прежде чем приступать к процессу оценки рисков, не забудьте определить роли в группе управления рисками безопасности. Поскольку управление рисками применяется в масштабах всей организации, сотрудники, не входящие в группу информационной безопасности, могут пожелать войти в команду. В этом случае необходимо четко определить роль каждого члена группы и согласовать ее с ролями и обязанностями, определенными выше в общей программе управления рисками. Определение ролей на начальных этапах уменьшает число недоразумений и помогает в принятии решений в рамках процесса. Все члены группы должны понимать, что группа информационной безопасности несет ответственность за весь процесс. Это очень важно, поскольку группа информационной безопасности — это единственная группа, являющаяся основным заинтересованным лицом на всех этапах процесса, включая этап составления отчетов для руководства. 38 Глава 3. Обзор управления рисками безопасности Роли и обязанности группы управления рисками безопасности После формирования группы управления рисками безопасности необходимо создать определенные роли и поддерживать их на протяжении всего процесса. Основными ролями являются описанные ниже роли координатора и секретаря оценки рисков. Координатор оценки рисков должен обладать глубокими знаниями всего процесса управления рисками, понимать особенности работы организации и технические особенности рисков безопасности, связанных с выполнением деловых функций, и уметь преобразовывать деловые сценарии в технические риски в процессе обсуждения рисков. В частности, координатор оценки рисков должен знать как технические угрозы и уязвимости, возникающие в работе мобильных работников, так и деловую ценность подобных работников. Например, платежи заказчиков не будут обработаны, если мобильный работник не сможет получить доступ к корпоративной сети. Координатор оценки рисков должен понимать особенности подобных ситуаций и уметь выявлять технические риски и требования к потенциальному элементу контроля (такие как требования к проверке подлинности и конфигурации мобильных устройств). Если возможно, на должность координатора оценки рисков следует назначать сотрудника, занимавшегося ранее оценкой рисков и знающего общие приоритеты организации. Если на эту должность невозможно назначить сотрудника с опытом оценки рисков, следует заручиться поддержкой квалифицированного партнера или консультанта. Кроме того, необходимо включить в команду члена группы информационной безопасности, знающего особенности организации и заинтересованных лиц. Примечание. Передавая функции координатора оценки рисков внешнему подрядчику, примите меры, чтобы после прекращения работы консультантов организация не потеряла информацию о ведении дел, безопасности и взаимоотношениях между заинтересованными лицами. Помните о значении процесса управления рисками для заинтересованных лиц и группы информационной безопасности. Секретарь оценки рисков ведет записи и документирует операции планирования и сбора данных. Хотя на данном этапе его обязанности могут казаться недостаточно формализованными для четкого определения роли, однако подробное ведение записей полностью окупится в дальнейшем на этапах определения приоритетов и принятия решений. Одним из наиболее важных аспектов управления рисками является распространение информации о рисках с использованием терминов, которые понятны заинтересованным лицам и могут применяться ими в работе. Тщательное документирование упрощает этот процесс, позволяя при необходимости предоставлять документацию в письменном виде. Заключение Главы 1–3 содержат обзор управления рисками и описание общих целей и подходов, необходимых, чтобы заложить основу успешной реализации процесса управления рисками, предлагаемого корпорацией Майкрософт. В следующих главах подробно рассматриваются отдельные этапы данного процесса — оценка рисков, поддержка принятия решений, реализация контроля и оценка эффективности программы. Глава 4. Оценка рисков Обзор Обобщенный процесс управления рисками включает четыре этапа: оценку рисков, поддержку принятия решений, реализацию элементов контроля и оценку эффективности программы. Управление рисками показывает, каким образом формальная программа позволяет сформировать целостную методику использования ограниченных ресурсов для управления рисками в рамках организации. Внедрение управления рисками дает возможность разработать экономически эффективную среду контроля, позволяющую измерять риски и уменьшать их до допустимого уровня. Этап оценки рисков представляет собой формальный процесс определения и упорядочения рисков в рамках организации. Процесс управления рисками, предлагаемый корпорацией Майкрософт, содержит подробные рекомендации по оценке рисков и разбивает этап оценки рисков на следующие три шага. 1. Планирование. Разработка основы для успешной оценки рисков. 2. Координированный сбор данных. Сбор информации о рисках в ходе координированных обсуждений рисков. 3. Приоритизация рисков. Ранжирование выявленных рисков на основе непротиворечивого и повторяемого процесса. По завершении этапа оценки рисков организация получает ранжированный по приоритетам перечень рисков, необходимый на этапе поддержки принятия решений, который подробно описан в главе 5 «Поддержка принятия решений». На следующей схеме (рис. 4.1) в общем виде показаны процесс управления рисками и роль оценки рисков в данном процессе и указаны три шага этапа оценки рисков. Рис. 4.1. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт: этап оценки рисков 40 Глава 4. Оценка рисков Планирование Надлежащее планирование оценки рисков является необходимым условием успешной работы программы управления рисками в целом. Неправильное определение сферы действия и отсутствие надлежащего согласования и одобрения на этапе оценивания рисков снижает эффективность других этапов программы управления рисками. Оценка рисков может оказаться сложным процессом, требующим вложения значительных средств. Задачи и рекомендации, необходимые на этапе планирования, рассматриваются в следующем разделе данной главы. Координированный сбор данных По завершении планирования необходимо собрать у заинтересованных лиц организации информацию, относящуюся к управлению рисками. В дальнейшем эта информация будет использоваться на этапе поддержки принятия решений. На этом шаге собираются следующие основные данные. Активы организации. Вся информация о важных для организации активах. Описание актива. Краткое описание каждого актива, его ценность и его владелец для облегчения общего понимания актива на этапе оценки рисков. Угрозы безопасности. Причины и события, которые могут оказывать на актив негативное влияние и приводить к потере конфиденциальности, целостности или доступности актива. Уязвимости. Слабости или отсутствие элементов контроля, которые могут использоваться для влияния на актив. Текущая среда контроля. Описание используемых в настоящее время элементов контроля и их эффективности в рамках организации. Предлагаемые элементы контроля. Предложения по снижения риска. Операции тематического сбора данных представляют собой основную часть операций взаимодействия и совместной работы различных групп на этапе оценки рисков. Задачи и рекомендации, относящиеся к тематическому сбору данных, подробно описаны в третьем разделе данной главы. Приоритизация рисков В процессе тематического сбора данных группа управления рисками безопасности начинает сортировать большие объемы информации, собранной для приоритизации рисков. Приоритизация рисков является первым шагом данного этапа и содержит элемент субъективности. Процесс приоритизации является субъективным по своей природе, поскольку фактически требует прогнозирования будущих событий. Поскольку результаты оценки рисков влияют на дальнейшее выделение средств на нужды ИТ, формирование прозрачного процесса с четко определенными ролями и обязанностями является важнейшим условием утверждения полученных результатов и одобрения мероприятий по снижению рисков. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, предоставляет рекомендации по выявлению и приоритизации рисков на основе непротиворечивого и повторяемого подхода. Открытый и повторяемый подход помогает группе управления рисками быстро найти удовлетворяющее всех решение, уменьшив потенциальные задержки, вызываемые субъективным характером процесса приоритизации рисков. Задачи и рекомендации, относящиеся к приоритизации рисков, подробно описаны в четвертом разделе данной главы. Руководство по управлению рисками безопасности 41 Входные данные, необходимые для оценки рисков Каждый шаг этапа оценки рисков содержит перечень предварительно определенных задач и соответствующих им входных данных, а этап в целом требует не конкретных входных данных, а тщательно проработанной основы для оценки рисков. Как было сказано в главе 1, этап оценки рисков требует поддержки со стороны руководства организации, одобрения заинтересованных лиц и четкого определения ролей и обязанностей. В следующих разделах эти вопросы будут рассмотрены более подробно. Участники этапа оценки рисков Оценка рисков требует межгруппового взаимодействия и распределения между заинтересованными лицами обязанностей по решению задач в рамках процесса. Чтобы уменьшить число ошибочных толкований ролей в рассматриваемом процессе, следует распространить сведения о проверках и «противовесах» в рамках ролей и обязанностей по управлению рисками. При выполнении оценки необходимо сообщить заинтересованным лицам информацию о ролях и убедить их, что группа управления рисками безопасности не нарушает определяемые ролями границы полномочий. В таблице 4.1 перечислены роли и основные обязанности заинтересованных лиц на этом этапе процесса управления рисками. Таблица 4.1. Роли и обязанности в программе управления рисками Роль Обязанности Владелец организации Определение стоимостей бизнес-активов Группа информационной безопасности Определение вероятности влияния на бизнес-активы ИТ: проектирование Разработка технических решений и оценка затрат на проектирование ИТ: операции Разработка операционных компонентов решения и оценка операционных затрат Следующие разделы посвящены планированию, тематическому сбору данных и приоритизации рисков на этапе оценки рисков. Кроме того, в этих разделах будут рассмотрены встроенные тактические проверки и «противовесы». Средства оценки рисков В процессе оценки рисков осуществляется сбор данных о рисках, а затем собранные данные используются для приоритизации рисков. На этом этапе можно использовать следующие четыре средства, находящиеся в папке Tools and Templates, которая была создана при распаковке архива, содержащего данное руководство и сопутствующие файлы. Шаблон Data Gathering Template (SRMGTool1-Data Gathering Tool.doc). Этот шаблон поможет проводить обсуждения при сборе данных о рисках. Рабочий лист Summary Level Risk Analysis Worksheet (SRMGTool2-Summary Risk Level.xls). Данный рабочий лист Microsoft® Excel поможет организациям выполнить начальный этап анализа рисков — анализ общего уровня. Рабочий лист Level Risk Analysis Worksheet (SRMGTool3-Detailed Level Risk Prioritization.xls). Данный рабочий лист Excel поможет организациям выполнить подробный анализ основных рисков, выявленных в процессе анализа общего уровня. Примерное расписание Sample schedule (SRMGTool4-Sample Project Schedule.xls). Оно поможет в планировании операций для данного этапа. 42 Глава 4. Оценка рисков Кроме того, в приложении Б «Типичные активы информационных систем» перечислены типичные активы информационных систем, встречающиеся в организациях различных типов. Результаты этапа оценки рисков По завершении этапа оценки рисков организация получает ранжированный по приоритетам перечень рисков, включающий качественное ранжирование и количественные оценки. Данный перечень используется на этапе поддержки принятия решений, который описан в следующей главе. Планирование Планирование является наиболее важным шагом, обеспечивающим одобрение со стороны заинтересованных лиц и их поддержку на протяжении всего процесса управления рисками. Одобрение заинтересованных лиц — необходимое условие реализации данного процесса, поскольку группе управления рисками безопасности требуется активное участие других заинтересованных лиц. Поддержка также является чрезвычайно важной, поскольку, если для снижения рисков необходимы новые элементы контроля, результаты оценки могут влиять на размеры средств, выделяемых заинтересованным лицам. Основные задачи этапа планирования состоят в надлежащем согласовании этапа оценки рисков с бизнес-процессами, точном определении сферы действия оценки и получении одобрения заинтересованных лиц. В следующем разделе эти задачи рассматриваются более подробно, там же описаны условия их успешного решения. Согласование Рекомендуется, чтобы начало этапа оценки рисков предшествовало составлению бюджета организации. Согласование упрощает получение поддержки руководства и повышает прозрачность в рамках организации и ИТ-подразделений при разработке бюджетов на следующий финансовый год. Надлежащее планирование времени позволяет заинтересованным лицам принимать активное участие в процессе планирования, что помогает найти удовлетворяющее всех решение на этапе оценки. Группу информационной безопасности часто рассматривают как группу реагирования, нарушающую работу организации и застающую сотрудников врасплох известиями о сбоях систем и остановке работы. Рациональное планирование времени на этапе оценки является важным условием, необходимым для обеспечения поддержки и помогающим организации осознать, что обеспечение безопасности представляет собой общее дело всех сотрудников и является жизненно важным для организации. Еще одним преимуществом оценки рисков является демонстрация того факта, что группа информационной безопасности может рассматриваться не как орган надзора за соблюдением политик в аварийных ситуациях, а, скорее, как проактивный партнер. Данное руководство предлагает пример временной шкалы проекта, помогающий согласовать процесс оценки рисков в организации. Разумеется, группа управления рисками безопасности не должна скрывать информацию о рисках в ожидании цикла бюджетирования. Согласование расписания оценки является просто рекомендацией, выработанной ИТ-подразделением корпорации Майкрософт в ходе оценки рисков. Примечание. Надлежащее согласование процесса оценки рисков и цикла планирования бюджета обеспечивает преимущества при проведении внешнего и внутреннего аудита, однако вопросы координирования подобных операций и определения сферы их действия выходят за пределы данного руководства. Руководство по управлению рисками безопасности 43 Определение сферы действия В процессе планирования необходимо четко определить сферу действия оценки рисков. Чтобы эффективно управлять рисками в организации, в сфере действия оценки рисков должны документироваться все функции организации, входящие в оценку риска. Если размер организации не позволяет выполнять оценку рисков в масштабах всей компании, необходимо выбрать часть организации, которая будет входить в сферу действия оценки рисков, и определить заинтересованных лиц. Как было сказано в главе 2, если организация не имеет опыта управления рисками, можно начать с реализации данного процесса в отдельном прозрачном сегменте. Например, выбор конкретного приложения по управлению персоналом или ИТ-службы (такой как служба удаленного доступа) может помочь продемонстрировать преимущества данного процесса и стать трамплином для оценки рисков в рамках организации. Примечание. Зачастую организации не могут правильно определить сферу действия управления рисками. Поэтому перед выполнением дальнейших шагов необходимо выбрать оцениваемые области организации и получить одобрение руководства. Выбор сферы действия должен регулярно обсуждаться на встречах заинтересованных лиц в ходе процесса и быть понятен всем заинтересованным лицам. При планировании необходимо также определить сферу действия самой оценки рисков. В отрасли информационной безопасности термин «оценка» имеет различные значения, что может привести к его ошибочной интерпретации заинтересованными лицами, не имеющими технической подготовки. Например, оценка уязвимостей выполняется для выявления технологических слабостей конфигурации или операций. Термин «оценка соответствия» может использоваться для описания результатов аудита или сравнения текущих элементов контроля с формальными политиками. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, определяет оценку рисков как процесс выявления и приоритизации угрожающих организации корпоративных рисков безопасности в сфере ИТ. Это определение можно изменять в соответствии с потребностями конкретной организации. Например, в некоторых случаях группы управления рисками безопасности могут включать в сферу действия вопросы безопасности персонала. Одобрение заинтересованных лиц Оценка рисков требует активного участия заинтересованных лиц. Наилучшим вариантом является проведение неформальной работы со всеми заинтересованными лицами на начальных стадиях процесса, чтобы убедиться, что они понимают важность оценки, свои роли и предъявляемые к ним требования по соблюдению сроков. Любой опытный координатор оценки рисков может сказать, что существуют отличия между одобрением проекта заинтересованными лицами и утверждением заинтересованными лицами сроков и приоритетов проекта. Наилучшим способом получения поддержки заинтересованных лиц является предварительное ознакомление с концепциями и операциями в процессе оценки рисков. Предварительное ознакомление может включать неформальные встречи с заинтересованными лицами перед ознакомлением с формальными требованиями. Необходимо обратить внимание на факторы, благодаря которым проактивная оценка помогает заинтересованным лицам в долгосрочной перспективе путем поиска элементов контроля, способствующих устранению нарушения системы безопасности при дальнейшей работе. Рассмотрение в ходе обсуждения возникавших ранее нарушений системы безопасности является эффективным методом напоминания о возможном влиянии подобных нарушений на работу организации. Примечание. Чтобы помочь заинтересованным лицам понять особенности данного процесса, подготовьте краткий обзор, показывающий необходимость и преимущества оценки, и ознакомьте с ним как можно больше заинтересованных лиц. Если они начнут рассказывать друг другу об этом обзоре, значит, вы достигли успеха. При описании преимуществ процесса оценки рисков в качестве отправного пункта можно использовать материал, изложенный в разделе «Основные положения» данного руководства. 44 Глава 4. Оценка рисков Подготовка к внедрению: формирование ожиданий Важность правильного формирования ожиданий невозможно переоценить. Формирование надлежащих ожиданий является необходимым условием успешной оценки рисков, поскольку данный процесс требует активного участия различных групп, которые могут принадлежать к разным подразделениям организации. Кроме того, участники должны понимать и согласовывать критерии достижения успешных результатов для своих ролей и для процесса в целом. Если хотя бы одна из этих групп не понимает особенностей процесса или не принимает в нем активного участия, это может отрицательно сказаться на эффективности программы в целом. При поиске удовлетворяющего всех решения в процессе планирования сделайте формирование ожиданий более важной задачей, чем определение ролей, обязанностей и уровней участия, требуемых от других заинтересованных лиц. Необходимо также распространять информацию о проблемах, возникающих в ходе оценки. Например, чтобы избежать непонимания, рекомендуется четко описать процессы выявления и приоритизации рисков. Преодоление субъективности Иногда владельцев организаций раздражает, что внешняя группа (в данном случае группа информационной безопасности) прогнозирует возможность рисков безопасности, что может повлиять на формирование бюджета. Чтобы снизить их недовольство, можно ознакомить их с ожиданиями относительно целей процесса управления рисками и заверить их, что в процессе управления рисками будут строго соблюдаться роли и обязанности. В частности, группа информационной безопасности должна осознавать, что ценность бизнес-активов определяется владельцами организаций. Кроме того, это означает, что заинтересованные лица должны полагаться на вывод группы информационной безопасности, чтобы оценить вероятность влияния угроз на работу организации. Прогнозирование будущего субъективно по своей природе. Владельцы организации должны признать и поддержать факт, что группа информационной безопасности будет использовать их опыт для оценивания вероятностей рисков. Установите эти взаимоотношения на ранних стадиях проекта и продемонстрируйте полномочия, опыт и общность целей группы информационной безопасности и владельцев организаций. Завершив планирование, определение ролей и обязанностей и формирование ожиданий, организация будет готова приступить к практическим шагам по оценке рисков: тематическому сбору данных и приоритизации рисков. Эти шаги описаны в двух следующих разделах, а затем в главе 5 будет рассмотрен этап поддержки принятия решений. Координированный сбор данных Во вводном разделе данной главы содержатся общие сведения о процессе оценки рисков и о трех основных шагах данного процесса: планировании, тематическом сборе данных и приоритизации рисков. Завершив планирование, необходимо получить сведения о рисках у заинтересованных лиц со всей организации. Эта информация поможет выявить риски и правильно определить их приоритеты. Данный раздел разбит на три части. В первой части подробно рассмотрены процесс сбора данных и условия успешного сбора информации о рисках. Во второй части описаны мероприятия по сбору данных о рисках с помощью встреч с заинтересованными лицами (как обладающими, так и не обладающими технической подготовкой). В третьей части рассказано о действиях по объединению собранных данных в набор формулировок влияний, как описано в главе 3. Чтобы завершить процесс оценки рисков, этот перечень формулировок влияния используется как входные данные на этапе приоритизации рисков, описанном в следующем разделе. Руководство по управлению рисками безопасности 45 Условия успешного сбора данных Может показаться, что бесполезно задавать подробные вопросы об оценке рисков в сфере ИТ людям, которые не являются специалистами по обеспечению безопасности. Однако опыт оценки рисков сотрудниками ИТ-подразделения корпорации Майкрософт свидетельствует, что необходимо знать мнение всех заинтересованных лиц (как имеющих, так и не имеющих техническую подготовку) о рисках для активов, которыми они управляют. Кроме того, специалисты по информационной безопасности должны подробно узнать мнение заинтересованных лиц, чтобы перевести сведения об их средах в приоритезированные риски. Встречи с заинтересованными лицами помогают им понять риски в осмысленных и поддающихся оценке терминах. Кроме того, заинтересованные лица определяют размеры затрат на ИТ или влияют на них. Если они не осознают потенциальное влияние рисков на бизнес организации, процесс локализации активов может вызывать значительные трудности. Владельцы организаций определяют также культуру компании и влияют на поведение пользователей, что само по себе может являться мощным средством управления рисками. После выявления рисков группе информационной безопасности потребуется поддержка заинтересованных лиц для локализации активов и нахождения удовлетворяющего всех решения относительно определения и приоритизации рисков. Некоторые группы информационной безопасности, не имеющие программы проактивного управления рисками, подталкивают организации к дальнейшим действиям, рассказывая о тяжести возможных последствий. Однако данная стратегия может обеспечить лишь кратковременный эффект. Если программа управления рисками должна поддерживаться на протяжении длительного времени, группе информационной безопасности необходимо научиться получать поддержку организации. Первым шагом на пути к получению подобной поддержки является проведение встреч с заинтересованными лицами. Получение поддержки Владельцы организаций играют важнейшую роль в процессе оценки рисков — они несут ответственность за выявление бизнес-активов своих организаций и оценку ущерба от возможного негативного влияния на эти активы. Формализовав эти обязанности, группа информационной безопасности и владельцы организаций принимают на себя равную ответственность за успех управления рисками. В большинстве случаев специалисты по обеспечению безопасности и заинтересованные лица, не имеющие технической подготовки, не могут самостоятельно реализовать эту возможность. Выступая в качестве экспертов по управлению рисками, специалисты по информационной безопасности должны взять на себя инициативу по заполнению пробелов в знаниях заинтересованных лиц в ходе обсуждения рисков. Как было указано в предыдущей главе, поддержка ответственного руководителя, знающего особенности организации, значительно упрощает налаживание подобных взаимоотношений. Обсуждения и опросы Многие методы управления рисками безопасности требуют, чтобы члены группы информационной безопасности задавали заинтересованным лицам четко сформулированные вопросы (например: «Опишите, пожалуйста, ваши политики обеспечения надлежащей сегментации обязанностей» или «В чем состоит принятый у вас процесс анализа политик и процедур?») и записывали их ответы. Внимательно следите за тоном и направлением подобных бесед. Чтобы упростить организацию двусторонней беседы, рекомендуется уделять основное внимание «незаконченным» вопросам. Это также позволяет заинтересованным лицам следовать духу вопроса, а не просто сообщать координатору оценки рисков то, что он хочет услышать. Обсуждение рисков не является попыткой аудита задокументированных политик — оно призвано обеспечить понимание особенностей организации и возникающих при ее работе рисков безопасности. Хотя мнение заинтересованных лиц, не имеющих технической подготовки, представляет собой определенную ценность, как правило, его недостаточно для достижения поставленных целей — группа управления рисками безопасности должна самостоятельно (независимо от владельца организации) выявить, изучить и проанализировать все риски для каждого актива. 46 Глава 4. Оценка рисков Обеспечение доброжелательности Обеспечение информационной безопасности представляет собой сложную задачу, поскольку зачастую считается, что мероприятия по снижению рисков приводят к снижению удобства работы и производительности труда сотрудников. Поэтому необходимо использовать координированные обсуждения для налаживания взаимоотношений с заинтересованными лицами. Требования законодательства, необходимость сохранения конфиденциальности, конкурентное давление и возросшая потребительская осведомленность приводят к тому, что руководители и лица, принимающие деловые решения, начинают осознавать, что обеспечение безопасности является одним из важнейших компонентов бизнеса. Помогите заинтересованным лицам осознать важность управления рисками и понять свою роль в рамках программы. В некоторых случаях хорошие взаимоотношения между группой информационной безопасности и заинтересованными лицами могут обеспечить больший эффект, чем фактические данные, собранные в ходе встреч, что является небольшим, но важным успехом в ходе общего процесса управления рисками. Подготовка к обсуждению рисков Прежде чем перейти к обсуждению, группа управления рисками безопасности должна изучить каждый подлежащий обсуждению элемент и понять все особенности этих элементов. В следующих разделах изложены рекомендации и более полные определения каждого элемента в полной формулировке риска, которые необходимы в процессе подготовки к обсуждениям с заинтересованными лицами. Определение входных данных для оценки рисков Группа оценки рисков должна тщательно готовиться к встречам с заинтересованными лицами. Работа группы становится более эффективной, а обсуждения приносят больше результатов, если группа оценки рисков хорошо знает особенности организации, ее техническую среду и предыдущие оценки рисков. Чтобы упростить сбор информации, необходимой для оценки рисков, воспользуйтесь следующим списком. Новые факторы развития бизнеса. Обновите имеющиеся сведения о приоритетах организации и внесите новые данные, которые учитывают изменения, произошедшие после последней оценки. Обратите особое внимание на операции приобретения и слияния. Предыдущие оценки рисков. Изучите выполнявшиеся ранее оценки рисков, чтобы проанализировать перспективы. Группе оценки рисков может потребоваться согласовать новые оценки с выполнявшимися ранее. Аудит. Изучите все аудиторские отчеты, относящиеся к оценке рисков. Результаты аудита необходимо учитывать как при оценке рисков, так и при выборе решения для контроля. Инциденты с системой безопасности. Используйте сведения о возникавших ранее проблемах с безопасностью для выявления ключевых активов, определения их стоимости и выявления преобладающих уязвимостей и дефицитов контроля. Отраслевые мероприятия. Выявляйте новые тенденции внутри организации и внешние влияния. Требования национального, местного и международного законодательства могут оказывать значительное влияние на состояние рисков в организации. Выявление новых тенденций может потребовать от организации выполнения больших объемов работы по анализу и оценке, поэтому можно выделить отдельного сотрудника, который в течение года отслеживал бы это. Бюллетени. Ознакомьтесь с информацией о проблемах в области безопасности, распространяемой разработчиками программных продуктов и публикуемой в Интернете и группах новостей. Руководства по информационной безопасности. Выясните, появились ли новые тенденции, средства и методики управления рисками. Для упрощения оценки рисков и повышения ее точности, а также для упрощения поиска новых стратегий снижения рисков можно воспользоваться отраслевыми и международными стандартами. Руководство по управлению рисками безопасности 47 В данном руководстве используются концепции, изложенные в стандарте ISO (International Standards Organization) 17799 и в ряде других стандартов. Тщательная оценка и применение стандартов позволяют воспользоваться плодами работы других специалистов и повышают доверие со стороны заинтересованных лиц в организации. Стандарты можно отдельно рассмотреть в ходе обсуждений рисков, чтобы убедиться, что оценка учитывает все области информационной безопасности. Выявление и классификация активов Сфера действия оценки рисков определяет части организации, подлежащие рассмотрению в процессе обсуждения собранных данных. Для обсуждения рисков необходимо найти бизнес-активы, находящиеся внутри данной сферы действия. Активами считается все, что представляет ценность для организации, включая как материальные активы (например, физическую инфраструктуру), так и нематериальные (например, репутацию организации и цифровую информацию). Наиболее эффективный подход заключается в том, чтобы соблюдать максимальную точность при определении бизнес-активов (например, сведений о заказчиках в системе управления отношениями с заказчиками). Определяя актив, не следует обсуждать формулировки влияний, поскольку они характеризуют потери или повреждения, которые могут коснуться организации. Примером формулировки влияния может быть доступность сведений о заказчиках в системе управления отношениями с заказчиками. Формулировки влияний будут рассматриваться далее в процессе обсуждения рисков. Обратите внимание, что в процессе обсуждения для каждого актива может быть выявлено несколько влияний. Определив актив, необходимо сразу выявить или подтвердить его владельца. Зачастую выявление ответственного за актив сотрудника или группы оказывается намного сложнее, чем кажется. Сведения о конкретных владельцах активов, полученные в ходе обсуждения рисков, необходимо задокументировать. Эти сведения могут потребоваться в процессе приоритизации рисков, чтобы подтвердить эти сведения и осведомить о рисках владельцев активов. Чтобы помочь в определении категорий рисков, можно сгруппировать их в бизнессценарии (например, сценарий интерактивных банковских транзакций или разработки исходного кода). При работе с заинтересованными лицами, не имеющими технической подготовки, начните обсуждение актива с использованием бизнес-сценариев, а затем задокументируйте конкретный актив в каждом сценарии. После выявления активов следующей задачей владельцев организаций является классификация каждого актива в терминах его потенциального влияния на организацию. Классификация активов является критическим компонентом общего процесса управления рисками. Чтобы упростить данный процесс, воспользуйтесь приведенными ниже сведениями. Активы Бизнес-активы могут быть материальными и нематериальными. Каждый тип актива необходимо определять таким образом, чтобы владельцы организаций могли определить стоимость актива в показателях организации. Обе категории активов требуют, чтобы заинтересованное лицо указало ожидания в форме прямых денежных убытков и косвенного финансового влияния. К материальным активам относится физическая инфраструктура (например, центры обработки данных, серверы и имущество). К нематериальным активам относятся данные и другая ценная для организации информация, хранящаяся в цифровой форме (например, банковские транзакции, расчеты платежей, спецификации и планы разработки продуктов). В некоторых организациях может оказаться полезным определение третьего типа активов — ИТ-служб. ИТ-служба представляет собой сочетание материальных и нематериальных активов. Например, корпоративная служба электронной почты включает физические серверы и использует физическую сеть, но при этом может 48 Глава 4. Оценка рисков содержать важные цифровые данные. Кроме того, ИТ-службу можно рассматривать как актив потому, что, как правило, у физического актива и актива данных разные владельцы. Например, владелец службы электронной почты обязан обеспечить возможность приема и отправки сообщений, однако служба электронной почты может не обеспечивать конфиденциальность передаваемой по почте финансовой информации или физический контроль среды почтовых серверов. Примерами ИТ-служб являются также службы общего доступа к файлам, хранения данных, обслуживания сети, удаленного доступа и телефонии. Классы активов Активы, входящие в сферу действия оценки, должны входить в качественную группу или класс. Классы упрощают определение общего влияния рисков безопасности и помогают организациям сосредоточить основные усилия на самых важных активах. Разные модели оценки рисков определяют различные классы активов. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, использует три класса активов, чтобы помочь определить стоимость актива для организации. Почему только три класса? Потому что эта классификация обеспечивает достаточное разделение и уменьшает затраты времени на обсуждение и выбор соответствующего класса. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, определяет следующие три качественных класса активов: высокое влияние на бизнес (ВВБ), среднее влияние на бизнес (СВБ) и низкое влияние на бизнес (НВБ). На этапе приоритизации рисков данный процесс предлагает также рекомендации по количественной оценке активов. В процессе обсуждения рисков организация может выбрать количественные методы оценки активов. В этом случае необходимо учитывать затраты времени на достижение согласия в количественной оценке денежной стоимости в процессе обсуждения рисков. Чтобы уменьшить число рисков, требующих дальнейшего анализа, данный процесс рекомендует подождать, пока не будут выявлены все риски и определены их приоритеты. Примечание. Дополнительные сведения об определении и выборе категорий информационных систем см. в публикации 800-60 Mapping Types of Information and Information Systems to Security Categories («Сопоставление типов информации и информационных систем категориям безопасности») материалов симпозиума Национального института стандартов и технологий США и в публикации 199 федеральных стандартов обработки информации Security Categorization of Federal Information and Information Systems («Выбор категорий безопасности федеральной информации и информационных систем»). Высокое влияние на бизнес Влияние на конфиденциальность, целостность и доступность этих активов может причинить организации значительный или катастрофический ущерб. Влияние может быть выражено с помощью финансовых терминов или может отражать косвенные убытки или последствия хищения финансовых инструментов, снижения производительности труда, ухудшения репутации или наступления значительной правовой или регулятивной ответственности. Ниже приведены некоторые примеры, относящиеся к классу ВВБ. Учетные данные. Например, пароли, секретные ключи шифрования и аппаратные маркеры. Конфиденциальные деловые данные. Например, финансовые данные и интеллектуальная собственность. Активы, к которым предъявляются особые регулятивные требования. Например, GLBA, HIPAA, CA SB1386 и директива ЕС о защите данных. Информация личного порядка (PII). Любые сведения, которые дают злоумышленнику возможность узнать информацию о заказчике или получить его личные данные. Руководство по управлению рисками безопасности 49 Данные авторизации финансовых транзакций. Такие как сроки действия и номера кредитных карт. Финансовые профили. Например, справки о кредитоспособности заказчиков и личные декларации о доходах. Медицинские профили. Например, номера медицинских карточек и биометрические данные. В целях защиты конфиденциальности активов в данном классе доступ к ним осуществляется с использованием минимально необходимого объема прав и предоставляется только членам организации. Число людей, которым предоставлен доступ к этим данным, должно строго контролироваться ответственным за соответствующий ресурс. Аналогичные меры предосторожности должны быть предприняты для сохранения целостности и доступности активов данного класса. Среднее влияние на бизнес Влияние на конфиденциальность, целостность и доступность этих активов может причинить организации средний ущерб. Средний ущерб не вызывает значительных или катастрофических изменений, однако нарушает нормальную работу организации до такой степени, что это требует проактивных элементов контроля для минимизации влияния в данном классе активов. Среднее влияние может быть выражено с помощью финансовых терминов или может отражать косвенные убытки или последствия хищения финансовых инструментов, снижения производительности труда, ухудшения репутации или наступления значительной правовой или регулятивной ответственности. Данные активы могут использоваться определенной группой сотрудников и пользователей, не являющихся сотрудниками организации, если это продиктовано ее бизнес-потребностями. Примером активов класса СВБ могут служить следующие сведения. Внутренние коммерческие данные. Каталог сотрудников, данные о заказах на поставку, проекты сетевой инфраструктуры, данные, находящиеся на внутренних веб-узлах и во внутренних общих папках и предназначенные для использования только внутри организации. Низкое влияние на бизнес Активы, не попадающие в классы ВВБ и СВБ, относятся к классу НВБ. К защите подобных активов не выдвигаются формальные требования, и она не требует дополнительного контроля, выходящего за рамки стандартных рекомендаций по защите инфраструктуры. Как правило, эти активы содержат информацию, к которой имеет доступ большое число людей, а несанкционированный доступ к подобным активам не влечет за собой значительные финансовые потери, наступление правовой или регулятивной ответственности, нарушение работы организации или утрату конкурентного преимущества. Ниже приведены некоторые примеры активов данного класса. Общие сведения о структуре организации. Основные сведения о платформе, используемой для ИТ-операций. Возможность чтения общедоступных веб-страниц. Открытые ключи шифрования. Опубликованные пресс-релизы, брошюры с информацией о продуктах, информационные документы и документы, входящие в состав выпущенных продуктов. Устаревшие коммерческие данные и материальные активы. 50 Глава 4. Оценка рисков Упорядочивание информации о рисках Риск включает большое число компонентов: активы, угрозы, уязвимости и элементы контроля. Координатор оценки рисков должен определить, какие компоненты риска следует рассмотреть на обсуждении, чтобы это не мешало основному диалогу. Чтобы помочь в организации обсуждения, используйте шаблон обсуждения риска (SRMGTool1-Data Gathering Tool.doc). Это облегчит участникам понимание особенности компонентов риска. Кроме того, данный шаблон позволяет секретарю оценки рисков последовательно сохранять информацию о рисках в ходе встреч. Хотя шаблон может заполняться в любой последовательности, практика показывает, что рассмотрение вопросов в указанном ниже порядке помогает участникам обсуждения понять компоненты риска и получить больше информации. Какой ресурс следует защитить? Насколько ценен этот ресурс для организации? От каких угроз (известных и потенциальных) следует защищать данный ресурс? Как может быть причинен ущерб или использована подверженность воздействию? Какова степень потенциальной подверженности воздействию? Какие меры предпринимаются в настоящее время, чтобы снизить вероятность или степень ущерба активу? Какие действия можно предпринять, чтобы снизить вероятность подобных событий в будущем? Для специалистов по информационной безопасности перечисленные выше вопросы преобразуются в специфические термины оценки рисков и категории, используемые для приоритизации рисков. Однако заинтересованные лица могут не владеть данной терминологией и не несут ответственности за приоритизацию рисков. Опыт показывает, что отказ от использования терминов из области информационной безопасности (таких как «угрозы», «уязвимости» и «контрмеры») повышает эффективность обсуждения и помогает участникам, не имеющим технической подготовки, чувствовать себя более уверенно. Еще одним преимуществом использования функциональных терминов при обсуждении риска является уменьшение вероятности того, что другие технические специалисты увлекутся обсуждением тонкостей отдельных терминов, поскольку на этом этапе намного важнее понять особенности более масштабных областей риска, чем обсуждать различные варианты определений угроз и уязвимостей. Координатор оценки рисков должен дождаться завершения обсуждения, чтобы ответить на вопросы об определениях рисков и терминологии. Упорядочивание по уровням многоуровневой защиты В ходе обсуждений секретарь и координатор оценки рисков соберут большие объемы данных. Используйте многоуровневую модель защиты, чтобы помочь организовать обсуждение, касающееся всех элементов риска. Это позволит сформировать структуру и поможет группе управления рисками безопасности собирать сведения о рисках в рамках организации. Пример уровней многоуровневой защиты включен в шаблон обсуждения рисков и приведен ниже на рис. 4.2. Более подробное описание многоуровневой модели см. в разделе «Организация решений для контроля» главы 6 «Реализация контроля и оценка эффективности программы». Руководство по управлению рисками безопасности 51 Рис. 4.2. Модель многоуровневой защиты Еще одним полезным средством, дополняющим модель многоуровневой защиты, является использование стандарта ISO 17799 для упорядочивания вопросов и ответов, относящихся к рискам. Ссылка на универсальные стандарты, такие как ISO 17799, помогает также упростить обсуждение рисков в отдельных областях (например, в области законодательства, политики, процессов, персонала и разработки приложений). Определение угроз и уязвимостей Информация об угрозах и уязвимостях предоставляет технические данные, используемые для приоритизации рисков в рамках организации. Поскольку существует вероятность того, что многие заинтересованные лица, не имеющие технической подготовки, незнакомы с рисками, влияющими на их бизнес, координатору обсуждения рисков имеет смысл привести примеры, чтобы начать обсуждение. На данном этапе может понадобиться предварительное исследование, которое поможет владельцам организаций найти и проанализировать риски в своей среде. Для ссылок: стандарт ISO 17799 определяет угрозу как источник потенциального влияния на организацию; NIST определяет угрозы как потенциально вредоносные для системы события или субъекты. Влияние, возникающее в результате угрозы, как правило, определяется с помощью концепций конфиденциальности, целостности и доступности. Использование отраслевых стандартов может быть особенно полезно при исследовании угроз и уязвимостей. Чтобы упростить обсуждение рисков, может потребоваться использовать вместо понятий «угрозы» и «уязвимости» термины, знакомые заинтересованным лицам, которые не имеют технической подготовки (например, «Чего именно вы пытаетесь избежать?» или «Что может случиться с активом?»). В большинстве случаев влияние на работу организации может быть отнесено к определенной категории, исходя из того, насколько важны для организации конфиденциальность, целостность и доступность соответствующего актива. Попробуйте использовать этот подход, если заинтересованные лица не могут понять значение термина «угроза» применительно к активам организации. Типичным примером угрозы для организации является нарушение целостности финансовых данных. Выяснив, чего нужно избегать, необходимо определить, каким образом могут возникнуть угрозы для организации. Уязвимость представляет собой слабое место актива или группы активов, которое может быть использовано угрозой. Другими словами, уязвимость создает механизм осуществления угрозы. NIST определяет уязвимость как состояние (или слабость, отсутствие) процедур безопасности, технических, физических и других элементов контроля, которое может быть использовано угрозой. Типичным примером уязвимости узлов является отсутствие обновлений системы безопасности. Наличие указанных уязвимостей и угроз порождает следующую формулировку: «Наличие узлов, на которых не установлены обновления, может привести к нарушению целостности финансовой информации, хранящейся на этих узлах». 52 Глава 4. Оценка рисков Типичной ошибкой, совершаемой при оценке рисков, является учет только технологических уязвимостей. Опыт показывает, что наиболее значительные уязвимости зачастую возникают из-за отсутствия определенного процесса или ответственности за обеспечение информационной безопасности. В процессе сбора данных нельзя недооценивать организационные аспекты обеспечения безопасности и роль руководителя. Например, в приведенном выше примере неспособность установить обновления в управляемых системах может привести к нарушению целостности финансовой информации, хранящейся на этих узлах. Во многих случаях отсутствие ответственности и соблюдения политик безопасности обусловлено организационными просчетами. Примечание. В процессе сбора данных можно выделить общие группы угроз и уязвимостей. Отслеживайте эти группы, чтобы определить, могут ли схожие элементы контроля уменьшить вероятность нескольких рисков. Оценка подверженности актива воздействию После того как координатор оценки рисков завершит обсуждение выявленных активов, угроз и уязвимостей, необходимо получить от заинтересованных лиц оценки ущерба, который может быть причинен активу, независимо от класса актива. Уровень потенциального ущерба называется подверженностью актива воздействию. Как говорилось ранее, владелец организации несет ответственность как за выявление активов, так и за оценку потенциального ущерба, который может быть причинен активу или организации. Класс актива, подверженность воздействию и комбинация угроз и уязвимостей определяют общее влияние на организацию. В дальнейшем величина влияния объединяется с вероятностью, чтобы завершить формирование полной формулировки риска. Координатор оценки рисков начинает обсуждение, используя следующие примеры качественных категорий потенциальной подверженности воздействию для каждого сочетания угроз и уязвимостей для выбранного риска. Конкурентное преимущество. Законы и регулятивные требования. Операционная доступность. Репутация на рынке. Для каждой категории необходимо помочь заинтересованным лицам сделать оценки в следующих трех группах. Высокая подверженность воздействию. Значительный или полный ущерб для актива. Средняя подверженность воздействию. Средний или ограниченный ущерб. Низкая подверженность воздействию. Незначительный ущерб или отсутствие такового. В разделе данной главы, посвященном приоритизации, содержатся рекомендации по добавлению деталей к рассмотренным выше категориям подверженности воздействию. Как и в случае с количественной оценкой активов, процесс управления рисками безопасности, предлагаемый корпораций Майкрософт, рекомендует дождаться этапа приоритизации рисков, а лишь затем изменять определение уровней подверженности воздействию. Примечание. Если в процессе обсуждения заинтересованные лица не могут выбрать уровни подверженности воздействию, рассмотрите угрозы и уязвимости более подробно, чтобы помочь определить потенциальный уровень ущерба, который может быть причинен активу. Кроме того, можно использовать общедоступные примеры брешей в системе безопасности и более подробно рассмотреть уровни подверженности воздействию, как это сделано в разделе приоритизации, далее в этой главе. Руководство по управлению рисками безопасности 53 Оценка вероятности угроз После того как заинтересованные лица предоставят оценки потенциального влияния на активы организации, координатор оценки рисков собирает мнения заинтересованных лиц относительно вероятности возникновения влияний. Этот этап завершает обсуждение рисков и помогает заинтересованным лицам понять особенности процесса выявления рисков безопасности. Напомните, что группа информационной безопасности несет ответственность за окончательное решение по оценке вероятности возникающих влияний. Можно считать, что данное обсуждение направлено на улучшение взаимоотношений с заинтересованными лицами. Чтобы оценить вероятность для каждой угрозы и уязвимости, выявленной в ходе обсуждения, воспользуйтесь следующими рекомендациями. Высокая. Вероятно возникновение одного или нескольких влияний в пределах года. Средняя. Влияние может возникнуть в пределах двух-трех лет. Низкая. Возникновение влияния в пределах трех лет маловероятно. Зачастую при этом необходимо проанализировать возникавшие в последнее время инциденты. Если необходимо, обсудите эти вопросы, чтобы помочь заинтересованным лицам понять важность обеспечения безопасности и общего процесса управления рисками. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, использует для категории с высокой вероятностью временной интервал длительностью один год, поскольку внедрение элементов контроля информационной безопасности зачастую занимает длительное время. Определение вероятности для срока в один год призвано привлечь внимание к соответствующему риску и стимулировать принятие решения по нейтрализации риска в следующем бюджетном цикле. Комбинация высокой вероятности и высокого уровня влияния требует обсуждения риска заинтересованными лицами и группой управления рисками. Оценивая вероятности влияний, группа информационной безопасности должна помнить об этом моменте. Следующей задачей является получение мнений заинтересованных лиц относительно возможных элементов контроля, способных уменьшить вероятность выявленных влияний. Это обсуждение следует провести в виде мозгового штурма, не критикуя и не отвергая любые идеи. Следует помнить, что основной целью данного обсуждения является демонстрация всех компонентов риска, что облегчит их понимание. Фактический выбор стратегии нейтрализации риска происходит на этапе поддержки принятия решений. Для каждого возможного элемента контроля следует провести обсуждение, которое позволит оценить уровень снижения вероятности возникновения риска с использованием рассмотренных выше качественных категорий. Укажите заинтересованным лицам, что концепция уменьшения вероятности риска является основной переменной для снижения риска до приемлемого уровня. Проведение обсуждений рисков В этом разделе рассматривается подготовка к обсуждению рисков и определяются пять задач обсуждения собранных данных (определение организационных активов и сценариев, выявление угроз, выявление уязвимостей, оценка подверженности актива воздействию, выявление существующих элементов контроля и определение вероятности взлома). 54 Глава 4. Оценка рисков Подготовка встречи Неявным, но важным фактором достижения успеха является порядок обсуждения рисков. Опыт корпорации Майкрософт показывает, что чем больше информации подготавливает для каждой встречи группа управления рисками безопасности, тем более результативно проходит встреча. Одной из стратегий является создание базы знаний о рисках в рамках организации, что позволяет использовать опыт ИТ-подразделения и подразделения информационной безопасности. Организуйте встречу с группой информационной безопасности, а затем с ИТ-подразделением, чтобы обновить информацию о среде. Это позволит группе управления рисками безопасности лучше понять обязанности каждого заинтересованного лица в организации и выполнить совместно с заинтересованными лицами оценку рисков по обстановке. Все обсуждения рисков с руководством организации рекомендуется проводить на последнем этапе процесса сбора данных. Руководители зачастую хотят получить предварительное направление, в котором выполняется оценка риска. Не смешивайте данное понятие с понятием поддержки и ролью ответственного руководителя. Участие руководства необходимо на всем протяжении процесса управления рисками. Сформируйте список приглашенных на каждое обсуждение рисков. Рекомендуется организовывать встречи с группами заинтересованных лиц, имеющих схожие обязанности и технические знания. Это позволит проводить встречу, используя удобный для участников технический уровень. Хотя ознакомление с различными представлениями организационных рисков может оказаться полезным для заинтересованных лиц, процесс оценки рисков должен быть направлен на получение всех необходимых данных за отведенное время. Составив расписание обсуждений рисков, проанализируйте участок работы каждого заинтересованного лица в организации, чтобы ознакомиться с активами, угрозами, уязвимостями и элементами контроля. Как было сказано выше, эта информация позволяет координатору оценки рисков обеспечить эффективность обсуждения. Проведение обсуждений Обсуждение должно носить неформальный характер, однако координатору оценки рисков следует управлять ходом обсуждения, чтобы рассмотреть весь необходимый материал. Опыт показывает, что зачастую обсуждения отклоняются от повестки дня. Наиболее распространенные ошибки при обсуждении связаны с вовлечением заинтересованных лиц в техническое обсуждение новых уязвимостей и их предвзятым отношением к решению для контроля. Координатор оценки рисков должен руководствоваться опытом и результатами предварительного изучения, чтобы сформулировать результаты технического обсуждения и проводить обсуждение в соответствии с планом. При надлежащей подготовке встреча с 4–6 заинтересованными лицами должна длиться около 60 минут. Потратьте несколько минут в начале встречи, чтобы огласить повестку дня и ознакомить присутствующих с ролями и обязанностями в программе управления рисками. Заинтересованные лица должны хорошо знать свои роли и обязанности. Рекомендуется предоставлять заинтересованным лицам рабочие листы обсуждения рисков для ведения собственных записей. Это также обеспечивает ссылочный материал, когда координатор оценки рисков ведет обсуждение рисков. Кроме того, рекомендуется прийти на встречу заранее и нарисовать на доске эскиз шаблона риска для записи информации в ходе встречи. Расписание 60-минутной встречи должно выглядеть следующим образом. Обзор управления рисками: 5 минут. Роли и обязанности: 5 минут. Обсуждение рисков: 50 минут. Руководство по управлению рисками безопасности 55 Обсуждение риска состоит из следующих разделов. Определение активов организации и сценариев. Выявление угроз. Выявление уязвимостей. Оценка подверженности актива воздействию. Оценка вероятности угроз. Обсуждение предлагаемых элементов контроля. Подведение итогов встречи и дальнейшие действия. Фактический ход встречи зависит от группы участников, числа обсуждаемых рисков и опыта координатора оценки рисков, поэтому приведенное выше расписание следует использовать для планирования относительных затрат времени на решение каждой задачи. Кроме того, если заинтересованные лица имеют опыт оценки рисков, рекомендуется перед встречей отправить им шаблон сбора данных. Примечание. В оставшиеся разделы данной главы включен пример, который поможет продемонстрировать использование средств, упомянутых при рассмотрении этапа оценки рисков. Рассматриваемая в примере компания является вымышленной, а соответствующие данные представляют собой только часть информации, необходимой для полной оценки рисков. Приведенный пример призван просто продемонстрировать методику сбора и анализа данных с помощью средств, поставляемых вместе с этим руководством. Полная демонстрация всех возможностей процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, порождает большие объемы данных и выходит за рамки настоящего руководства. Вымышленная компания представляет собой банк Woodgrove Bank, занимающийся обслуживанием мелких клиентов. Материал, относящийся к данному примеру, предваряется заголовком «Пример банка Woodgrove». Задача 1. Определение активов организации и сценариев Первая задача состоит в получении от заинтересованных лиц определений активов организации, попадающих в сферу действия оценки рисков. Используйте приведенный ниже шаблон сбора данных, чтобы собрать сведения о соответствующих материальных и нематериальных активах, а также активах ИТ-служб (файл SRMGTool1-Data Gathering Tool.doc также включен в настоящее руководство в качестве средства). Помогите заинтересованным лицам выбрать класс каждого актива и указать его в шаблоне. Если необходимо, укажите также владельца актива. Если заинтересованные лица не могут выбрать класс актива, убедитесь, что актив определен с достаточной степенью детализации, чтобы упростить дальнейшее обсуждение. Если заинтересованные лица по-прежнему не могут определить класс, пропустите этот шаг и подождите, пока не начнется обсуждение угроз и уязвимостей. Опыт показывает, что заинтересованные лица могут легче классифицировать актив после осознания угроз для актива и организации в целом. Обсуждение, касающееся активов организации, можно свести к нескольким простым вопросам. Например, можно спросить, является ли актив критически важным для успешной работы организации и оказывает ли он существенное влияние на результаты работы. Если да, это может свидетельствовать о высокой степени воздействия этого актива на бизнес организации. 56 Глава 4. Оценка рисков Рис. 4.3. Снимок экрана шаблона Data Gathering Template (SRMGTool1) Пример банка Woodgrove. Woodgrove Bank располагает большим числом дорогостоящих активов, начиная с систем начисления процентов и информации личного порядка о клиентах и заканчивая их финансовыми данными и репутацией банка как заслуживающего доверия учреждения. Чтобы продемонстрировать использование средств, включенных в настоящее руководство, в приведенном примере рассматривается только один из этих активов — финансовые данные клиентов. По результатам обсуждения вопроса о принадлежности активов группа по управлению рисками безопасности определяет, что ответственным за актив является вицепрезидент по обслуживанию клиентов. Если будет обнаружено, что риск является противоречивым или стратегия нейтрализации риска является слишком затратной, данный владелец будет являться основным заинтересованным лицом, определяющим допустимый уровень риска для Woodgrove Bank. При встрече с представителями подразделения обслуживания клиентов группа управления рисками безопасности получила подтверждение, что финансовые данные клиентов представляют собой актив с высокой деловой ценностью. Задача 2. Выявление угроз Чтобы упростить обсуждение вопросов, посвященных угрозам, используйте общепринятые термины. Например, можно спросить у заинтересованных лиц, есть ли что-то, что может случиться с различными активами и чего они хотели бы избежать. При обсуждении уделяйте основное внимание тому, что может случиться, а не каким образом это может произойти. Сформулируйте вопросы в терминах конфиденциальности, целостности или доступности актива и занесите полученные сведения в шаблон сбора данных. Пример банка Woodgrove. Используя рассмотренные ранее активы, можно обнаружить большое число угроз. Для краткости в данном примере рассматривается только угроза нарушения целостности финансовых данных клиентов. Помимо этого могут также существовать угрозы нарушения доступности и конфиденциальности данных клиентов, однако они находятся за пределами этого примера. Задача 3. Выявление уязвимостей Для каждой обнаруженной угрозы проведите мозговой штурм с целью выявления уязвимостей (например, чтобы понять, каким образом может возникнуть соответствующая угроза). Попросите заинтересованных лиц указывать при документировании уязвимостей конкретные технические примеры. Каждая угроза может включать несколько уязвимостей. Это нормальное явление, которое в дальнейшем может помочь при выборе элементов контроля на этапе поддержки принятия решений. Пример банка Woodgrove. Проанализировав угрозу нарушения целостности финансовых данных клиентов и сведения, полученные в ходе обсуждения рисков, группа управления рисками безопасности выделила следующие три уязвимости. Хищение доверенным сотрудником учетных данных консультанта по финансовым вопросам с помощью подслушивания, социальной инженерии и других методов без использования технических средств. Хищение учетных данных консультанта по финансовым вопросам с узлов локальной сети вследствие несвоевременного обновления конфигураций системы безопасности. Хищение учетных данных консультанта по финансовым вопросам с удаленных и мобильных узлов вследствие несвоевременного обновления конфигураций системы безопасности. Руководство по управлению рисками безопасности 57 Примечание. В данном сценарии может существовать большое число уязвимостей, однако рассматриваемый пример призван показать, каким образом уязвимости сопоставляются конкретным угрозам. Необходимо отметить, что заинтересованные лица могут быть не в состоянии определить уязвимости с помощью технических терминов. Поэтому группе управления рисками безопасности может потребоваться уточнить формулировки угроз и уязвимостей. Задача 4. Оценка подверженности актива воздействию Координатор оценки рисков должен вести обсуждение таким образом, чтобы получить оценку подверженности воздействию для каждого сочетания угроз и уязвимостей. Попросите заинтересованных лиц выбрать высокий, средний или низкий уровень подверженности воздействию и занести полученные данные в шаблон. Для цифровых активов и систем подверженность воздействию рекомендуется считать высокой, если уязвимость позволяет получить доступ к активу на уровне администратора или привилегированного пользователя. Пример банка Woodgrove. После выявления угроз и уязвимостей координатор оценки рисков в ходе обсуждения собирает сведения о потенциальном уровне ущерба, который могут причинить организации рассмотренные выше сочетания угроз и уязвимостей. В результате обсуждения группой было определено следующее. Нарушение целостности вследствие злонамеренных действий доверенных сотрудников может нанести ущерб организации, однако размер ущерба, скорее всего, будет не очень большим. В данном случае величина ущерба ограничена, поскольку каждый консультант по финансовым вопросам имеет доступ к данным только тех клиентов, с которыми он работает. Таким образом, в ходе обсуждения выяснилось, что хищение учетных данных небольшого числа пользователей причинит меньший ущерб, чем хищение учетных данных большого числа пользователей. Нарушение целостности вследствие хищения учетных данных с узлов локальной сети может причинить организации серьезный ущерб, особенно при использовании автоматизированной атаки, способной за короткий период времени похитить учетные данные у нескольких консультантов по финансовым вопросам. Нарушение целостности вследствие хищения учетных данных с мобильных узлов также может причинить организации серьезный или высокий ущерб. В процессе обсуждения было отмечено, что на удаленных узлах конфигурации системы безопасности зачастую обновляются позже, чем на узлах локальной сети. Задача 5. Выявление существующих элементов контроля и вероятности взлома Используйте обсуждение рисков, чтобы лучше понять мнение заинтересованных лиц о текущей среде контроля и вероятности взлома и ознакомиться с предлагаемыми ими элементами контроля. Мнение заинтересованных лиц может не соответствовать фактическому положению дел, однако оно содержит важные сведения для группы информационной безопасности. На этом этапе обсуждения рекомендуется напомнить заинтересованным лицам об их ролях и обязанностях в программе управления рисками. Отразите полученные результаты в шаблоне. Пример банка Woodgrove. После обсуждения потенциальной подверженности бизнеса воздействию вследствие угроз и уязвимостей выяснилось, что заинтересованные лица, не имеющие технической подготовки, не могут оценить вероятность нарушения системы безопасности конкретных узлов, однако они согласны, что удаленные и мобильные узлы управляются хуже, чем узлы локальной сети. В процессе обсуждения отмечалось, что консультанты по финансовым вопросам должны периодически просматривать отчеты о выполнявшихся операциях с целью выявления несанкционированных действий. Это мнение будет учитываться группой управления рисками безопасности на этапе поддержки принятия решений. Подведение итогов обсуждения рисков По завершении обсуждения рисков следует кратко перечислить все выявленные риски, чтобы подвести итоги встречи. Кроме того, необходимо напомнить заинтересованным лицам об общем процессе управления рисками и временной шкале. Информация, собранная в ходе обсуждения рисков, позволяет заинтересованным лицам играть активную роль в процессе управления рисками и содержит важные сведения для группы управления рисками безопасности. 58 Глава 4. Оценка рисков Пример банка Woodgrove. Координатор оценки рисков подводит итоги обсуждения, обращает внимание на обсуждавшиеся активы, угрозы и уязвимости, описывает общий процесс управления рисками и сообщает участникам обсуждения, что группа управления рисками безопасности учтет результаты этого и других обсуждений при оценке вероятности каждой угрозы и уязвимости. Определение формулировок влияний Последней задачей процесса тематического сбора данных является анализ информации, полученной во время обсуждения рисков (необходимо учитывать, что данная информация может иметь большой объем). Результатом анализа является перечень формулировок, характеризующих активы и их потенциальную подверженность угрозам и уязвимостям. Как было указано в главе 3, данные формулировки называются формулировками влияний. Влияние определяется путем объединения класса актива и уровня потенциальной подверженности актива воздействию. Определение влияния представляет собой половину полной формулировки риска. Чтобы завершить ее, необходимо учесть и вероятность возникновения влияния. Группа управления рисками безопасности создает формулировки влияний путем объединения сведений, собранных в ходе обсуждений рисков, информации о выявленных ранее влияниях и данных о влияниях, полученных на основе собственных наблюдений. Хотя ответственность за решение этой задачи возлагается на группу управления рисками безопасности, в ходе работы эта группа может запрашивать у заинтересованных лиц дополнительные сведения. Формулировка влияния включает актив, классификацию актива, уровень многоуровневой защиты, уровень подверженности воздействию, а также описания угрозы и уязвимости. Чтобы создать формулировки влияний для всех состоявшихся координированных обсуждений, используйте сведения, занесенные в шаблон сбора данных. На рис. 4.4 показаны возможные заголовки столбцов шаблона перечня рисков на обобщенном уровне, предназначенного для сбора данных о влияниях. Рис. 4.4. Рабочий лист Summary Risk Level Worksheet: столбцы Asset («Актив») и Exposure («Подверженность воздействию») (SRMGTool2) Пример банка Woodgrove. Информация, собранная в ходе обсуждений рисков, может быть упорядочена путем создания формулировок влияний. Группа управления рисками безопасности может сохранить формулировки влияний в виде предложений (например, «Целостность информации о клиентах, имеющей высокую ценность, может быть нарушена при хищении учетных данных с мобильных узлов»). Хотя этот подход дает возможность получить точные данные, его использование не позволяет описать большое число рисков вследствие различий в написании и понимании предложений, а также в силу отсутствия данных для упорядочивания (сортировки и выполнения запросов). Более эффективный подход состоит в сохранении характеристик влияния в показанной ниже таблице обобщенных сведений (рис. 4.5). Руководство по управлению рисками безопасности 59 Рис. 4.5. Пример банка Woodgrove: информация, полученная при сборе данных (SRMGTool2) Примечание. Следующий раздел называется «Приоритизация рисков» и содержит дополнительные рекомендации по выбору и документированию уровня влияния, используемые в процессе получения обобщенных сведений об уровнях риска. Сбор данных: подведение итогов Объединяя информацию, полученную в ходе обсуждения собранных данных, в отдельные формулировки влияний, группа управления рисками безопасности завершает процесс тематического сбора данных этапа оценки рисков. В следующем разделе подробно рассматриваются задачи, решаемые при приоритизации рисков. В процессе приоритизации рисков группа управления рисками безопасности должна оценить вероятность каждого события, указанного в формулировке влияния, а затем объединить формулировки влияний с полученными значениями. Это позволяет получить полный перечень ранжированных по приоритетам рисков и завершить этап оценки рисков. При анализе рисков может оказаться, что некоторые риски зависят от возникновения других рисков. Например, несанкционированное получение прав доступа к активу с низким уровнем влияния на бизнес организации может привести к уязвимости актива с высоким уровнем влияния. Хотя это всего лишь пример, реальное обнаружение и отслеживание зависимостей рисков, а также управление ими может потребовать обработки больших объемов данных. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, рекомендует находить зависимости, однако активное управление ими не всегда оказывается экономически эффективным. Общей целью данного процесса является управление рисками, имеющими наибольший приоритет для организации. 60 Глава 4. Оценка рисков Приоритизация рисков Как было сказано в предыдущем разделе, в процессе тематического сбора данных создается перечень формулировок влияний, необходимый для выявления активов организации и потенциальных влияний на них. В данном разделе рассматривается следующий шаг этапа оценки рисков — приоритизация рисков. На этом этапе к формулировке влияния добавляется формулировка вероятности. Помните, что в полной формулировке риска необходимо указать как влияние на организацию, так и вероятность возникновения соответствующего влияния. Процесс приоритизации рисков — последний шаг на пути определения рисков, наиболее существенных для организации, а результатом данного шага является ранжированный по приоритетам перечень рисков, который будет использоваться в качестве входных данных на этапе поддержки принятия решений, рассматриваемом в главе 5 «Поддержка принятия решений». Единоличная ответственность за процесс приоритизации возлагается на группу информационной безопасности, которая может консультировать заинтересованных лиц (как обладающих, так и не обладающих технической подготовкой), однако основной задачей этой группы является определение вероятности потенциальных влияний на организацию. Применение процесса управления рисками, предлагаемого корпораций Майкрософт, позволяет, учитывая вероятность риска, повысить внимание, уделяемое организацией данному риску, или же снизить его настолько, что риск можно будет считать допустимым без дальнейшего обсуждения. Оценка вероятности рисков требует от группы управления рисками безопасности значительных затрат времени на тщательную оценку приоритета каждого сочетания угрозы и уязвимостей. Для каждого сочетания анализируется эффективность элементов контроля, чтобы определить вероятность влияния на организацию. Для больших организаций этот процесс может оказаться очень трудоемким и вызвать сомнения в правильности решения о переходе к формальной программе управления рисками. Чтобы уменьшить затраты времени на приоритизацию рисков, можно разбить этот процесс на две стадии: процесс на обобщенном уровне и процесс на уровне детализации. Процесс на обобщенном уровне позволяет очень быстро сформировать перечень ранжированных по приоритетам рисков, используя процедуру, аналогичную процедуре установления очередности медицинской помощи, которая применяется в больницах, чтобы гарантировать, что в первую очередь помощь будет оказана наиболее нуждающимся в ней пациентам. Недостаток этого подхода состоит в том, что полученный перечень содержит только общие сравнения рисков. Длинный перечень на обобщенном уровне, в котором указывается относительная серьезность каждого риска, не содержит информации, необходимой группе управления рисками, и не позволяет выполнить приоритизацию стратегий нейтрализации риска. Однако этот перечень дает возможность быстро выявить высокие и средние риски, что позволяет группе управления рисками безопасности сконцентрировать усилия на наиболее существенных рисках. Процесс на уровне детализации позволяет сформировать перечень с большим числом деталей, что упрощает разделение рисков. Подробное представление рисков позволяет упорядочить риски и включает больше сведений о потенциальном финансовом влиянии риска. Этот количественный элемент упрощает обсуждение затрат на элемент контроля в процессе поддержки принятия решений, как описано в следующей главе. Некоторые организации могут решить вообще не формировать перечень рисков на обобщенном уровне. Хотя может показаться, что такой подход позволяет сэкономить время, на самом деле это не так. Уменьшение числа рисков в перечне на уровне детализации значительно повышает эффективность процесса оценивания рисков. Основной целью процесса управления рисками безопасности, предлагаемого Руководство по управлению рисками безопасности 61 корпорацией Майкрософт, является упрощение процесса оценки рисков путем соблюдения баланса между повышением детализации при анализе риска и объемом усилий для определения риска. Кроме того, данный процесс стремится использовать понятную логику, что позволяет заинтересованным лицам лучше понимать особенности рисков для организации. Некоторые риски могут иметь одинаковый уровень как в обобщенном, так и в подробном перечне, однако ранжирование позволяет определить, является ли соответствующий риск существенным для организации и нужно ли рассматривать его в процессе поддержки принятия решений. Примечание. Основной целью этапа оценки рисков является выявление рисков, наиболее существенных для организации, а этап поддержки принятия решений призван определить, каким образом следует противостоять этим рискам. Зачастую рабочие группы тратят много времени на этот этап, поскольку заинтересованные лица обсуждают важность различных рисков. Чтобы уменьшить задержки, воспользуйтесь следующими рекомендациями. 1. Перед началом процесса приоритизации определите, в чем заключается высокий и средний уровень риска для организации, не используя технические термины. 2. Обратите особое внимание на риски, находящиеся между средним и высоким уровнем. 3. Избегайте обсуждения мер борьбы с каким-либо риском, если еще не определено, существенен ли этот риск для организации. Учтите, что некоторые заинтересованные лица могут заранее принять решение о необходимости использования какого-либо элемента контроля и искать сведения о рисках, которые позволили бы оправдать внедрение именно этого решения. В оставшейся части данного раздела рассматриваются факторы и задачи создания обобщенных и подробных ранжированных перечней рисков. Перечисленные ниже задачи и рис. 4.6 предоставляют обзор данного раздела и основные этапы процесса приоритизации рисков. Основные задачи и этапы Задача 1. Формирование перечня на обобщенном уровне с использованием широких категорий, позволяющего оценить вероятность влияния на организацию. Результат. Перечень на обобщенном уровне, позволяющий быстро выявить основные риски для организации. Задача 2. Изучение перечня на обобщенном уровне вместе с заинтересованными лицами с целью нахождения устраивающего всех решения о приоритетах рисков и выбор рисков для формирования перечня на уровне детализации. Задача 3. Формирование перечня на уровне детализации путем анализа подробных атрибутов рисков в текущей бизнес-среде (включая рекомендации по количественной оценке каждого риска). Результат. Перечень на уровне детализации позволяет лучше рассмотреть важнейшие риски для организации. 62 Глава 4. Оценка рисков Рис. 4.6. Задачи приоритизации рисков Примечание. Перечень рисков на уровне детализации будет рассматриваться при участии заинтересованных лиц в процессе поддержки принятия решений, описанном в главе 5. Подготовка к выполнению Приоритизация рисков для организации является непростой задачей. Группа управления рисками безопасности должна попытаться спрогнозировать будущее, предсказав время и метод потенциального влияния на организацию, а затем обосновать эти прогнозы перед заинтересованными лицами. Общей ошибкой многих рабочих групп является «сокрытие» задач, выполняемых в ходе оценки вероятности, и применение вычислений для представления вероятности в виде процентов или результирующих графиков, которые, по их мнению, произведут более сильное впечатление на владельцев. Однако опыт применения процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, показал, что заинтересованные лица лучше воспринимают результаты анализа, выполненного группой управления рисками безопасности, если понятна логика приоритизации. Поэтому данный процесс уделяет большое внимание обеспечению понятности с точки зрения заинтересованных лиц. Чтобы уменьшить затраты времени на поиск удовлетворяющего всех решения и повысить его понятность, необходимо использовать как можно более простую логику приоритизации. Исходя из опыта оценки рисков в ИТ-подразделении корпорации Майкрософт и в других организациях, были выработаны следующие рекомендации, помогающие группе управления рисками безопасности в процессе приоритизации. Анализируйте риски в процессе сбора данных. Поскольку приоритизация рисков может потребовать значительных затрат времени, попытайтесь заранее выявить противоречивые риски и начать процесс приоритизации как можно раньше (это возможно, поскольку группа управления рисками безопасности несет единоличную ответственность за процесс приоритизации). Выполните исследования, которые позволят собрать данные для оценки вероятности. Используйте отчеты о выполнявшихся ранее аудиторских проверках и примите во внимание существующие в отрасли тенденции и соответствующие внутренние проблемы, возникавшие в системе безопасности. Если необходимо, организуйте повторные встречи с заинтересованными лицами, чтобы узнать об используемых элементах контроля и о конкретных рисках в их среде. Выделите в проекте достаточный объем времени на исследование и анализ эффективности и возможностей текущей среды контроля. Напомните заинтересованным лицам, что группа управления рисками безопасности несет ответственность за определение вероятности. Ответственный руководитель также должен подтвердить эту роль и поддержать анализ, выполненный группой управления рисками безопасности. Руководство по управлению рисками безопасности 63 Выразите риски в терминах бизнеса. Выполняя анализ приоритетов, избегайте технического жаргона и выражений, которые могут вызвать опасения у заинтересованных лиц. Группа управления рисками безопасности должна распространять сведения о рисках, используя терминологию, понятную членам организации, и не преувеличивать уровень опасности. Согласуйте сведения о новых и предыдущих рисках. При формировании перечня на обобщенном уровне включите в него риски, выявленные при выполнении предыдущих оценок. Это позволит группе управления рисками безопасности отслеживать риски в рамках нескольких оценок и даст возможность при необходимости обновлять сведения о прежних элементах рисков. Например, если выявленный ранее риск не был уменьшен в силу высокой стоимости нейтрализации риска, повторно оцените вероятность возникновения этого риска и проанализируйте возможные изменения в решениях по нейтрализации риска и стоимость подобных решений. Приоритизация рисков безопасности В следующем разделе рассматривается процесс формирования перечней рисков обобщенного и подробного уровней. Если необходимо, распечатайте вспомогательные шаблоны для каждого процесса, находящиеся в разделе Tools. Приоритизация рисков на обобщенном уровне Перечень на обобщенном уровне использует формулировку влияния, созданную в процессе сбора данных. Формулировка влияния является первой частью входных данных в обобщенном представлении. Второй частью входных данных является оценка вероятности, определенная группой управления рисками безопасности. Следующие три предоставляют обзор процесса приоритизации на обобщенном уровне. Задача 1. Определение величины влияния на основе формулировок влияний, полученных в процессе сбора данных. Задача 2. Оценка вероятности влияния для перечня на обобщенном уровне. Задача 3. Завершение формирования перечня на обобщенном уровне путем объединения величин влияний и вероятностей для каждой формулировки риска. Задача 1. Определение уровня влияния Чтобы определить уровень влияния, необходимо объединить сведения о классе актива и информацию о подверженности актива воздействию, полученную в процессе сбора данных. Помните, что влияние представляет собой сочетание класса актива и степени подверженности актива воздействию. Чтобы выбрать уровень влияния для каждой формулировки влияния, воспользуйтесь рис. 4.7. Рис. 4.7. Рабочий лист анализа риска: класс актива и уровень подверженности воздействию (SRMGTool2) 64 Глава 4. Оценка рисков Пример банка Woodgrove. В примере с банком Woodgrove было создано три формулировки влияний. Следующий перечень обобщает их, объединяя класс актива и уровень подверженности воздействию. Влияние вследствие хищения, совершенного доверенным работником: класс актива — ВВБ и низкая подверженность воздействию, что соответствует среднему влиянию (см. рис. 4.7). Влияние вследствие хищения, совершенного путем нарушения системы безопасности узлов локальной сети: класс актива — ВВБ и высокая подверженность воздействию, что соответствует высокому влиянию (см. рис. 4.7). Влияние вследствие нарушения системы безопасности удаленных узлов: класс актива — ВВБ и высокая подверженность воздействию, что соответствует высокому влиянию. Задача 2. Оценка вероятности на обобщенном уровне Используйте перечисленные ниже категории вероятностей (эти категории обсуждались ранее при рассмотрении процесса сбора данных). Высокая. Вероятно возникновение одного или нескольких влияний в течение года. Средняя. Влияние может хотя бы один раз возникнуть в течение двух или трех лет. Низкая. Возникновение влияния в течение трех лет маловероятно. Пример банка Woodgrove. Приоритизация рисков на обобщенном уровне является первым формальным документом, содержащим оценки вероятностей рисков, сделанные группой управления рисками безопасности. Группа управления рисками безопасности должна быть готова предоставить доказательства своих оценок или подтверждения на основе практических примеров (например, путем анализа последних инцидентов или текущей эффективности элементов контроля). Ниже приведены уровни вероятности для примера с банком Woodgrove. Вероятность хищения доверенным работником: низкая. Банк Woodgrove National Bank гордится тем, что может доверять своим сотрудникам. Администрация скрытно проверяет консультантов по финансовым вопросам и случайным образом осуществляет аудит операций, выполняемых ими. В прошлом в компании не было выявлено ни одного случая злоупотребления со стороны сотрудников. Вероятность нарушения системы безопасности узлов локальной сети: средняя. ИТ-подразделение банка недавно формализовало процессы конфигурации и установки исправлений в локальной сети, поскольку ранее в течение нескольких лет изменения носили несогласованный характер. В силу децентрализованной структуры банка иногда обнаруживается несоответствие систем, однако за последние несколько месяцев не было зафиксировано ни одного инцидента. Вероятность нарушения системы безопасности удаленных узлов: высокая. Удаленные узлы зачастую в течение длительного времени не соответствуют предъявляемым требованиям. В банке было зафиксировано несколько инцидентов, связанных с заражением удаленных узлов вирусами или программами-червями. Задача 3. Завершение перечня на обобщенном уровне После того как группа управления рисками безопасности оценит вероятности, воспользуйтесь следующей таблицей (рис. 4.8), чтобы определить итоговый уровень риска. Рис. 4.8. Рабочий лист анализа риска: влияние и вероятность (SRMGTool2) Примечание. В зависимости от особенностей организации объединение среднего влияния и средней вероятности может приводить к появлению высокого уровня риска. Определение уровней риска, независимо от процесса оценки риска, требует наличия методики принятия этого решения. Помните, что руководство по управлению рисками безопасности представляет собой средство, упрощающее разработку всеобъемлющей, целостной программы управления рисками. Каждая организация должна самостоятельно определить для себя допустимый уровень риска. Руководство по управлению рисками безопасности 65 Пример банка Woodgrove. В результате объединения уровней влияний и вероятностей были получены следующие величины рисков. Риск хищения доверенным работником: низкий (среднее влияние, низкая вероятность). Риск нарушения системы безопасности узлов локальной сети: высокий (высокое влияние, средняя вероятность). Риск нарушения системы безопасности удаленных узлов: высокий (высокое влияние, высокая вероятность). На рис. 4.9 представлены все столбцы перечня на обобщенном уровне, который также включен в файл SRMGTool2-Summary Risk Level.xls Рис. 4.9. Рабочий лист анализа риска: перечень на обобщенном уровне (SRMGTool2) При необходимости к этой таблице можно добавить столбцы со вспомогательной информацией (например, столбец «Дата обнаружения», позволяющий различать риски, выявленные в ходе различных оценок). Кроме того, можно добавить столбцы с дополнительным описанием рисков и выделить любые изменения рисков, возникшие после предыдущей оценки. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, следует изменить в соответствии с потребностями конкретной организации. Пример банка Woodgrove. На рис. 4.10 показан окончательный вариант перечня рисков на обобщенном уровне для банка Woodgrove Bank. Обратите внимание, что к данным формулировки влияния добавлены столбцы «Вероятность» и «Итоговый уровень риска», чтобы завершить формирование элементов полной формулировки риска. 66 Глава 4. Оценка рисков Рис. 4.10. Банк Woodgrove Bank: пример перечня рисков на обобщенном уровне (SRMGTool2) Изучение вместе с заинтересованными лицами Следующей задачей в приоритизации рисков является изучение обобщенных результатов вместе с заинтересованными лицами. Это позволяет проинформировать заинтересованных лиц о процессе оценки рисков и учесть их мнение при выборе рисков для анализа. При выборе рисков для приоритизации на уровне детализации используйте следующие критерии. Риски высокого уровня. В перечень на уровне детализации необходимо включить все риски высокого уровня. В процессе поддержки принятия решений для каждого риска должно быть принято отдельное решение (например, считать ли риск допустимым или разрабатывать решение по его нейтрализации). Граничные риски. Выполните подробный анализ приоритетов для рисков среднего уровня, которые необходимо снижать. В некоторых организациях подробный перечень может включать все риски среднего уровня. Противоречивые риски. Если риск является новым и знаний об этом риске у организации недостаточно или различные заинтересованные лица оценивают этот риск по-разному, выполните подробный анализ этого риска, чтобы помочь заинтересованным лицам лучше понять данный риск. Пример банка Woodgrove. Обратите внимание, что в перечне рисков на обобщенном уровне риск «Хищение доверенным сотрудником» имеет низкий уровень. На данном этапе процесса оценки рисков заинтересованные лица хорошо понимают особенности этого риска. В этом случае данный риск является примером риска, который не нужно учитывать на этапе детализации, поэтому в оставшейся части примера выполняется приоритизация только рисков хищения данных с узлов локальной сети и с удаленных узлов. Руководство по управлению рисками безопасности 67 Приоритизация рисков на уровне детализации Формирование перечня рисков на уровне детализации является последней задачей процесса оценки рисков. Составление данного перечня является одной из важнейших задач, поскольку он позволяет организации определить источники наиболее существенных рисков. В некоторых случаях по завершении процесса оценки рисков достаточно передать заинтересованным лицам тщательно задокументированные сведения о рисках для выполнения дальнейших действий. В организациях, не использующих программы формального управления рисками, рекомендуется внедрить процесс управления рисками, предлагаемый корпорацией Майкрософт. Примечание. Если заинтересованные лица хорошо понимают особенности риска, для выбора решения по нейтрализации риска может оказаться достаточно предоставить обобщенные сведения о риске. При составлении перечня рисков на уровне детализации применяются многие данные, используемые при составлении перечня на обобщенном уровне; однако при формировании перечня на уровне детализации группа управления рисками безопасности должна предоставить более конкретные описания влияний и вероятностей. Для каждого риска из перечня на обобщенном уровне убедитесь, что каждое сочетание угрозы и уязвимости является уникальным в рамках рисков. Зачастую риски, представленные обобщенными сведениями, нельзя описать достаточно точно, чтобы сопоставить соответствующий риск конкретным средствам управления в среде. В этом случае точная оценка вероятности возникновения риска может оказаться невозможной. Например, в следующей обобщенной формулировке риска можно изменить описание угрозы таким образом, чтобы описать два отдельных риска. Обобщенная формулировка риска. Вследствие несвоевременной установки исправлений обладающие высокой ценностью серверы в течение одного года могут подвергнуться влиянию средней степени со стороны программ-червей. Подробная формулировка 1. Вследствие несвоевременной установки исправлений обладающие высокой ценностью серверы в течение одного года могут быть недоступны на протяжении трех дней в результате действия программ-червей. Подробная формулировка 2. Вследствие заражения программами-червями, вызванного несвоевременной установкой исправлений, на обладающих высокой ценностью серверах в течение одного года может быть нарушена система безопасности, что вызовет нарушение целостности данных. Примечание. Перед сбором данных рекомендуется ознакомиться с результатами подробного анализа рисков. Это поможет группе управления рисками безопасности в ходе первого обсуждения собранных данных задавать заинтересованным лицам конкретные вопросы и уменьшить потребность в последующих обсуждениях. Перечень рисков на уровне детализации также требует указания конкретных формулировок об эффективности текущей среды контроля. После того как группа управления рисками безопасности полностью изучит влияющие на организацию угрозы и уязвимости, можно приступать к анализу текущих элементов контроля. Текущая среда контроля определяет вероятность рисков для организации. Если среда контроля достаточно эффективна, вероятность риска для организации будет низкой. Если среда контроля недостаточно эффективна, необходимо определить стратегию в отношении рисков — например, определить, что риск является допустимым, или разработать решение по его нейтрализации. Рекомендуется отслеживать риски независимо от окончательного уровня риска. Например, если риск является допустимым, сохраните сведения для последующих оценок. Последним элементом перечня рисков на уровне детализации является оценка каждого риска в числовой (денежной) форме. Выбор денежной величины риска не производится, пока не начнется работа над перечнем на уровне детализации, поскольку это требует времени на поиск решения, удовлетворяющего всех заинтересованных лиц. Чтобы собрать необходимые данные, группе управления рисками безопасности может потребоваться провести повторные встречи с заинтересованными лицами. 68 Глава 4. Оценка рисков Следующие четыре задачи дают общее представление о процессе составления перечня рисков на уровне детализации. Если необходимо, распечатайте шаблон SRMGTool3-Detailed Level Risk Prioritization.xls, который находится в разделе Tools. Результатом данного процесса является перечень на уровне детализации для рисков, влияющих на организацию. Количественная оценка вычисляется после подробного определения уровня риска и описывается в следующем разделе. Задача 1. Определение величины влияния и подверженности воздействию. Задача 2. Определение текущих элементов контроля. Задача 3. Определение вероятности влияния. Задача 4. Подробное определение уровня риска. Задача 1. Определение влияния и подверженности воздействию Сначала укажите в шаблоне подробного перечня класс актива, взяв его из обобщенной таблицы. Затем укажите подверженность актива воздействию. Обратите внимание, что в подробном шаблоне подверженность актива воздействию указывается более точно, чем на обобщенном уровне, — в подробном шаблоне уровень подверженности воздействию имеет значение от 1 до 5. Помните, что данное значение определяет уровень причиняемого активу ущерба. Чтобы определить уровень подверженности воздействию для организации, воспользуйтесь следующими шаблонами (рис. 4.11 и 4.12). Поскольку уровень влияния на актив может зависеть от каждого значения в таблицах подверженности воздействию, при заполнении этих таблиц указывайте наибольшие из всех значений. Первый рисунок, характеризующий подверженность воздействию, помогает определить величину влияния нарушений конфиденциальности или целостности бизнес-активов. Второй рисунок помогает определить влияние на доступность актива. Рис. 4.11. Рабочий лист анализа риска: уровни подверженности воздействию для конфиденциальности и целостности (SRMGTool3) Оценив величину ущерба от потенциального нарушения конфиденциальности и целостности, используйте рис. 4.12, чтобы определить уровень влияния в результате нарушения доступности. В качестве уровня подверженности воздействию выберите максимальное значение, полученное из обеих таблиц. Руководство по управлению рисками безопасности 69 Рис. 4.12. Рабочий лист анализа риска: уровни подверженности воздействию для доступности (SRMGTool3) Используйте данный рисунок в качестве руководства по сбору данных об уровне подверженности воздействию для каждого потенциального влияния. Если обсуждение собранных данных не позволяет получить необходимую информацию о возможных уровнях подверженности воздействию, может потребоваться обсудить этот вопрос с ответственным за выбранный актив. Как было сказано в разделе, посвященном сбору данных, при необходимости в процессе обсуждения рисков можно ссылаться на указанные ранее описания подверженности воздействию. Пример банка Woodgrove. В следующем списке содержатся данные об уровнях подверженности воздействию для двух оставшихся рисков. Уровень подверженности воздействию для хищений данных с узлов локальной сети: 4. Влияние на бизнес организации может быть значительным и заметным снаружи, однако это влияние не должно полностью уничтожить все финансовые данные заказчиков. Поэтому было выбрано значение 4. Уровень подверженности воздействию для хищений данных с удаленных узлов: 4 (аналогично приведенному выше). После определения уровня подверженности воздействию можно приступать к определению величины влияния путем заполнения соответствующих столбцов в файле SRMGTool3-Detailed Risk Level Prioritization.xls и вычисления результирующего значения. В процессе подробного анализа рисков влияние определяется на основе класса влияния и фактора подверженности воздействию. Каждому уровню подверженности воздействию сопоставляется значение в процентах, отражающее величину ущерба, причиненного активу, и называемое фактором подверженности воздействию. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, рекомендует использовать линейную шкалу подверженности воздействию от 100 до 20%, которая может изменяться в соответствии с требованиями организации. Кроме того, каждой величине влияния сопоставляется качественная оценка: высокая, средняя или низкая. Подобная классификация помогает обмениваться информацией об уровне влияния и отслеживать элементы риска в подробных расчетах риска. На рис. 4.13 показаны возможные величины влияния для каждого класса влияния. Рис. 4.13. Рабочий лист анализа риска: определение величин влияния (SRMGTool3) 70 Глава 4. Оценка рисков Пример банка Woodgrove. На рис. 4.14 показано определение класса влияния, уровня подверженности воздействию и общего уровня влияния в примере с банком Woodgrove. Рис. 4.14. Пример банка Woodgrove: подробные значения влияния, класса влияния и уровня подверженности воздействию (SRMGTool3) Задача 2. Определение текущих элементов контроля Файл SRMGTool3-Detailed Risk Level Prioritization.xls описывает элементы контроля, используемые в организации для снижения вероятностей угроз и уязвимостей, определенных в формулировке влияния. Эффективность элементов контроля оценивается также при подробном расчете вероятностей, однако документирование применимых элементов контроля помогает при обмене информацией об элементах риска. В ряде случаев может оказаться целесообразным упорядочить описания элементов контроля в соответствии с известными категориями групп управления, эксплуатации и технической поддержки. Эта информация полезна также в процессе поддержки принятия решений, описанном в главе 5. Пример банка Woodgrove. Ниже приведен пример списка основных элементов контроля для риска «Нарушение системы безопасности узлов локальной сети». Дополнительное описание элементов контроля см. в файле SRMGTool3-Detailed Risk Level Prioritization.xls. Обратите внимание, что описания элементов контроля могут также использоваться для обоснования оценки подверженности воздействию. Консультанты по финансовым вопросам могут обращаться только к своим учетным данным. Таким образом, подверженность воздействию составляет менее 100%. Пользователям проактивно отправляется электронная почта с уведомлениями о необходимости установить на компьютере исправления или обновления программного обеспечения. В локальной сети каждые несколько часов проверяется состояние обновлений антивирусных средств и системы безопасности и выполняется установка требуемых обновлений. Данный элемент контроля уменьшает временной интервал, в течение которого узлы локальной сети уязвимы перед атакой. Задача 3. Определение вероятности влияния Результирующий уровень вероятности определяется на основании двух значений. Первое значение определяет вероятность существования уязвимости в текущей среде исходя из атрибутов уязвимости и возможности взлома. Второе значение определяет вероятность существования уязвимости исходя из эффективности текущих элементов контроля. Каждое значение изменяется в диапазоне от 1 до 5. Чтобы определить вероятности каждого влияния для организации, воспользуйтесь следующими рисунками. Чтобы определить относительную величину риска, необходимо умножить уровень вероятности на уровень влияния. Примечание. Рис. 4.15 и 4.17 использовались ИТ-подразделением корпорации Майкрософт, чтобы лучше проанализировать вероятности рисков, возникающих в их среде. Содержимое рисунков следует изменить в соответствии с потребностями конкретной организации. Группа информационной безопасности несет ответственность за процесс приоритизации и при необходимости должна изменять атрибуты приоритизации. Например, если оценка рисков сосредоточена на разработке приложений, эти рисунки можно изменить Руководство по управлению рисками безопасности 71 таким образом, чтобы уделить основное внимание уязвимостям приложений, а не инфраструктуры. Целью данного процесса является создание целостного набора критериев оценки рисков в среде организации. На рис. 4.15 используются следующие атрибуты уязвимостей. Число злоумышленников. Как правило, вероятность взлома возрастает с увеличением числа злоумышленников и их квалификации. Удаленный и локальный доступ. Как правило, возможность удаленного взлома увеличивает вероятность его успешности. Известность средства взлома. Как правило, вероятность успешного взлома возрастает, если методы и средства взлома широко известны и общедоступны. Автоматизация взлома. Как правило, вероятность успешного использования уязвимости возрастает, если средство взлома позволяет выполнять автоматический поиск уязвимостей в большой среде. Помните, что оценка вероятности взлома имеет субъективный характер. Используйте перечисленные выше атрибуты в качестве руководства по определению и обоснованию оценок вероятностей. При выполнении и обосновании прогнозов группа управления рисками безопасности должна полагаться на собственный опыт. Рис. 4.15. Рабочий лист анализа риска: оценка уязвимости (SRMGTool3) На рис. 4.16 выберите подходящее значение. Рис. 4.16. Рабочий лист анализа риска: оценка уровня вероятности (SRMGTool3) Пример банка Woodgrove. Для локальной сети и удаленных узлов велика вероятность того, что все атрибуты уязвимостей высокой категории в ближайшем будущем будут известны как в среде локальной сети банка Woodgrove, так и вне ее. Таким образом, для обоих рисков величина уязвимости равна 5. 72 Глава 4. Оценка рисков Рис. 4.17 посвящен оценке эффективности текущих элементов контроля. Это значение является субъективным и основано на способности группы управления рисками безопасности оценить среду контроля. Ответьте на все вопросы и просуммируйте полученные величины, чтобы определить итоговое значение. Меньший результат означает большую эффективность элементов контроля и их способность уменьшать вероятность взлома. Рис. 4.17. Рабочий лист анализа риска: оценка эффективности текущего контроля (SRMGTool3) Пример банка Woodgrove. Чтобы показать, каким образом могут использоваться показатели эффективности элементов контроля, в таблице 4.2 приведены значения только для риска нарушения системы безопасности узлов локальной сети. Полный пример см. в файле SRMGTool3-Detailed Risk Level Prioritization.xls. Таблица 4.2. Пример банка Woodgrove. Показатели эффективности контроля Показатель эффективности контроля Значение Описание Эффективно ли определена и реализована ответственность? 0 (да) Ответственность за создание политики и обеспечение соответствия узлов регулятивным требованиям определена эффективно Эффективно ли осуществляется информирование? 0 (да) Пользователям регулярно отправляются оповещения, а в организации проводятся информационные кампании Эффективно ли определены и реализованы процессы? 0 (да) В организации задокументированы и осуществляются измерение и обеспечение соответствия регулятивным нормам Эффективно ли существующие технологии или элементы контроля снижают угрозы? 1 (нет) Существующие элементы контроля оставляют временной интервал между возникновением уязвимости и установкой исправлений Обеспечивают ли существующие методы аудита обнаружение злоупотреблений и недостатка контроля? 0 (да) Существующие средства эффективно осуществляют измерение и аудит соответствия Сумма всех атрибутов контроля 1 После этого сложите значение из таблицы, описывающей уязвимости (рис. 4.16), со значением из таблицы, описывающей текущие элементы контроля (рис. 4.17), и занесите результат в шаблон для уровня детализации. Данный шаблон показан на рис. 4.18. Руководство по управлению рисками безопасности 73 Рис. 4.18. Рабочий лист анализа риска: оценка уровня вероятности с контролем (SRMGTool3) Пример банка Woodgrove. Общий уровень вероятности в примере с узлами локальной сети составляет 6 (сумма значения уязвимости, равного 5, и значения эффективности элементов контроля, равного 1). Задача 4. Подробное определение уровня риска На рис. 4.19 показан перечень рисков на уровне детализации, позволяющий определить уровень каждого выявленного риска. Поскольку оценка рисков на уровне детализации может оказаться сложным процессом, логику выполнения каждой задачи приоритизации рисков можно пояснить, используя приведенные выше рисунки, что позволяет отслеживать каждую задачу в формулировке риска и значительно упрощает понимание заинтересованными лицами особенностей оценки рисков. Рис. 4.19. Рабочий лист анализа риска: подробное определение уровня риска (SRMGTool3) 74 Глава 4. Оценка рисков Пример банка Woodgrove. На рис. 4.20 показан пример перечня рисков на уровне детализации для банка Woodgrove Bank (эти данные включены также в файл SRMGTool3). Рис. 4.20. Пример банка Woodgrove Bank: перечень рисков на уровне детализации (SRMGTool3) На приведенном выше рисунке показаны уровни риска и соответствующие элементы данных. Как было сказано ранее, уровень риска определяется на основе уровня влияния (со значением от 1 до 10) и уровня вероятности (со значением от 0 до 10). В результате уровень риска может принимать значения от 0 до 100. Применяя те же правила, что и для перечня рисков на обобщенном уровне, детализированный уровень риска можно охарактеризовать как высокий, средний или низкий. Например, средний уровень влияния и высокая вероятность порождают высокий уровень риска. Однако перечень на уровне детализации содержит дополнительные данные для каждого уровня риска, как показано на рис. 4.21. Руководство по управлению рисками безопасности 75 Рис. 4.21. Рабочий лист анализа риска: результирующее качественное ранжирование (SRMGTool3) Детализированные уровни рисков следует использовать только в качестве руководства. Как было сказано в главе 3, группа управления рисками безопасности должна быть в состоянии в письменном виде объяснить сотрудникам организации особенности высокого, среднего и низкого риска. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, представляет собой средство выявления рисков и управления ими в рамках организации с использованием целостной и повторяемой методики. Количественная оценка рисков Как говорилось в главе 2, процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, сначала использует качественный подход, позволяющий быстро и эффективно выполнить выявление и приоритизацию рисков. Однако при выборе стратегии нейтрализации риска необходимо учитывать также потенциальную денежную оценку риска. Таким образом, для высокоприоритетных или противоречивых рисков данный процесс предоставляет рекомендации по количественной оценке. Количественная оценка рисков осуществляется после завершения процесса получения перечня рисков на уровне детализации, поскольку для того, чтобы прийти к единому мнению относительно денежных оценок, могут потребоваться значительные затраты усилий и времени. В результате, если в ходе данного процесса ранее выполнялась количественная оценка рисков, на количественную оценку рисков с низким приоритетом может уйти много времени. Как правило, денежная оценка полезна при сравнении затрат на разные стратегии нейтрализации риска. Однако (в силу субъективного характера оценки нематериальных активов) точных алгоритмов количественной оценки рисков не существует. Попытка точного определения величины денежного ущерба может значительно замедлить процесс оценки рисков, если заинтересованные лица не смогут прийти к единому мнению. Группа управления рисками безопасности должна объяснить, что количественная оценка представляет собой лишь одну из многих величин, определяющих приоритет или потенциальную стоимость риска. Одним из преимуществ применения качественной модели для первоначальной приоритизации рисков является возможность использования качественных формулировок, чтобы помочь в реализации целостного количественного подхода. Например, описанный ниже количественный подход использует класс актива и уровень подверженности воздействию, определенные и задокументированные в ходе обсуждения с заинтересованными лицами, как описано в разделе «Координированный сбор данных» этой главы. 76 Глава 4. Оценка рисков Как и при использовании качественного подхода, первой задачей количественного подхода является определение общей стоимости актива. Второй задачей являются определение величины ущерба, который может быть причинен активу, и оценка вероятности возникновения. Чтобы уменьшить субъективность количественной оценки, процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, рекомендует использовать класс актива для определения общей стоимости актива и фактор подверженности воздействию для определения процентной величины ущерба для актива. Это позволяет использовать три класса активов и пять значений фактора подверженности воздействию (или пятнадцать возможных значений количественной стоимости актива). Однако оценка вероятности не имеет таких ограничений. В зависимости от потребностей конкретной организации можно выразить вероятность с использованием диапазона времени или же определить годичную стоимость риска. Целью данного подхода является поиск баланса между простотой выбора относительных величин в качественном подходе и сложностью определения денежной ценности и оценки вероятности в количественном подходе. Чтобы определить количественные характеристики, необходимо выполнить следующие задачи. Задача 1. Сопоставить каждому классу активов в организации денежную стоимость. Задача 2. Определить стоимость актива для каждого риска. Задача 3. Определить величину ожидаемого разового ущерба. Задача 4. Определить ежегодную частоту возникновения (ЕЧВ). Задача 5. Определить ожидаемый годовой ущерб (ОГУ). Примечание. Задачи, решаемые в ходе количественной оценки рисков безопасности, схожи с операциями, используемыми в страховании для оценки стоимости актива и рисков и соответствующего страхового покрытия. На момент составления данного документа политики страхования для рисков информационной безопасности только начали появляться. Когда страховые компании накопят больше опыта в оценке рисков информационной безопасности, страховые таблицы для информационной безопасности и подобные им средства станут важным подспорьем в количественной оценке рисков. Задача 1. Сопоставление денежной стоимости классам активов Используя определения для классов активов, которые описаны в разделе, посвященном тематическому сбору данных, начните количественную оценку активов, соответствующих описанию класса ВВБ. Это позволит группе управления рисками безопасности в первую очередь сосредоточить усилия на активах, которые наиболее важны для организации. Для каждого актива определите денежную стоимость с точки зрения его материальной и нематериальной ценности для организации. Оценивая общую стоимость влияния для каждого актива, используйте следующие категории. Стоимость замены. Затраты на обслуживание и поддержание работоспособности. Затраты на обеспечение избыточности и доступности. Репутация организации (репутация на рынке). Эффективность работы организации. Годовой доход. Конкурентное преимущество. Внутренняя эффективность эксплуатации. Правовая и регулятивная ответственность. Примечание. Рабочая книга SRMGTool3-Detailed Level Risk Prioritization содержит рабочий лист, упрощающий данный процесс. Определив денежные оценки для каждой категории, просуммируйте полученные значения, чтобы определить общую оценку актива. Повторите данный процесс для всех активов, представленных в классе ВВБ. В результате получится перечень Руководство по управлению рисками безопасности 77 активов с указанием их приоритетов и приблизительной оценки их денежной стоимости для организации. Повторите этот процесс для каждого актива в классах СВБ и НВБ. Для каждого класса активов выберите одно денежное значение, которое будет представлять ценность класса активов. Консервативный подход состоит в выборе минимальной стоимости актива в каждом классе. Выбранное значение будет использоваться для представления ценности актива исходя из класса актива, выбранного заинтересованными лицами в процессе обсуждения собранных данных. Данный подход упрощает задачу выбора денежной стоимости каждого актива за счет использования классов активов, выбранных в ходе обсуждения собранных данных. Примечание. Еще один подход к определению стоимости активов основан на сотрудничестве с группой управления финансовыми рисками, у которой должны быть страховые оценки и информация о страховом покрытии для соответствующих активов. Использование существенности Если выбор классов активов на основе рассмотренного выше метода вызывает затруднения, можно воспользоваться рекомендациями, связанными с определением существенности в финансовых отчетах, которые публикуются зарегистрированными на бирже компаниями США. Понимание этих принципов может помочь организации при выборе высокой стоимости актива для количественной оценки. Совет по стандартам финансового учета (FASB) США выдвигает следующее требование к финансовым отчетам компаний, зарегистрированных на бирже: «Положения настоящего отчета не должны использоваться для несущественных элементов». Необходимо помнить об этом, поскольку FASB не имеет методик, позволяющих различать существенность и несущественность, и предостерегает против использования строгих количественных методов. Вместо этого FASB рекомендует учитывать все относящиеся к делу аспекты: «FASB отказался от стандартного подхода к уменьшению „тягостных обязанностей по принятию существенных решений“ в пользу подхода, учитывающего все относящиеся к делу аспекты». Несмотря на отсутствие конкретных формул, Комиссия по ценным бумагам и биржам в Бюллетене Комиссии по ценным бумагам и биржам № 99 подтвердила применение общего правила ссылок в государственном бухгалтерском учете для упрощения поиска существенных искажений. Дополнительные сведения см. на веб-странице www.sec.gov/interps/account/sab99.htm. В случае применения указанного выше общего правила ссылок для показателей финансовой отчетности используется величина 5%. Например, одним из способов оценки существенности чистого дохода в размере 8 млрд. долларов США может быть подробный анализ потенциальных искажений в размере 400 млн. долларов США или набора искажений, которые могут достигать 400 млн. долларов США. Рекомендации по использованию существенности в значительной степени зависят от конкретной организации и должны применяться только в справочных целях. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, не предназначен для представления финансового положения организаций каким-либо образом. Рекомендации по использованию существенности могут помочь при определении ценности активов класса ВВБ, однако они не помогут при оценке активов в классах СВБ и НВБ. Помните, что оценка влияния носит субъективный характер и призвана выбрать значения, отражающие особенности конкретной организации. При выборе значений для классов СВБ и НВБ рекомендуется выбирать денежное значение, отражающее особенности конкретной организации с точки зрения затрат на ИТ. Кроме того, при выборе можно исходить из текущих затрат на связанные с безопасностью элементы контроля применительно к каждому классу активов. В частности, для активов класса СВБ можно сравнить соответствующее значение с текущими денежными затратами на элементы контроля базовой сетевой инфраструктуры. Например, может потребоваться оценить общую стоимость программного обеспечения, оборудования и операционных ресурсов, необходимую для внедрения в 78 Глава 4. Оценка рисков организации антивирусных средств. Это позволяет сравнить стоимость активов с величиной известных денежных затрат в организации. Еще одним примером является то, что стоимость влияния класса СВБ может быть больше, чем текущие затраты на защиту активов с помощью межсетевых экранов. Пример банка Woodgrove. Группа управления рисками безопасности компании Woodgrove вместе с заинтересованными лицами провела работу по определению денежной стоимости классов активов. Поскольку компания ранее не применяла управление рисками, для расчета стоимости активов было решено использовать рекомендации по определению существенности. Планируется, что после получения определенного опыта эти оценки будут пересмотрены. Компания Woodgrove ежегодно получает чистый доход в размере приблизительно 200 млн. долларов США. С учетом рекомендаций по определению существенности (из расчета 5%) классу активов ВВБ была сопоставлена стоимость 10 млн. долларов США. Проанализировав последние затраты компании Woodgrove на нужды ИТ, заинтересованные лица определили, что стоимость активов класса СВБ составляет 5 млн. долларов США, а активов класса НВБ — 1 млн. долларов США. Эти значения были выбраны исходя из затрат на большие ИТ-проекты, использовавшиеся ранее в компании Woodgrove для обеспечения безопасности и поддержки цифровых активов. На протяжении следующего ежегодного цикла управления рисками эти значения также будут пересмотрены. Задача 2. Определение стоимости актива После определения стоимостей классов активов необходимо определить и выбрать стоимость каждого риска. Стоимость класса актива должна быть согласована с группой классов активов, выбранной заинтересованными лицами в ходе обсуждения собранных данных. Этот же класс используется в перечнях рисков обобщенного и детализированного уровней. Данный подход уменьшает затраты времени на обсуждение стоимости конкретных активов, поскольку стоимость класса актива определяется заранее. Помните, что процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, пытается поддерживать баланс между точностью и эффективностью. Пример банка Woodgrove. В процессе обсуждения собранных данных финансовые данные клиентов были отнесены к классу ВВБ. Таким образом, исходя из определенной выше стоимости класса ВВБ, стоимость актива составляет 10 млн. долларов США. Задача 3. Определение степени ожидаемого разового ущерба (ОРУ) Следующей задачей является определение степени ущерба, который может быть причинен активу. Чтобы помочь определить степень ущерба, который может быть причинен активу (в процентах), используйте уровень подверженности воздействию, определенный в ходе обсуждения собранных данных. Полученное значение называется фактором подверженности воздействию. Это же значение используется в перечнях рисков обобщенного и детализированного уровней. Консервативный подход заключается в использовании линейной скользящей шкалы для каждого значения уровня подверженности воздействию. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, рекомендует использовать для каждого значения уровня подверженности воздействию 20-процентную скользящую шкалу. Эту величину можно изменять в соответствии с потребностями конкретной организации. Последний шаг состоит в получении количественной оценки влияния путем умножения стоимости актива на фактор подверженности воздействию. В классической количественной модели это значение называется величиной ожидаемого разового ущерба (ОРУ). На рис. 4.22 приведен пример простого количественного подхода. Обратите внимание, что данный пример просто разделяет класс ВВБ на две части, чтобы определить средние и низкие значения. По мере получения опыта в оценке рисков эти значения могут быть изменены. Руководство по управлению рисками безопасности 79 Рис. 4.22. Рабочий лист анализа риска: количественная оценка ожидаемого разового ущерба (SRMGTool3) Пример банка Woodgrove. На рис. 4.23 показаны значения для определения ОРУ для двух примеров риска. Рис. 4.23. Определение ожидаемого разового ущерба в примере с банком Woodgrove Bank: суммы указаны в миллионах долларов (SRMGTool3) Задача 4. Определение ежегодной частоты возникновения (ЕЧВ) После определения ожидаемого разового ущерба необходимо определить вероятность ущерба, чтобы завершить денежную оценку риска. Общепринятый подход состоит в оценке частоты возникновения риска в будущем. В дальнейшем полученное значение преобразуется в годичную оценку. Например, если группа информационной безопасности считает, что риск может возникнуть два раза в год, ежегодная частота возникновения (ЕЧВ) будет равна 2. Если риск может возникнуть один раз в три года, ЕЧВ будет равна одной третьей (33%, или 0,33). Чтобы получить оценку вероятности, используйте качественный подход, описанный выше при рассмотрении подробного расчета риска. Чтобы упростить определение и передачу количественной оценки ЕЧВ, воспользуйтесь рис. 4.24. Рис. 4.24. Количественная оценка ежегодной частоты возникновения (SRMGTool3) Приведенный выше рисунок может использоваться только в справочных целях. Выбор значения, представляющего ЕЧВ, должен осуществляться группой информационной безопасности. Пример банка Woodgrove. Группа управления рисками безопасности определила, что выбранные риски имеют следующие значения ЕЧВ. ЕЧВ для узлов локальной сети. Используя качественную оценку среднего уровня вероятности, группа управления рисками безопасности определила, что данный риск может возникать один раз в два года или чаще. Таким образом, значение ЕЧВ равно 0,5. ЕЧВ для удаленных узлов. Используя качественную оценку высокого уровня вероятности, группа управления рисками безопасности определила, что данный риск может возникать один раз в год или чаще. Таким образом, значение ЕЧВ равно 1. 80 Глава 4. Оценка рисков Задача 5. Определение ожидаемого годового ущерба (ОГУ) Чтобы завершить количественную оценку, умножьте ежегодную частоту возникновения на величину ожидаемого разового ущерба. Полученное значение называется ожидаемым годовым ущербом (ОГУ). Ожидаемый годовой ущерб (ОГУ) = ЕЧВ × ОРУ Величина ОГУ характеризует потенциальные годовые убытки от риска. Хотя данный показатель может помочь в оценке ущерба заинтересованным лицам, имеющим финансовую подготовку, группа управления рисками безопасности должна напомнить, что влияние на организацию не ограничивается величиной годовых издержек — возникновение риска может повлечь за собой причинение ущерба в полном объеме. Определив количественную оценку риска, откройте рабочий лист перечня рисков на уровне детализации, который содержит дополнительный столбец, позволяющий указать дополнительные сведения о количественной оценке и необходимые пояснения. Используйте этот столбец, чтобы при необходимости помочь обосновать количественную оценку и привести доказательства. Пример банка Woodgrove. На рис. 4.25 показаны базовые расчеты по определению ОГУ для каждого примера риска. Обратите внимание, что одно изменение любого показателя может привести к значительному изменению ОГУ. Используйте соответствующие качественные данные, чтобы определить количественную оценку и обосновать сделанный выбор. Рис. 4.25. Определение величины ожидаемого годового ущерба в примере с банком Woodgrove Bank: суммы указаны в миллионах долларов (SRMGTool3) Заключение Этап оценки рисков цикла управления рисками необходим для управления рисками в рамках организации. Выполняя планирование, координированный сбор данных приоритизацию, помните, что этап оценки рисков призван не только выявить риски и определить их приоритеты, но и обеспечить выполнение этих задач в сжатые сроки и с максимальной эффективностью. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, использует комбинированный подход, который основан на применении качественного анализа для быстрого поиска рисков и выявления наиболее существенных из них и последующем определении рисков с помощью финансовых атрибутов, полученных в ходе количественного анализа. Помощь на этапе поддержки принятия решений Определив приоритеты рисков для организации, группа управления рисками безопасности должна выбрать соответствующие стратегии нейтрализации риска. Чтобы помочь заинтересованным лицам в выборе решений по нейтрализации риска, группа должна разработать функциональные требования, которые помогут ограничить сферу действия стратегии нейтрализации риска для соответствующего сотрудника, ответственного за нее. Вопрос разработки функциональных требований в рамках более масштабного процесса поддержки принятия решений рассматривается в главе 5 «Поддержка принятия решений». Глава 5. Поддержка принятия решений Обзор К этому моменту организация должна завершить оценку рисков и иметь ранжированный по приоритетам перечень рисков для наиболее ценных активов. Следующей задачей, которая стоит перед организацией, является борьба с наиболее существенными рисками путем определения перечня мероприятий по снижению рисков. Данный этап называется этапом поддержки принятия решений. На предыдущем этапе группа управления рисками безопасности занималась поиском активов, угроз для этих активов, уязвимостей, которые могли быть использованы найденными угрозами с целью потенциального влияния на активы, и элементов контроля, которые уже используются для обеспечения безопасности активов. После этого группа управления рисками безопасности формировала ранжированный по приоритетам перечень рисков. Процесс поддержки принятия решений включает формальный анализ выгод и затрат с определением ролей и обязанностей в рамках организации. Анализ выгод и затрат позволяет создать универсальную целостную структуру для поиска, определения сферы действия и выбора наиболее результативных и экономически эффективных решений по нейтрализации риска для снижения рисков до приемлемого уровня. Как и в случае с процессом оценки рисков, для эффективного использования анализа выгод и затрат необходимо строгое распределение ролей. Кроме того, перед анализом выгод и затрат группа управления рисками безопасности должна убедиться, что все заинтересованные лица, включая ответственного руководителя, согласны с процессом. На этапе поддержки принятия решений группа управления рисками безопасности должна определить наиболее результативные и экономически эффективные меры противодействия основным рискам безопасности. Конечным результатом данного процесса является разработка четких планов, позволяющих уменьшить, принять, передать или устранить каждый из основных рисков, обнаруженных в ходе оценки рисков. Этап поддержки принятия решений включает следующие шесть шагов. 1. Определение функциональных требований. 2. Выбор возможных решений для контроля. 3. Проверка соответствия решений требованиям. 4. Оценка уровня снижения риска, обеспечиваемого применением каждого решения для контроля. 5. Оценка стоимости каждого решения. 6. Выбор стратегии нейтрализации риска. На рис. 5.1 изображены перечисленные выше шаги и место этапа поддержки принятия решений в общем процессе управления рисками безопасности корпорации Майкрософт. 82 Глава 5. Поддержка принятия решений Рис. 5.1. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт: этап поддержки принятия решений Сравнение стоимостей различных элементов контроля может оказаться весьма сложной задачей, что обусловлено целым рядом причин. Например, некоторые элементы контроля влияют на несколько активов. Группа управления рисками безопасности должна согласовать принципы сравнения стоимостей элементов контроля, влияющих на разные комбинации активов. Кроме того, существуют такие затраты, которые напрямую не связаны с применением элементов контроля. Необходимо рассмотреть следующие вопросы. Как долго контроль будет эффективен? Сколько человеко-часов в год требуется для мониторинга и поддержания контроля? Какие неудобства в работе пользователей создает контроль? Какое обучение должны пройти сотрудники, ответственные за внедрение, мониторинг и поддержание контроля? Обоснованы ли затраты на контроль по сравнению со стоимостью соответствующего актива? В оставшейся части данной главы будут рассмотрены ответы на эти вопросы. Чтобы успешно завершить этап поддержки принятия решений, нужно следовать строгому плану. Кроме того, необходимо, чтобы участники понимали свою роль на каждом шаге. На следующей схеме (рис. 5.2) показаны действия группы управления рисками безопасности в процессе поддержки принятия решений. Ответственные за нейтрализацию риска должны предложить элементы контроля для снижения рисков и определить стоимость каждого из них. Для каждого предложенного элемента контроля группа управления рисками безопасности оценивает уровень снижения риска, который сможет обеспечить контроль. Имея эту информацию, группа управления рисками безопасности может выполнить эффективный анализ выгод и затрат в отношении элемента контроля и определить, рекомендовать ли его внедрение. Руководство по управлению рисками безопасности 83 После этого организационный комитет по обеспечению безопасности выбирает элементы контроля, подлежащие реализации. Рис. 5.2. Обзор этапа поддержки принятия решений Строгое распределение ролей уменьшает задержки, поскольку за принятие решений отвечает только одна группа. Однако опыт показывает, что общая эффективность процесса управления рисками повышается, если все ответственные сотрудничают с заинтересованными лицами. Примечание. Управление рисками представляет собой бесконечный цикл, поэтому поддержание командного духа повышает моральное состояние заинтересованных лиц и может способствовать снижению рисков для организации, позволяя заинтересованным лицам видеть результаты своей деятельности и своевременно выполнять действия по снижению рисков. Безусловно, это настроение необходимо поддерживать на протяжении всего процесса управления рисками и процесса поддержки принятия решений. Требуемые входные данные для этапа поддержки принятия решений Единственной информацией, которая определяется на этапе оценки рисков и потом требуется на этапе подготовки данных для принятия решений, является ранжированный по приоритетам перечень рисков, которые необходимо нейтрализовать. Если организация выполнила процедуры, описанные в главе 4 «Оценка рисков», эта информация должна быть сохранена на рабочем листе анализа рисков файла Microsoft® Excel® SRMGTool3-Detailed Level Risk Prioritization.xls, который находится в папке Tools and Templates (эта папка создается при распаковке архива, содержащего данное руководство и сопутствующие файлы). Этот же рабочий лист будет использоваться на данном этапе процесса. Участники этапа поддержки принятия решений Состав участников этапа поддержки принятия решений схож с составом участников этапа оценки рисков. Фактически большинство членов групп (или даже все члены групп) участвуют в выполнении задач обоих этапов. Анализ выгод и затрат обрисовывает большинство задач, возникающих на этапе поддержки принятия решений. Прежде чем выполнять анализ выгод и затрат, убедитесь, что все заинтересованные лица понимают свои роли. 84 Глава 5. Поддержка принятия решений В таблице 5.1 перечислены роли и основные обязанности для каждой группы в процессе поддержки принятия решений. Таблица 5.1. Роли и обязанности в программе управления рисками Роль Обязанности Бизнес-операции Поиск процедурных элементов контроля для управления рисками Владелец организации Ответственность за анализ выгод и затрат для актива Финансы Помощь в выполнении анализа выгод и затрат; может помочь при разработке бюджета и контроле исполнения Персонал Определение требований к обучению персонала и контроль обучения ИТ-архитектура Поиск и оценка потенциальных элементов контроля ИТ-проектирование Определение стоимости решений для контроля и путей их реализации ИТ-операции Реализация технических решений для контроля Внутренний аудит Определение требований к обеспечению соответствия и проверка эффективности контроля Юриспруденция Выявление элементов контроля, соответствующих требованиям законодательства, политик и договоров; проверка оценок, созданных для учета влияния бренда, ответственности корпорации и других факторов, возникающих при ведении коммерческой деятельности Связи с общественностью Проверка оценок, созданных для учета влияния бренда, ответственности корпорации и других факторов, возникающих при ведении коммерческой деятельности Организационный комитет по обеспечению безопасности Выбор элементов контроля на основании рекомендаций группы управления рисками безопасности Группа управления рисками Определение функциональных требований безопасности к элементам контроля для каждого риска, информирование заинтересованных лиц и пользователей о состоянии проекта по мере необходимости Группа управления рисками безопасности должна определить технологии обеспечения безопасности для каждого риска. Наличие одного контактного лица уменьшает вероятность того, что группа управления рисками безопасности будет отправлять несогласованные сообщения, и позволяет использовать четкую модель взаимодействия на протяжении всего процесса анализа выгод и затрат. Руководство по управлению рисками безопасности 85 Средства поддержки принятия решений Информация, собранная на данном этапе, должна быть сохранена на рабочем листе рисков на уровне детализации в файле SRMGTool3-Detailed Level Risk Prioritization.xls, который находится в папке Tools and Templates (эта папка создается при распаковке архива, содержащего данное руководство и сопутствующие файлы). Требуемые выходные данные этапа поддержки принятия решений На этом этапе процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, необходимо определить и выбрать ключевые элементы данных о каждом из приоритетных рисков, обнаруженных на этапе оценки рисков. Эти ключевые элементы сведены в таблице 5.2. Более подробное их описание см. в следующих разделах. Таблица 5.2. Требуемые выходные данные этапа поддержки принятия решений Собираемая информация Описание Решение о методе реагирования на каждый риск Следует ли уменьшать, принимать, передавать или устранять каждый из приоритетных рисков Функциональные требования Описание функций, необходимых для снижения риска Возможные решения для контроля Перечень элементов контроля, определенных ответственными за нейтрализацию риска и группой управления рисками безопасности и способных эффективно уменьшить каждый риск Уменьшение риска каждым решением для контроля Оценка каждого решения по обеспечению безопасности и определение величины снижения риска для актива Оценочная стоимость каждого решения для контроля Все затраты, связанные с приобретением, внедрением, поддержкой и контролем работоспособности каждого предложенного решения Перечень решений для контроля, подлежащих реализации Выбор, сделанный в результате анализа выгод и затрат Анализ вариантов поддержки принятия решений У организаций существует два основных варианта реагирования на риски: принять риск или внедрить элементы контроля для его снижения. Если организация решает принять риск, она может передать риск или его часть третьей стороне, например страховой компании или компании, предоставляющей управляемые услуги. Эти подходы (принятие риска и реализация контроля для снижения риска) рассмотрены в следующих двух разделах. Примечание. Многие специалисты по управлению рисками безопасности считают, что существует еще один вариант — устранение риска. Однако необходимо помнить, что, выбирая вариант устранения риска, организация принимает решение прекратить 86 Глава 5. Поддержка принятия решений все операции, связанные с данным риском. Чтобы устранить риск безопасности, организации придется прекратить пользоваться информационной системой, содержащей данный риск. Например, если риск состоит в том, что «на протяжении одного года система безопасности серверов, на которых не установлены обновления безопасности, может быть нарушена вредоносными программами, что может привести к нарушению целостности финансовых данных», единственным вариантом устранения данного риска является отказ от использования серверов, что, скорее всего, невозможно. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, исходит из того, что организации оценивают только активы, которые имеют бизнес-ценность и должны использоваться. По этой причине устранение рисков в данном руководстве не рассматривается. Принятие текущего риска Организационный комитет по обеспечению безопасности должен принять текущий риск, если окажется, что не существует экономически эффективных элементов контроля, способных уменьшить этот риск. Это не означает, что организация не может оперировать с данным риском путем реализации одного или нескольких элементов контроля. Это означает, что затраты на внедрение элементов контроля или издержки от их влияния на возможность ведения бизнеса в организации являются высокими по сравнению со стоимостью актива, требующего защиты. В качестве примера рассмотрим следующий случай. Группа управления рисками безопасности обнаружила, что одним из наиболее приоритетных рисков для основных активов организации является применение паролей для проверки пользователей при входе в корпоративную сеть. Группа управления рисками безопасности определила, что наиболее эффективным средством, позволяющим уменьшить использование паролей при проверке подлинности или полностью отказаться от системы паролей, является применение двухфакторной проверки подлинности, например с использованием смарт-карт. После этого ответственный за нейтрализацию риска рассчитал затраты на внедрение смарт-карт в рамках всей организации и влияние данного решения на используемые в организации приложения и операционную систему. Стоимость реализации оказалась достаточно высокой, но обоснованной, однако обнаружилось, что многие приложения, разработанные подразделениями организации, используют систему проверки подлинности на основе паролей и внесение изменений в эти приложения или их замена приведут к очень большим затратам и потребуют нескольких лет. В результате группа управления рисками безопасности приняла решение в ближайшем будущем не рекомендовать организационному комитету по обеспечению безопасности использовать смарт-карты для всех сотрудников, а предложить ввести обязательное использование смарт-карт при проверке подлинности администраторов доменов, основных руководителей и других сотрудников, обладающих существенными правами или имеющих доступ к важным данным. Организационный комитет по обеспечению безопасности принимает решение последовать рекомендациям группы управления рисками безопасности и не вводить обязательное использование смарт-карт для всех сотрудников. Одним из вариантов принятия риска является передача риска третьей стороне (например, путем страхования ИТ-активов, которое становится доступным в настоящее время, или путем заключения соглашения с другими компаниями, специализирующимися на предоставлении управляемых служб обеспечения безопасности). При этом внешний подрядчик может частично или полностью принять на себя ответственность за защиту ИТ-активов организации. Реализация контроля для снижения рисков Элементы контроля, иногда называемые мерами безопасности или контрмерами, представляют собой организационное, процедурное или технологическое управление рисками. Ответственные за нейтрализацию риска с помощью группы управления рисками безопасности выявляют все возможные элементы контроля, рассчитывают стоимость реализации каждого элемента контроля, определяют прочие затраты, относящиеся к данному элементу контроля (такие как снижение удобства работы пользователей или затраты на обслуживание элемента контроля), и оценивают возможное снижение риска, достигаемое при внедрении каждого Руководство по управлению рисками безопасности 87 элемента контроля. Все эти данные позволяют рабочей группе выполнить анализ выгод и затрат для каждого предложенного элемента контроля. Элементы контроля, которые наиболее эффективно снижают риски для основных активов и имеют приемлемую стоимость, в дальнейшем рекомендуются для реализации. Условия успешной реализации Как и на этапе оценки рисков, рациональный выбор ожиданий является необходимым условием успешного завершения этапа поддержки принятия решений. Поддержка принятия решений требует активного участия различных групп, представляющих всю организацию. Если хотя бы одна из этих групп не понимает особенностей процесса или не принимает активного участия, это может отрицательно сказаться на эффективности программы в целом. Убедитесь, что каждому участнику хорошо известно, что от него ожидают на этапе поддержки принятия решений, включая роли, обязанности и степень участия. Достижение единогласия Очень важно, чтобы все члены группы управления рисками безопасности по возможности достигали единогласия. В противном случае комментарии членов группы, имеющих особое мнение, могут дискредитировать рекомендации, передаваемые группой управления рисками безопасности организационному комитету по обеспечению безопасности. Даже если комитет одобрит полученные рекомендации, в дальнейшем подобное расхождение во взглядах может привести к неудаче при внедрении элементов контроля. Чтобы весь процесс управления рисками завершился успешно, необходимо, чтобы все члены группы были согласны с рекомендуемыми элементами контроля и поддерживали их внедрение. Избежание обструкционизма Поскольку одной из задач этого этапа является единогласное формирование перечня элементов контроля, любое участвующее в данном процессе заинтересованное лицо может замедлить или остановить работу, прибегнув к обструкционизму. Это означает, что любой участник этапа поддержки принятия решений может решить, что он не согласен рекомендовать тот или иной элемент контроля. И наоборот, если какой-то из рассматриваемых элементов контроля будет отвергаться, кто-то может попытаться навязать свое мнение большинству. Очень важно, чтобы координатор оценки рисков нейтрализовал проявления обструкционизма. Подробное рассмотрение вопросов управления этой проблемой находится за пределами данного руководства, однако эффективные тактики включают в себя поиск основных причин особой точки зрения и последующее их обсуждение с рабочей группой с целью нахождения эффективных альтернатив или компромиссов, которые были бы приемлемы для всех членов группы. Выявление и сравнение элементов контроля В данном разделе объясняется, каким образом ответственные за нейтрализацию риска могут выявить потенциальные решения по контролю и определить типы затрат, связанных с внедрением каждого элемента контроля, и каким образом группа управления рисками безопасности будет оценивать уровень снижения риска, обеспечиваемый каждым предложенным элементом контроля. В дальнейшем ответственные за нейтрализацию риска и группа управления рисками безопасности предоставляют результаты своего анализа и рекомендации организационному комитету по обеспечению безопасности, который формирует окончательный перечень подлежащих внедрению элементов контроля. 88 Глава 5. Поддержка принятия решений Следующая схема (рис. 5.3) представляет собой извлечение из рабочего листа рисков на уровне детализации, который входит в рабочую книгу Excel, используемую для подробной оценки рисков, как описано в предыдущей главе. Этот рабочий лист (SRMGTool3-Detailed Level Risk Prioritization.xls) поставляется вместе с данным руководством и находится в папке Tools and Templates. Приведенная схема показывает все элементы, использованные при анализе выгод и затрат. Отдельные столбцы описаны ниже. Рис. 5.3. Раздел поддержки принятия решений на рабочем листе рисков на уровне детализации (SRMGTool3) Примечание. Данный рабочий лист призван помочь определить уменьшение вероятности влияния при определении уровня снижения риска. Предполагается, что стоимость актива не изменяется за время оценки рисков. Как правило, уровень подверженности воздействию (величина ущерба, который может быть причинен активу) остается постоянным. Опыт показывает, что уровни подверженности воздействию обычно не изменяются, если описания угроз и уязвимостей указаны с достаточной степенью детализации. Шаг 1. Определение функциональных требований Функциональные требования к безопасности представляют собой формулировки, описывающие элементы контроля, необходимые для нейтрализации риска. Термин «функциональные» является очень важным, поскольку при описании необходимо указывать желаемые функции, а не используемые технологии. Кроме того, для снижения рисков могут использоваться альтернативные технические решения и другие методы, соответствующие функциональным требованиям к безопасности. Функциональные требования к безопасности разрабатываются группой управления рисками безопасности и являются первым результатом процесса анализа выгод и затрат. Чтобы найти возможные элементы контроля, группа управления рисками безопасности должна определить, какие результаты должно обеспечивать применение элементов контроля, чтобы это позволило снизить риски. Хотя ответственность за выполнение данной задачи возлагается на группу управления рисками безопасности, в процессе работы группе рекомендуется сотрудничать с ответственными за нейтрализацию риска. Руководство по управлению рисками безопасности 89 Функциональные требования должны быть определены для каждого риска, рассмотренного в процессе поддержки принятия решений. В результате будут получены определения функциональных требований. Определение функциональных требований и ответственных за их соблюдение является важным условием анализа выгод и затрат. В данном документе описано, что должно происходить, чтобы выявленный риск уменьшился, но не указаны способы снижения риска и не определены конкретные элементы контроля. Это разделение возлагает на группу управления рисками безопасности ответственность за выполнение своих обязанностей, однако позволяет ответственным за нейтрализацию риска, внедряющим соответствующие элементы контроля, принимать решения относительно осуществления своей деятельности. Сведения о реагировании на каждый риск изложены в столбце Functional Security Requirement («Функциональные требования к безопасности») файла SRMG3-Detailed Level Risk Prioritization.xls. Функциональные требования необходимо повторно анализировать не реже чем раз в год, чтобы определить, нужно ли вносить изменения в эти требования. Рис. 5.4. Первый шаг этапа поддержки принятия решений Мероприятия, выполненные на предыдущем этапе, позволяют организациям выявить свои риски и рационально определить элементы контроля, которые следует внедрить для уменьшения наиболее существенных рисков. Ответственные руководители и владельцы организаций хотят знать мнение группы информационной безопасности о действиях организации в отношении каждого риска. Чтобы ответить на возникающие вопросы, группа информационной безопасности разрабатывает функциональные требования к безопасности. При этом для каждого риска четко указываются типы функций или процессов, которые необходимо внедрить для снижения данного риска. Пример банка Woodgrove. В примере с банком Woodgrove Bank, рассмотренном в предыдущей главе, функциональным требованием для риска хищения учетных данных с управляемых компьютеров локальной сети вследствие несвоевременного обновления баз данных антивирусных средств или конфигураций узлов или несвоевременной установки обновления системы безопасности может являться следующее. При входе пользователей в локальную сеть НЕОБХОДИМА проверка подлинности с применением двух или более факторов. Следующее требование не является функциональным. Решение ДОЛЖНО использовать смарт-карты для проверки подлинности пользователей. 90 Глава 5. Поддержка принятия решений Второе требование не является функциональным, поскольку оно описывает применение определенной технологии. Предоставление перечня конкретных элементов контроля, соответствующих функциональным требованиям, является обязанностью ответственных за нейтрализацию риска. При этом ответственные преобразуют функциональные требования в технические решения по снижению рисков и административные элементы контроля (политики, стандарты, рекомендации и т. п.). Функциональное требование к безопасности для второго риска, рассмотренного при подробной приоритизации рисков (риск хищения учетных данных с удаленных и мобильных узлов вследствие несвоевременного обновления конфигурации системы безопасности), имеет следующий вид. При удаленном входе пользователей в сеть НЕОБХОДИМА проверка подлинности с применением двух или более факторов. Укажите функциональные требования для каждого риска в столбце Functional Security Requirements («Функциональные требования к безопасности») файла SRMGTool3-Detailed Level Risk Prioritization.xls. На веб-странице www.ietf.org/rfc/rfc2119.txt находится документ RFC 2119 группы IETF, содержащий рекомендации по использованию основных слов и предложений в описании требований. К числу этих терминов относятся ДОЛЖЕН, НЕ ДОЛЖЕН, ТРЕБУЕТСЯ, ОБЯЗАН, СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, МОЖЕТ и НЕОБЯЗАТЕЛЬНО. Как правило, эти термины выделяются прописными буквами. Корпорация Майкрософт рекомендует использовать эти основные термины при составлении функциональных требований, руководствуясь следующими правилами, приведенными в документе RFC 2119. ДОЛЖЕН. Данный термин (или ТРЕБУЕТСЯ и ОБЯЗАН) означает, что соответствующее определение является обязательным требованием спецификации. Например, если оценка рисков выявила высокий риск, слово ДОЛЖЕН, вероятно, является наилучшим термином, описывающим требования для этого случая. НЕ ДОЛЖЕН. Данный термин означает, что соответствующее определение ни в коем случае не должно применяться. СЛЕДУЕТ. Этот термин (или РЕКОМЕНДУЕТСЯ) означает, что в ряде случаев могут существовать причины, чтобы игнорировать определенное требование, однако при этом необходимо полностью понимать особенности реализации и тщательно взвешивать свои действия. Например, если оценка рисков выявила низкий риск, слово СЛЕДУЕТ является наилучшим термином, описывающим требования для этого случая. НЕ СЛЕДУЕТ. Этот термин (или НЕ РЕКОМЕНДУЕТСЯ) означает, что в ряде случаев определенное поведение может являться допустимым или даже выгодным, однако при этом необходимо полностью понимать особенности реализации и тщательно взвешивать свои действия. МОЖЕТ. Этот термин (или НЕОБЯЗАТЕЛЬНО) означает, что соответствующий элемент является необязательным. Один поставщик может включать какой-либо элемент, поскольку этого требует местный рынок или поставщик считает, что это улучшит продукт, в то время как другой поставщик может не использовать этот элемент. Реализация, не включающая конкретный дополнительный элемент, ДОЛЖНА быть готова к взаимодействию с другой реализацией, включающей этот элемент, даже если это приведет к ограничению функциональных возможностей. Аналогично, реализация, включающая какой-либо необязательный элемент, ДОЛЖНА быть готова к взаимодействию с другой реализацией, не включающей этот элемент (за исключением возможностей, предоставляемых данным элементом). После того как функциональные требования для каждого риска будут определены и задокументированы, организация будет готова перейти к следующему шагу этапа поддержки принятия решений. Руководство по управлению рисками безопасности 91 Шаг 2. Поиск решений для контроля На следующем шаге данного этапа ответственные за нейтрализацию риска должны составить для каждого риска перечень новых потенциальных элементов контроля в соответствии с функциональными требованиями для данного риска. Во многих организациях члены группы информационной безопасности смогут помочь в решении этой задачи, определив диапазон возможных элементов контроля для каждого риска, который был обнаружен и проанализирован на предыдущем этапе. В организациях, не имеющих опыта решения подобных задач собственными силами, ответственным за нейтрализацию риска может потребоваться помощь консультантов. Рис. 5.5. Второй шаг этапа поддержки принятия решений Процесс поиска потенциальных элементов контроля может показаться очень сложным, особенно если ответственные за нейтрализацию риска (или большая их часть) делали этого ранее. Существует два подхода, которые могут помочь рабочим группам в поиске новых идей (многие организации используют оба эти подхода). Первый подход состоит в организации неформальных мозговых штурмов, а второй является более формальным и основывается на классификации и упорядочивании элементов контроля. Группе управления рисками безопасности следует использовать оба эти подхода. При проведении мозговых штурмов координатор оценки рисков предлагает рабочей группе ответить на приведенные ниже серии вопросов по каждому риску. Секретарь оценки рисков документирует все ответы в столбце Proposed Control («Предлагаемый элемент контроля») рабочего листа рисков на уровне детализации в файле SRMGTool3-Detailed Level Risk Prioritization.xls. Эта процедура повторяется, пока все существенные риски не будут проанализированы и рабочая группа не перейдет к определению размеров затрат, связанных с каждым элементом контроля. Какие действия может предпринять организация, чтобы противостоять риску или предотвратить его? Например, внедрить многофакторную проверку подлинности, уменьшающую риск нарушения парольной защиты, или развернуть инфраструктуру автоматизированного управления исправлениями, уменьшающую вероятность нарушения системы безопасности вредоносными мобильными приложениями. 92 Глава 5. Поддержка принятия решений Какие действия может предпринять организация, чтобы устранить последствия возникновения риска? Например, сформировать и обучить квалифицированную группу реагирования или внедрить и проверить процессы архивации и восстановления для всех компьютеров, работающих под управлением серверных операционных систем. Кроме того, организация может разместить в удаленных офисах избыточные вычислительные ресурсы, которые будут использоваться при выходе из строя оборудования в основном офисе. Каким образом организация может обнаружить возникновение риска? Например, установить в демилитаризованной зоне и ключевых точках внутренней сети сетевую систему обнаружения вторжений или установить распределенную систему обнаружения вторжений на всех компьютерах организации. Каким образом можно осуществлять мониторинг и аудит выбранного элемента контроля, чтобы убедиться в его работоспособности? Например, установив предоставляемые производителем продукта элементы контроля и регулярно проверяя их. Каким образом организация может проверить эффективность элемента контроля? Например, обратившись к эксперту по уязвимостям, позволяющим обойти данный элемент контроля. Существуют ли еще какие-либо действия, позволяющие управлять рассматриваемым риском? Например, передача риска путем страхования, чтобы обезопасить себя от связанных с риском убытков. Второй метод поиска новых потенциальных элементов контроля разделяет элементы контроля на три большие категории: организационные, операционные и технологические. На более низких уровнях элементы контроля делятся на предотвращающие, обнаруживающие, восстанавливающие и управляющие. Предотвращающие элементы контроля призваны предотвратить возникновение риска (например, путем устранения брешей прежде, чем о них станет известно). Обнаруживающие и восстанавливающие элементы контроля помогают организациям обнаруживать возникновение проблем с безопасностью и восстанавливать нормальную работу после их устранения. Управляющие элементы контроля сами по себе не обеспечивают защиту, однако они необходимы для использования других элементов контроля. Эти категории более подробно рассматриваются в следующих разделах. Организационные элементы контроля Организационные элементы контроля представляют собой процессы и процедуры, определяющие, каким образом сотрудники организации должны выполнять свои обязанности. В число предотвращающих элементов контроля в данной категории входят следующие. Строгое распределение ролей и обязанностей. Необходимо строго распределить и задокументировать роли и обязанности, чтобы руководство и персонал организации знали, кто несет ответственность за обеспечение надлежащего уровня безопасности наиболее важных ИТ-активов. Установка минимальных привилегий и разделение обязанностей. Если данный элемент контроля реализован надлежащим образом, то сотрудники имеют лишь те права доступа к ИТ-системам, которые необходимы им для выполнения должностных обязанностей. Документирование процедур и планов обеспечения безопасности. Процедуры и планы обеспечения безопасности разрабатываются, чтобы пояснить, каким образом реализованы и поддерживаются элементы контроля. Проведение учебных курсов по безопасности и постоянное информирование. Этот элемент контроля необходим, чтобы все пользователи и сотрудники ИТ-подразделения знали свои обязанности и правила использования информационных активов, позволяющие защитить данные организации. Руководство по управлению рисками безопасности 93 Системы и процессы инициализации и деинициализации пользователей. Эти элементы контроля необходимы для быстрого обеспечения производительности работы новых членов организации и немедленного лишения доступа уволившихся сотрудников. Процессы инициализации должны также поддерживать сопряженный с изменением уровня доступа перевод сотрудника в другую группу внутри организации. Например, в связи с изменением должностных обязанностей уровень допуска руководителей может изменяться с секретного до совершенно секретного и наоборот. Применение процессов предоставления доступа подрядчикам, поставщикам, партнерам и заказчикам. Как правило, данный элемент контроля является разновидностью описанных выше элементов контроля для инициализации пользователей, однако зачастую между ними существуют отличия. В частности, предоставление общего доступа к данным одной группе внешних пользователей и предоставление общего доступа к другому набору данных другой их группе может оказаться сложной задачей. Законодательные и регулятивные требования зачастую ограничивают возможности выбора (например, при работе с финансовыми или медицинскими данными). В число обнаруживающих элементов контроля в данной категории входят следующие. Постоянное выполнение программ управления рисками с целью оценки и контроля рисков, угрожающих основным активам организации. Периодический анализ элементов контроля с целью проверки их эффективности. Периодический аудит систем, позволяющий убедиться в правильности конфигурации систем и в отсутствии ее нарушений. Изучение прошлого соискателей вакантных должностей. Кроме того, организация должна рассмотреть необходимость дополнительного изучения прошлого сотрудников, если их переход на новые должности связан со значительным расширением прав доступа к ИТ-активам организации. Введение практики ротации обязанностей, позволяющей эффективно выявлять злоупотребления со стороны сотрудников ИТ-подразделения и пользователей, имеющих доступ к важным сведениям. В число управляющих элементов контроля в данной категории входят следующие. Планирование реакции на инциденты, обеспечивающее организации возможность быстро реагировать на нарушения безопасности и быстро восстанавливать работоспособность после нарушений, уменьшая влияние нарушения и предотвращая распространение проблем на другие системы. Планирование мер обеспечения непрерывной работы организации, позволяющее восстанавливать работоспособность после катастрофических событий, влияющих на значительную часть ИТ-инфраструктуры. Операционные элементы контроля Операционные элементы контроля определяют, каким образом сотрудники организации должны использовать данные, оборудование и программное обеспечение, и включают меры физической защиты и защиты среды, как описано ниже. В число предотвращающих элементов контроля в данной категории входят следующие. Обеспечение безопасности вычислительных активов с использованием физических средств (таких как охрана, электронные идентификационные карточки и замки, биометрические замки и ограждения). Физические средства защиты пользовательских систем, включая замки и сигнализации для мобильных компьютеров и средства шифрования файлов, хранящихся на мобильных устройствах. Резервные источники питания, защищающие важные электрические системы от снижений и отключений напряжения и позволяющие приложениям и операционным системам завершить работу в штатном порядке, чтобы сохранить данные и транзакции. 94 Глава 5. Поддержка принятия решений Системы противопожарной защиты (такие как огнетушители и системы автоматического пожаротушения), являющиеся важным средством защиты основных активов организации. Системы контроля температуры и влажности, продлевающие срок службы важного электрического оборудования и помогающие защитить данные, которые хранятся на этом оборудовании. Процедуры контроля доступа к носителям данных и утилизации носителей данных, гарантирующие, что доступ к важным данным имеет только полномочный персонал и что перед утилизацией носителей, использовавшихся для хранения подобных данных, вся находившаяся на них информация будет удалена с помощью процедур размагничивания или других методов. Архивация систем и данных для хранения вне основного офиса, упрощающая восстановление поврежденных и утраченных данных. В случае катастрофических событий резервные носители данных, хранящиеся вне основного офиса, позволяют разместить важные данные на резервных системах. В число обнаруживающих и восстанавливающих элементов контроля в данной категории входят следующие. Меры обеспечения физической безопасности (например, сенсоры, системы сигнализации, камеры и датчики движения), которые защищают организацию от злоумышленников, пытающихся получить доступ к активам организации. Системы контроля за состоянием окружающей среды (например, датчики возгорания и задымления, сигнализация, сенсоры и системы обнаружения затопления), защищающие организацию от пожаров, затоплений и других угроз со стороны внешней среды. Технологические элементы контроля Технологические элементы контроля имеют различную сложность и включают разработку архитектуры системы, проектирование, оборудование, программное обеспечение и микропрограммы. Все они представляют собой технологические компоненты, используемые для создания информационных систем организаций. В число предотвращающих элементов контроля в данной категории входят следующие. Проверка подлинности. Процесс проверки учетных данных пользователя, компьютера, процесса или устройства. Для проверки подлинности необходимо, чтобы пользователь, процесс или устройство отправили запрос и предоставили идентифицирующие отправителя учетные данные. Общепринятыми формами учетных данных являются цифровые подписи, смарт-карты, биометрические данные и сочетания имени пользователя и пароля. Авторизация. Процесс предоставления пользователю, компьютерному процессу или устройству доступа к определенным данным, услугам или возможностям. Авторизация выполняется на основе учетных данных, предоставленных запрашивающим доступ пользователем, компьютерным процессом или устройством и проверенных в ходе проверки подлинности. Неподдельность. Эта технология используется, чтобы гарантировать, что пользователь, выполнивший какое-либо действие на компьютере, не сможет отрицать выполнение им этого действия. Неподдельность позволяет получить неопровержимые доказательства выполнения таких операций, как перевод денег, подтверждение покупки и отправка сообщений. Управление доступом. Механизм ограничения доступа к определенной информации на основании учетных данных пользователя и членства в предварительно определенных группах. Управление доступом может быть обязательным, на уровне пользователей и на основе ролей. Защищенные каналы связи. Эти элементы контроля используют шифрование для обеспечения целостности и конфиденциальности данных, передаваемых по сети. Руководство по управлению рисками безопасности 95 В число обнаруживающих и восстанавливающих элементов контроля в данной категории входят следующие. Системы аудита. Позволяют выполнять мониторинг и отслеживание поведения системы, отклоняющегося от установленных норм. Системы аудита являются основным средством обнаружения, изучения и устранения брешей в системе безопасности. Антивирусные средства. Предназначены для обнаружения программ-червей, вирусов и других вредоносных программ и борьбы с ними. Для борьбы с вредоносными программами могут использоваться блокирование доступа к зараженным файлам, очистка зараженных файлов и систем и оповещение пользователей об обнаружении зараженных программ. Средства обеспечения целостности системы. Позволяют сотрудникам ИТ-подразделений проверять, вносились ли в систему несанкционированные изменения. Например, некоторые средства обеспечения целостности системы вычисляют контрольные суммы для всех файлов системы и сохраняют полученные результаты в базе данных на отдельном компьютере, а в дальнейшем позволяют автоматически сравнивать текущую конфигурацию системы и сохраненную ранее удачную конфигурацию. В число управляющих элементов контроля в данной категории входят следующие. Административные средства безопасности, входящие в состав многих операционных систем и деловых приложений, а также оборудование и программные продукты для обеспечения безопасности. Эти средства необходимы для эффективного сопровождения, поддержки и устранения неполадок в системах безопасности соответствующих продуктов. Шифрование, являющееся основой многих других средств обеспечения безопасности. Безопасные средства создания, хранения и распространения ключей шифрования обеспечили возможность развития таких технологий, как виртуальные частные сети, безопасная проверка подлинности пользователей и шифрование данных на различных типах носителей. Идентификация, позволяющая однозначно определять пользователей и процессы, что дает возможность реализовывать в системах функции учета, управления доступом на уровне пользователей, управления доступом на основе ролей и обязательного управления доступом. Встроенные в системы средства защиты, обеспечивающие защиту информации, которая хранится или обрабатывается в системе. Примерами подобных средств являются объекты, обеспечивающие безопасное повторное использование, память с поддержкой технологии запрета исполнения и изоляция процессов. При рассмотрении элементов контроля рекомендуется изучить раздел «Организация решений для контроля» главы 6 «Реализация контроля и оценка эффективности программы». Данный раздел содержит ссылки на подробные руководства, призванные помочь организациям в защите своих информационных систем. Пример банка Woodgrove. Чтобы уменьшить первый риск (риск того, что учетные данные консультанта по финансовым вопросам могут быть похищены при входе в локальную сеть), можно потребовать от пользователей использовать смарт-карты для проверки подлинности при локальном подключении к корпоративной сети. Чтобы уменьшить второй риск (риск того, что учетные данные консультанта по финансовым вопросам могут быть похищены при удаленном входе в сеть), можно потребовать от пользователей использовать смарт-карты для проверки подлинности при удаленном подключении к корпоративной сети. Занесите сведения о каждом из предложенных элементов контроля для каждого риска в столбец Proposed Control («Предлагаемый элемент контроля») файла SRMGTool3-Detailed Level Risk Prioritization.xls. 96 Глава 5. Поддержка принятия решений Шаг 3. Проверка соответствия решений требованиям Группа управления рисками безопасности должна утвердить решение для контроля, чтобы удостовериться, что контроль соответствует определенным ранее функциональным требованиям. Еще одним преимуществом совместной работы в процессе анализа выгод и затрат является возможность предварительного учета особенностей процесса (например, если в определении требований безопасности участвовал ответственный за нейтрализацию риска, как правило, решение будет соответствовать требованиям). Элементы контроля, не соответствующие функциональным требованиям для выбранного риска, удаляются из рабочего листа рисков на уровне детализации. Рис. 5.6. Третий шаг этапа поддержки принятия решений Пример банка Woodgrove. Группа управления рисками безопасности проанализировала возможность применения смарт-карт для проверки подлинности пользователей, чтобы определить, соответствует ли это функциональным требованиям. В данном случае применение смарт-карт полностью соответствует функциональным требованиям обоих рисков, рассматриваемых в этом примере. Пометьте все отклоненные элементы контроля, выделив их в файле SRMGTool3-Detailed Level Risk Prioritization.xls с помощью хорошо заметного форматирования. Шаг 4. Оценка снижения риска После того как группа управления рисками безопасности утвердит потенциальную стратегию нейтрализации риска, она должна повторно определить общее снижение риска для организации. Полученный результат необходимо сравнить с затратами на внедрение решения по нейтрализации риска. Этот шаг является первым шагом, на котором количественная денежная сумма является важной для анализа выгод и затрат. Опыт показывает, что снижение риска, как правило, оценивается исходя из уменьшения вероятности возникновения влияния на бизнес организации. Помните, что каждый уровень вероятности (высокий, средний и низкий) имеет прогнозируемый временной интервал, в котором может возникнуть соответствующее влияние. Руководство по управлению рисками безопасности 97 Рис. 5.7. Четвертый шаг этапа поддержки принятия решений Увеличение временного интервала, в течение которого может возникнуть влияние, с одного года до срока более трех лет имеет большое значение для группы управления рисками безопасности и организационного комитета по обеспечению безопасности. Оценка финансовых потерь может остаться прежней, но при этом уменьшается вероятность возникновения этих потерь в ближайшем будущем. Необходимо помнить, что целью данного процесса является не сведение вероятности влияния к нулю, а ее снижение до приемлемого уровня. Еще одно преимущество уменьшения вероятности возникновения риска в ближайшем будущем связано с общей тенденцией уменьшения затрат на технические элементы контроля с течением времени и увеличения их эффективности. Например, усовершенствование текущей стратегии управления исправлениями может значительно снизить вероятность нарушения системы безопасности узлов в ближайшие дни. Однако стоимость развертывания исправлений и изменений системы безопасности может уменьшаться по мере появления новых средств и методик, повышающих эффективность управления этими операциями. Снижение затрат при использовании двухфакторной проверки подлинности представляет собой еще один пример этой тенденции. При определении относительного уровня снижения риска для элемента контроля убедитесь, что учитываются все пути влияния данного элемента контроля на риск. В частности, необходимо рассмотреть следующие вопросы. Предотвращает ли данный элемент контроля конкретную атаку или набор атак? Минимизирует ли данный элемент контроля риск атак определенного типа? Обнаруживает ли данный элемент контроля факт взлома? Если элемент контроля обнаруживает взлом, позволяет ли он противостоять атаке или отследить ее? Помогает ли данный элемент контроля в восстановлении активов, пострадавших от атаки? Какие еще преимущества предоставляет данный элемент контроля? Каковы затраты на внедрение данного элемента контроля по сравнению со стоимостью соответствующего актива? 98 Глава 5. Поддержка принятия решений Эти вопросы могут оказаться более сложными, если соответствующий элемент контроля влияет на несколько активов и уязвимостей. В конечном счете целью данного шага является оценка того, насколько каждый элемент контроля снижает уровень риска. Для каждого риска занесите новые значения уровня влияния, уровня вероятности и уровня риска в столбцы Impact Rating with New Control («Уровень влияния с новым элементом контроля»), Probability Rating with New Control («Уровень вероятности с новым элементом контроля») и New Risk Rating («Новый уровень риска») файла SRMGTool3-Detailed Level Risk Prioritization.xls. Пример банка Woodgrove. В отношении первого риска (риск хищения паролей консультантов по финансовым вопросам при работе в локальной сети) группа управления рисками безопасности может прийти к выводу, что после реализации проверки подлинности с использованием смарт-карт уровень влияния будет равен 8, уровень вероятности уменьшится до 1, а новый уровень риска станет равным 8. Аналогичные значения группа управления рисками безопасности получит и для второго риска (риск хищения паролей консультантов по финансовым вопросам при удаленном доступе к сети). Занесите новые значения уровня влияния, уровня вероятности и уровня риска для каждого предложенного элемента контроля в столбцы Impact Rating with New Control («Уровень влияния с новым элементом контроля»), Probability Rating with New Control («Уровень вероятности с новым элементом контроля») и New Risk Rating («Новый уровень риска») рабочего листа рисков на уровне детализации в файле SRMGTool3-Detailed Level Risk Prioritization.xls. Шаг 5. Оценка стоимости решения Следующей задачей на данном этапе является оценка ответственными за нейтрализацию риска величины относительных затрат для каждого предложенного элемента контроля. Группа ИТ-проектирования должна быть в состоянии определить методы реализации каждого элемента контроля и предоставить разумные оценки затрат на его приобретение, внедрение и поддержку. Поскольку процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, использует комбинированный процесс управления рисками, точную величину затрат рассчитывать не нужно — достаточно ее оценки. В процессе анализа выгод и затрат сравниваются не абсолютные финансовые показатели, а относительные выгоды и затраты для каждого элемента контроля. Когда рабочая группа получит эти оценки, она должна будет проанализировать все перечисленные ниже прямые и косвенные затраты, которые могут относиться к соответствующему элементу контроля. Занесите величину затрат для каждого элемента контроля в столбец Cost of Control Description («Описание затрат для элемента контроля») файла SRMGTool3-Detailed Level Risk Prioritization.xls. Руководство по управлению рисками безопасности 99 Рис. 5.8. Пятый шаг этапа поддержки принятия решений Затраты на приобретение Эти затраты включают затраты на приобретение программного обеспечения, оборудования и услуг, имеющих отношение к предлагаемому элементу контроля. Для некоторых элементов контроля затраты на приобретение могут отсутствовать — например, реализация нового элемента контроля может состоять во включении отключенных ранее функций используемого в организации сетевого оборудования. Прочие элементы контроля могут требовать приобретения новых продуктов (например, программного обеспечения распределенных межсетевых экранов или отдельного аппаратного межсетевого экрана с поддержкой фильтрации на уровне приложений). Некоторые элементы контроля не требуют приобретения программных продуктов и оборудования, но для их реализации необходимо оплатить услуги сторонней организации. Например, компания может заключить договор с организацией, которая будет ежедневно предоставлять обновляемый черный список с известными адресами узлов, осуществляющих рассылку нежелательной почты. Полученный список может использоваться фильтрами нежелательной почты, установленными на почтовых серверах организации. В организации могут применяться и другие элементы контроля, разрабатываемые собственными силами. В этом случае в затраты на приобретение должны включаться затраты на проектирование, разработку и тестирование соответствующих элементов контроля. Затраты на внедрение Эти затраты вызваны затратами на оплату работы персонала и консультантов, которые будут устанавливать и настраивать предлагаемый новый элемент контроля. Для надлежащих разработки, проектирования, проверки и реализации некоторых элементов контроля требуются большие рабочие группы. В то же время, если в организации используются корпоративные элементы контроля, квалифицированный администратор системы может за несколько минут отключить на всех настольных и мобильных компьютерах неиспользуемые службы. 100 Глава 5. Поддержка принятия решений Текущие затраты Эти затраты связаны с регулярными затратами на поддержание работоспособности нового элемент контроля, например на управление, мониторинг и поддержку. Если эти затраты трудно рассчитать, попробуйте оценить их, определив, сколько рабочего времени будет тратиться каждую неделю (месяц, год) на решение этих задач и сколько человек должно в этом участвовать. Крупным корпорациям, имеющим офисы на нескольких континентах, следует рассмотреть возможность установки надежной распределенной сетевой системы обнаружения вторжений. Подобная система требует непрерывного и круглосуточного мониторинга и наличия сотрудников, которые могут правильно понять поступающие оповещения и надлежащим образом отреагировать на них. Чтобы использовать все возможности подобной системы, организации может потребоваться от восьми до десяти (и даже более) сотрудников, которые будут заниматься только этой задачей. Затраты на информирование Эти затраты связаны с мероприятиями по информированию пользователей о новых политиках и процедурах. Например, организации, имеющей несколько сотен сотрудников, при установке новых электронных замков на дверях серверной комнаты может оказаться достаточным отправить сообщения электронной почты сотрудникам ИТ-подразделения и старшему руководству. Однако организациям, внедряющим смарт-карты, может потребоваться большая работа по информированию пользователей, причем эта работа должна проводиться до, в процессе и после распространения смарт-карт и устройств считывания, поскольку пользователям необходимо изучить новую методику входа на компьютеры, что будет связано с возникновением большого числа новых и неожиданных ситуаций. Затраты на обучение ИТ-персонала Эти затраты связаны с необходимостью обучения ИТ-специалистов, которые должны будут осуществлять внедрение, мониторинг и поддержку нового элемента контроля. Давайте рассмотрим приведенный ранее пример организации, решившей внедрять смарт-карты. Различные группы ИТ-персонала организации будут иметь разные обязанности и, следовательно, потребуют различного обучения. Группа поддержки пользователей должна знать, каким образом помочь пользователям в решении типичных проблем, таких как повреждение карты или устройства считывания и восстановление забытого PIN-кода. Группа поддержки компьютеров должна знать, как устанавливать, проверять и заменять устройства считывания смарт-карт и уметь устранять неполадки при работе с этими устройствами. Одна из групп ИТ-подразделения и одна из групп отдела персонала или, возможно, одна из групп службы безопасности организации будет нести ответственность за выдачу и замену карт, а также за их изъятие у увольняющихся сотрудников. Затраты на обучение пользователей Эти затраты связаны с необходимостью обучения пользователей, которым требуется освоить новые методики, необходимые для работы с новой системой защиты. В случае внедрения смарт-карт, как было описано в примере выше, все пользователи должны знать правила использования смарт-карт и устройств считывания, а также правила обращения со смарт-картами, поскольку в большинстве случаев смарт-карты более чувствительны к физическим повреждениям, чем кредитные и банковские карты. Руководство по управлению рисками безопасности 101 Затраты на обеспечение удобства и производительности Эти затраты вызваны тем, что новый элемент контроля влияет на работу ряда пользователей. В случае со смарт-картами может показаться, что по завершении первых недель и месяцев использования смарт-карт и устройств считывания и после того, как пользователям будет оказана помощь в решении первоочередных проблем, число проблем уменьшится. Однако в большинстве случаев это не так. Например, многие организации обнаружат, что используемые ими приложения не совместимы со смарт-картами. В некоторых случаях это может оказаться несущественным, однако что делать со средствами, применяемыми отделом персонала для управления конфиденциальными сведениями о сотрудниках, или с программным обеспечением для управления отношениями с заказчиками, используемым в масштабах всей организации для отслеживания важных данных обо всех заказчиках? Если важные бизнес-приложения, наподобие приведенных выше, несовместимы со смарт-картами и требуют проверки подлинности пользователей, организация может столкнуться со сложной проблемой выбора. В этой ситуации организация может обновить программное обеспечение, что может потребовать еще больших затрат с учетом приобретения новых лицензий и затрат на внедрение и обучение. Или же организация может отключить функции проверки подлинности, значительно снизив защищенность. Кроме того, организация может потребовать от пользователей указывать имя и пароль при доступе к этим приложениями, однако при этом пользователям придется снова запоминать пароли, в результате чего будет подорвано одно из основных преимуществ смарт-карт. Затраты на аудит и проверку эффективности Организации придется нести эти затраты после реализации нового элемента контроля. Чтобы точнее определить величину этих затрат, ответьте на следующие вопросы. Каким образом можно убедиться, что элемент контроля действительно выполняет свои функции? Будут ли сотрудники ИТ-подразделения проводить тестирование на проникновение? Будут ли сотрудники ИТ-подразделения использовать образцы вредоносного кода для атаки актива, который призван защищать элемент контроля? После того как эффективность элемента контроля будет подтверждена, каким образом организация сможет постоянно проверять его работоспособность? Организация должна быть в состоянии регулярно проверять, не изменил ли и не отключил ли кто-либо элемент контроля (случайно или намеренно), и назначить ответственного за выполнение этой проверки. Для наиболее важных активов может потребоваться назначение нескольких сотрудников, которые будут проверять действенность элементов контроля. Пример банка Woodgrove. В таблицах 5.3 и 5.4 указаны стоимости рисков, определенные ответственными за нейтрализацию риска. Занесите оценки затрат для каждого элемента контроля в столбец Cost of Control Description («Описание затрат для элемента контроля») файла SRMGTool3_Detailed Level Risk Prioritization.xls. 102 Глава 5. Поддержка принятия решений Таблица 5.3. Затраты на внедрение смарт-карт для доступа администраторов и доступа с помощью сетей VPN Категория Примечания Оценка (долл. США) Затраты на приобретение Затраты составляют 15 долларов США из расчета на одну смарт-карту и 15 долларов США из расчета на одно устройство считывания. Поскольку только десяти тысячам сотрудников банка требуется административный доступ или доступ с помощью VPN, общие затраты на смарт-карты и устройства считывания составят 300 000 долларов США 300 000 Затраты на внедрение Банк планирует обратиться в консалтинговую компанию, которая поможет внедрить данное решение за 750 000 долларов США. Кроме того, затраты рабочего времени сотрудников банка на внедрение этого решения оцениваются в 150 000 долларов США 900 000 Затраты Для информирования сотрудников о новостях на информирование банк уже использует печатные бюллетени, внутренние веб-узлы и списки рассылки электронной почты, поэтому затраты на информирование о развертывании смарт-карт будут несущественными 50 000 Затраты на обучение ИТперсонала Банк планирует обратиться в упомянутую выше консалтинговую компанию для обучения ИТперсонала, что должно помочь при внедрении нового решения. Стоимость обучения составит 10 000 долларов США. Большая часть ИТсотрудников потратит на обучение от 4 до 8 часов рабочего времени. Общие затраты рабочего времени на обучение оцениваются в 80 000 долларов США 90 000 Затраты на обучение пользователей Для обучения сотрудников правилам применения смарт-карт банк планирует использовать учебные материалы с веб-интерфейсом, предоставленные поставщиком смарт-карт. Стоимость учебных материалов входит в стоимость оборудования. Каждый сотрудник потратит на обучение около часа рабочего времени. Общий ущерб от снижения производительности труда оценивается в 300 000 долларов США 300 000 Затраты на обеспечение удобства и производительности Банк предполагает, что среднестатистический пользователь потеряет около часа рабочего времени и что один из четырех пользователей обратится в службу поддержки для получения помощи в использовании смарт-карт. Общий ущерб от снижения производительности труда оценивается в 300 000 долларов США, а затраты на обработку обращений в службу поддержки составят 100 000 долларов США 400 000 Затраты на аудит и проверку эффективности Группа управления рисками безопасности считает, что стоимость выполнения ею аудита и проверки эффективности нового элемента контроля составит 50 000 долларов США за первый год эксплуатации 50 000 Итого 2 090 000 Руководство по управлению рисками безопасности 103 Таблица 5.4. Затраты на внедрение смарт-карт для локального доступа Категория Примечания Затраты на приобретение Затраты составляют 15 долларов США из расчета 1 950 000 на одну смарт-карту и 15 долларов США из расчета на одно устройство считывания. Поскольку локальный доступ требуется всем пятнадцати тысячам сотрудников банка, общие затраты на смарт-карты и устройства считывания составят 450 000 долларов США. Кроме того, банку придется заменить или обновить многие бизнес-приложения, что потребует приблизительно 1 500 000 долларов США Затраты на внедрение Оценка (долл. США) Банк планирует обратиться в консалтинговую компанию, которая поможет внедрить данное решение. Стоимость услуг компании составит 750 000 долларов США. Кроме того, затраты рабочего времени сотрудников банка на внедрение этого решения оцениваются в 150 000 долларов США Затраты Для информирования сотрудников о новостях банк на информирование уже использует печатные бюллетени, внутренние веб-узлы и списки рассылки электронной почты, поэтому затраты на информирование о развертывании смарт-карт будут несущественными Затраты Банк планирует обратиться в упомянутую выше на обучение ИТконсалтинговую компанию для обучения ИТперсонала персонала, что должно помочь при внедрении нового решения. Стоимость обучения составит 10 000 долларов США. Большая часть ИТсотрудников потратит на обучение от 4 до 8 часов рабочего времени. Общие затраты рабочего времени на обучение оцениваются в 80 000 долларов США Затраты Для обучения сотрудников правилам применения на обучение смарт-карт банк планирует использовать учебные пользователей материалы с веб-интерфейсом, предоставленные поставщиком смарт-карт. Стоимость учебных материалов входит в стоимость оборудования. Каждый сотрудник потратит на обучение около часа рабочего времени. Общий ущерб от снижения производительности труда оценивается в 450 000 долларов США Затраты на обеспе- Банк предполагает, что среднестатистический чение удобства и пользователь потеряет около часа рабочего производительности времени и один из четырех пользователей обратится в службу поддержки для получения помощи в использовании смарт-карт. Общий ущерб от снижения производительности труда оценивается в 450 000 долларов США, а затраты на обработку обращений в службу поддержки составят 150 000 долларов США 900 000 Затраты на аудит и проверку эффективности 150 000 Итого Группа управления рисками безопасности считает, что стоимость выполнения ею аудита и проверки эффективности нового решения составит 150 000 долларов США за первый год эксплуатации 50 000 90 000 450 000 600 000 4 190 000 104 Глава 5. Поддержка принятия решений Шаг 6. Выбор решения по нейтрализации риска Последний этап анализа выгод и затрат — это сопоставление уровня риска после реализации решения по нейтрализации риска с затратами на это внедрение. Как оценка риска, так и оценка затрат содержит субъективные значения, которые трудно измерить с помощью точных финансовых характеристик. В этом случае для сравнения можно использовать количественные оценки. Не поддавайтесь соблазну исключить из рассмотрения нематериальные затраты, появляющиеся при возникновении риска. Узнайте у владельца актива, что произойдет, если риск реализуется. Попросите владельца изложить ответ в письменном виде — это поможет оценить важность решения по нейтрализации риска. Подобная тактика может оказаться настолько же убедительной, как и арифметическое сравнение количественных оценок. Рис. 5.9. Шестой шаг этапа поддержки принятия решений Одна из наиболее распространенных ошибок при проведении анализа выгод и затрат состоит в том, что все внимание уделяется величине снижения риска, а не величине риска после нейтрализации (этот риск часто называют остаточным риском). Это можно проиллюстрировать следующим простым примером, использующим количественные оценки. Если величина риска составляет 1000 долларов США, а предлагаемый элемент контроля уменьшает риск на 400 долларов США, то владельцу организации придется принять риск после нейтрализации (остаточный риск) в размере 600 долларов США. Даже если решение по нейтрализации риска снизит риск менее чем на 400 долларов США, будет присутствовать остаточный риск в размере 600 долларов США. Пример банка Woodgrove. По всей видимости, банк решит использовать смарт-карты только для проверки подлинности при удаленном доступе, поскольку внедрение смарт-карт для всех пользователей сопряжено с очень высокими затратами. Перед переходом к следующему этапу процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, задокументируйте рекомендованные решения по обеспечению безопасности, которые были выбраны для реализации. Руководство по управлению рисками безопасности 105 Заключение На этапе поддержки принятия решений группа управления рисками безопасности собирает важные части дополнительной информации о каждом приоритетном риске, выявленном на этапе оценки рисков. Для каждого риска принимается решение о том, должна ли организация принять, передать, контролировать или устранить риск. Затем рабочая группа определяет функциональные требования для каждого риска. После этого ответственные за нейтрализацию риска вместе с группой управления рисками безопасности разрабатывают перечень потенциальных решений для контроля, а затем группа управления рисками безопасности оценивает уровень снижения риска, обеспечиваемый каждым элементом контроля, и величину затрат, связанных с ним. В заключение организационный комитет по обеспечению безопасности выбирает решения для контроля, которые ответственные за нейтрализацию риска должны будут реализовать на этапе реализации контроля, описанном в следующей главе. Глава 6. Реализация контроля и оценка эффективности программы Обзор В этой главе рассматриваются последние два этапа процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт: реализация контроля и оценка эффективности программы. Название этапа реализации контроля говорит само за себя: чтобы снизить риски, выявленные на этапе оценки рисков, сотрудники, ответственные за нейтрализацию риска, разрабатывают и выполняют планы на основании перечня решений для контроля, сформированного на этапе поддержки принятия решений. В данной главе содержатся ссылки на подробные руководства, которые помогут сотрудникам, ответственным за нейтрализацию риска, уменьшить различные виды рисков. Оценка эффективности программы включает в себя набор операций, которые периодически выполняются группой управления рисками безопасности и позволяют проверить, обеспечивают ли реализованные на предыдущем этапе элементы контроля надлежащий уровень безопасности. Кроме того, на этом этапе производится оценка изменения уровня управления рисками в организации в целом. В данной главе вводится понятие системы показателей рисков безопасности, позволяющей отслеживать уровень рисков безопасности в организации. В заключительной части главы обосновывается важность отслеживания изменений в информационной среде (таких как добавление и изъятие систем и приложений, а также появление новых угроз и уязвимостей). Подобные изменения могут потребовать от организации выполнения действий, направленных на защиту от новых или изменившихся рисков. Реализация контроля На этом этапе ответственные за нейтрализацию риска реализуют элементы контроля, выбранные на предыдущем этапе. Важнейшим условием успешного завершения данного этапа процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, является использование ответственными за нейтрализацию риска целостного подхода к реализации решений для контроля. При разработке планов приобретения и реализации решений по нейтрализации риска им необходимо учитывать требования всей ИТ-системы, всего подразделения или даже организации в целом. Раздел «Организация решений для контроля» данной главы содержит ссылки на подробные руководства, которые помогут организации в разработке планов реализации решений для контроля. В данном разделе рассматривается многоуровневая система защиты, упрощающая поиск методов решения некоторых типов проблем. 108 Глава 6. Реализация контроля и оценка эффективности программы Рис. 6.1. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт: этап реализации контроля Входные данные, необходимые для этапа реализации контроля Единственной информацией, которая определяется на этапе поддержки принятия решений и потом требуется на этапе реализации контроля, является ранжированный по приоритетам перечень подлежащих реализации элементов контроля. Если организация выполнила процедуры, описанные в главе 5 «Поддержка принятия решений», группа управления рисками безопасности должна была сохранить эти данные, предоставляя результаты своей работы организационному комитету по обеспечению безопасности. Участники этапа реализации контроля Основными участниками данного этапа являются ответственные за нейтрализацию риска, однако они могут прибегать к помощи группы управления рисками безопасности. Этап реализации контроля включает следующие роли, которые были определены в главе 3 «Обзор управления рисками безопасности». Группа управления рисками безопасности (группа информационной безопасности, координатор оценки рисков и секретарь оценки рисков). Ответственные за нейтрализацию риска (ИТ-архитектура, ИТ-проектирование и ИТ-операции). В следующем списке перечислены основные обязанности. ИТ-проектирование. Определение методов реализации решений для контроля. ИТ-архитектура. Определение методов реализации решений для контроля, обеспечивающих совместимость с существующими компьютерными системами. ИТ-операции. Реализация технических решений для контроля. Руководство по управлению рисками безопасности 109 Информационная безопасность. Помощь в устранении проблем, которые могут возникнуть в процессе тестирования и развертывания. Финансы. Позволяет удостовериться, что уровень затрат не превышает величину выделенного бюджета. Группе управления рисками безопасности рекомендуется определить технологии обеспечения безопасности для каждого выявленного риска. Наличие одного контактного лица уменьшает вероятность того, что группа управления рисками безопасности будет отправлять несогласованные сообщения, и позволяет использовать четкую модель взаимодействия на протяжении всего процесса развертывания. Средства для этапа реализации контроля Вместе с данным руководством не поставляются средства, предназначенные для использования на этапе реализации контроля. Требуемые выходные данные этапа реализации контроля На этом этапе процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, будут разработаны планы реализации контроля, выбранные на этапе поддержки принятия решений. Соответствующие основные элементы перечислены в таблице 6.1 и будут рассмотрены в следующих разделах данной главы. Таблица 6.1. Обязательные выходные данные этапа реализации контроля Информация, которую необходимо собрать Описание Решения для контроля Перечень элементов контроля, выбранных организационным комитетом по обеспечению безопасности и реализованных ответственными за нейтрализацию риска Отчеты о развертывании элементов контроля Отчет или серия отчетов, созданных ответственными за нейтрализацию риска и описывающих ход развертывания выбранных решений для контроля Организация решений для контроля Предыдущая глава была посвящена процессу поддержки принятия решений. По результатам анализа, выполняемого на этом этапе, организационный комитет по обеспечению безопасности принимает решение относительно того, каким образом организация будет реагировать на риски безопасности, выявленные на предшествующем этапе оценки рисков. Некоторые риски могли быть приняты или переданы третьим сторонам, а для рисков, которым необходимо противодействовать, формируется ранжированный по приоритетам перечень решений для контроля. Следующим шагом является разработка планов действия по реализации выбранных элементов контроля в указанные сроки. Эти планы должны быть строгими и точными, и для каждого решения необходимо определить ответственного исполнителя или группу. Чтобы отслеживать ход и своевременность выполнения задач проекта, используйте рекомендации по управлению проектами. 110 Глава 6. Реализация контроля и оценка эффективности программы Примечание. Решение Microsoft Solutions Framework (MSF) помогает в выполнении планов действий, разработанных на данном этапе. MSF представляет собой тщательно продуманный, последовательный подход к технологическим проектам, основанный на определенных наборах принципов, моделях, концепциях, руководствах, порядках действий и проверенных рекомендациях корпорации Майкрософт. Применение MSF помогает организациям реализовывать высококачественные технологические решения в заданные сроки и в пределах выделенного бюджета. Дополнительные сведения о MSF см. по адресу www.microsoft.com/technet/itsolutions/msf/default.mspx. Существует несколько важных условий успешного завершения этого этапа проекта. Ответственные руководители проектов по управлению рисками должны проинформировать сотрудников, что члены рабочей группы имеют право реализации соответствующих элементов контроля. В противном случае некоторые сотрудники могут возражать против реализации новых элементов контроля или даже противодействовать этому процессу. Сотрудникам, которые обязаны помогать в реализации новых элементов контроля, необходимо предоставить возможность пересмотреть текущие должностные обязанности. Сотрудники, работающие над элементами контроля, и их руководители должны знать, что реализация этих элементов контроля является первоочередной задачей. Если организация не выделила необходимые временные и финансовые ресурсы, это может привести к значительному снижению эффективности реализации элементов контроля. Кроме того, ненадлежащее выделение ресурсов может привести к возникновению проблем, ответственность за которые будет ошибочно возложена на используемую технологию или элемент контроля. Сотрудникам, ответственным за реализацию элементов контроля, должны быть предоставлены надлежащие денежные средства, оборудование, возможности для обучения и другие ресурсы, необходимые для эффективной реализации каждого элемента контроля. Сотрудники, занимающиеся реализацией элементов контроля, должны отмечать ход выполнения в отчетах или сериях отчетов, которые в дальнейшем передаются группе управления рисками безопасности и организационному комитету по обеспечению безопасности. Чтобы ознакомиться с исчерпывающей упорядоченной подборкой документов, посвященных различным вопросам безопасности, обратитесь на веб-узел Центр безопасности Майкрософт. Руководства, находящиеся на этом веб-узле, помогут организациям реализовать выбранные элементы контроля из ранжированного по приоритетам перечня. Примечание. Большая часть содержимого данного раздела почерпнута из статьи Обзор документов корпорации Майкрософт, посвященных безопасности, находящейся по адресу http://go.microsoft.com/fwlink/?LinkId=20263. Обратитесь на этот веб-узел, чтобы ознакомиться с последними версиями подробных рекомендаций корпорации Майкрософт по обеспечению безопасности. Оставшаяся часть данного раздела посвящена многоуровневой модели защиты корпорации Майкрософт (см. рис. 6.2). Как и общедоступные модели, используемые другими организациями, многоуровневая модель защиты корпорации Майкрософт организует элементы контроля в несколько широких категорий. В каждом разделе даны ссылки на методические инструкции и технические документы, описывающие элементы контроля для защиты на каждом уровне сети, а также содержащиеся в них рекомендации. Методические инструкции содержат пошаговые рекомендации по планированию и развертыванию законченного решения. Эти инструкции были полностью проверены в средах заказчиков. Технические документы и статьи, как правило, включают техническое описание возможностей продукта и фрагментов общего решения, однако в них может отсутствовать часть информации из методических инструкций. Руководство по управлению рисками безопасности 111 Примечание. В этой главе отсутствует раздел, соответствующий приведенному на следующей схеме (рис. 6.2) уровню «Физическая защита», поскольку корпорация Майкрософт еще не публиковала подробные руководства на эту тему. Рис. 6.2. Модель многоуровневой защиты Защита сети Надлежащим образом спроектированная и реализованная архитектура сети обеспечивает высокие доступность, безопасность, масштабируемость, управляемость и надежность. Организации, имеющие несколько сетей и желающие проверить, надежно ли защищены все сети, или убедиться, что сети, обладающие высокой ценностью, защищены от атак со стороны общедоступных сетей, должны оценить каждую сеть в индивидуальном порядке. При защите внутренних сетей необходимо уделить особое внимание надлежащему проектированию сети, обеспечению безопасности беспроводной сети и, возможно, ограничению доступа к важным сетевым ресурсам путем применения протокола IPSec (Internet Protocol security). Методические инструкции Методические инструкции по обеспечению безопасности с помощью межсетевых экранов см. в разделе «Проектирование инфраструктуры межсетевых экранов в организации» главы Службы межсетевых экранов руководства по эталонной архитектуре системы Windows Server по адресу www.microsoft.com/technet/itsolutions/wssra/raguide/FirewallServices/default.mspx. Дополнительные методические инструкции см. в главе 15 «Защита сети» документа Повышение защищенности веб-приложений: угрозы и меры противодействия по адресу http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnnetsec/html/threatcounter.asp. Методические инструкции по обеспечению безопасности беспроводных локальных сетей с помощью протокола EAP и цифровых сертификатов см. в документе Обеспечение безопасности беспроводных локальных сетей с помощью цифровых сертификатов по адресу http://go.microsoft.com/fwlink/?LinkId=14843. Методические инструкции по обеспечению безопасности беспроводных локальных сетей с помощью протокола PEAP и паролей см. в документе Обеспечение безопасности беспроводных локальных сетей с помощью протокола PEAP и паролей по адресу http://go.microsoft.com/fwlink/?LinkId=23459. Методические инструкции по обеспечению безопасности и повышению производительности сети с помощью сегментации см. в разделе «Проектирование корпоративной инфраструктуры» главы Проектирование архитектуры сети руководства по эталонной архитектуре системы Windows Server по адресу http://www.microsoft.com/technet/ itsolutions/wssra/raguide/ArchitectureBlueprints/rbabna.mspx. 112 Глава 6. Реализация контроля и оценка эффективности программы Технические документы и статьи Сведения о внедрении протокола IPSec см. в разделе «Обзор развертывания IPSec» главы Развертывание сетевых служб руководства из комплекта развертывания Microsoft® Windows Server™ 2003 по адресу http://technet2.microsoft.com/WindowsServer/en/Library/119050c9-7c4d-4cbf-8f3897c45e4d01ef1033.mspx. Дополнительные сведения об использовании протокола IPSec см. в техническом документе Применение Microsoft Windows IPSec для повышения защищенности серверов внутренней корпоративной сети по адресу www.microsoft.com/downloads/details.aspx?FamilyID=a774012a-ac25-4a1d-8851b7a09e3f1dc9&DisplayLang=en. Более подробное обсуждение вопросов сегментации сети и проблем, устраняемых путем использования надежной структуры сети, см. в разделе «Проектирование корпоративной инфраструктуры коммутаторов и маршрутизаторов» части Сетевые устройства руководства по эталонной архитектуре системы Windows Server по адресу www.microsoft.com/technet/itsolutions/techguide/wssra/raguide/ Network_Devices_SB_1.mspx. Обзор существующих типов межсетевых экранов и методов их использования см. в разделе Межсетевые экраны по адресу www.microsoft.com/technet/security/topics/network/firewall.mspx. Дополнительные сведения об управлении карантином доступа к сети см. в следующих технических документах. ● Технический документ Управление карантином доступа к сети в Windows Server 2003 по адресу www.microsoft.com/windowsserver2003/techinfo/overview/quarantine.mspx. ● Технический документ Виртуальные частные сети в Windows Server 2003: обзор по адресу www.microsoft.com/windowsserver2003/techinfo/overview/vpnover.mspx. Защита узлов Существует два типа узлов: клиенты и серверы. Обеспечение эффективной защиты обоих типов узлов требует соблюдения баланса между уровнем безопасности и функциональностью. Хотя бывают и исключения, но, как правило, повышение защищенности компьютера сопряжено с уменьшением его функциональности. Защита узлов может включать операции по отключению служб, удалению определенных прав пользователей, своевременному обновлению операционной системы и использованию антивирусных средств и распределенных межсетевых экранов. Подробные рекомендации Веб-страница Управление исправлениями веб-узла Microsoft TechNet, находящаяся по адресу www.microsoft.com/technet/security/topics/patch/default.mspx, содержит средства и руководства, помогающие организациям повысить эффективность проверки, развертывания и поддержки обновлений программного обеспечения. Подробные рекомендации по защите Windows XP Professional см. в руководстве Подробное руководство по защите Windows XP Professional с пакетом обновления 2 (SP2) в малом и среднем бизнесе по адресу http://go.microsoft.com/fwlink/?linkid=19453. Подробные рекомендации по защите Windows XP см. в руководстве Руководство по защите Windows XP по адресу http://go.microsoft.com/fwlink/?LinkId=14839. Подробные рекомендации по защите Windows Server 2003 см. в руководстве Руководство по защите Windows Server 2003 по адресу http://go.microsoft.com/fwlink/?LinkId=14845. Большая часть функций и параметров безопасности, входящих в состав Windows Server 2003 и Windows XP, перечислена в руководстве Угрозы и борьба с ними. Руководство по управлению рисками безопасности 113 Этот документ, который содержит более подробные сведения и дополняет руководство по обеспечению безопасности Windows Server 2003, находится по адресу http://go.microsoft.com/fwlink/?LinkId=15159. Подробные рекомендации по защите серверов под управлением Windows 2000 см. в руководстве Повышение защищенности Windows 2000 по адресу www.microsoft.com/downloads/details.aspx?FamilyID=15E83186-A2C8-4C8F-A9D0A0201F639A56&DisplayLang=en. Информационные документы и статьи Приложения и серверные операционные системы корпорации Майкрософт используют для обмена данными друг с другом и с клиентскими компьютерами различные сетевые протоколы, включая большое число портов протоколов Transmission Control Protocol (TCP) и User Datagram Protocol (UDP). Многие из них перечислены в статье 832017 базы знаний Майкрософт Службы и сетевые порты в серверных системах Microsoft Windows по адресу http://support.microsoft.com/?kbid=832017. Антивирусное программное обеспечение: вопросы и ответы — это обзорная статья, содержащая общие сведения об антивирусных программных продуктах и рекомендации по приобретению, установке и поддержанию работоспособности этих продуктов. Данная статья находится по адресу www.microsoft.com/security/protect/antivirus.asp. Межсетевые экраны для подключения к Интернету: вопросы и ответы — это статья, показывающая важную роль межсетевых экранов, описывающая ситуации, когда необходимо устанавливать программные межсетевые экраны на пользовательские компьютеры, и содержащая рекомендации по устранению некоторых типичных проблем, возникающих при использовании подобных программных продуктов. Данная статья находится по адресу www.microsoft.com/security/protect/firewall.asp. Защита приложений Защита приложений является важной частью модели безопасности. Приложения существуют в контексте всей системы, поэтому при оценке безопасности приложений организации необходимо проанализировать безопасность всей среды. Перед использованием приложений в рабочей среде необходимо тщательно проверить соответствие каждого приложения требованиям безопасности. Реализация защиты приложений включает операции, позволяющие сократить число уязвимых мест за счет выполнения приложений с минимальным необходимым набором привилегий. Методические инструкции Руководство Усиление защиты сервера Exchange 2003, содержащее сведения о защите сервера Microsoft Exchange 2003 Server, находится по адресу www.microsoft.com/downloads/details.aspx?FamilyID=6a80711f-e5c9-4aef-9a44504db09b9065&displaylang=en. Руководство по обеспечению безопасности сервера Exchange 2000, содержащее рекомендации по защите сервера Microsoft Exchange 2000 Server, находится по адресу www.microsoft.com/technet/security/prodtech/mailexch/opsguide/default.mspx. Руководство Повышение защищенности веб-приложений: угрозы и меры противодействия, содержащее сведения, необходимые для успешного проектирования, создания и конфигурации безопасных веб-приложений ASP.NET, находится по адресу http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnnetsec/html/ThreatCounter.asp. Глава 18 Обеспечение безопасности сервера баз данных руководства «Повышение защищенности веб-приложений: угрозы и меры противодействия» содержит подробные сведения о защите сервера Microsoft SQL Server™. Данный документ находится по адресу http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/dnnetsec/html/THCMCh18.asp. 114 Глава 6. Реализация контроля и оценка эффективности программы Руководство Создание защищенных приложений ASP.NET. Проверка подлинности, авторизация и защита соединений, описывающее практический подход на основе сценариев к проектированию и разработке приложений ASP.NET для Windows 2000 и Microsoft.NET Framework версии 1.0, находится по адресу http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true. Технические документы и статьи Технический документ Создание и настройка защищенных веб-узлов содержит подробные сведения об уроках, извлеченных подразделением безопасности корпорации Майкрософт в ходе интерактивного семинара по безопасности 2002 OpenHack 4, проводившегося компанией eWeek. Рассматривавшееся на семинаре решение включало.NET Framework, сервер Microsoft Windows® 2000 Advanced Server, службы Internet Information Services (IIS) версии 5.0 и сервер SQL Server 2000. Данное решение успешно противостояло 82,5 тысячи попыток атак, которые не смогли нарушить его защиту. Данный документ находится по адресу http://msdn.microsoft.com/library/en-us/dnnetsec/html/openhack.asp. Защита данных Данные являются наиболее ценным ресурсом организаций. На уровне клиентов данные зачастую хранятся локально и могут быть частично уязвимы для атак. Для защиты данных могут использоваться различные способы, включая применение службы шифрования файлов (EFS) и частое создание защищенных архивов. Методические инструкции Сведения об архивации данных в сетях Windows 2000 см. в документе Решения для архивации и восстановления данных под управлением Windows 2000 Server по адресу www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/backuprestdefault.mspx. Методические инструкции по внедрению EFS см. в разделе Защита данных: внедрение шифрованной файловой системы (EFS) в Windows 2000 по адресу www.microsoft.com/windows2000/techinfo/planning/security/efssteps.asp. Оценка эффективности программы Этап оценки эффективности программы позволяет группе управления рисками безопасности формально задокументировать текущее состояние рисков в организации. По мере прохождения организацией цикла управления рисками данный этап помогает продемонстрировать снижение рисков до приемлемого уровня в процессе управления рисками. Чтобы повысить эффективность информирования, в данном разделе вводится концепция системы показателей рисков безопасности, позволяющей отслеживать уровень рисков безопасности в организации. Система показателей помогает продемонстрировать, что управление рисками действительно интегрировано в ИТ-операции. Концепция «интегрированного управления рисками» является также основным атрибутом при определении уровня зрелости управления рисками в организации, как описано в главе 3 «Обзор управления рисками безопасности». Руководство по управлению рисками безопасности 115 Рис. 6.3. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт: этап оценки эффективности программы Требуемые входные данные для этапа оценки эффективности программы Ниже перечислены входные данные, которые определяются на предыдущих этапах и используются на этапе оценки эффективности программы. Перечень ранжированных по приоритетам рисков, которые необходимо нейтрализовать. Если организация выполнила процедуры, описанные в главе 4 «Оценка рисков», эта информация должна быть сохранена в файле Microsoft Excel® SRMGTool3-Detailed Level Risk Prioritization.xls, который находится в папке Tools and Templates (эта папка создается при распаковке архива, содержащего данное руководство и сопутствующие файлы). Ранжированный по приоритетам перечень решений для контроля, выбранных организационным комитетом по обеспечению безопасности. Если организация выполнила процедуры, описанные в главе 5 «Поддержка принятия решений», группа управления рисками безопасности должна была сохранить эти данные, предоставляя результаты своей работы организационному комитету по обеспечению безопасности. Отчеты о развертывании элементов контроля, созданные ответственными за нейтрализацию риска на этапе реализации контроля и описывающие ход работ по развертыванию выбранных решений для контроля. 116 Глава 6. Реализация контроля и оценка эффективности программы Участники этапа оценки эффективности программы Основными участниками этапа оценки эффективности программы являются члены группы информационной безопасности. Они должны разработать систему показателей рисков безопасности (см. ниже), убедиться, что элементы контроля реализованы и уменьшают риски надлежащим образом, и отслеживать изменения в ИТ-среде, которые могут изменить профиль риска организации. Группа информационной безопасности регулярно предоставляет отчеты организационному комитету по обеспечению безопасности. Кроме того, ответственные за нейтрализацию риска помогают рабочей группе, информируя об основных изменениях в информационной инфраструктуре и сообщая подробные сведения обо всех событиях в области безопасности. Еще раз отметим, что этап оценки эффективности программы включает следующие роли, которые были определены в главе 3 «Обзор управления рисками безопасности». Группа управления рисками безопасности (группа информационной безопасности, координатор оценки рисков и секретарь оценки рисков). Ответственные за нейтрализацию риска (ИТ-архитектура, ИТ-проектирование и ИТ-операции). Организационный комитет по обеспечению безопасности (ответственный руководитель, владельцы организаций, архитектура и ИТ-проектирование). Ниже перечислены обязанности, соответствующие этим ролям. Информационная безопасность. Создание итоговых отчетов для организационного комитета по обеспечению безопасности в разрезе эффективности развернутых элементов контроля и изменений профиля риска организации; создание и ведение системы показателей рисков в организации. Внутренний аудит. Проверка эффективности решений для контроля. ИТ-проектирование. Информирование группы управления рисками безопасности о предстоящих изменениях. ИТ-архитектура. Информирование группы управления рисками безопасности о планируемых изменениях. ИТ-операции. Подробное информирование группы управления рисками безопасности о событиях в области безопасности. Предоставляемые средства оценки эффективности программы Вместе с данным руководством не поставляются средства, предназначенные для использования на этапе оценки эффективности программы. Руководство по управлению рисками безопасности 117 Требуемые выходные данные этапа оценки эффективности программы На этом этапе группа управления рисками безопасности создает отчеты о текущем профиле рисков безопасности в организации. Соответствующие основные элементы перечислены в таблице 6.2 и будут подробно рассмотрены в следующих разделах данной главы. Таблица 6.2. Выходные данные этапа оценки эффективности программы Информация, которую необходимо собрать Описание Рассматриваемые изменения Отчеты с информацией о планируемых изменениях в ИТ-среде Утвержденные изменения Отчеты с информацией об изменениях в ИТ-среде, которые должны быть внесены в ближайшее время События безопасности Отчеты с подробной информацией о незапланированных событиях безопасности, повлиявших на ИТ-среду Общие характеристики эффективности решений для контроля Отчет с общими данными о снижении уровня риска решениями для контроля Изменения профиля рисков организации Отчет, показывающий, каким образом выявленные ранее угрозы изменились вследствие появления новых угроз, и содержащий сведения о новых уязвимостях и изменениях в ИТ-среде организации Система показателей рисков безопасности Обобщенная система показателей, характеризующая текущий профиль рисков организации Разработка системы показателей рисков безопасности Система показателей рисков безопасности — это важное средство, помогающее информировать о текущем состоянии рисков в организации и демонстрирующее изменения в управлении рисками. Кроме того, данное средство позволяет показать важность управления рисками и его значимость для организации. Система показателей должна предоставлять руководству обобщенные сведения об уровне риска — она не предназначена для отображения тактических представлений подробных сведений о рисках, выявленных на этапе оценки рисков. Примечание. Не путайте системы показателей рисков безопасности с ИТ-системами показателей, рассматриваемыми в других руководствах корпорации Майкрософт. ИТсистемы показателей могут являться эффективным средством отслеживания изменений в общей ИТ-среде организации, а основная задача системы показателей рисков безопасности состоит в оценке конкретной части ИТ-среды — безопасности. Система показателей рисков безопасности помогает группе управления безопасностью уменьшать риски в рамках организации до допустимого уровня за счет выявления проблемных областей и концентрации усилий на решении соответствующих проблем. Даже если элементы системы показателей помечены как обладающие высоким риском, организация может решить принять соответствующий риск. В дальнейшем система показателей может использоваться для отслеживания этих решений на высоком уровне и пересмотра решений о реакции на риски в следующих циклах процесса управления рисками. 118 Глава 6. Реализация контроля и оценка эффективности программы На рис. 6.4 показан пример системы показателей рисков безопасности, структурированной в соответствии с многоуровневой моделью защиты, как описано в главе 4 «Оценка рисков». Содержимое системы показателей следует изменить в соответствии с потребностями конкретной организации. Например, некоторые организации могут принять решение упорядочить риски в соответствии с подразделениями организации или уникальными ИТ-средами (под ИТ-средой в данном случае понимается набор ИТ-активов, предназначенных для выполнения общей бизнес-цели и имеющих одного ответственного за их работу). Децентрализованные компании могут использовать несколько систем показателей. Рис. 6.4. Пример системы показателей рисков безопасности Система показателей рисков безопасности может являться частью более масштабной ИТ-панели мониторинга, содержащей основные метрики ИТ-операций. Корпорация Майкрософт также рекомендует использовать практику измерения и отображения ИТ-метрик с помощью панели мониторинга. Измерение эффективности контроля После развертывания элементов контроля необходимо убедиться, что все решения работают надлежащим образом и обеспечивают ожидаемый уровень защиты. Например, может оказаться, что основная причина крупной бреши в системе безопасности заключалась в том, что из-за неправильной настройки при развертывании механизм проверки подлинности пользователей виртуальной частной сети (VPN) позволял неавторизованным пользователям обращаться к корпоративной сети. Еще более тяжелыми последствиями может обернуться факт, что злоумышленники получили доступ к внутренним активам, поскольку администратор сети изменил конфигурацию межсетевого экрана, разрешив использование дополнительных протоколов и не утвердив изменения с помощью принятого в организации процесса управления изменениями. Исследование Счетной палаты правительства США, посвященное управлению безопасностью в ведущих негосударственных организациях (GAO/AIMD-98-68), показало, что, по мнению организаций, непосредственное тестирование является наиболее эффективным методом определения величины снижения уровня риска, обеспечиваемого элементами контроля. Для выполнения подобного тестирования могут использоваться различные методы, включая автоматизированные средства оценки уязвимостей, оценку вручную и тестирование проникновения. Руководство по управлению рисками безопасности 119 Если оценка выполняется вручную, сотрудник ИТ-подразделения проверяет работоспособность каждого элемента контроля. При проверке большого числа систем этот подход требует значительных затрат времени, является утомительным и нередко приводит к ошибкам. Корпорация Майкрософт выпустила бесплатное автоматизированное средство оценки уязвимостей, называемое Microsoft Baseline Security Analyzer (MBSA). MBSA позволяет проверять локальные и удаленные компьютеры и находить отсутствующие исправления системы безопасности, а также определять ряд других важных параметров безопасности. Дополнительные сведения о средстве MBSA см. по адресу www.microsoft.com/technet/security/tools/mbsahome.mspx. Хотя средство MBSA является бесплатным и очень информативным, организации используют и другие средства автоматизированной оценки различных разработчиков. Еще одним упомянутым выше подходом является тестирование проникновения. При этом один или несколько человек, наделенных соответствующими полномочиями, выполняют ручные и автоматизированные тесты, проверяя, можно ли вторгнуться в сеть организации. Одни организации выполняют этот тест собственными силами, а другие привлекают сторонних экспертов, специализирующихся на проведении этого тестирования. Независимо от того, кто выполняет тестирование, группа информационной безопасности должна нести ответственность за руководство данным процессом и отслеживать результаты. Хотя тестирование проникновения является эффективным подходом, оно, как правило, не позволяет обнаружить широкий диапазон уязвимостей, поскольку не столь универсально, как правильно реализованные средства оценки уязвимостей. Поэтому проверку устойчивости к атакам рекомендуется сочетать с другими подходами. Примечание. Дополнительные сведения о тестировании проникновения см. в книге Assessing Network Security («Оценка безопасности сети»), написанной сотрудниками подразделения безопасности корпорации Майкрософт Беном Смитом (Ben Smith), Дэвидом Лебланком (David LeBlanc) и Кевином Лэмом (Kevin Lam) (Microsoft Press, 2004). Существуют и другие методы проверки соответствия требованиям. Группа информационной безопасности должна предложить всем сотрудникам организации оставить свои отзывы или использовать более формальный процесс, требующий от каждого подразделения периодического предоставления отчетов (данный процесс может быть внедрен в дополнение к получению отзывов пользователей). Процесс реакции на инциденты, используемый группой информационной безопасности, должен включать операции по созданию собственных отчетов группы с описанием видимых симптомов, пострадавших данных, подвергшихся атаке систем и хода атаки. Инциденты в области безопасности могут вызываться целым рядом причин, включая действие вредоносного кода (например, вирусов и программ-червей), случайные нарушения политик внутренними пользователями, сознательное предоставление доступа к важной информации со стороны внутренних пользователей, действия внешних злоумышленников (например, конкурентов или иностранных правительственных учреждений) и стихийные бедствия. Необходимо задокументировать все действия, которые группа информационной безопасности должна предпринимать при возникновении инцидента. Эффективность работы группы информационной безопасности может определяться с помощью различных критериев, включая перечисленные ниже. Число типичных инцидентов безопасности, повлиявших на работу подобных организаций, но нейтрализованных элементами контроля, рекомендованными группой управления рисками безопасности. Время, необходимое на полное восстановление работоспособности вычислительных служб после инцидентов безопасности. Качество и количество контактов с пользователями. Число внутренних семинаров. Число внутренних аудиторных занятий. Число проведенных оценок. 120 Глава 6. Реализация контроля и оценка эффективности программы Число проведенных семинаров по компьютерной безопасности. Число и уровень публичных мероприятий. Полученные и поддерживаемые профессиональные сертификаты. Повторная оценка новых и измененных активов и рисков безопасности Для эффективного управления рисками необходимо, чтобы данный процесс носил постоянный характер в рамках организации, а не остался временным проектом. Первым этапом повторного выполнения цикла управления рисками является периодическая повторная оценка среды с использованием процесса, описанного в главе 4 «Оценка рисков». Хотя положение дел может казаться очевидным, группа управления рисками безопасности должна повторно использовать и обновить перечень активов, уязвимостей, элементов контроля и другую интеллектуальную собственность, разработанную в ходе выполнения начального проекта по управлению рисками. Рабочая группа может повысить эффективность использования своих ресурсов, уделив особое внимание изменениям в рабочей среде организации. Если после последней оценки актив не изменился, не имеет смысла подробно оценивать его еще раз. Чтобы определить участки, требующие повышенного внимания, рабочая группа должна своевременно собирать точные сведения об изменениях, влияющих на информационные системы организации. Необходимо обращать особое внимание на следующие внутренние события: установка нового компьютерного оборудования и программного обеспечения, внедрение новых приложений, разработанных силами сотрудников организации, корпоративные реорганизации, корпоративные слияния и приобретения и ликвидация частей организации. Рекомендуется также просмотреть существующий перечень рисков, чтобы определить, возникли ли какие-то изменения, и изучить журналы аудита системы безопасности, которые могут выявить новые области для анализа. Кроме того, рабочая группа должна отслеживать изменения, которые происходят за пределами организации, но могут влиять на систему безопасности организации. Ниже приведены некоторые примеры. Изучение веб-узлов и списков рассылки разработчиков программного обеспечения в поисках новых обновлений системы безопасности и новых документов, посвященных безопасности. Изучение веб-узлов и списков рассылки сторонних организаций в поисках новых материалов, посвященных безопасности, и сообщений о новых уязвимостях. Участие в семинарах и конференциях, включающих обсуждение вопросов безопасности. Прохождение учебных курсов по информационной безопасности. Постоянное изучение новых технологий путем чтения литературы по безопасности компьютеров и сетей. Отслеживание оповещений о новых методах и средствах атак. Руководство по управлению рисками безопасности 121 Заключение На этапе реализации контроля ответственные за нейтрализацию риска развернули решения для контроля, выбранные организационным комитетом по обеспечению безопасности на этапе поддержки принятия решений. Кроме того, ответственные за нейтрализацию риска предоставили группе управления рисками безопасности отчеты о ходе реализации решений для контроля. Четвертый этап процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, по большей части состоит из постоянно выполняемых операций, которые будут длиться, пока группа управления рисками безопасности не начнет следующий цикл путем выполнения новой оценки активов. В число этих операций входит составление подробных отчетов с информацией о планируемых изменениях в ИТ-среде, об изменениях в ИТ-среде, которые должны быть внесены в ближайшее время, и о незапланированных событиях безопасности, повлиявших на ИТ-среду. Данный этап включает также составление группой управления рисками безопасности отчетов, показывающих, насколько внедренные решения снизили риски и каким образом выявленные ранее угрозы изменились вследствие появления новых угроз, а также содержащих сведения о новых уязвимостях и изменениях в ИТ-среде организации. Кроме того, на этом этапе создается и ведется система показателей рисков, характеризующая текущий профиль риска организации. Выводы из руководства В данном руководстве описана методика управления рисками безопасности, предлагаемая корпорацией Майкрософт и основанная на проактивном подходе, способном помочь организациям любого размера в борьбе с рисками безопасности, которые могут влиять на бизнес организации. Формальный процесс управления рисками безопасности позволяет организациям использовать экономически эффективные методы работы с известными и допустимыми бизнес-рисками и предоставляет целостную и понятную методику организации и приоритизации ограниченных ресурсов, необходимых для управления рисками. Внедрение системы управления рисками безопасности дает возможность выбрать экономически эффективные элементы контроля, уменьшающие риск до приемлемого уровня. Определение приемлемого уровня риска и подход к управлению рисками зависят от конкретной организации — универсального решения не существует, а разные организации используют различные модели управления рисками. Каждая модель предлагает собственное сочетание точности, ресурсов, времени, сложности и субъективности. Инвестирование в процесс управления рисками, основанный на проверенной концепции и четком определении ролей и ответственностей, подготавливает организации к определению приоритетов и планированию мероприятий по нейтрализации угроз и соотнесению угроз и уязвимостей с бизнесом. Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, использует отраслевые стандарты для объединения существующих моделей управления рисками в интерактивный четырехэтапный процесс, направленный на достижение баланса затрат и эффективности. В процессе оценки рисков быстро выполняется качественное определение наиболее важных рисков, а затем осуществляется количественная оценка, основанная на строго определенных ролях и ответственности. Данный подход учитывает множество деталей и позволяет получить полное представление об основных рисках. Качественные и количественные шаги в процессе оценки рисков позволяют сформировать основу для принятия решений о рисках и нейтрализациях риска, сопутствующих интеллектуальным бизнес-процессам. Теперь, полностью изучив материал руководства, вы готовы начать данный процесс. Для этого вернитесь к главе 4 «Оценка рисков». Приложение А. Оперативная оценка рисков Процесс управления рисками безопасности, предлагаемый корпорацией Майкрософт, описывает этап оценки рисков как плановую операцию в ходе программы управления рисками. Этап оценки рисков определяет шаги по выявлению и приоритизации известных организации сценариев рисков. Результатом выполнения операций данного этапа является создание ранжированного по приоритетам перечня рисков на обобщенном и детализированном уровнях. Кроме того, оценка рисков позволяет получить данные, необходимые на других этапах управления рисками. Хотя оценка рисков имеет большое значение, в ходе деятельности организации корпоративные риски постоянно изменяются, и группа управления рисками безопасности должна определить процесс выявления и анализа рисков, независимый от этапа цикла управления рисками, поскольку корпорация Майкрософт не рекомендует откладывать анализ рисков до следующего цикла оценки рисков. Потребность в быстром получении сведений о риске может возникнуть в любой момент. Например, может оказаться, что заинтересованные лица не способны достичь согласия при определении уровня риска малоизученной угрозы. В этом случае разные заинтересованные лица могут высказывать противоречивые мнения и предлагать взаимоисключающие решения по нейтрализации риска. Группа управления рисками безопасности должна задокументировать мнение о риске и оказать помощь в процессе принятия решения, подобно тому, как это осуществляется в формальной программе управления рисками. Скорее всего, группе управления рисками безопасности предложат разработать для выбранного сценария функциональные требования, которые не могут (и не должны) разрабатываться, если отсутствует информация обо всех элементах риска. Это означает, что требуется безотлагательная, оперативная оценка риска. Остерегайтесь требований оценки риска, направленных на использование процесса оценки в качестве средства для обоснования развертывания предвзятого решения. Оценка рисков должна обеспечить беспристрастную характеристику фактических рисков, связанных с конкретной проблемой. В процессе управления рисками безопасности, предлагаемом корпорацией Майкрософт, оцениваются различные сценарии рисков, а затем определяются их приоритеты. При оперативной оценке риски анализируются по отдельности. Оперативная оценка призвана ответить на конкретный вопрос, например: «В чем состоят риски, связанные с предоставлением пользователям-гостям доступа с использованием беспроводной сети?» или «Какие риски возникнут, если позволить мобильным устройствам подключаться к корпоративным активам?» Оперативная оценка рисков использует методику, рассмотренную при описании процесса оценки рисков, однако определение приоритетов риска и решения по отношению к другим корпоративным рискам не является обязательным. Формальная приоритизация может быть необходима только в том случае, если решение по нейтрализации риска является дорогостоящим. Зачастую сравнения со схожими рисками вполне достаточно для оперативной оценки риска с целью приоритизации. Результаты оперативной оценки, разумеется, должны быть соответствующим образом учтены в формальном процессе. 124 Приложение А. Оперативная оценка рисков При оперативной оценке рисков также может использоваться шаблон обсуждения риска, включенный в раздел Tools данного руководства. Однако может оказаться, что собранные данные требуют анализа, а не встреч с заинтересованными лицами. Группе управления рисками безопасности по-прежнему необходимо ответить на основные вопросы, указанные в данном шаблоне, однако автором вопросов может быть сама рабочая группа. Например, если рабочая группа пытается собрать информацию о рисках, возникающих при использовании мобильных устройств, могут потребоваться сведения об уровне потерь подобных устройств. Эта информация может быть получена на основе результатов внешних исследований или от других ИТ-подразделений, ответственных за обслуживание. Результаты оперативной оценки рисков могут распространяться в виде документа, имеющего следующую структуру. Основные положения. В этом разделе излагаются общие сведения об оценке в целом. Необходимо, чтобы эти сведения можно было извлечь в виде отдельного документа. Перечень допущений, относящихся к сфере действия и целям оперативной оценки риска. Описание подлежащего защите актива и его ценности для организации. Полная формулировка риска, соответствующая требованиям процесса управления рисками безопасности, предлагаемого корпорацией Майкрософт, и позволяющая получить ответ на следующие вопросы. Каких последствий для актива необходимо избежать? Как может быть причинен ущерб или использована подверженность воздействию? Каков уровень подверженности актива воздействию? Какие меры предпринимаются в настоящее время, чтобы снизить вероятность возникновения риска или уменьшить его влияние, если защитные меры потерпят неудачу? Каков общий риск? Включите формулировку вида «Высока вероятность того, что атака сможет нарушить целостность цифровых активов, оказывающих среднее влияние на бизнес организации, что обусловливает высокий риск для организации». Какие действия можно предпринять, чтобы снизить вероятность подобных событий в будущем? Каков будет общий риск в случае реализации потенциальных элементов контроля? Оценка одного риска может содержать несколько сценариев угроз. В примере с гостевым доступом к беспроводной сети одним сценарием может быть атака гостем другого гостя, вторым — внешняя атака, направленная на одного из гостей, а третьим — использование гостевого доступа для атаки цели через Интернет. Рабочая группа должна сформировать формулировки рисков для всех применимых сценариев. При наличии полной информации о рисках бывает достаточно просто распространить эти сведения. Возможно также, что желаемым результатом является формулировка функциональных требований группы управления рисками безопасности. При наличии функциональных требований они должны быть сопоставлены конкретным рискам, для устранения которых они разработаны. Документ, посвященный оценке риска и содержащий функциональные требования к безопасности, представляет собой эффективное средство, помогающее понять особенности риска и выбрать наилучшее решение по нейтрализации риска. Приложение Б. Типичные активы информационных систем В приложении Б перечислены типичные активы информационных систем, встречающиеся в организациях различных типов. Приведенный перечень не претендует на полноту и является лишь образцом, который может использоваться в качестве отправной точки. Поскольку маловероятно, что в нем окажутся все активы, входящие в уникальную среду конкретной организации, на этапе оценки рисков в него необходимо внести соответствующие изменения. Таблица Б.1. Типичные ИТ-активы Класс актива Общая ИТ-среда Название актива Уровень актива Высший уровень описания актива Определение следующего уровня (если необходимо) Уровень стоимости актива (1–5) Материальный Физическая инфраструктура Центр обработки данных 5 Материальный Физическая инфраструктура Серверы 3 Материальный Физическая инфраструктура Настольные компьютеры 1 Материальный Физическая инфраструктура Мобильные компьютеры 3 Материальный Физическая инфраструктура Карманные ПК 1 Материальный Физическая инфраструктура Сотовые телефоны 1 Материальный Физическая инфраструктура Серверные приложения 1 Материальный Физическая инфраструктура Приложения для пользователей 1 Материальный Физическая инфраструктура Средства разработки 3 Материальный Физическая инфраструктура Маршрутизаторы 3 Материальный Физическая инфраструктура Сетевые коммутаторы 3 Материальный Физическая инфраструктура Факсимильные аппараты 1 Материальный Физическая инфраструктура Мини-АТС 3 126 Приложение Б. Типичные активы информационных систем Материальный Физическая инфраструктура Съемные носители 1 (магнитные ленты, дискеты, компакт- и DVDдиски, портативные жесткие диски, устройства хранения с интерфейсом PC card, устройства хранения с интерфейсом USB и т. п.) Материальный Физическая инфраструктура Источники питания 3 Материальный Физическая инфраструктура Источник бесперебойного питания 3 Материальный Физическая инфраструктура Системы пожаротушения 3 Материальный Физическая инфраструктура Система кондиционирования воздуха 3 Материальный Физическая инфраструктура Система фильтрации воздуха 1 Материальный Физическая инфраструктура Прочие системы контроля влияния окружающей среды 3 Материальный Данные интрасети Исходный код 5 Материальный Данные интрасети Данные о сотрудниках 5 Материальный Данные интрасети Финансовые данные 5 Материальный Данные интрасети Маркетинговая информация 5 Материальный Данные интрасети Пароли сотрудников 5 Материальный Данные интрасети Секретные ключи шифрования сотрудников 5 Материальный Данные интрасети Ключи шифрования компьютерных систем 5 Материальный Данные интрасети Смарт-карты 5 Материальный Данные интрасети Интеллектуальная собственность 5 Материальный Данные интрасети Данные для соблюдения нормативных требований (GLBA, HIPAA, CA SB1386, директива ЕС о защите данных и т. п.) 5 Материальный Данные интрасети Номера социального 5 страхования сотрудников Руководство по управлению рисками безопасности 127 Материальный Данные интрасети Номера водительских удостоверений сотрудников 5 Материальный Данные интрасети Стратегические планы 3 Материальный Данные интрасети Информация о потребительских кредитах покупателей 5 Материальный Данные интрасети Медицинские данные заказчиков 5 Материальный Данные интрасети Параметры биометриической идентификации сотрудников 5 Материальный Данные интрасети Информация о деловых контактах сотрудников 1 Материальный Данные интрасети Информация о личных контактах сотрудников 3 Материальный Данные интрасети Информация о заказах на закупку 5 Материальный Данные интрасети Схема инфраструктуры сети 3 Материальный Данные интрасети Внутренние веб-узлы 3 Материальный Данные интрасети Этнографические данные сотрудников 3 Материальный Данные экстрасети Информация о контрактах с партнерами 5 Материальный Данные экстрасети Финансовые данные партнеров 5 Материальный Данные экстрасети Контактные данные партнеров 3 Материальный Данные экстрасети Приложения для совместной работы с партнерами 3 Материальный Данные экстрасети Ключи шифрования партнеров 5 Материальный Данные экстрасети Отчеты о кредитоспособ- 3 ности партнеров Материальный Данные экстрасети Информация партнеров о заказах на закупку 3 Материальный Данные экстрасети Информация о контрактах с поставщиками 5 Материальный Данные экстрасети Финансовые данные поставщиков 5 Материальный Данные экстрасети Контактные данные поставщиков 3 128 Приложение Б. Типичные активы информационных систем Материальный Данные экстрасети Приложения для совместной работы с поставщиками 3 Материальный Данные экстрасети Ключи шифрования поставщиков 5 Материальный Данные экстрасети Отчеты о кредитоспособ- 3 ности поставщиков Материальный Данные экстрасети Информация поставщиков о заказах на закупку 3 Материальный Интернет-данные Приложения для продаж с помощью веб-узлов 5 Материальный Интернет-данные Маркетинговая информация относительно веб-узлов 3 Материальный Интернет-данные Данные кредитных карт покупателей 5 Материальный Интернет-данные Контактные данные покупателей 3 Материальный Интернет-данные Открытые ключи шифрования 1 Материальный Интернет-данные Пресс-релизы 1 Материальный Интернет-данные Информационные документы 1 Материальный Интернет-данные Документация по продукту 1 Материальный Интернет-данные Учебные материалы 3 Нематериальный Репутация 5 Нематериальный Доброжелательность 3 Нематериальный Моральное состояние сотрудников 3 Нематериальный Производительность сотрудников 3 ИТ-службы Обмен сообщениями Обмен электронной почтой и ведение расписания (например, в Microsoft Exchange) 3 ИТ-службы Обмен сообщениями Обмен мгновенными сообщениями 1 ИТ-службы Обмен сообщениями Microsoft Outlook® Web Access (OWA) 1 ИТ-службы Основная инфраструктура Служба каталогов Active Directory® 3 Руководство по управлению рисками безопасности 129 ИТ-службы Основная инфраструктура Система DNS 3 ИТ-службы Основная инфраструктура Протокол DHCP 3 ИТ-службы Основная инфраструктура Корпоративные элементы контроля 3 ИТ-службы Основная инфраструктура Общий доступ к файлам 3 ИТ-службы Основная инфраструктура Хранение данных 3 ИТ-службы Основная инфраструктура Удаленный доступ с использованием телефонной сети 3 ИТ-службы Основная инфраструктура Телефония 3 ИТ-службы Основная инфраструктура Доступ с помощью виртуальных частных сетей (VPN) 3 ИТ-службы Основная инфраструктура Служба WINS 1 ИТ-службы Прочая инфраструктура Службы совместной работы (например, Microsoft SharePoint®) — Приложение В. Типичные угрозы В приложении В перечислены наиболее распространенные угрозы, влияющие на работу широкого круга организаций. Приведенный перечень включает не все угрозы и является лишь образцом, который может использоваться в качестве отправной точки. Кроме того, поскольку данный перечень не обновляется, он не является актуальным. Поэтому на этапе оценки рисков необходимо исключить из него угрозы, которые не могут повлиять на работу конкретной организации, дополнить его обнаруженными угрозами. Таблица В.1. Типичные угрозы Угроза Пример Общее описание угрозы Конкретный пример Катастрофа Пожар Катастрофа Наводнение Катастрофа Землетрясение Катастрофа Сильная гроза Катастрофа Террористический акт Катастрофа Общественные волнения, массовые беспорядки Катастрофа Обвал или оползень Катастрофа Сход лавины Катастрофа Авария на производстве Механическая неисправность Отключение электропитания Механическая неисправность Сбой оборудования Механическая неисправность Сбой в работе сети Механическая неисправность Сбой в системе контроля окружающей среды Механическая неисправность Авария на строительстве Не злоумышленник Неосведомленный сотрудник Не злоумышленник Неосведомленный пользователь Злоумышленник Хакер, взломщик Злоумышленник Компьютерный преступник Злоумышленник Производственный шпионаж Злоумышленник Шпионаж, финансируемый правительством Злоумышленник Социальная инженерия Злоумышленник Рассерженный сотрудник Злоумышленник Рассерженный бывший сотрудник 132 Приложение В. Типичные угрозы Злоумышленник Террорист Злоумышленник Халатный сотрудник Злоумышленник Нечестный сотрудник (коррумпированный или шантажируемый) Злоумышленник Вредоносный мобильный код Приложение Г. Уязвимости В приложении Г перечислены наиболее распространенные уязвимости, влияющие на работу широкого круга организаций. Приведенный перечень включает не все уязвимости и является лишь образцом, который может использоваться в качестве отправной точки. Кроме того, поскольку данный перечень не обновляется, в нем отсутствуют сведения о последних версиях уязвимостей. Поэтому на этапе оценки рисков необходимо исключить из него уязвимости, которые не могут повлиять на работу конкретной организации, и дополнить его обнаруженными угрозами. Таблица Г.1. Уязвимости Класс уязвимости Уязвимость Пример Общее описание класса уязвимости Краткое описание уязвимости Конкретный пример (если существует) Физические параметры Незапертые двери Физические параметры Неконтролируемый доступ к компьютерному оборудованию Физические параметры Недостаточная эффективность систем пожаротушения Физические параметры Неудачные проекты зданий Физические параметры Ошибки при строительстве зданий Физические параметры Использование легковоспламеняющихся материалов при строительстве Физические параметры Использование легковоспламеняющихся материалов при отделке Физические параметры Незапертые окна Физические параметры Недостаточно надежные стены Физические параметры Внутренние стены не полностью отгораживают комнату сверху и снизу Природный Оборудование расположено на линии сброса Природный Оборудование расположено в зоне затопления Природный Оборудование расположено в зоне схода лавин Оборудование Отсутствие исправлений Оборудование Устаревшая микропрограмма 134 Приложение Г. Уязвимости Оборудование Ошибочная конфигурация систем Оборудование Не обеспечена физическая безопасность систем Оборудование На общедоступных интерфейсах разрешены протоколы управления Программное обеспечение Устаревшее антивирусное программное обеспечение Программное обеспечение Отсутствие исправлений Программное обеспечение Недостатки при разработке приложений Применение многоузловых сценариев Программное обеспечение Недостатки при разработке приложений Внедрение кода SQL Программное обеспечение Недостатки при разработке приложений Переполнение буфера и другие слабые места в коде Программное обеспечение Намеренное создание изъянов Лазейки разработчиков ПО для управления или восстановления систем Программное обеспечение Умышленное создание слабых мест Программы-шпионы наподобие клавиатурных шпионов Программное обеспечение Умышленное создание изъянов Программы-трояны Программное обеспечение Умышленное создание изъянов Программное обеспечение Ошибки конфигурации Инициализация вручную, ведущая к противоречивой конфигурации Программное обеспечение Ошибки конфигурации Системы не защищены Программное обеспечение Ошибки конфигурации Не выполняется аудит систем Программное обеспечение Ошибки конфигурации Не выполняется мониторинг систем Среда Электрические помехи Связь Нешифруемые сетевые протоколы Связь Подключения к нескольким сетям Связь Не отключены ненужные протоколы Руководство по управлению рисками безопасности 135 Связь Отсутствует фильтрация между сегментами сети Человеческий фактор Неправильно определенные процедуры Недостаточная подготовленность к реагированию на инциденты Человеческий фактор Неправильно определенные процедуры Подготовка к работе выполняется вручную Человеческий фактор Неправильно определенные процедуры Недостаточно разработаны планы восстановления после сбоев Человеческий фактор Неправильно определенные процедуры Тестирование на рабочих системах Человеческий фактор Неправильно определенные процедуры Отсутствует уведомление о нарушениях Человеческий фактор Неправильно определенные процедуры Недостаточное управление изменениями Человеческий фактор Похищенные учетные данные Участники проекта Группа разработки решений Майкрософт по безопасности и соответствию регулятивным нормам (MSSC) и центр Microsoft Security Center of Excellence (SCOE) выражают признательность коллективу, составившему данное «Руководство по управлению рисками безопасности». Перечисленные ниже люди отвечали за создание описанного решения непосредственно или внесли значительный вклад в его разработку и тестирование. Авторы Другие участники Курт Диллард (Kurt Dillard) Джаред Пфост (Jared Pfost) Стефен Райан (Stephen Ryan), Content Master Чейз Карпентер (Chase Carpenter) Брайан Филдер (Brian Fielder) Мишель Глэсс (Michael Glass), Volt Джон Хоуи (John Howie) Максим Каптейнс (Maxim Kapteijns) Крисси Льюис (Chrissy Lewis), Siemens Кейт Проктор (Keith Proctor) Билл Рейд (Bill Reid) Ли Вокер (Lee Walker) Соавторы Прайс Оден (Price Oden) Джефф Уильямс (Jeff Williams) Испытатели Дэн Хичкок (Dan Hitchcock) Мехул Медивала (Mehul Mediwala), Infosys Technologies Пит Намита (Pete Narmita) Прайс Оден (Price Oden) Джейсон Вонг (Jason Wong) Редакторы Венди Клиари (Wendy Cleary), S&T Onsite Дженифер Кернс (Jennifer Kerns), Content Master Ответственные за выпуск Флика Крэндл (Flicka Crandell) Карл Сенг (Karl Seng), Siemens Руководители проектов Рецензенты Шанти Бэлэремен (Shanti Balaraman) Рич Бенэк (Rich Bennack), US GTSC Security Мэтью Гролью (Mathieu Groleau) Алан Хакими (Alan Hakimi) Эллен Макдермот (Ellen McDermott) Марко Нуйджен (Marco Nuijen) Брайан Ши (Brian Shea), Bank of America Дэвид Смит (David Smith) Брэд Ворендер (Brad Warrender) Джон Вейгелт (John Weigelt) Джессика Зан (Jessica Zahn) Карл Гранвальд (Karl Grunwald) Элисон Вулфорд (Alison Woolford), Content Master По просьбе корпорации Майкрософт в рецензировании данных документов приняли участие Министерство торговли США и Национальный институт стандартов и технологии. Предоставленные ими комментарии включены в опубликованные версии.
