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

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

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

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

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

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

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

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

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. Процесс управления рисками может настраиваться под потребности конкретной организации. Для успешной оценки и управления рисками необходимо собирать информацию из различных источников в организации.