Следует отметить, что СТО БР ИББС-2.2-2009 - отличный документ. В этой связи его вполне могут взять на вооружение и не только "организации БС РФ", но и все желающие. Тем не менее, есть здесь ряд моментов, по поводу которых хочется пофантазировать
Несколько слов о подходе,а также, чтобы обозначить терминологию.
1. Определяется перечень информационных активов. Это, фактически, классификация информации:
- информация ограниченного доступа,
- открытая;
- т.п., в зависимости от того, кто как желает классифицировать и с какой степенью детализации.
По каждому информационному активу определяется перечень свойств ИБ, которые необходимо защищать, предлагается классика:
- конфиденциальность,
- целостность,
- доступность.
Любопытно, что в документе пример дается исключительно про классификацию по конфиденциальности (ограниченная, открытая), однако свойства предлагаются все (КЦД) :-). Поэтому разумно в классификации учитывать эти свойства, скажем:
- информация, критичная к нарушению конфиденциальности,
- информация, не конфиденциальная, но где должна быть прогарантирована целостность и доступность,
и т.п.
2. Определяется перечень типов объектов среды для каждого информационного актива. По сути - это те места/контейнеры, где располагаются информационные активы, примеры:
- сети передачи данных,
- серверы,
- файлы,
- т.п.
Исчерпывающий, на мой взгляд, список приведен в разделе 4.5. документа.
3. Для каждого объекта среды определяются источники угроз и свойство ИБ на которое он воздействует. Перечень источников угроз приведен в приложении 1, необходима очень развитая фантазия, чтобы туда что-то добавить - надо брать за основу.
4. Определяются два ключевых момента:
- степень возможности реализации угрозы (СВР), что по сути является вероятностью того, что выявленный источник угрозы будет негативно воздействовать на объект среды,
Рекомендуемая шкала оценки СВР:
-- нереализуемая,
-- минимальная,
-- средняя,
-- высокая,
-- критическая,
- степень тяжести последствий (СТП) от потери свойств ИБ, что фактически является ущербом.
Рекомендуемая шкала для СТП:
-- минимальная,
-- средняя,
-- высокая,
-- критическая,
В СТП и СВР надо(*) заложить какие-либо числа, тогда оценка рисков станет количественной. Пример приведен в разделе 6.
Как на основании СВР и СТП принять решение о материальности риска дает ответ таблица 1. Предлагаю ее брать в этом виде.
В документе приведены хорошие приложения, содержащие прототипы табличек, которыми можно пользоваться для документирования процесса оценки рисков.
Основное волшебство заключается в определение СВР и СТП. Надо помнить, что анализ рисков делается не просто чтобы определить стоимость риска, а также придумать контроли, как эти риски снижать до приемлемого уровня, причем, чтобы стоимость контролей была экономически оправдана (для этого я написал надо(*) ). Поэтому важно понять, на что мы можем влиять.
А влиять мы можем:
1. полностью на СВР, поскольку накручивая базовые контроли безопасности - требования к обеспечению безопасности сетевого периметра, требования по безопасной конфигурации стандартных подсистем (ОС, СУБД, сервера приложений, сетевое оборудование, т.п.), требования к типовым операционным сервисам (управление изменениями, управление патчами, т.п.), требования к проектированию информационных систем (чтобы уже сразу при проектировании проектировалась и безопасность, что сделает ее интегрированной, а следовательно, более эффективной) - мы уже значительно снижаем наши СВР для тех или иных источников угроз. Тут, как мне кажется, на N+1-ом случае фиксации одного и того же риска следует задуматься о реализации соответствующего контроля на уровне базовых контролей ИБ. В конечном счете надо стремиться к тому, что под анализ рисков попадают только специфичные для данной системы контроли ИБ, - не надо всякий раз указывать баяны и изобретать велосипед. Отсюда следствие, что так или иначе все "стандартные" контроли рано или поздно выдавятся в инфраструктуру, а для анализа останется тот "сухой остаток", сильно специфичный для системы.
2. на СТП - в части стоимости восстановления после инцидента (ликвидации последствия нарушения ИБ, - как это указано в документе). Если превентивных контролей ИБ (априорные защитные меры, как это указано в документе) недостаточно или они нерентабельны, то можно посмотреть в сторону реактивных контролей (апостериорные защитные меры, как это называется в документе) - т.е. заняться вопросами DRP&BCP. Опять же надо следить за рентабельностью контролей.
Подытожим план:
1. Проанализировать циркулирующую информацию, критичность ее по основным свойствам, источники угроз, выявить СВР и СТП на текущий момент. Определить контроли.
2. Понять, какие контроли постоянно востребованы и унести их инфраструктуру и базовое ИТ.
3. Всякий раз при оценке рисков анализировать что можно унести в инфраструктуру, чтобы сконцентрировать процесс анализа рисков максимально на специфических для системы рисках и контролях, которые нерентабельно реализовывать глобально в базовом ИТ.
Несколько слов о подходе,а также, чтобы обозначить терминологию.
1. Определяется перечень информационных активов. Это, фактически, классификация информации:
- информация ограниченного доступа,
- открытая;
- т.п., в зависимости от того, кто как желает классифицировать и с какой степенью детализации.
По каждому информационному активу определяется перечень свойств ИБ, которые необходимо защищать, предлагается классика:
- конфиденциальность,
- целостность,
- доступность.
Любопытно, что в документе пример дается исключительно про классификацию по конфиденциальности (ограниченная, открытая), однако свойства предлагаются все (КЦД) :-). Поэтому разумно в классификации учитывать эти свойства, скажем:
- информация, критичная к нарушению конфиденциальности,
- информация, не конфиденциальная, но где должна быть прогарантирована целостность и доступность,
и т.п.
2. Определяется перечень типов объектов среды для каждого информационного актива. По сути - это те места/контейнеры, где располагаются информационные активы, примеры:
- сети передачи данных,
- серверы,
- файлы,
- т.п.
Исчерпывающий, на мой взгляд, список приведен в разделе 4.5. документа.
3. Для каждого объекта среды определяются источники угроз и свойство ИБ на которое он воздействует. Перечень источников угроз приведен в приложении 1, необходима очень развитая фантазия, чтобы туда что-то добавить - надо брать за основу.
4. Определяются два ключевых момента:
- степень возможности реализации угрозы (СВР), что по сути является вероятностью того, что выявленный источник угрозы будет негативно воздействовать на объект среды,
Рекомендуемая шкала оценки СВР:
-- нереализуемая,
-- минимальная,
-- средняя,
-- высокая,
-- критическая,
- степень тяжести последствий (СТП) от потери свойств ИБ, что фактически является ущербом.
Рекомендуемая шкала для СТП:
-- минимальная,
-- средняя,
-- высокая,
-- критическая,
В СТП и СВР надо(*) заложить какие-либо числа, тогда оценка рисков станет количественной. Пример приведен в разделе 6.
Как на основании СВР и СТП принять решение о материальности риска дает ответ таблица 1. Предлагаю ее брать в этом виде.
В документе приведены хорошие приложения, содержащие прототипы табличек, которыми можно пользоваться для документирования процесса оценки рисков.
Основное волшебство заключается в определение СВР и СТП. Надо помнить, что анализ рисков делается не просто чтобы определить стоимость риска, а также придумать контроли, как эти риски снижать до приемлемого уровня, причем, чтобы стоимость контролей была экономически оправдана (для этого я написал надо(*) ). Поэтому важно понять, на что мы можем влиять.
А влиять мы можем:
1. полностью на СВР, поскольку накручивая базовые контроли безопасности - требования к обеспечению безопасности сетевого периметра, требования по безопасной конфигурации стандартных подсистем (ОС, СУБД, сервера приложений, сетевое оборудование, т.п.), требования к типовым операционным сервисам (управление изменениями, управление патчами, т.п.), требования к проектированию информационных систем (чтобы уже сразу при проектировании проектировалась и безопасность, что сделает ее интегрированной, а следовательно, более эффективной) - мы уже значительно снижаем наши СВР для тех или иных источников угроз. Тут, как мне кажется, на N+1-ом случае фиксации одного и того же риска следует задуматься о реализации соответствующего контроля на уровне базовых контролей ИБ. В конечном счете надо стремиться к тому, что под анализ рисков попадают только специфичные для данной системы контроли ИБ, - не надо всякий раз указывать баяны и изобретать велосипед. Отсюда следствие, что так или иначе все "стандартные" контроли рано или поздно выдавятся в инфраструктуру, а для анализа останется тот "сухой остаток", сильно специфичный для системы.
2. на СТП - в части стоимости восстановления после инцидента (ликвидации последствия нарушения ИБ, - как это указано в документе). Если превентивных контролей ИБ (априорные защитные меры, как это указано в документе) недостаточно или они нерентабельны, то можно посмотреть в сторону реактивных контролей (апостериорные защитные меры, как это называется в документе) - т.е. заняться вопросами DRP&BCP. Опять же надо следить за рентабельностью контролей.
Подытожим план:
1. Проанализировать циркулирующую информацию, критичность ее по основным свойствам, источники угроз, выявить СВР и СТП на текущий момент. Определить контроли.
2. Понять, какие контроли постоянно востребованы и унести их инфраструктуру и базовое ИТ.
3. Всякий раз при оценке рисков анализировать что можно унести в инфраструктуру, чтобы сконцентрировать процесс анализа рисков максимально на специфических для системы рисках и контролях, которые нерентабельно реализовывать глобально в базовом ИТ.
