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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• персонал;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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