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

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

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

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

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

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

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)