Управление информационной безопасностью. Стандарты СУИБ (СИ)

В 2010 году Международная организация по стандартизации опубликовала новый стандарт ISO/IЕС 27003 «ИТ. Методы защиты. СУИБ. Руководство по реализации СУИБ».

Он посвящён вопросам успешной разработки и внедрения СУИБ в соответствии с требованиями ISO/IEC 27001. Стандарт ISO/IЕС 27003 описывает процесс формирования требований и проектирования СУИБ от начала проекта и до подготовки планов внедрения.

Указан процесс получения согласия руководства на внедрение СУИБ, дается детализация проекта внедрения СУИБ, даются рекомендации по планированию проекта внедрения СУИБ, результатом которого является окончательный план внедрения СУИБ.

Планирование внедрения СУИБ состоит из 5 этапов:

1) получение одобрения руководства для проектирования СУИБ (раздел 5);

2) определение области действия и политики СУИБ (раздел 6);

3) проведение анализа организации (раздел 7);

4) проведение анализа и планирование обработки рисков (раздел 8);

5) разработка СУИБ (раздел 9).

Каждый раздел содержит следующую информацию:

— цели (что необходимо достичь);

— действия для их достижения.

Описания действий структурированы в виде исходных данных, рекомендаций и выходных данных.

Исходные данные — описывают отправную точку, например, наличие документированных решений или выходных данных других действий, описываемых в стандарте;

Рекомендации — содержат подробную информацию, позволяющую выполнить данное действие;

Выходные данные — описывают результат (ы) или документ (ы), получаемые после выполнения действия.

1. Одобрение руководством проектирования СУИБ

Цель: Получить одобрение руководства путем определения случая применения СУИБ для предприятия и подготовки плана проекта.

Исходные данные: Описание случая применения СУИБ для данного предприятия, включающее приоритеты и цели внедрения СУИБ, а также структуру организации для СУИБ.

Рекомендации: Составить первоначальный план проекта СУИБ.

Выходные данные: Описание случая применения СУИБ для данного предприятия и первоначальный план проекта СУИБ с описанием ключевых этапов.

Одобрение руководством проектирования СУИБ определяют следующие процессы:

1) определение приоритетов организации для разработки СУИБ;

2) определение предварительной области действия СУИБ;

3) техническое обоснование и план проекта СУИБ для получения санкции руководства.

1.1. Определение приоритетов организации для разработки СУИБ

Исходные данные:

— стратегические цели организации;

— обзор существующих систем управления;

— перечень действующих нормативно-правовых и договорных требований к ИБ.

Рекомендации: Выполнить сбор существенной информации, показывающей значение СУИБ для организации. Организация должна определить, зачем нужна СУИБ, определить цели внедрения СУИБ и запустить проектирование СУИБ.

Выходные данные:

— документ, излагающий цели, приоритеты в области ИБ и требования организации к системе СУИБ;

— перечень нормативно-правовых и контрактных требований к ИБ организации;

— описание характеристик организации, местонахождения, активов и технологий.

1.2. Определение предварительной области действия СУИБ

Определение предварительной области обеспечивают следующие процессы:

— разработка предварительной области;

— определение для нее ролей и сфер ответственности.

1.2.1. Разработка предварительной области

Исходные длиные: Выходные данные 1.1.

Рекомендации: Определить структуру организации для реализации СУИБ.

Выходные данные:

— изложение обязательных требований к УИБ, определяемых руководством организации, и обязательств, накладываемых на организацию извне;

— описание того, как части области действия СУИБ взаимодействуют с другими системами управления;

— перечень целей предприятия в области УИБ;

— перечень важнейших бизнес-процессов, активов, организационных структур и регионов, где будет использоваться СУИБ;

— соотношение существующих систем управления, регулирования, соответствия и целей организации;

— характеристики организация, местонахождение, активы и технологии.

1.2.2. Определение для предварительной области ролей и сфер ответственности

Исходные данные

— выходные данные 1.2.1;

— список заинтересованных сторон, которые получат выгоду в результате реализации проекта СУИБ.

Рекомендации: Определить роль организации в реализации проекта и ответственных лиц за УИБ, а для сотрудников должны быть определены роли и сферы ответственности на основе квалификации, требуемой для выполняемой работы.

Выходные данные: представляют собой документ или таблицу, описывающую роли и сферы ответственности с указанием имен и организацию, необходимую для успешного внедрения СУИБ.

1.3. Техническое обоснование и план проекта СУИБ для получения санкции руководства

Одобрение руководства и выделение ресурсов для реализации проекта внедрения СУИБ должны быть получены путем определения случая применения СУИБ для предприятия и подготовки плана проекта СУИБ.

Исходные данные:

— выходные данные 1.1;

— выходные данные 1.2.

Рекомендации:

Информация по случаю применения СУИБ для предприятия и первоначальный план проекта СУИБ должны охватывать следующие вопросы:

— цели и конкретные задачи;

— выгоды для организации;

— предварительная область действия СУИБ, включая затрагиваемые бизнес-процессы;

— важнейшие процессы и ф акторы для достижения целей СУИБ;

— описание проекта высокого уровня;

— первоначальный план внедрения СУИБ;

— определенные роли и сферы ответственности;

— требуемые ресурсы (технологические и людские);

— соображения, касающиеся внедрения СУИБ, включая существующую систему ИБ;

— временная шкала с ключевыми этапами;

— предполагаемые затраты;

— важнейшие факторы успеха;

— количественное определение выгод для организации.

Руководство должно утвердить описание случая применения СУИБ для предприятия и первоначальный план проекта, чтобы составить поручения для всей организации и начать реализацию проекта СУИБ.

Выходные данные:

— документированное одобрение руководством выполнения проекта СУИБ с распределенными ресурсами;

— документированное описание случая применения СУИБ для данного предприятия;

— начальное предложение по проекту СУИБ с основными этапами, такими как выполнение оценки риска, реализация проекта, внутренний аудит и проверки, осуществляемые руководством.

2. Определение области действия, границ и политики СУИБ

Цель: Определить области действия и границ СУИБ и разработать политику СУИБ.

Определение области действия и границ СУИБ обеспечивают предварительные процессы:

— определение организационной и физической областей действия и границ СУИБ;

— определение области действия и границ информационных и коммуникационных технологий (далее — ИКТ);

Определение областей действия и политики СУИБ также обеспечивают заключительные процессы:

— объединение всех областей действия и границ СУИБ;

— разработка политики СУИБ и получение одобрения руководства.

2.1. Определение организационной области действия и границ

Исходные данные:

— выходные данные 1.2 — документированная предварительная область действия СУИБ, охватывающая:

• соотношения существующих систем управления, регулирования, соответствия и целей организации;

• характеристики организации, ее местонахождения, активов и технологий.

— выходные данные 1.1 — документированное утверждение руководством внедрения СУИБ и запуск проекта с необходимыми распределенными ресурсами.

Рекомендации: Одним из методов определения организационных границ является определение сфер ответственности, не перекрывающих друг друга, чтобы облегчить назначение подотчетности в организации.

На основе такого подхода анализируемые организационные границы должны определять всех сотрудников, участвующих в сфере УИБ, и эти границы должны быть включены в область действия СУИБ. Если некоторые процессы в организации выполняются сторонними организациями, эти зависимости должны быть четко задокументированы.

Выходные данные:

— описание организационных границ СУИБ, включая обоснования исключения каких-либо частей организации из области действия СУИБ;

— функции и структура частей организации, находящихся в области действия СУИБ;

— определение информации, подлежащей обмену в рамках области действия СУИБ, и информации, обмен которой осуществляется через границы СУИБ;

— процессы в организации и сферы ответственности за информационные активы в области действия СУИБ и за ее пределами;

— процесс в иерархии принятия решений, а также ее структура в рамках системы СУИБ.

2.2. Определение области действия и границ ИКТ

Исходные данные:

— выходные данные 1.2 — описание предварительной области действия СУИБ;

— выходные данные 2.1 — определение организационной области действия и границ.

Рекомендации: Определение области действия и границ ИКТ может быть получено на основе анализа имеющихся информационных систем. Элементы ИКТ включают все части организации, которые хранят, обрабатывают или передают важную информацию, активы или являются важными для других частей организации, входящих в область действия СУИБ.

Границы ИКТ должны включать описание следующих элементов:

— инфраструктура связи, в которой ответственность за ее управление входит в компетенцию организации, располагающей различными технологиями (например, беспроводные и проводные сети или сети передачи данных и телефонной связи);

— ПО в рамках организационных границ, используемое и контролируемое организацией;

— аппаратное обеспечение ИКТ, требуемое для сетей, приложений или производственных систем;

— роли и сферы ответственности, связанные с аппаратным обеспечением ИКТ, сетью и ПО.

Выходные данные:

— информация, обмен которой осуществляется как в рамках области действия СУИБ, так и через ее границы;

— границы ИКТ для СУИБ с обоснованием исключения из области действия СУИБ каких-либо элементов ИКТ, находящихся под управлением организации;

— информация об информационных и телекоммуникационных системах, описывающая, какие из них находятся в пределах области действия СУИБ вместе с ролями и сферами ответственности для этих систем.

2.3. Определение физической области действия и границ

Исходные данные:

— выходные данные 1.2 — описание предварительной области действия СУИБ;

— выходные данные 2.1 — определение организационной области действия и границ;

— выходные данные 2.2 — определение области действия и границ ИКТ.

Рекомендации: Определить помещения, обьекты и оборудование в организации, которые должны стать частью СУИБ. При этом сложнее работать с информационными системами, пересекающими физические границы, и для этого требуется:

— периферийное оборудование;

— средства связи с информационными системами клиентов и обслуживание, предоставляемое сторонними организациями;

— применение соответствующих средств связи и уровней обслуживания.

Физические границы должны включать описание следующих элементов:

— функций или процессов с учетом их физического местонахождения и степени контроля их организацией;

— специального оборудования, используемого для размещения аппаратного обеспечения ИКТ или данных, применяемых в СУИБ.

Выходные данные:

— описание физических границ СМИБ с обоснованием для исключения каких-либо физических границ, находящихся под управлением организации, из области действия СМИБ;

— описание организации и ее географических характеристик, относящихся к области действия СМИБ.

2.4. Объединение всех областей действия и границ СУИБ

Исходные данные:

— выходные данные 1.2 — описание предварительной области действия СУИБ;

— выходные данные 2.1 — определение организационной области действия и границ;

— выходные данные 2.2 — определение области действия и границ ИКТ;

— выходные данные 2.3 — определение физической области действия и границ.

Рекомендации: Свести все исходные данные в один документ.

Выходные данные: Документ, описывающий область действия и границы СУИБ, должен содержать следующую информацию:

— ключевые характеристики организации (функция, структура, активы и область действия и границы ответственности для каждого актива);

— процессы в организации, находящиеся в области действия СУИБ;

— предварительный перечень активов, находящихся в области действия СУИБ;

— конфигурация оборудования и сетей, находящихся в области действия СУИБ;

— схемы объектов, определяющие физические границы СУИБ;

— описание ролей и сфер ответственности в рамках СУИБ и их связи со структурой организации;

— описание и обоснование исключений каких-либо элементов из области действия СУИБ.

2.5. Разработка политики СУИБ и получение одобрения руководства

Исходные данные:

— выходные данные 2.4 — документированная область действия и границы СУИБ;

— выходные данные 1.2 — документированные цели внедрения СУИБ;

— выходные данные 1.3 — описание случая применения и проект плана СУИБ.

Рекомендации: Обычно политика безопасности организации является политикой высшего уровня. Она подкрепляется более конкретными политиками, включая политику ИБ и политику СУИБ. В свою очередь, политика ИБ может подкрепляться более детальными политиками по конкретным предметам, относящимся к аспектам ИБ.

Многие из этих политик описываются в стандарте ISO/IEC 27002, например, политика ИБ подкрепляется политиками, касающимися контроля доступа, политики чистого рабочего стола и экрана, использования сетевых служб и криптографического контроля. В некоторых случаях возможно включение дополнительных уровней политики.

Согласно стандарту ISO/IEC 27001 требуется, чтобы организации имели политику СУИБ и политику ИБ. Согласно стандарту ISO/IEC 27035 требуется, чтобы организации имели политику управления инцидентами ИБ.

Эти политики могут разрабатываться как равноправные политики — политика СУИБ может подчиняться политике ИБ или наоборот. В то же время политика управления инцидентами ИБ является составной частью политики СУИБ.

Содержание политики основано на контексте, в котором работает организация.

При разработке любой политики нужно учитывать следующие составляющие:

— цели и задачи;

— стратегии для достижения целей;

— структуру и процессы организации;

— требования политик более высокого уровня.

Любая политика содержит следующие разделы:

— введение;

— область действия;

— цели, принципы;

— сферы ответственности;

— ключевые результаты;

— связанные политики.

Краткое содержание политики:

1. Введение — краткое объяснение предмета политики.

2. Область действия — описывает части или действия организации, находящиеся под влиянием политики.

3. Цели — описание назначения политики.

4. Принципы — описание правил, касающихся действий и решений для достижения целей. В некоторых случаях может быть полезным определить ключевые процессы, связанные с предметом политики, и затем — правила выполнения процессов.

5. Сферы ответственности — кто отвечает за действия по выполнению требований политики. В некоторых случаях этот пункт может содержать описание организационных соглашений, а также сферы ответственности лиц с определенными ролями.

6. Ключевые результаты — описание результатов, получаемых предприятием, если цели достигнуты.

7. Связанные политики — описание других политик, относящихся к достижению целей, обычно с представлением дополнительных подробностей, касающихся отдельных предметов.

Выходные данные: Задокументировання политика СУИБ, утвержденная руководством.

3. Проведение анализа требований к ИБ

Цель: Определить требования, которым должна соответствовать СУИБ, определить активы и получить данные по текущему состоянию ИБ в рамках области действия СУИБ.

Информация, собранная в процессе анализа ИБ, должна:

— стать основной для управления;

— определять и документировать условия для внедрения СУИБ;

— обеспечивать четкое и обоснованное понимание возможностей организации;

— учитывать определенные обстоятельства и положение в организации;

— определять требуемый уровень защиты информации;

— определять сбор и обработку информации, требуемые для всего предприятия или его части, находящейся в рамках предложенной области действия СУИБ.

Проведение анализа требований к ИБ определяют следующие процессы:

1) определение требований к ИБ для СУИБ;

2) определение активов в рамках СУИБ;

3) проведение оценки ИБ.

3.1. Определение требований к ИБ для СУИБ

Исходные данные:

— выходные данные 1.1 — приоритеты организации для разработки СУИБ;

— выходные данные 2.5 — политика СУИБ.

Рекомендации: Для каждого процесса в организации и задачи для специалиста требуется принять решение в отношении того, насколько важной является информация, т. е. какой требуется уровень защиты. Требуется базовое краткое описание проанализированной информации по процессам в организации и системам ИКТ.

Для получения подробных требований к ИБ для СУИБ следует рассмотреть следующие вопросы:

— предварительное определение важных информационных активов и текущего состояния защиты информации;

— определение представлений организации и их влияния на будущие требования к ИБ;

— анализ видов обработки информации, системного ПО, коммуникационных сетей, определения действий и ресурсов для информационных технологий и т. д.;

— определение всех обязательных требований (законодательства, договоров, стандартов и соглашений с клиентами, условий страхования и т. д.);

— определение уровня информированности в области ИБ и определение требований к обучению в отношении каждого подразделения.

Выходные данные:

— определение основных процессов, функций, объектов, информационных систем и коммуникационных сетей;

— информационные активы организации;

— классификация важнейших процессов (активов);

— требования к ИБ, сформулированные на основе обязательных требований;

— перечень известных уязвимостей, которые должны быть устранены в результате выполнения требований к ИБ;

— требования к обучению и образованию в области ИБ в организации.

3.2. Определение активов в рамках СУИБ

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 3.1 — требования к ИБ для процесса СУИБ.

Рекомендации: Для определения активов в рамках области действия СУИБ необходимо указать следующую информацию:

— уникальное наименование процесса;

— описание процесса и связанные с ним действия (создание, хранение, передача, удаление);

— важность процесса для организации (критический, важный, вспомогательный);

— владелец процесса (подразделение организации);

— процессы, обеспечивающие исходные и выходные данные этого процесса;

— приложения ИТ, поддерживающие процесс;

— классификация информации (конфиденциальность, целостность, доступность и другие важные для организации свойства).

Выходные данные:

— определенные информационные активы основных процессов в организации в рамках области действия СУИБ;

— классификация важнейших процессов и информационных активов с точки зрения ИБ.

3.3. Проведение оценки ИБ

Необходимо провести оценку ИБ путем сравнения текущего состояния ИБ в организации с целями организации.

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 3.1 — требований к ИБ для процесса СУИБ;

— выходные данные 3.2 — активы в рамках области действия СУИБ.

Рекомендации: При оценке ИБ анализируется текущая ситуация в организации путем использования следующей информации и определяется текущее состояние ИБ и недостатки в документации:

— изучение предпосылок на основе важнейших процессов;

— классификация информационных активов;

— требования организации к ИБ.

Для успешной оценки ИБ важными являются следующие действия:

— перечисление соответствующих стандартов;

— определение требований к управлению, установленных на основе политики ИБ, обязательных требований, результатов прошедших проверок или оценок рисков;

— использование этих документов для приблизительной оценки существующих требований к уровню ИБ.

Подход к проведению оценки ИБ следующий:

— выбрать важные бизнес-процессы и этапы процессов, касающиеся требований к ИБ;

— составить подробную блок-схему, охватывающую основные процессы, включая инфраструктуру;

— обсудить и проанализировать с ключевыми сотрудниками существующую ситуацию в организации в отношении требований к ИБ;

— определить недостатки в управлении путем сравнения существующих средств управления с определенными требованиями к управлению;

— определить и задокументировать текущее состояние организации.

Выходные данные: Документ, описывающий состояние ИБ в организации и обнаруженные уязвимости.

4. Проведение оценки и планирование обработки рисков

Цель: Определить методологию оценки риска, определить, проанализировать и оценить риски ИБ, чтобы выбрать варианты их обработки и средства ИБ.

Проведение оценки и планирование обработки рисков определяют следующие процессы:

1) проведение оценки рисков;

2) выбор средств ИБ;

3) получение санкции руководства на внедрение и использование СУИБ.

4.1. Проведение оценки рисков

Исходные данные:

— выходные данные раздела 2 — область действия и политика СУИБ;

— выходные данные раздела 3 — состояние ИБ и информационные активы;

— ISO/IEC 27005 — управление рисками ИБ.

Рекомендации: Оценка рисков состоит из следующих мероприятий:

— идентификация рисков;

— измерение рисков;

— оценивание рисков.

При оценке рисков необходимо определить:

— угрозы и их источники;

— меры защиты;

— уязвимости;

— последствия нарушений ИБ.

При оценке риска нужно также осуществить:

— оценку уровня риска;

— оценку влияния инцидента на организацию;

— сравнение уровня риска с критериями оценки и приемлемости.

Выходные данные:

— описание методологий оценки рисков;

— результаты оценки рисков.

4.2. Выбор средств ИБ

Исходные данные:

— выходные данные 4.1 — результаты оценки риска;

— ISO/IEC 27002 — правила СУИБ;

— ISO/IEC 27005 — управление рисками ИБ;

— ISO/IEC 27035 — управление инцидентами ИБ.

Рекомендации: Важно продемонстрировать, как выбранные меры и средства защиты могут снизить риск и вероятность возникновения инцидента. В случае снижения риска установление соотношения между каждым риском (вероятным инцидентом) и выбранными средствами является полезным для разработки СУИБ.

Разработка плана обработки инцидентов

Цель плана обработки инцидентов ИБ — обеспечить подробную документацию, описывающую процессы и процедуры обработки событий, инцидентов и уязвимостей ИБ и их взаимодействия. План обработки инцидентов ИБ приводится в действие при обнаружении события ИБ или сообщении об уязвимости ИБ.

Каждая организация должна использовать план в качестве руководства для:

— реагирования на события ИБ;

— определения того, становятся ли события ИБ инцидентами;

— управления инцидентами ИБ до их разрешения;

— реагирования на уязвимости ИБ;

— идентификации полученных уроков при обработке инцидентов, а также необходимых улучшений СУИБ;

— реализации улучшений СУИБ.

Выходные данные:

— перечень выбранных мер и средств защиты;

— планы обработки рисков и инцидентов.

4.3. Получение санкции руководства на внедрение и использование СУИБ

Исходные данные:

— выходные данные 1.4 — утвержденный начальный проект СУИБ;

— выходные данные раздела 2 — область действия и политика СУИБ;

— выходные данные 4.1 — результаты оценки риска;

— выходные данные 4.2 — планы обработки рисков и инцидентов.

Рекомендации: Необходимо получить одобрение высшего руководства для принятия решения о принятии остаточных рисков, а также санкцию на фактическое использование СУИБ. Эти решения должны основываться на оценке рисков и вероятности их возникновения в результате внедрения СУИБ, в сравнении с рисками, возникающими в случае, когда СУИБ не применияется.

Выходные данные:

— письменное одобрение руководством внедрения СУИБ;

— утверждение руководством планов обработки рисков и инцидентов;

— положение о применимости, включающее выбранные меры и средства защиты.

5. Разработка СУИБ

Цель: Составить конечный план внедрения СУИБ путем разработки системы безопасности организации на основе выбранных вариантов обработки риска, а также требований, касающихся записей и документов и разработки средств управления, объединяющих меры безопасности ИКТ, физические и организационные процессы и разработку специальных требований для СУИБ.

При разработке СУИБ следует принять во внимание следующие аспекты:

— безопасность организации;

— безопасность ИКТ;

— безопасность физических объектов;

— особые требования к СУИБ.

Безопасность организации охватывает административные аспекты ИБ, включая ответственность за обработку риска.

Безопасность ИКТ охватывает аспекты ИБ, связанные с ответственностью за снижение рисков при выполнении операций с ИКТ.

Безопасность физических объектов охватывает аспекты ИБ, связанные, в частности, с ответственностью, возникающей при проработке физического окружения, например, зданий и их инфраструктуры, за снижение риска.

Особые требования к СУИБ охватывают аспекты соответствии СУИБ требованиям ISO/IEC 27001 в отличие от предыдущих аспектов.

Разработку СУИБ определяют следующие процессы:

1) разработка системы ИБ организации;

2) разработка системы ИБ ИКТ и физических объектов;

3) создание условий надежного функционирования СУИБ;

4) разработка окончательного плана проекта СУИБ.

5.1. Разработка системы ИБ

Разработку системы ИБ обеспечивают следующие разработки:

— конечной структуры организации для ИБ;

— основы для документирования СУИБ;

— политики ИБ;

— стандартов и процедур обеспечения ИБ.

5.1.1. Разработка конечной структуры организации для ИБ

Необходимо сопоставить функции, роли и сферы ответственности в организации, связанные с ИБ, с обработкой рисков.

Исходные данные:

— выходные данные 1.1.2 — таблица ролей и сфер ответственности;

— выходные данные 2.3 — область действия и границы СУИБ.

— выходные данные 2.4 — политика СУИБ;

— выходные данные 3.1 — требования к ИБ для процесса СУИБ;

— выходные данные 3.2 — активы в рамках области действия СУИБ;

— выходные данные 3.3 — результаты оценки ИБ;

— выходные данные 4.1 — результаты оценки рисков;

— выходные данные 4.2 — планы обработки рисков и инцидентов;

— ISO/IEC 27002 — правила СУИБ;

— ISO/IEC 27035 — управление инцидентами ИБ.

Рекомендации: При разработке структуры организации и процессов для внутренних операций СУИБ следует попытаться создать их и обьединить с уже существующими, если это практически применимо.

Согласно стандарта ISO/IEC 27035, в первую очередь, необходимо создать группу технической поддержки, чтобы обеспечить поддержку всех аспектов информационных технологий и связанной с ними обработки информации. Как только приходит сообщение о событии ИБ, группа поддержки обрабатывает его в фазе обнаружении и оповещения.

Во вторую очередь, необходимо создать в организации специальную группу реагирования на инциденты ИБ (ГРИИБ). Целью ее создания является обеспечение организации соответствующим персоналом для оценки, реагирования иа инциденты ИБ и извлечения уроков из них, а также необходимой координации всех заинтересованных сторон и процесса обмена информацией.

Кроме того, организация обеспечить взаимодействие с внутренними подразделениями и внешними организациями, которые имеют отношение к управлению событиями, инцидентами и уязвимостями ИБ в организации.

Важно определить, какой орган в схеме обеспечения политики управления инцидентами ИБ руководитель ГРИИБ оповещает о серьезных инцидентах ИБ. Процедуры общения со СМИ и ответственность за это общение также должны быть согласованы с высшим руководством. Эти процедуры должны определить представителя организации по работе со СМИ и его взаимодействие с ГРИИБ.

Выходные данные: Документ, описывающий структуру организации, роли и сферы ответственности.

5.1.2. Разработка основы для документирования СУИБ

Необходимо проконтролировать записи и документы в системе СУИБ путем определения основы, которая позволит выполнить требования по текущему контролю записей и документов в системе СУИБ.

Исходные данные:

— выходные данные 1.3 — первоначально утвержденный проект СУИБ;

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 5.1.1 — структура организации, роли и сферы ответственности;

— ISO/IЕС 27002 — правила СУИБ.

Рекомендации: Документация по СУИБ должна включать записи решений руководства, обеспечивать возможность отслеживания действий для принятия решений и разработки политики руководством и воспроизводимость записанных результатов.

Необходимо осуществлять управление документами СУИБ и сделать их доступными персоналу. Эти действия включают:

— учреждение административной процедуры управления документами СУИБ;

— подтверждение соответствия формата документов перед изданием;

— обеспечение определения изменений и текущего состояния редакций документов;

— защита и контроль документов как информационных активов организации.

Также требуется сохранять записи состояния внедрения системы для всей фазы «PDCA», а также записи об инцидентах и событиях ИБ, записи об обучении, навыках, опыте и квалификации, внутреннем аудите СУИБ, корректирующих и предупреждающих действиях и организационные записи.

Для контроля записей необходимо выполнить следующие задачи:

— документировать меры и средства контроля и управления, требуемые для идентификации, хранения, защиты, поиска и удаления данных, и документировать продолжительность хранения;

— определить, что и в какой степени должно записываться в процессах управления организацией;

— если соответствующим законодательством определен какой-либо период хранения, он должен быть установлен в соответствии с этими требованиями.

Выходные данные:

— документ, описывающий требования к записям СУИБ и контролю документации;

— хранилища и шаблоны требуемых записей СУИБ.

5.1.3. Разработка политики ИБ

Необходимо документировать стратегическую позицию руководства и администрации, связанную с целями ИБ в отношении использования СУИБ.

Исходные данные:

— выходные данные 1.1 — приоритеты организации для разработки СУИБ;

— выходные данные 1.3 — первоначально утвержденный проект СУИБ;

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 3.1 — требования к ИБ для процесса СУИБ;

— выходные данные 3.2 — активы в рамках области действия СУИБ;

— выходные данные 3.3 — результаты оценки ИБ;

— выходные данные 4.2 — планы обработки рисков и инцидентов;

— выходные данные 4.3 — положение о применимости;

— выходные данные 5.1.1 — структура организации для ИБ;

— выходные данные 5.1.2 — основы документирования СУИБ;

— ISO/IЕС 27002 — правила СУИБ.

Рекомендации: Политика ИБ документирует стратегическую позицию организации в отношении ИБ во всей организации. Объем и структура политики ИБ должны подкреплять документы, которые используются на следующем этапе процесса для введения СУИБ.

Для больших организаций со сложной структурой (с широким спектром различных областей деятельности) может возникнуть необходимость создания общей политики и множества политик более низкого уровня, адаптированных к конкретным областям деятельности.

Предлагаемая политика (с номером версии и датой) должна быть подвергнута проверке и утверждена в организации руководством. Затем она доводится до сведения каждого работника организации надлежащим способом, чтобы стать доступной и понятной для читателей.

Выходные данные: Задокументированная и утвержденная руководством политика ИБ.

5.1.4. Разработка стандартов и процедур обеспечения ИБ

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 4.2 — план обработки рисков,

— выходные данные 4.3 — положение о применимости;

— выходные данные 5.1.1 — структура организации для ИБ;

— выходные данные 5.1.2 — основы документирования СУИБ;

— выходные данные 5.1.3 — политики ИБ;

— ISO/IEC 27002 — правила СУИБ.

Рекомендации: В процессе разработки стандартов и процедур должны участвовать представители разных частей организации, попадающих в область действия системы СУИБ. Участники процесса должны иметь полномочия и являться представителями организации.

Стандарты и процедуры ИБ должны впоследствии использоваться в качестве основы для разработки подробных технических и оперативных процессов.

Документация должна предоставляться каждому сотруднику организации, попадающему в область действия СУИБ. Стандарты и процедуры по ИБ должны применяться ко всей организации или точно указывать, какие роли, системы и подразделения попадают под их действие.

Процесс редактирования и проверки должен быть определен на ранней стадии. Необходимо создать стратегию и технологию распространения информации об изменениях политики ИБ.

Выходные данные:

— стандарты ИБ:

— процедуры обеспечения ИБ для получения стандартов ИБ.

5.2. Разработка системы ИБ ИКТ и физических объектов

Исходные данные:

— выходные данные 2.5 — область действия и границы СУИБ;

— выходные данные 2.6 — политика СУИБ;

— выходные данные 3.2 — требования к ИБ для процесса СУИБ;

— выходные данные 3.3 — активы в рамках области действия СУИБ;

— выходные данные 3.4 — результаты оценки ИБ;

— выходные данные 4.3 — положение о применимости;

— ISO/IEC 27002 — правила СУИБ.

Рекомендации:

Необходимо документировать следующую информацию:

— имя лица, ответственного за внедрение мер защиты;

— приоритет внедряемых мер защиты;

— задачи или действия по внедрению;

— установление времени, в течение которого должно быть внедрено средство защиты;

— лицо, перед которым нужно отчитываться о внедрении мер защиты по его завершению;

— ресурсы для внедрения (рабочая сила, требуемое пространство, затраты).

Сферы ответственности за процесс первоначального внедрения обычно включают:

— задание целей управления с описанием предполагаемого планируемого состояния;

— распределение ресурсов (объем работ, финансовые ресурсы);

— реальное заданное время внедрения мер защиты;

— варианты объединения с системами безопасности ИКТ, физических объектов и организации.

Сферы ответственности за процесс фактического внедрения включают:

— разработку каждого из средств защиты для области безопасности ИКТ, физических объектов и организации на оперативном уровне рабочего места;

— конкретизацию каждой меры защиты в соответствии с согласованным проектом;

— предоставление процедур и информации для органов управления и учебных курсов, способствующих информированию в сфере безопасности;

— оказание помощи и внедрение средств управления на рабочем месте.

ИБ должна быть объединена в процедуры и процессы, применяемые во всей организации. Если для части организации или третьей стороны окажется трудным внедрение этих процедур и процессов, соответствующие стороны должны сообщить об этом немедленно, чтобы согласовать решение проблемы. Решение по подобным вопросам включает изменение процедур или процессов, перераспределение должностей и сфер ответственности и адаптацию технических процедур.

Результаты внедрения средств ИБ должны быть следующими:

— план внедрения, в котором подробно описывается внедрение средств защиты, например, график, структура группы по внедрению и т. д.;

— записи и документация по результатам внедрения.

Выходные данные:

Структурированный подробный план внедрения средств управления, связанных с безопасностью ИКТ и физических обьектов, включает:

— подробное описание;

— сферы ответственности за разработку и внедрение;

— предполагаемые временные шкалы;

— связанные задачи;

— требуемые ресурсы;

— собственность (линии отчетности).

5.3. Создание условий для надежного функционирования СУИБ

Создание условий для надежного функционирования СУИБ предполагает разработку следующих документов:

— план проверок, проводимых руководством;

— программа обучения в области ИБ.

5.3.1. План проверок, проводимых руководством

Необходимо разработать план, обеспечивающий участие руководства и выдачу поручений на проверку работы СУИБ и проводимых улучшений.

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 4.3 — положение о применимости;

— выходные данные 5.1.3 — политики ИБ;

— ISO/IEC 27004 — проведение измерений СУИБ.

Рекомендации: Проверка руководством действия по внедрению СУИБ должна начинаться на самых ранних стадиях задания условий для СУИБ и описания случая применения СУИБ и продолжаться вплоть до регулярных проверок операций СУИБ.

Планирование проверок, проводимых руководством, включает установление времени и способа проведения проверок. Чтобы запланировать проверку, необходимо определить, какие должностные лица должны в ней участвовать. Назначенные должностные лица должны быть утверждены руководством и проинформированы об этом как можно раньше

Проверки, проводимые руководством, должны основываться на результатах измерений СУИБ и другой информации, накопленной за время использования СУИБ. Эта информация используется для выполнения действий руководством для определения готовности и эффективности СУИБ.

До проведения проверки руководством необходимо запланировать внутренний аудит. Результаты внутреннего аудита СУИБ являются важными исходными данными для проверок СУИБ, проводимых руководством.

Внутренний аудит СУИБ должен включать проверку того, эффективно ли внедряются и обеспечиваются меры защиты, процессы и процедуры СУИБ и соответствуют ли они:

— требованиям ISO/IEC 27001;

— действующему законодательству и правилам;

— другим требованиям ИБ.

Предварительным условием для проведения проверок СУИБ, проводимых руководством, являются данные его постоянного мониторинга. В процессе мониторинга СУИБ должны документироваться его результаты, которые записываются и сообщаются руководству.

Информация, предоставляемая руководству, может включать следующее:

— отчеты об инцидентах за последний период использования СУИБ;

— отчеты по внедрению СУИБ и обнаруженные несоответствия;

— результаты других регулярных проверок;

— рекомендации по улучшению СУИБ.

Выходные данные: Документ, содержащий план организации проверок, проводимых руководством, и включающий:

— исходные данные, требуемые для проверки СУИБ руководством;

— процедуры проверок, проводимых руководством и касающихся аспектов аудита, мониторинга и измерения.

5.3.2. Программа обучения в области ИБ

Исходные данные6

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 3.1, — требований к ИБ для процесса СУИБ;

— выходные данные 4.2 — план обработки рисков;

— выходные данные 4.3 — положение о применимости;

— выходные данные 5.1.3 — политики ИБ;

— выходные данные 5.1.4 — стандарты и процедуры ИБ;

— обзор общей программы обучения в организации.

Рекомендации: Руководство отвечает за обучение, чтобы сотрудники, назначенные на определенные должности, имели необходимые знания для выполнения требуемых операций. Содержание программы образования и обучения должно помогать всем сотрудникам знать и понимать значение и важность операций по обеспечению ИБ, в которых они участвуют, и то, как они могут способствовать достижению целей.

Программа обучения с целью информирования по вопросам ИБ должна обеспечивать составление записей по обучению в области ИБ. Эти записи должны регулярно проверяться для обеспечения получения требуемого обучения всеми сотрудниками. Необходимо назначить должностное лицо, ответственное за этот процесс.

Материалы по обучению в области ИБ должны быть разработаны таким образом, чтобы они были связаны с другими обучающими материалами, используемыми в организации, особенно, учебные курсы для пользователей ИС. Обучение по существенным аспектам ИБ должно включаться в каждый учебный курс для пользователей ИС.

Обучающие материалы по ИБ должны включать, как минимум, следующие пункты в зависимости от целевой аудитории:

— основные термины ИБ;

— риски и угрозы ИБ;

— четкое определение инцидента ИБ: рекомендации по его обнаружению, устранению и отчетности;

— политики ИБ, стандарты и процедуры организации;

— сферы ответственности и каналы отчетности, связанные с ИБ;

— рекомендации по оказанию помощи в повышении уровня ИБ;

— рекомендации, связанные с нарушениями ИБ и отчетностью;

— координаты получения дополнительной информации.

Необходимо определить группу по обучению ИБ, которая может выполнять следующие задачи:

— создание и управление записями по ИБ;

— составление и управления материалами по обучению;

— проведение обучения.

Выходные данные:

— материалы по обучению в области ИБ;

— формирование программ обучения в области ИБ, включая роли и сферы ответственности;

— планы обучения в области ИБ;

— записи, показывающие результаты обучения работников в области ИБ.

5.4. Разработка окончательного плана проекта СУИБ

Исходные данные:

— выходные данные 2.4 — область действия и границы СУИБ;

— выходные данные 2.5 — политика СУИБ;

— выходные данные 5.1 — разработка системы ИБ;

— выходные данные 5.2 — разработка системы ИБ ИКТ и физических объектов;

— выходные данные 5.3 — разработка ИБ, связанной с СУИБ;

— ISO/IEC 27002 — правила СУИБ.

Рекомендации: Действия, требуемые для внедрения выбранных средств управления и выполнения других действий, связанных с системой СУИБ, должны быть оформлены в виде подробного плана внедрения как части конечного проекта СУИБ. Подробный план внедрения системы также может подкрепляться описаниями предложенных инструментов и методов внедрения.

Поскольку проект СУИБ включает множество различных ролей в организации, важно, чтобы действия были четко определены для ответственных сторон и план был распространен на ранних стадиях проекта во всей организации.

Выходные данные: Выходные данные этого действия представляют собой окончательный план проекта внедрения СУИБ.

5. Управление рисками иб (стандарт ISO/IEC 27005:2010)

В начале 2006 года был принят первый британский национальный стандарт в сфере управления рисками ИБ BS 7799—3, который в 2008 году получил статус международного стандарта ISO/IEC 27005 «ИТ. Методы защиты. Управление рисками ИБ».

Новый стандарт ISO/IEC 27005 заменил сразу две части морально устаревшего технического стандарта ISO/IEC TR 13335 (TR — technical report — технический отчет) «ИТ. Методы защиты»: часть 3 «Методы управления безопасностью ИТ» и часть 4 «Выбор защитных мер», на базе которых он и был разработан.

В 2011 году была принята последняя редакция стандарта ISO/IEC 27005, в котором были пересмотрены и обновлены в соответствии с требованиями следующих документов:

— ISO 31000:2009 — Управление рисками — Принципы и руководства;

— ISO/IEC 31010:2009 — Управление рисками — Методики оценки рисков;

— ISO Guide 73:2009 — Управление рисками — Словарь.

Систематический подход к управлению рисками ИБ необходим для того, чтобы идентифицировать потребности организации, касающиеся требований ИБ, и создать эффективную СУИБ.

Усилия по обеспечению ИБ должны эффективно и своевременно рассматривать риски там и тогда, где и когда это необходимо. Управление рисками ИБ должно быть неотъемлемой частью всех видов деятельности, связанных с УИБ, а также должен применяться для реализации и поддержки функционирования СУИБ организации.

Управление рисками ИБ должно быть непрерывным процессом. Данный процесс должен устанавливать контекст, поддерживать оценку и обработку рисков, обеспечивать использование плана обработки риска для реализации, содействовать выработке рекомендаций и решений.

Управление рисками ИБ связано с анализом того, что может произойти, и какими могут быть возможные последствия, прежде чем выработать решение о том, что и когда должно быть сделано для снижения риска до приемлемого уровня.

Управление рисками ИБ должно способствовать следующему:

— идентификации рисков;

— оценке рисков, исходя из последствий их реализации для бизнеса и вероятности их возникновения;

— изучению вероятности и потенциальных последствий данных рисков;

— установлению порядка приоритетов в рамках обработки рисков;

— установлению приоритетов мероприятий по снижению имеющих место рисков;

— привлечению заинтересованных сторон к принятию решений об управлении рисками и поддержанию их информированности о состоянии управления рисками;

— эффективности проводимого мониторинга обработки рисков;

— проведению регулярного мониторинга и пересмотра процесса управления рисками;

— сбору информации для усовершенствования подхода к управлению рисками;

— подготовке менеджеров и персонала в сфере управления рисками и необходимых действий, предпринимаемых для их уменьшения.

Стандарт содержит описание процесса управления рисками ИБ и связанных с ним видов деятельности, основной обзор которых даётся в разделе 6.

Все действия по управлению рисками ИБ описываются в следующих разделах:

1) установление контекста (сферы применения) — в разделе 7;

2) оценка риска — в разделе 8;

3) обработка риска — в разделе 9;

4) принятие риска — в разделе 10;

5) обмен информацией о рисках — в разделе 11;

6) мониторинг и улучшение — в разделе 12.

Все составляющие управления рисками в каждом разделе структурированы в виде входных данных, действий, руководства по реализации и выходных данных.

Входные данные: идентифицируется любая информация, требуемая для выполнения деятельности.

Действие: описывается деятельность.

Руководство по реализации: предоставляется руководство по выполнению действия.

Выходные данные: идентифицируется любая информация, полученная после выполнения деятельности.

Процесс управления рисками ИБ может быть итеративным для таких видов деятельности, как оценка риска и/или обработка риска. Итеративный подход к проведению оценки риска может увеличить глубину и детализацию оценки при каждой итерации. Итеративный подход даёт хороший баланс между уменьшением времени и усилия, затрачиваемого на определение средств контроля, в то же время, по-прежнему обеспечивая уверенность в том, что высокоуровневые риски рассматриваются соответствующим образом.

Контекст впервые устанавливается тогда, когда проводится оценка высокоуровневого риска. Если она обеспечивает достаточную информацию для эффективного определения действий, требуемых для снижения риска до приемлемого уровня, то задача является выполненной и следует обработка риска. Если информация является недостаточной, то проводится другая итерация оценки риска с помощью пересмотренного контекста (например, критерии оценки рисков, критерии принятия рисков или критерии влияния), возможно на ограниченных частях полной области применения (точка принятия решения о приемлемости риска № 1).

Эффективность обработки риска зависит от результатов оценки риска. Возможно, что обработка риска не будет сразу же приводить к приемлемому уровню остаточного риска. В этой ситуации может потребоваться, если необходимо, другая итерация оценки риска с изменёнными параметрами контекста (например, оценка риска, принятие риска или критерии влияния), за которой последует дополнительная обработка риска (точка принятия решения о приемлемости риска № 2).

Деятельность по принятию риска должна обеспечивать уверенность в том, что остаточные риски однозначно принимаются руководством организации. Это особенно важно в ситуации, когда внедрение средств контроля не осуществляется или откладывается, например, из-за стоимости.

Важно, чтобы во время всего процесса управления рисками ИБ и их обработки осуществлялся обмен информацией относительно риска между руководством и персоналом. Даже до обработки рисков информация об идентифицированных рисках может быть очень ценной для осуществления управления инцидентами и может способствовать снижению потенциального ущерба.

На этапе планирования СУИБ осуществляются установление контекста, оценка риска, разработка плана обработки риска и принятие риска. На этапе реализации СУИБ осуществляются действия по снижению риска до приемлемого уровня в соответствии с планом обработки риска. На этапе проверки СУИБ осуществляются мониторинг и пересмотр обработки риска по результатам обработки инцидентов и изменений обстоятельств. На этапе улучшения СУИБ осуществляются любые корректирующие действия по усовершенствованию, включая повторное инициирование процесса управления рисками ИБ.

Следующая таблица суммирует действия по управлению рисками ИБ, относящиеся к 4-м этапам функционирования СУИБ:

1. Установление контекста (сферы применения)

Входные данные: Вся информация об организации, уместная для установления сферы применения управления рисками ИБ.

Действие: Для установления контекста организации необходимо определить:

— основные критерии управления рисками;

— сферы действия и границы;

— организационную структуру управления рисками.

Руководство по реализации: Необходимо определить цель управления рисками ИБ, так как она влияет на общий процесс и на сферу применения, в частности. Этой целью может быть:

— поддержка СУИБ;

— правовое соответствие и свидетельство должного внимания;

— подготовка плана обеспечения непрерывности бизнеса;

— подготовка плана реагирования на инциденты;

— описание требований ИБ для продукта, услуги или механизма.

Выходные данные: Спецификация основных критериев, сфера действия и границы, структура для процесса управления рисками ИБ.

1.1. Основные критерии

Должны быть разработаны следующие критерии управления рисками ИБ:

— оценки риска;

— воздействия риска;

— принятия риска.

Дополнительно организация должна оценить, доступны ли необходимые ресурсы для:

— выполнения оценки риска и установления плана обработки риска;

— определения и осуществления политики и процедуры, включая реализацию управления рисками;

— контроля мониторинга;

— мониторинга процесса управления рисками.

Критерии оценки риска

При разработке критериев оценки рисков необходимо учитывать следующее:

— стратегическая ценность обработки бизнес-информации;

— критичность затрагиваемых информационных активов;

— нормативно-правовые требования и договорные обязательства;

— важность для бизнеса доступности, конфиденциальности и целостности информации.

Кроме того, критерии оценки рисков могут использоваться для определения приоритетов для обработки рисков.

Критерии воздействия

Критерии воздействия должны разрабатываться и определяться, исходя из степени ущерба от события ИБ, учитывая следующее:

— уровень классификации информационного актива, на который оказывается влияние;

— нарушения ИБ (например, потеря конфиденциальности, целостности или доступности);

— ухудшение бизнес-операции;

— потеря ценности бизнеса и финансовой ценности;

— нарушение планов и конечных сроков;

— ущерб для репутации;

— нарушение нормативно-правовых или договорных требований.

Критерии принятия риска

Организация должна определять собственную шкалу уровней принятия риска.

При разработке критериев принятия риска следует учитывать, что они могут:

— включать многие пороговые значения с желаемым уровнем риска, но при условии, что при определённых обстоятельствах руководство будет принимать риски, находящиеся выше указанного уровня;

— выражаться как количественное соотношение оценённой выгоды к оценённому риску для бизнеса;

— включать требования для будущей дополнительной обработки, например, риск может быть принят, если имеется согласие на действия по его снижению до приемлемого уровня в рамках определённого периода времени.

Критерии принятия риска должны устанавливаться с учётом:

— критериев бизнеса;

— правовых и регулирующих аспектов;

— операций;

— технологий;

— финансов;

— социальных и гуманитарных факторов.

1.2. Область применения и границы

Область применения процесса УИБ необходимо определять для обеспечения того, чтобы все значимые активы принимались в расчёт при оценке риска. Кроме того, необходимо определять границы для рассмотрения тех рисков, источники которых могут находиться за данными границами.

При определении области применения и границ должна учитываться следующая информация, касающаяся организации:

— стратегические цели бизнеса организации, стратегии и политики;

— процессы бизнеса;

— функции и структура организации;

— нормативно-правовые и договорные требования;

— политика ИБ;

— общий подход к управлению рисками;

— информационные активы;

— местоположение организации и географические характеристики;

— ограничения, влияющие на организацию;

— социальная и культурная среда.

Примерами области применения управления рисками ИБ могут быть ИТ-приложение, ИТ— инфраструктура, бизнес-процесс или определённая часть организации.

1.3. Организационная структура

Необходимо устанавить организационную структуру организации и обязанности ответственных лиц для процесса управления рисками ИБ.

Главными ролями и обязанностями в такой структуре являются:

— разработка процесса управления рисками ИБ в организации;

— идентификация и анализ заинтересованных сторон;

— определение ролей и обязанностей всех сторон, как внутренних, так и внешних;

— установление требуемых взаимосвязей между заинтересованными сторонами;

— определение путей принятия решений;

— определение документов, которые необходимо вести.

2. Оценка рисков ИБ

Входные данные: Установленные критерии, сфера действия и границы, организационная структура для процесса управления рисками ИБ.

Действие: Оценку риска обеспечивают следующие меры:

— идентификация рисков;

— измерение рисков;

— оценивание рисков.

Руководство по реализации: Риски должны быть идентифицированы, количественно определены или качественно описаны и расставлены в соответствии с приоритетами, исходя из критериев оценки риска и целей организации.

Риск представляет собой комбинацию последствий, вытекающих из нежелательного события, и вероятности возникновения события. Оценка риска количественно определяет или качественно описывает риски и даёт возможность руководителям расставлять риски в соответствии с приоритетами согласно установленным критериям.

Оценка риска определяет ценность информационных активов, идентифицирует применимые угрозы и уязвимости, которые существуют (или могут существовать), идентифицирует существующие средства контроля и их влияние на идентифицированные риски, определяет потенциальные последствия и, наконец, расставляет выведенные риски в соответствии с приоритетами и ранжирует их по критериям оценки рисков.

Выходные данные: Перечень оценённых рисков, расставленных в соответствии с приоритетами согласно критериям оценки риска.

2.1. Идентификация рисков

Целью идентификации рисков является определение того, что могло бы произойти, чтобы нанести потенциальный, и чтобы получить представление о том, как, где и почему мог иметь место этот вред.

Для идентификация рисков необходимо идентифицировать следующие объекты:

— активы;

— угрозы;

— средства защиты;

— уязвимости;

— последствия.

2.1.1. Идентификация активов

Входные данные: Область применения и границы для оценки риска, перечень составных частей, включающий владельцев, местоположение, функцию и т. д.

Действие: Должны быть идентифицированы активы, входящие в установленную область применения, и определены их владельцы.

Руководство по реализации: Ответственность за каждый актив должен нести его владелец, который должен быть в организации определён или назначен. Чаще всего владелец актива является наиболее подходящим лицом, способным определить реальную ценность актива для организации.

Можно выделить два вида активов:

— первичные активы: бизнес-процессы и информация;

— активы поддержки всех типов: аппаратные средства и ПО, сети и сайты, организационная структура и персонал.

Все определения ценности активов должны быть сведены к общей основе. Это можно сделать с помощью критериев, которые могут использоваться для оценки возможных последствий, вытекающих из потери конфиденциальности, целостности, доступности, неотказуемости, учётности, подлинности или надёжности активов.

Они включают в себя:

— нарушение законодательства и/или предписаний;

— ухудшение функционирования бизнеса;

— потеря «неосязаемого капитала»/негативное влияние на репутацию;

— нарушения, связанные с личной информацией;

— создание угрозы личной безопасности;

— неблагоприятное влияние на обеспечение правопорядка;

— нарушение конфиденциальности;

— нарушение общественного порядка;

— финансовые потери;

— нарушение бизнес-деятельности;

— создание угрозы для безопасности окружающей среды.

Другим подходом к оценке последствий может быть:

— прерывание сервиса;

— потеря репутации и доверия клиента;

— нарушение внутреннего функционирования;

— нарушение функционирования третьей стороны;

— нарушение законов/предписаний;

— нарушение договора;

— опасность для персонала / безопасность пользователей;

— вторжение в частную жизнь пользователей;

— финансовые потери;

— финансовые потери, связанные с непредвиденными случаями или ремонтом:

— потеря товаров / денежных средств / активов;

— потеря клиентов, поставщиков;

— судебные дела и штрафы;

— потеря конкурентного преимущества;

— потеря технологического/технического лидерства;

— потеря эффективности/надёжности;

— потеря технической репутации;

— снижение способности к заключению соглашений;

— промышленный кризис (забастовки);

— правительственный кризис;

— материальный ущерб.

После установления критериев ценности активов организация должна согласовать шкалу, которая будет использоваться в масштабах организации. Первым шагом является принятие решения о числе используемых уровней. Обычно может использоваться любое число уровней от 3 (например, низкий, средний и высокий) до 10 в соответствии с подходом, используемым организацией для всего процесса оценки риска.

Организация может определить собственные границы для ценности активов, такие как «низкая», «средняя» или «высокая». Эти границы должны оцениваться в соответствии с выбранными критериями (например, для возможных финансовых потерь они должны быть даны в денежном выражении, но при рассмотрении угрозы личной безопасности, определить денежную ценность может быть затруднительно).

Выходные данные: Перечень активов, подлежащий управлению рисками, и перечень бизнес-процессов, связанных с активами, и их ценность.

2.1.2. Идентификация угроз

Входные данные: Информация об угрозах, полученная от владельцев активов, пользователей, в результате анализа инцидента, а также из других источников, включая реестры известных угроз.

Действие: Угрозы и их источники должны быть идентифицированы.

Руководство по реализации: Угроза обладает потенциалом причинения вреда активам. Должны быть идентифицированы и случайные, и умышленные источники угроз. Угроза может проистекать как из самой организации, так и вне её пределов. Угрозы должны идентифицироваться в общем и по виду (например, неавторизованные действия, физический ущерб, технические сбои).

Некоторые угрозы могут влиять более, чем на один актив. В таких случаях они могут являться причиной различных влияний, в зависимости от того, на какие активы оказывается воздействие

Используя реестры угроз или результаты прежних оценок угроз, не следует забывать о том, что происходит постоянная смена значимых угроз, особенно, если изменяются бизнес-среда или информационные системы.

Выходные данные: Перечень угроз с идентификацией вида и источника. Например, угрозы могут быть преднамеренными, случайными и экологическими. Особое внимание должно быть обращено на человеческие источники угроз.

2.1.3. Идентификация средств защиты

Входные данные: Документация средств защиты, планы обработки рисков и инцидентов.

Действие: Идентификацию средств защиты необходимо провести, чтобы проверить их эффективность и достаточность и избежать ненужных расходов, например, на их дублирование.

Если средства защиты не работают, как ожидалось, это может стать причиной уязвимости. Одним из способов количественно оценить действия средств защиты — посмотреть, как оно уменьшает вероятность угрозы и использования уязвимости или влияние инцидента.

Существующее или планируемое средство защиты может идентифицироваться как неэффективное или недостаточное, или необоснованное. Если его посчитали необоснованным или недостаточным, средство защиты необходимо проверить, чтобы определить стоит ли его удалить, заменить его другим, более подходящим, или стоит оставить его на месте, например, по стоимостным причинам.

Для идентификации существующих или планируемых средств защиты могут быть полезны следующие мероприятия:

— просмотр документов, содержащих информацию о средствах защиты (например, планы обработки рисков и инцидентов);

— проверка вместе с людьми, отвечающими за ИБ, и пользователями, какие средства защиты действительно реализованы для рассматриваемого информационного процесса или системы;

— обход здания с проведением осмотра физических средств защиты, проверка наличия существующих и реализованных средств защиты на предмет правильной и эффективной работы;

— рассмотрение результатов внутренних аудитов.

Выходные данные: Перечень всех существующих и планируемых средств защиты, их нахождение и состояние использования.

2.1.4. Идентификация уязвимостей

Входные данные: Перечни известных угроз, активов и существующих средств защиты.

Действие: Необходимо идентифицировать уязвимости, которые могут быть использованы угрозами, чтобы нанести ущерб активам или организации.

Руководство по реализации:

Уязвимости могут быть идентифицированы в следующих областях:

• организация работ;

• процессы и процедуры;

• установившиеся нормы управления;

• персонал;

• физическая среда;

• конфигурация ИС;

• аппаратные средства, ПО и оборудование связи;

• зависимость от внешних организаций.

Наличие уязвимости не причиняет вреда само по себе, так как необходимо наличие угрозы, которая воспользуется ею. Уязвимость, не имеющая соответствующей угрозы, может не требовать внедрения средства контроля, но должна осознаваться и подвергаться мониторингу на предмет изменений.

Уязвимости могут быть связаны со свойствами актива, которые могут использоваться способом и с целью, отличающимися от тех, которые планировались при приобретении или создании актива. Уязвимости, возникающие из различных источников, подлежат рассмотрению, например, те которые являются внешними или внутренними по отношению к активу.

Выходные данные:

— перечень уязвимостей, связанных с активами, угрозами и средствами защиты;

— перечень уязвимостей, не связанных с подлежащей рассмотрению угрозой.

2.1.5. Идентификация последствий

Входные данные: Перечни активов, бизнес-процессов, угроз и уязвимостей, связанных с активами, и их ценность.

Действие: Должны быть идентифицированы последствия для активов, которые могут быть результатом потери конфиденциальности, целостности или доступности. Последствием может быть потеря эффективности, неблагоприятные операционные условия, потеря бизнеса, ущерб, нанесённый репутации и т. д.

Эта деятельность идентифицирует ущерб для организации или последствия для организации, которые могут быть обусловлены сценарием инцидента, оказываемой угрозой, использующей определённую уязвимость в инциденте ИБ. Последствия могут быть временными или постоянными, как в случае разрушения активов.

Необходимо определять последствия сценариев инцидентов на основе таких факторов:

— времени на расследование и восстановление;

— потерь (рабочего) времени;

— упущенной возможности;

— нарушений охраны труда и безопасности;

— финансовых затрат на устранение последствий;

— ущерба для репутации и т. д.

Выходные данные: Перечень сценариев инцидентов с их последствиями, связанными с активами и бизнес-процессами.

2.2. Измерение риска

Измерение риска обеспечивают следующие меры:

— разработка методологии измерения риска;

— оценка последствий инцидента;

— оценка вероятности инцидента;

— измерение уровня риска.

2.2.1. Разработка методологии измерения риска

Методология измерения риска может быть качественной или количественной, или смешанной, в зависимости от обстоятельств. На практике качественная оценка часто используется первой для получения общих сведений об уровне риска и выявления основных значений рисков. Позднее может возникнуть необходимость в осуществлении количественного анализа основных значений рисков, поскольку качественный анализ является более бытрым и менее затратным.

Дополнительная информация (отсутствует в стандарте)

Предлагаемое на рынке ПО ориентировано в основном на уровень ИБ, несколько превышающий базовый уровень защищенности. Для решения данной задачи были разработаны программные комплексы анализа и контроля рисков, основанные на:

— качественной методике — COBRA, FRAP, RA2 art of risk;

— количественной методике — SecureWatch;

— смешанной методике — CRAMM, MSAT, vsRisk, РискМенеджер, ГРИФ.

Качественные методики

FRAP (Facilitated Risk Analysis Process)

Методика разработана Томасом Пелтиером в 2000 году. Оценка рисков производится для вероятности возникновения угрозы и ущерба от нее по 3-уровневой шкале (низкая, средняя, высокая). Определяется 4-уровневая оценка риска (A, B, C, D) в соответствии с правилом, задаваемым построенной матрицей рисков 3х3.

COBRA (Consultative Objective and Bi-Functional Risk Analysis — www.riskworld.net)

ПО разработано компанией «C&A Systems Security» в 1997 году. Методика представляет требования стандарта ISO/IEC 17799 в виде тематических вопросников (check list’s), на которые следует ответить в ходе оценки рисков. Далее введенные ответы автоматически обрабатываются, и формируется итоговый отчет c текущими оценками информационных рисков компании и рекомендациями по их управлению.

RA2 art of risk (ранее RA Software Tool) — ПО уже не поддерживается

В методике реализован простой для понимания процессный подход, общие требования к которому изложены в ISO/IEC 27001. Процесс управления рисками может настраиваться под потребности конкретной организации. Для успешной оценки и управления рисками необходимо собирать информацию из различных источников в организации.

Количественные методики используют шкалу с числовыми значениями и последствий, и вероятности, применяя данные из различных источников. Качество анализа зависит от точности и полноты числовых значений и от обоснованности используемых моделей. В большинстве случаев количественная оценка использует фактические данные за прошлый период, обеспечивая преимущество в том, что она может быть напрямую связана с целями ИБ и проблемами организации.

SecureWatch (ранее RiskWatch: http://riskwatch.com)

ПО разработано в 1988 году компанией «RiskWatch International» при участии Национального института стандартов и технологий США, Министерства обороны США и Канады и является по сути стандартом государственных организаций США.

Смешанные методики

CRAMM (UK Government Risk Analysis and Management Method) — ПО уже не поддерживается

Методика разработана компанией «BIS Applied Systems Ltd» пo заказу британского правительства и является государственным стандартом Великобритании. Получивший широкое распространение в мире, данный стандарт используется как в коммерческих, так и государственными организациями Великобритании с 1985 года.

vsRisk (www.vigilantsoftware.co.uk — www.itgovernance.co.uk)

Новая методика, разработанная компаниями «IT Governance» и «Vigilant Software» для оценки рисков ИБ в соответствии с требованиями стандарта ISO/IEC 27001. Также методика соответствует стандартам ISO/IEC 27005 и NIST SP 800—30.

Microsoft Security Assessment Tool (http://technet.microsoft.com/ru-ru/security/cc185712)

Методика состоит из более чем 200 вопросов, охватывающих инфраструктуру, приложения, операции и персонал. Вопросы, связанные с ними ответы и рекомендации выводятся из общепринятых практических рекомендаций, стандартов, таких как ISO 17799 и NIST-800.

ГРИФ (www.dsec.ru)

Комплексная система анализа и управления рисками информационной системы в составе пакета «Digital Security Office 2006», разработанная российской компанией «Digital Security». Использует два алгоритма: модель информационных потоков и модель анализа угроз и уязвимостей.

Риск Менеджер (www.srisks.ru)

Система автоматизации управления рисками, аудита, контроля, мониторинга безопасности банковских и других критических систем, инфраструктур и бизнес-процессов, разработанная Институтом системного анализа Российской Академии Наук.

2.2.2. Оценка последствий инцидента

Входные данные: Перечень идентифицированных сценариев инцидентов, включая идентификацию угроз, уязвимостей и затронутых активов, последствий для активов и бизнес-процессов.

Действие: Влияние бизнеса на организацию, которое может быть результатом возможных или фактических инцидентов ИБ должно быть оценено с учётом последствий нарушений ИБ (потеря конфиденциальности, целостности или доступности активов).

Руководство по реализации: Это значение влияния бизнеса может быть выражено в качественной или количественной формах, однако, любой метод присвоения денежного эквивалента может дать больше информации для принятия решений и, следовательно, сделает возможным более эффективный процесс принятия решений.

Определение ценности активов начинается с классификации активов в соответствии с их критичностью с точки зрения их важности для осуществления бизнес-целей организации.

Затем определяется восстановительная стоимость актива с учетом стоимости:

— восстановления и замены информации;

— последствий для бизнеса от потери или компрометации актива.

Определение ценности активов является ключевым фактором оценки влияния сценария инцидента, поскольку инцидент может затрагивать более, чем один актив. Различные угрозы и уязвимости могут иметь различное влияние на активы. Оценка последствий является, поэтому, связанной с определением ценности активов или делается исходя из анализа влияния на бизнес.

Выходные данные: Перечень оценённых последствий сценария инцидентов, выраженных по отношению к активам и критериям влияния на активы.

2.2.3. Оценка вероятности инцидента

Входные данные: Перечни идентифицированных сценариев инцидентов, включая идентификацию угроз, затрагиваемые активы, используемые уязвимости и последствия для активов и бизнес-процессов. Кроме того, список всех существующих и планируемых средств контроля и состояния их реализации и использования.

Действие: Должна быть оценена вероятность действия сценариев инцидентов.

Руководство по реализации: После идентификации сценариев инцидентов необходимо оценить вероятность каждого сценария и возникающее влияние, используя качественные или количественные методы оценки.

Здесь нужно учитывать тот факт, как часто возникают угрозы и насколько легко могут быть использованы уязвимости, рассматривая:

— опыт и применимую статистику вероятности угроз;

— для источников умышленных угроз: мотивацию и возможности, которые будут меняться с течением времени, и доступные для возможных нарушителей ресурсы, а также восприятие привлекательности и уязвимости активов возможным нарушителем;

— для источников случайных угроз: географические факторы, например, близость к химическому или нефтеперерабатывающему заводу, возможность экстремальных погодных условий и факторы, которые могут оказывать влияние на ошибки персонала и сбои оборудования;

— уязвимости в индивидуальном плане и в совокупности;

— существующие средства контроля и то, насколько эффективно они снижают уязвимости.

Выходные данные: Перечень сценариев инцидентов с количественной или качественной оценкой вероятности их реализации.

2.2.4. Измерение уровня риска

Входные данные: Перечень сценариев инцидентов с их последствиями, касающимися активов, и бизнес-процессов и их вероятности (количественных или качественных).

Действие: Должно быть осуществлено измерение уровня рисков для всех значимых сценариев инцидентов.

При измерении риска присваиваются значения вероятности и последствий риска. Эти значения могут быть качественными или количественными. Измерение риска основывается на оценённых последствиях и вероятности. Измеренный риск является комбинацией вероятности нежелательного сценария и его последствий.

Для примера идентифицируем значения ценности активов, используя числовую шкалу от 0 до 4. Следующим шагом идентифицируем каждый вид угрозы, каждую группу активов, с которой связан данный вид угрозы, чтобы сделать возможной оценку уровней угроз и уровней уязвимостей.

Ценность активов, уровни угроз и уязвимостей приводим к табличной форме (матрице), чтобы для каждой комбинации идентифицировать соответствующую меру риска на основе шкалы от 0 до 8. Значения заносятся в матрицу структурированным образом.

Для каждого актива рассматриваются уязвимости и соответствующие им угрозы. Теперь соответствующая строка в таблице устанавливает значение ценности актива, а соответствующая колонка — вероятность возникновения угрозы и уязвимости. Например, если актив имеет ценность 3, угроза является «высокой», а уязвимость «низкой», то мера риска будет равна 5.

Аналогичная матрица является результатом рассмотрения вероятности сценария инцидента с учетом влияния на бизнес. Получаемый в результате риск измеряется по шкале от 0 до 8 и может быть оценён по отношению к критериям принятия риска.

Таблица может быть использована также, чтобы связать факторы последствий для активов с вероятностью возникновения угрозы (принимая в расчёт аспекты уязвимости). Первый шаг состоит в оценивании последствий для активов по заранее определённой шкале, например, от 1 до 5, для каждого находящегося под угрозой актива (колонка 2). Второй шаг состоит в оценивании вероятности возникновения угрозы по заранее определённой шкале, например, от 1 до 5, для каждой угрозы (колонка 3).

Третий шаг состоит в вычислении меры риска путём умножения значений колонок 2 и 3. Наконец, угрозы могут быть ранжированы в порядке соответствующей меры риска. Отметим, что значение «1» в колонках 2 и 3 соответствует наименьшим последствиям и вероятности угрозы, а в колонке 5 — наибольшей опасности.

Выходные данные: Перечень рисков с присвоенными уровнями значений.

2.3. Оценивание риска

Входные данные: Перечень рисков с присвоенными уровнями значений и критерии оценки риска.

Действие: Уровень риска должен сравниваться с критериями оценивания и принятия риска.

Руководство по реализации: Характер решений, относящихся к оцениванию риска, и критерии оценивания риска, которые будут использованы для принятия этих решений, должны были быть определены при установлении сферы применения СУИБ. Для оценивания рисков должны сравниваться измеренные риски с критериями оценивания риска, выбранными на 1-м этапе управления рисками ИБ.

Критерии оценивания риска, используемые для принятия решений, должны согласовываться с определённой сферой применения СУИБ и принимать в расчёт цели организации, мнения заинтересованных сторон и т. д. Решения, связанные с оценкой риска, обычно основываются на его приемлемом уровне. Совокупность множества рисков низкого и среднего уровня может дать в итоге общий риск более высокого уровня.

При этом следует учесть следующее:

— свойства ИБ — если один критерий не актуален для организации (например, потеря конфиденциальности), то все риски, влияющие на этот критерий, могут быть также не актуальными;

— значимость бизнес-процесса, поддерживаемого конкретным активом или их совокупностью — если процесс определён как имеющий низкую значимость, связанные с ним риски должны рассматриваться в меньшей степени, чем риски, влияющие на более важные процессы.

Оценивание риска основывается на понимании сути риска, полученном на этапе его анализа, для принятия решений о будущих действиях. Решения должны включать в себя следующее:

— должны ли быть предприняты какие-то действия;

— приоритеты при обработке риска, учитывающие измеренные уровни рисков.

Выходные данные: Перечень рисков с назначенными приоритетами в соответствии с критериями оценки риска в отношении сценариев инцидентов, которые приводят к этим рискам.

3. Обработка рисков ИБ

Входные данные: Перечень рисков с назначенными приоритетами в соответствии с критериями оценки риска в отношении сценариев инцидентов, которые приводят к этим рискам.

Действие: Должен быть осуществлен выбор варианта обработки рисков, соответствующих мер и средства защиты, и разработан план обработки рисков.

Руководство по реализации:

Обработку риска обеспечивают следующие меры:

— поиск решений;

— выбор варианта обработки;

— реализация обработки;

— оценка остаточного риска.

Предусмотрены следующие варианты обработки риска:

— снижение;

— сохранение;

— избежание (предотвращение);

— перенос.

Вариант обработки риска должен выбираться на основе результатов оценки риска, ожидаемой стоимости реализации и выгоды от этого варианта. Выбирается тот вариант, когда значительное снижение риска может быть достигнуто при относительно небольших затратах. Неблагоприятные последствия риска необходимо снижать до разумных пределов и независимо от каких-либо абсолютных критериев.

Некоторые виды обработки рисков могут быть эффективными для более, чем одного риска (например, обучение и осведомлённость персонала). План обработки риска должен чётко определять порядок приоритетов, в котором должна реализовываться обработка отдельных рисков. Порядок приоритетов может устанавливаться с использованием различных методов, включая ранжирование рисков и анализ соотношения «затраты — выгода».

Идентификация существующих средств защиты может определять те средства, которые превышают текущую потребность также и с точки зрения сравнения затрат, включая поддержку. Если рассматривается удаление избыточных или ненужных средств защиты (особенно, если расходы на поддержку этих средств контроля велики), должны приниматься во внимание факторы ИБ и стоимости. Поскольку средства защиты оказывают влияние друг на друга, исключение избыточных средств может в итоге снизить эффективность использования всех оставшихся средств защиты.

Варианты обработки риска должны учитывать:

— как риск осознается сторонами, которых он касается;

— наиболее соответствующие пути взаимоотношений с этими сторонами.

После того как определён план обработки риска, необходимо определить остаточные риски. Это включает обновление или повторную операцию оценки риска, принимая во внимание ожидаемый эффект от предполагаемой обработки риска. Если остаточные риски по-прежнему не будут удовлетворять критериям принятия риска организации, может возникнуть необходимость дальнейшего процесса обработки риска, прежде чем перейти к принятию риска.

Выходные данные: План обработки риска и остаточные риски — предмет обсуждения для принятия решения руководством организации.

3.1. Снижение риска

Действие: Уровень риска должен быть снижен выбором таких средств защиты, чтобы остаточный риск был оценён как приемлемый.

Руководство по реализации: Средства управления рисками могут обеспечивать одну или несколько следующих функций: контроль, предупреждение, сдерживание, снижение, исправление, предотвращение.

Во время выбора средств важно «взвешивать» стоимость их приобретения, реализации, функционирования, администрирования, мониторинга и поддержки по отношению к ценности защищаемых активов. Кроме того, рентабельность инвестиций с точки зрения снижения риска, и потенциал для использования новых возможностей бизнеса, предоставляемых определёнными средствами защиты.

Существует много ограничений, которые могут влиять на выбор средств. Технические ограничения, такие как требования к функционированию, вопросы управляемости (требования операционной поддержки) и совместимости могут препятствовать использованию определённых средств защиты или могут вводить ошибку персонала, или аннулирующую средство защиты, вселяя ложное чувство безопасности, или даже увеличивающую риск, по отношению к тому как если бы не имелось никакого средства защиты (например, требования использования сложных паролей без соответствующего обучения, что может привести к записи паролей пользователями).

Более того, может произойти так, что средства защиты будут влиять на производительность. Менеджеры должны работать над идентификацией решения, которое удовлетворяет требованиям производительности, в то же время гарантирует достаточную ИБ. Результатом этого первого шага является перечень возможных средств защиты с их стоимостью, выгодой и приоритетом реализации.

При формировании рекомендаций и реализации средств защиты должны приниматься в расчёт различные ограничения: операционные, эксплуатационные, технические, временные и кадровые, финансовые, юридические, культурные, этические и экологические.

Операционные ограничения

Операционные ограничения, такие как потребность круглосуточной работы, производя при этом резервное копирование, могут приводить к сложной и дорогостоящей реализации средств защиты, если они не встраиваются в проект с самого начала.

Эксплуатационные ограничения

Неудобный интерфейс «человек-машина» будет вызывать ошибки персонала и может приводить к инцидентам. Средства защиты должны выбираться с целью обеспечения оптимальной простоты использования наряду с достижением приемлемого уровня остаточного риска для бизнеса. Применение средств защиты, которые трудно использовать, будет влиять на их эффективность, так как пользователи могут пытаться обходить или игнорировать их, насколько это возможно.

Технические ограничения

Реализация средств защиты для существующих информационных процессов или систем может затрудняться несовместимостью аппаратного или ПО. Новые средства управления могут быть не реализованы при наличии несовместимости с существующими.

Например, план использования биометрии для физического контроля доступа может вступать в конфликт с существующей системой управления доступом, основанной на наборе ПИН-кода. Стоимость перехода на новые средств защиты должна включать элементы, которые будут добавляться к общим расходам на обработку риска.

Временные ограничения

Например, средства защиты должны быть реализованы в течение срока предоставления услуг или использования системы или информации. Может быть период времени, который руководители организации считают подходящим для подверженности определённому риску.

Кадровые ограничения

Следует учитывать затраты на оплату совокупности специальных навыков для реализации и управления средствами защиты, а также возможность перемещения персонала на разные площадки при неблагоприятных рабочих условиях. Другие аспекты, такие как дискриминация одними членами персонала других, не проходивших проверку мастерства и благонадёжности, могут иметь важные следствия для политик безопасности и практических приёмов обеспечения безопасности. Требование проведения такой проверки до оформления найма представляет собой нормальную и наиболее безопасную практику.

Финансовые ограничения

Должны прилагаться все усилия, чтобы не превысить установленный бюджет и достичь финансовой выгоды благодаря использованию средств защиты. Однако в некоторых случаях может не быть возможности достичь желаемой безопасности и уровня принятия риска из-за бюджетных ограничений.

Юридические ограничения

Обеспечение соответствия действующему законодательству может предписывать определённые виды средств защиты, включая обеспечение защиты персональных данных и финансовый аудит, но может также не допускать использования других средств, например, шифрования.

Культурные ограничения

Не все средства защиты могут применяться во всех странах. Например, возможно реализовать досмотр сумок в странах Европы, но не в странах Ближнего Востока. Культурные ограничения нельзя игнорировать, потому что многие средства контроля зависят от активной поддержки персонала.

Этические ограничения

Этические ограничения могут препятствовать реализации таких средств защиты, как сканирование сообщений электронной почты персонала или видеонаблюдение за ним. Секретность информации может также меняться в зависимости от этических принципов региона или правления. Они могут больше касаться одних секторов индустрии, но не касаться других, например, правительства и здравоохранения.

Экологические ограничения

Факторы окружающей среды, такие как климатические условия, окружающая природная и городская география, могут влиять на выбор средств защиты. Например, обеспечение сейсмостойкости может быть необходимым в некоторых странах, но ненужным в других.

3.2. Сохранение риска

Если уровень риска соответствует критериям принятия риска, то нет необходимости реализовывать дополнительные средства контроля и риск может быть сохранен.

3.3. Предотвращение риска

Когда идентифицированные риски считаются слишком высокими или расходы на реализацию других вариантов обработки риска превышают выгоду, может быть принято решение об отказе от деятельности или изменении условий, при которых проводится эта деятельность.

Например, в отношении рисков, вызываемых стихийными бедствиями, наиболее выгодной альтернативой может быть физическое перемещение средств обработки информации туда, где этот риск не существует.

3.4. Перенос риска

Перенос риска — это передача риска сторонней организации, которая может наиболее эффективно управлять им. Перенос риска может создавать новые риски или модифицировать существующие, поэтому может быть необходима дополнительная обработка риска.

Перенос может быть осуществлён с помощью страхования, которое будет поддерживать последствия, или заключения договора с внешней организацией для проведения мониторинга системы и предотвращения угрозы, прежде чем она приведёт к ущербу.

4. Принятие риска ИБ

Входные данные: План обработки риска и оценка остаточного риска являются объектами решения руководства организации о принятии риска.

Действие: Должно быть принято и формально зарегистрировано решение о принятии рисков и ответственности за это решение.

Руководство по реализации: После обработки риска необходимо определить остаточные риски и осуществить принятие риска. Если остаточные риски удовлетворяют критериям принятия риска организации, руководство принимает решение о принятии риска.

Если остаточные риски не удовлетворяют критериям принятия риска организации, возможны следующие варианты решения руководства:

— дальнейшая обработка риска до снижения его уровня до приемлемого;

— принятие риска с обязательным обоснованием такого решения.

Выходные данные: Перечень принятых рисков с обоснованием тех рисков, которые не соответствуют критериям принятия риска.

5. Обмен информацией о рисках

Входные данные: Вся информация о рисках, полученная в результате управления рисками.

Действие: Принимающие решение представители организации и внешних организаций должны обмениваться информацией о рисках и совместно ее использовать.

Руководство по реализации: Обмен информацией о рисках представляет собой деятельность, связанную с достижением соглашения всех участвующих сторон о том, как осуществлять совместное управление рисками путём использования всей известной информации о рисках.

Обмен информацией будет обеспечивать уверенность в том, что все участвующие стороны понимают, на основании чего принимаются решения и причины необходимости определённых действий. Необходимо обеспечить, чтобы осознание риска всеми сторонами, а также осознание ими выгод могло быть идентифицировано и задокументировано, а лежащие в основе причины были чётко поняты и учтены.

Обмен информацией должен осуществляться с целью достижения:

— обеспечения доверия к результатам управления рисками;

— сбора информации о рисках;

— совместного использования результатов оценки рисков и представления плана их обработки;

— предотвращения или снижения вероятности возникновения и последствий нарушений ИБ из-за отсутствия взаимопонимания между сторонами;

— поддержки принятия решений;

— получения новых знаний об ИБ;

— координации действий по реагированию для уменьшения последствий какого-либо инцидента;

— выработки чувства ответственности сторон по отношению к рискам;

— повышения осведомлённости.

Координация сторон может быть достигнута посредством формирования соответствующих коллегиальных органов (комитетов), на заседании которых могут проходить обсуждения вопросов о рисках и выработке решений по обработке и принятию рисков.

Выходные данные: Постоянное понимание и координация процесса управления рисками ИБ.

6. Мониторинг и улучшение

Цель мониторинга рисков состоит в наблюдении за прогрессом выполнения принятых планов (предотвращения рисков и смягчения их последствий), количественными параметрами, условиями, определяющими применение плана обработки рисков, и в информировании ответственных лиц в случае наступления риска.

Мониторинг рисков — процесс отслеживания идентифицированных рисков, мониторинга остаточных рисков, идентификации новых рисков, исполнения плана обработки рисков и оценки его эффективности. Непрерывный мониторинг может поддерживаться внешними сервисами, которые обеспечивают информацию о новых угрозах или уязвимостях.

Необходимо проводить непрерывный мониторинг следующих факторов:

— новые активы, которые были включены в сферу действия управления рисками;

— изменение ценности активов, например, вследствие изменившихся бизнес-требований;

— новых угроз, которые могут быть активными вне и внутри организации, и которые ещё не оценивались;

— вероятности того, что новые или увеличившиеся уязвимости могут позволить угрозам их использовать;

— идентифицированные уязвимости для определения тех уязвимостей, которые становятся подверженными новым или повторно возникающим угрозам;

— повышенное влияние последствий оценённых угроз, уязвимостей и рисков, объединение которых имеет результатом неприемлемый уровень риска;

— инциденты ИБ.

Мониторинг рисков важен для эффективной реализации действий, запланированных на предыдущих этапах. Он обеспечивает своевременное исполнение превентивных мер и планов по смягчению последствий и выполняется с помощью признаков, указывающих на возможность то, что события риска произошли или произойдут в ближайшее время.

Примеры параметров, к которым могут быть привязаны признаки рисков и за которыми может проводиться мониторинг:

— количество «открытых» (найденных и неисправленных) ошибок системы;

— среднее за неделю количество сверхурочных часов работы на одного сотрудника;

— еженедельное количество изменений в требованиях к разрабатываемой системе;

— изменения бизнес-процессов;

— своевременность выделения требуемых ресурсов;

— техническое обеспечение работ.

Мониторинг и улучшение рисков является последним этапом управления рисками и включет следующие мероприятия:

— мониторинг и пересмотр рисков;

— анализ и улучшение управления рисками.

6.1. Пересмотр рисков

Входные данные: Вся информация о рисках, полученная в результате управления рисками.

Действие: Риски и их факторы (ценность активов, угрозы, уязвимости, вероятность риска) должны подвергаться мониторингу и пересмотру с целью идентификации любых изменений на ранней стадии.

Руководство по реализации: Пересмотр рисков должен проводиться регулярно, согласно расписанию, составленному на этапе планирования. В процессе мониторинга рисков может возникать необходимость в проведении идентификации новых рисков, пересмотре состояния известных рисков и планировании дополнительных мероприятий по обработке рисков.

Выходные данные: Непрерывное согласование управления рисками с бизнес-целями и критериями принятия риска.

6.2. Анализ и улучшение

Входные данные: Вся информация о рисках, полученная в результате управления рисками.

Действие: Процесс управления рисками должен постоянно подвергаться анализу и улучшению.

Руководство по реализации: Постоянный анализ необходим для обеспечения уверенности в том, что результаты оценки и обработки рисков, а также план обработки рисками соответствуют реальным обстоятельствам. Необходимо регулярно проверять, что критерии измерения риска и его элементов по-прежнему остаются действительными и согласующимися с бизнес-целями, стратегиями и политиками ИБ.

Эта деятельность должна уделять внимание:

— правовой сфере и условиям окружающей среды;

— сфере конкуренции;

— подходу к оценке риска;

— ценности и категориям активов;

— критериям влияния на активы и процессы;

— критериям оценки риска;

— критериям принятия риска;

— полной стоимости эксплуатации активов;

— необходимым ресурсам.

Организация должна обеспечивать уверенность в том, что ресурсы оценки и обработки рисков постоянно доступны для пересмотра рисков, рассмотрения новых или изменившихся угроз и уязвимостей и соответствующего уведомления руководства.

Анализ должен обеспечить изменение или улучшение подхода, методологии или инструментальных средств, используемых в зависимости от:

— идентифицированных изменений;

— итерации оценки риска;

— цели процесса управления рисками (например, непрерывность бизнеса, устойчивость к инцидентам, совместимость);

— объекта процесса управления рисками (например, организация, бизнес-подразделение, информация, приложение, подключение к Интернет).

Выходные данные

Непрерывная значимость процесса управления рисками ИБ для бизнес-целей организации.