«Петренко С. А. ...»

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

Пример оценки рисков по трем факторам

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

Сначала определим уровни угроз, уязвимостей, тяжести последствий и рисков. Уровни угроз:

• низкий (Н) - реализация данной угрозы маловероятна, за последние два года подобных случаев не зафиксировано;
• средний (С) - угроза может реализоваться в течение одного года с вероятностью около 0,3;
• высокий (В) - угроза, скорее всего, реализуется в течение года и, возможно, не один раз.

Уровни уязвимостей:

• низкий (Н) - защищенность системы очень высока, реализация угроз почти никогда не приводит к происшествию;
• средний (С) - защищенность системы средняя, реализация около 30% угроз приводит к происшествию;
• высокий (В) - защищенность системы низкая, реализация угрозы практически всегда приводит к происшествию.

Показатель негативного воздействия (тяжесть последствий)

210Используем введенную в главе 2 классификацию последствий:

11) Negligible (менее $100).

12) Minor (менее $1000).

13) Moderate (менее $10 000).

14) Serious (существенное негативное влияние на бизнес).

15) Critical (катастрофическое воздействие, возможно прекращение функционирования системы).

Уровни рисков

Показатель риска измеряется по шкале от 0 до 8, уровни риска определяются следующим образом:

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

2 - риск незначителен. Событие наступает редко, последствия (потери) находятся в допустимых пределах (не более 1000 долларов);

…

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

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

Таблица 3.6. Определение уровня риска в зависимости от уровней угроз и уязвимостей

Уровень угрозы
низкий			средний				высокий
Уровни уязвимости			Уровни уязвимости				Уровни уязвимости
Н	С	В		Н	С	В		Н	С	В
2	3	4		3	4	5		4	5	6

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

 Методика анализа рисков Microsoft

В качестве возможного примера корпоративной методики анализа рисков рассмотрим методику компании Microsoft.

В методике риск определяется как возможность понести убытки из-за нарушения безопасности сети изнутри или извне. Управление рисками предприятия в сфере информационной безопасности требует выполнения четырех этапов:

31617) Распознавание (идентификация) рисков.

18) Определение размера риска.

19) Разработка плана управления рисками.

20) Текущий контроль и управление рисками.

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

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

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

Предлагаемая Microsoft стратегия оценки рисков включает следующие этапы:

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

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

Таблица 3.7. Табличная оценка риска в зависимости от факторов

Вероятность			Стоимость
		высокая		средняя		низкая
Высокая		Красная		Красная		Синяя
Средняя		Желтая		Желтая		Зеленая
Низкая		Синяя		Синяя		Зеленая

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

• высокий риск (красная область). Предполагается, что без снижения таких рисков обращение к информационной системе предприятия может оказать отрицательное влияние на бизнес;
• существенный риск (желтая область). Здесь требуется эффективная стратегия управления рисками, которая позволит уменьшить или полностью исключить отрицательные последствия нападения;
• умеренный риск (синяя область). В отношении рисков, попавших в эту область, достаточно применить основные процедуры управления рисками;
• незначительный риск (зеленая область). Усилия по управлению рисками в данном случае не будут играть важной роли.

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

Планирование заключается в следующем:

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

Выделяются четыре составные части планирования управления рисками:

• исследование;
• принятие (можно ли принять данный риск?);
• управление (можно ли сделать что-то, чтобы уменьшить риск?);
• исключение (что можно сделать, чтобы предотвратить риск или блокировать его?).

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

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

Глава  
Инструментальные средства анализа рисков

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

В России в настоящее время чаще всего используются разнообразные «бумажные» методики, достоинствами которых являются гибкость и адаптивность. Как правило, разработкой данных методик занимаются компании - системные и специализированные интеграторы в области защиты информации. По понятным причинам методики обычно не публикуются, поскольку относятся к «know how» компании. В силу закрытости данных методик судить об их качестве, объективности и возможностях достаточно сложно.

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

Предлагаемое на рынке ПО ориентировано в основном на уровень информационной безопасности, несколько превышающий базовый уровень защищенности. Таким образом, инструментарий рассчитан в основном на потребности организаций 3-4 степени зрелости, описанных в первой главе.

В 2000 году принят международный стандарт ISO 17799, за основу которого взят британский стандарт BS 7799. В результате большинство инструментальных средств (ПО анализа риска) было в последнее время модифицировано так, чтобы обеспечить соответствие требованиям именно этого стандарта. Рассмотрим специализированное ПО, условно разделив его на две группы: ПО базового уровня и ПО полного анализа рисков.

 Инструментарий базового уровня

Прежде всего обсудим инструментарий, соответствующий ISO 17799:

• справочные и методические материалы;
• ПО анализа рисков и аудита Cobra

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

 Справочные и методические материалы

Некоторые британские фирмы предлагают следующие продукты:

• политику информационной безопасности (Information Security Police)>
• гипертекстовые справочники по вопросам защиты информации (SOS -INTERACTIVE "ONLINE" SECURITY POLICIES AND SUPPORT);
• руководства для сотрудников служб безопасности (Security Professionals Guide).

Эти продукты представляют собой справочники, посвященные практическим аспектам реализации политики безопасности в соответствии с ISO 17799 (вид справочника приводится на рис. 4.1). Демонстрационные версии (Evaluation version) можно загрузить с сайта [341].

Рис. 4.1. Справочник для разработки политики безопасности

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

Еще один продукт подобного рода - руководство по применению стандарта ISO 17799 (THE ISO 17799 TOOLKIT), текст стандарта ISO 17799 с комплектом методических материалов по его применению и презентацией.

 COBRA

Программный продукт для анализа и управления рисками COBRA [348], производитель - С & A Systems Security Ltd., позволяет формализовать и ускорить процесс проверки на соответствие режима информационной безопасности требованиям Британского стандарта BS 7799 (ISO 17799) и провести простейший анализ рисков. Имеется несколько баз знаний: общие требования BS 7799 (ISO 17799) и специализированные базы, ориентированные на различные области применения. Доступна демонстрационная версия этого ПО.

COBRA позволяет представить требования стандарта в виде тематических «вопросников» по отдельным аспектам деятельности организации (см. пример на рис. 4.2).

Рис. 4.2. Анализ рисков с использованием ПО Cobra

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

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

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

 RA Software Tool

Еще один метод, условно относящийся к базовому уровню, - RA Software Tool [349] - базируется на британском стандарте BS 7799, части 1 и 2, на методических материалах Британского института стандартов (BSI) PD 3002 (Руководство по оценке и управлению рисками), PD 3003 (Оценка готовности компании к аудиту в соответствии с BS 7799), PD 3005 (Руководство по выбору системы защиты), а также стандарте ISO 13335, части 3 и 4 (Руководство по управлению режимом информационной безопасности, технологии управления безопасностью и выбор средств защиты). Основные модули метода перечислены на рис. 4.3.

Рис. 4.3. Модули RA Software Tool

Этот инструментарий позволяет выполнять оценку рисков (модули 4 и 5) в соответствии как с требованиями базового уровня, так и с более детальными спецификациями PD 3002 Британского института стандартов.

Каждый из модулей разбивается на ряд шагов.

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

 Средства полного анализа рисков

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

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

Программные средства, позволяющие провести полный анализ рисков, создаются с использованием структурных методов системного анализа и проектирования (SSADM - Structured Systems Analysis and Design) и относятся к категории средств автоматизации разработки или CASE-средств (Computer Aided System Engineering).

Такие методы представляют собой инструментарий для:

• построения модели ИС с позиции ИБ;
• оценки ценности ресурсов;
• составления списка угроз и оценки их вероятностей;
• выбора контрмер и анализа их эффективности;
• анализа вариантов построения защиты;
• документирования (генерации отчетов).

Один из наиболее известных продуктов этого класса, CRAMM, рассмотрен в следующем разделе.

 Метод CRAMM

История создания метода

В 1985 году Центральное агентство по компьютерам и телекоммуникациям (ССТА) Великобритании начало исследования существующих методов анализа ИБ, чтобы рекомендовать методы, пригодные для использования в правительственных учреждениях, занятых обработкой несекретной, но критичной информации. Ни один из рассмотренных методов не подошел. Поэтому был разработан новый метод, соответствующий требованиям ССТА Он получил название CRАММ - метод ССТА анализа и контроля рисков. Затем появилось несколько версий метода, ориентированных на требования Министерства обороны, гражданских государственных учреждений, финансовых структур, частных организаций, Одна из версий, «коммерческий профиль», представляет собой коммерческий продукт.

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

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

CRAMM, судя по числу ссылок в Internet, - самый распространенный метод анализа рисков и управления ими.

В настоящее время продается версия CRAMM 5 [350], соответствующая стан-дарту BS 7799 (ISO 17799).

Концепция, положенная в основу метода

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

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

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

• все возможные риски идентифицированы;
• уязвимости ресурсов идентифицированы и их уровни оценены;
• угрозы идентифицированы и их уровни оценены;
• контрмеры эффективны;
• расходы, связанные с ИБ, оправданы.

Исследование ИБ системы с помощью CRAMM проводится в несколько этапов (рис. 4.4).

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

На стадии идентификации и оценки ресурсов, Identification and Valuation of Assets, описывается и анализируется все, что касается идентификации и определения

Рис. 4.4. Основные этапы метода CRAMM

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

Стадия оценивания угроз и уязвимостей, Threat and Vulnerability Assessment, не является обязательной, если заказчика удовлетворит базовый уровень информационной безопасности. Эта стадия выполняется при проведении полного анализа рисков. Принимается во внимание все, что относится к идентификации и оценке уровней угроз для групп ресурсов и их уязвимостей. В конце стадии заказчик получает идентифицированные и оцененные уровни угроз и уязвимостей для своей системы.

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

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

Каждая стадия объявляется законченной после детального обсуждения и согласования результатов с заказчиком.

 Пример использования метода CRAMM

Возможности метода лучше всего продемонстрировать на небольшом примере. Рассмотрим рис. 4.5 - информационную систему поддержки принятия решений аварийно-спасательной службы.

Система состоит из следующих элементов:

• рабочие места, с которых операторы вводят информацию, поступающую по телефонам, радиоканалам и др.;
• почтовый сервер, куда информация приходит с удаленных узлов ведомственной сети и через Internet;
• сервер обработки, на котором установлена СУБД и производится автоматизированный анализ текущей ситуации;

Рис. 4.5. Информационная система для поддержки принятия решений

• сервер резервного копирования;
• рабочие места группы оперативного реагирования;
• рабочее место администратора безопасности;
• рабочее место администратора БД.

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

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

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

Определение границ исследования

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

Идентификация ресурсов и построение модели системы с точки зрения ИБ

Проводится идентификация следующих ресурсов: физических (для рассмотренного примера - рис. 4.6), программных и информационных, содержащихся внутри границ системы. Каждый ресурс необходимо отнести к одному из предопределенных классов. Классификация физических ресурсов представлена в приложении 5. Затем строится модель информационной системы с позиции ИБ. Для каждого информационного процесса, имеющего самостоятельное значение с точки зрения пользователя и называемого пользовательским сервисом (End-User-Service), формируется дерево связей применяемых ресурсов. В рассматриваемом примере будет единственный подобный сервис (см. рис. 4.7). Построенная модель позволяет выделить критичные элементы.

Ценность ресурсов

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

Рис. 4.6. Идентификация физических ресурсов

Рис. 4.7. Построение модели информационной системы с точки зрения ИВ

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

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

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

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

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

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

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

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

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

Ущерб репутации организации:

• 2 - негативная реакция отдельных чиновников, общественных деятелей;
• 4 - критика в средствах массовой информации, не получившая широкого общественного резонанса;
• 6 - негативная реакция отдельных депутатов Государственной Думы, Совета Федерации;
• 8 - критика в средствах массовой информации, имеющая последствия в виде крупных скандалов, парламентских слушаний, широкомасштабных проверок и т.п.;
• 10 - негативная реакция на уровне президента и правительства.

Ущерб для здоровья персонала:

• 2 - минимальный ущерб (последствия не связаны с госпитализаций или длительным лечением);
• 4 - ущерб среднего размера (необходимо лечение для одного или нескольких сотрудников, но длительных отрицательных последствий нет);
• 6 - серьезные последствия (продолжительная госпитализация, инвалидность одного или нескольких сотрудников);
• 10 - гибель людей.

Финансовые потери, связанные с восстановлением ресурсов:

• 2 - менее 1000 долл.;
• 6 - от 1000 до 10 000 долл.;
• 8 - от 10 000 до 100 000 долл.;
• 10 - свыше 100 000 долл.

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

• 2 - до 15 минут;
• 4 - до 1 часа;
• 6 - до 3 часов;
• 8 - от 12 часов;
• 10 - более суток.

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

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

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

Рис. 4.8. Определение ценности информационных ресурсов

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

• оценивается зависимость пользовательских сервисов от определенных групп ресурсов;
• оценивается существующий уровень угроз и уязвимостей;
• анализируются результаты.

Зависимость системы от групп ресурсов

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

Оценка уровней угроз и уязвимостей

Для уровней угроз и уязвимостей возможна оценка, выполненная по результатам исследования косвенных факторов, либо прямая оценка экспертов (упрощенным способом). В первом случае программное обеспечение CRAMM для каждой группы ресурсов и каждого отдельного ресурса генерирует список вопросов, допускающих однозначный ответ (см. рис. 4.9). Методика оценки рисков и уязвимостей на основе косвенных факторов для данного метода рассматривалась в главе 3. Уровень угроз оценивается, в зависимости от ответов, как (см. рис. 4.10):

• очень высокий;
• высокий;
• средний;
• низкий;
• очень низкий.

Рис. 4.9. Оценка уровня угрозы безопасности по косвенным факторам

Рис. 4.10. Оценка угроз безопасности и уязвимости ресурсов

Уровень уязвимости оценивается, в зависимости от ответов, как:

• высокий;
• средний;
• низкий;
• отсутствует.

Возможно проведение коррекции результатов или использование других методов оценки.

На основе этой информации рассчитываются уровни рисков в дискретной шкале с градациями от 1 до 7 (этап анализа рисков) - фрагмент результирующего отчета см. на рис. 4.11.

Рис. 4.11. Оценка рисков на основе уровней угроз и уязвимостей

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

Управление рисками

Основные шаги стадии управления рисками приведены на рис. 4.12.

На этой стадии CRAMM генерирует несколько вариантов мер противодействия, адекватных выявленным рискам и их уровням. Контрмеры разбиты на группы (см. приложение 5). Условно их можно разделить на пять категорий:

42122) рекомендации общего плана, относящиеся к технологии в целом;

23) обеспечение безопасности на сетевом уровне;

24) обеспечение физической безопасности;

25) обеспечение безопасности поддерживающей инфраструктуры;

26) меры безопасности на уровне системного администратора.

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

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

Рис. 4.12. Управление рисками в CRAMM 4

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

CRAMM как инструментарий аудитора

CRAMM имеет средства генерации отчетов, необходимые при проведении аудита информационной безопасности в соответствии с BS 7799 (ISO 17799). Это следующие отчеты:

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

Метод CRAMM в настоящее время применяется наиболее часто, если требуется провести аудит в соответствии с требованиями Британского стандарта.

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

Его недостаток с позиции отечественного потребителя состоит в сложности русификации и большом объеме выходных документов (сотни страниц). Аналитик (аудитор) обычно вынужден на основе полученных документов сам писать отчет для заказчика.

 Средства компании MethodWare

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

• ПО анализа и управления рисками Operational Risk Builder и Risk Advisor. Методология отвечает австралийскому стандарту Australian/New Zealand Risk Management Standard (AS/NZS 4360:1999). Имеется версия, соответствующая ISO 17799;
• ПО управления жизненным циклом информационной технологии в соответствии с открытым стандартом в области информационных технологий CobiT Advisor 3rd Edition (Audit) и CobiT 3rd Edition Management Advisor. В руководствах CobiT существенное место уделяется анализу и управлению рисками;
• ПО для автоматизации построения разнообразных опросных листов Questionnaire Builder.

Демонстрационную версию этого ПО можно загрузить с сайта компании Меthodware [342].

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

Основные этапы работы:

• описание контекста;
• описание рисков;
• описание угроз;
• оценка потерь;
• анализ управляющих воздействий;
• предложение контрмер и плана действий.

Описание контекста

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

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

Организационный контекст отражает отношения внутри организации: стратегию, цели на организационном уровне, внутреннюю политику.

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

Контекст бизнес-целей - основные бизнес-цели.

Критерии оценивания рисков - имеются в виду критерии, принятые при управлении рисками.

Описание рисков

Задается матрица рисков (рис. 4.13), поэтому риски описываются в соответствии с определенным шаблоном и устанавливаются связи этих рисков с другими элементами модели.

Риски оцениваются по качественной шкале и разделяются на приемлемые и неприемлемые (рис. 4.14) на основе простейшей модели.

Рис. 4.13. Идентификация и определение рисков в Risk Advisor

Рис. 4.14. Разделение рисков на приемлемые и неприемлемые в Risk Advisor

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

Описание угроз

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

Описание потерь

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

Анализ результатов

В результате построения модели можно сформировать подробный отчет (около 100 разделов), посмотреть на экране агрегированные описания в виде графика рисков (рис. 4.15).

Рис. 4.15. Анализ результатов в Risk Advisor

Оценка возможностей метода Risk Advisor

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

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

 Экспертная система «АванГард»

В настоящее время на российском рынке продается отечественное ПО «АванГард», разработка Института системного анализа РАН, подробное описание которого можно найти в [46].

«АванГард» позиционируется как экспертная система управления информационной безопасностью. Структура и функции комплекса приведены на рис. 4.16.

Рис. 4.16. Структура и функции ПО «АванГард»

Типовой пакет программных средств КЭС «АванГард» включает два программных комплекса - «АванГард-Анализ» и «АванГард-Контроль». Каждый из этих комплексов базируется на своей методике оценки рисков.

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

Сначала строятся модели событий рисков, содержащие по возможности подробное неформальное описание этих событий и перечень угроз, которые могут привести к ним. Далее по каждой модели события риска рассчитывается оценка риска -как произведение оценки вероятности события риска и оценки степени опасности события риска. При этом оценки, как вероятностей событий риска, так и степени опасности этих событий, предлагается получать с помощью ранговых шкал. Шкала вероятности имеет фиксированный размер от 0 до 100 (от нулевой до 100-процентной вероятности возникновения события риска в течение года). Нижняя граница шкалы опасности - 0, верхняя граница отсутствует, поэтому шкала строится по следующему принципу. Сначала на нее наносятся те риски, вся опасность которых сводится к материальному ущербу и может быть выражена в денежных единицах. В результате получается базовая шкала опасности событий рисков. Далее пользователям предлагается абстрагироваться от «денежной» метрики и воспринимать шкалу как выражающую лишь относительную степень опасности отдельных событий и указывать на ней события рисков путем сравнения степени их нежелательности или недопустимости. При этом верхняя граница шкалы может по мере надобности подниматься. Предусмотрен мощный механизм верификации даваемых оценок путем попарного сравнения вероятностей и степеней опасности каждого вновь указываемого события риска с теми, которые уже определены. Если для какой-либо пары соотношение в оценках не соответствует взглядам экспертов, то ранее выставленные оценки должны быть пересмотрены. Кроме того, предусматривается возможность распечатки выставленных оценок и их обсуждения и корректировки множеством экспертов (метод Дельфийских групп).

Методика предполагает, что любое событие риска происходит в результате реализации некоторого множества угроз, причем каждая из них может быть определена как угроза безопасности какого-либо компонента оцениваемой системы. Таким образом удается определить рискообразующий потенциал каждой из угроз в зависимости от ее «вклада» в события риска, а также рискообразующие потенциалы тех компонентов, к которым эти угрозы относятся, и рассчитать риски по всём структурным составляющим оцениваемой системы и по системе в целом.

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

Методика оценки рисков комплекса «АванГард-Контроль» подчинена задаче контроля уровня защищенности АИС и потому отличается от методики комплекса «АванГард-Анализ». Если методика комплекса «АванГард-Анализ» относится к рискам возможных нарушений безопасности оцениваемой системы, то методика комплекса «АванГард-Контроль» посвящена рискам, являющимся результатом невыполнения требований обеспечения безопасности оцениваемой системы и ее компонентов.

Следовательно, для применения комплекса «АванГард-Контроль» необходимо для каждого компонента оцениваемой системы иметь полный набор требований, выполнение которых означает нулевой риск нарушения безопасности системы. В то же время подразумевается, что при невыполнении всех требований риск нарушения безопасности системы будет 100-процентным.

Значительно облегчить работу по составлению полных наборов требований позволяет использование профилей защиты для отдельных компонентов оцениваемой системы, построенных на основе принятого в конце 2002 г. ГОСТ Р ИСО/МЭК 15408-2002 по критериям оценки безопасности информационных технологий. В связи с тем, что в 2004 г. планируется введение этого ГОСТа в действие, рассмотрим подробнее возможности оценить риски невыполнения его требований с помощью системы «АванГард-Контроль».

Предварительно поясним, что программный комплекс «АванГард-Контроль», в свою очередь, состоит из двух частей - программного комплекса (ПК) «АванГард-Центр» и ПК «АванГард-Регион». Первый предназначен для нескольких целей, таких как разработка профилей защиты (ПЗ); подготовка и рассылка ПЗ посредством электронной почты по подконтрольным частям АИС; автоматизированный сбор отчетности о выполнении требований безопасности в частях АИС; оценка рисков невыполнения требований безопасности в АИС; идентификация узких мест в защите. Второй - для получения профилей защиты в отдельных частях АИС, автоматизации ведения отчетности о выполнении ПЗ и отсылки этой отчетности для ее обработки ПК «АванГард-Центр».

Разработка профилей защиты в ПК «АванГард-Центр» проводится в разделе ведения каталогов программного комплекса. Изначально в КЭС «АванГард» было определено несколько ключевых понятий, таких как метакласс, класс, мера, требование. Метаклассы предназначены для группировки классов объектов АИС по каким-либо конкретным признакам. Классы определяют классы объектов, для которых формируются типовые наборы требований (профили защиты). Меры устанавливают функциональные классы и классы гарантий требований в терминологии ГОСТ Р ИСО/МЭК 15408-2002. Требования включают функциональные семейства, семейства гарантий, функциональные компоненты, компоненты гарантий, функциональные элементы и элементы гарантий в соответствии с ГОСТ Р ИСО/ МЭК 15408-2002.

Для профилей защиты, создаваемых на основе ГОСТ Р ИСО/МЭК 15408-2002, в каталогах ПК «АванГард-Центр» выделен метакласс «Требования и профили защиты по ГОСТ Р ИСО/МЭК 15408-2002» (рис. 4.17). В этом метаклассе создан один «базовый» класс, в который входят все требования, содержащиеся в ГОСТ Р ИСО/МЭК 15408-2002 (рис. 4.18), как функциональные, так и касающиеся гарантий безопасности.

По каждому из уровней в нижней правой части формы выводится подробная информация, относящаяся к выбранной записи каталога. На рис. 4.19 представлен набор требований по мере в ПК «АванГард-Центр». В рассматриваемом примере FAU_GEN.l будет преобразован из формы, содержащей указания на необходимость определения списков назначения, в форму, где такие списки будут сформированы для конкретного профиля защиты.

Профили защиты по ГОСТ Р ИСО/МЭК 15408-2002 строятся следующим образом. Средствами ПК «АванГард-Центр» делается копия класса «Требования ГОСТ Р ИСО/МЭК 15408-2002». Далее выполняется операция «Вставить как шаблон профиля защиты» в метакласс «Требования и профили защиты по

Рис. 4.17. Состав метакласса «Требования и профили защиты по ГОСТ Р ИСО/МЭК 15408-2002» в ПК «АванГард-Центр»

Рис. 4.18. Состав класса «Требования ГОСТ Р ИСО/МЭК 15408-2002» в ПК «АванГард-Центр»

Рис. 4.19. Состав требований по мере (функциональному классу) в ПК «АванГард-Центр»

ГОСТ Р ИСО/МЭК 15408-2002». При этом предлагается поменять название класса. Предположим, что оно было заменено на следующее: «Система с разграничением доступа - Профиль защиты». В результате создается шаблон, который путем последовательного анализа требований корректируется так, что в нем остаются только меры и требования, необходимые для поддержания безопасности объектов того типа, для которого строится этот профиль защиты (рис. 4.20). Все ненужные в данном профиле меры и требования удаляются, а в оставшихся содержимое приводится в соответствие задачам обеспечения безопасности заданного типа объектов.

На рис. 4.21 показано, как было изменено и конкретизировано требование FAU_GEN.l в профиле защиты для систем с разграничением доступа (ПЗ СРД).

В рассмотренном примере в качестве шаблона использовался полный набор требований ГОСТ Р ИСО/МЭК 15408-2002, но в принципе шаблоном для создания нового профиля может послужить и любой другой из уже готовых профилей защиты, причем допускается не только удалять из него ненужные меры и требования, но при необходимости добавлять новые, а также изменять их для достижения нужной степени адекватности целям безопасности, которым должен удовлетворять новый ПЗ.

Созданные профили защиты могут быть либо распечатаны на бумаге, либо экспортированы в файл формата редактора WinWord. Фрагмент генерируемого отчета представлен на рис. 4.22.

Рис. 4.20. Профиль защиты для систем с разграничением доступа (ПЗ СРД),

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

не отвечающими целям безопасности ПЗ СРД

Рис. 4.21. Конкретизация профиля защиты

Рис. 4.22. Фрагмент отчета «Профиль защиты», генерируемого ПК «АванГард-Центр»

С помощью разрабатываемых в системе ПК «АванГард-Центр» профилей защиты в структурную модель анализируемой системы заносятся объекты, оцениваемые по заданному ПЗ. Для создания таких объектов оценки (ОО) выполняется операция перетаскивания (drug and drop) нужного профиля защиты на ту составляющую структурной модели, в качестве элемента которой должен быть показан объект, отвечающий требованиям безопасности и соответствующий выбранному ПЗ. Результат такого рода операции и пример оценок, отражающих фиксацию фактов выполнения отдельных требований, демонстрируется на рис. 4.23.

«АванГард-Центр» позволяет по результатам анализа выполнения требований ПЗ по отдельным ОО оценить риски невыполнения требований в информационной системе. Пример представления в виде гистограмм оценок рисков невыполнения требований демонстрируется на рис. 4.24. Чем больше требований не выполняется, тем больше риски и тем выше столбики гистограммы. В рассмотренном примере значимости отдельных требований приняты одинаковыми, но в принципе можно задавать различные значения, отражающие реальную важность отдельных требований для обеспечения безопасности ОО.

Рис. 4.23. Пример оценки выполнения требований ПЗ по конкретному оцениваемому объекту

Рис. 4.24. Пример графической иллюстрации оценок рисков невыполнения требований ПЗ в ПК «Аван[ард-Центр»

Таким образом, КЭС «АванГард» позволяет не только автоматизировать процесс разработки профилей защиты в соответствии с ГОСТ Р ИСО/МЭК 15408-2002, но и использовать ПЗ для оценки выполнения этих требований в информационных системах организации.

В заключение следует отметить, что экспертная система «АванГард» хорошо подходит для построения ведомственных и корпоративных методик анализа рисков и управления ими. Ее можно рассматривать как полноценный универсальный инструментарий и для анализа и оценки рисков, и для решения задач всеобъемлющего систематического контроля безопасности АИС (в том числе в таких аспектах, как выполнение политик безопасности, ГОСТов и требований Гостехкомиссии, законодательства, внутренних приказов и распоряжений, касающихся безопасности, а также должностных инструкций) во всех подразделениях, использующих АИС.

 RiskWatch

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

В продукте, предназначенном для управления рисками в информационных системах, учитываются требования стандартов США (можно выбирать требуемый уровень защищенности). Кроме того, выпущена версия продукта RiskWatch RW17799®, соответствующая стандарту ISO 17799.

RiskWatch помогает провести анализ рисков и сделать обоснованный выбор мер и средств защиты. Используемая в программе методика состоит из четырех этапов.

Первый этап - определение предмета исследования. На данном этапе описываются параметры организации: ее тип, состав исследуемой системы, базовые требования в области безопасности (рис. 4.25). Описание формализуется в ряде подпунктов, которые можно отметить для подробной детализации (рис. 4.26) или пропустить.

Далее каждый из указанных пунктов описывается подробно.

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

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

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

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

Рис. 4.25. Описание информационной системы с позиции безопасности в RiskWatch

На этом этапе:

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

Третий этап - оценка рисков (см. рис. 4.28). Сначала устанавливаются связи между ресурсами, потерями, угрозами и уязвимостями, выделенными на предыдущих этапах.

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

,

Рис. 4.26. Описание ресурсов информационной системы

где р - частота возникновения угрозы в течение года,

v - стоимость ресурса, который подвергается угрозе.

Например, если стоимость сервера составляет 150 000 долл., а вероятность его уничтожения пожаром в течение года - 0,01, то ожидаемые потери будут равны 1500 долл.

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

Четвертый этап - генерация отчетов. Типы отчетов:

• краткие итоги;
• полные и краткие отчеты об элементах, описанных на стадиях 1 и 2;
• отчет о стоимости защищаемых ресурсов и ожидаемых потерь от реализации угроз;
• отчет об угрозах и мерах противодействия;
• отчет о результатах аудита безопасности.

Ниже (рис. 4.29) приводится фрагмент отчета.

Рис. 4.27. Оценка параметров угроз с использованием статистических данных

Возможности RiskWatch

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

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

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

Рис. 4.28. Содержание третьей стадии в RiskWatch

Рис. 4.29. Результирующие оценки по одной из угроз - кражи (начало)

Рис. 4.29. Результирующие оценки по одной из угроз ~ кражи (окончание)

Глава  
Аудит безопасности и анализ рисков

 Актуальность аудита безопасности

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

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

Практика внедрения новых корпоративных информационных систем свидетельствует, что компании не всегда получают полную отдачу капиталовложений, и прежде всего из-за усложнения современных корпоративных систем и большей их уязвимости. Можно выделить две основные причины увеличения уязвимости корпоративных систем. Во-первых, возросла уязвимость собственно корпоративных информационных систем за счет обоснованного усложнения их аппаратно-программных элементов, повышения структурной и функциональной сложности системного и прикладного программного обеспечения, применения новых технологий обработки, передачи и хранения данных. А во-вторых, расширился спектр угроз корпоративным информационным системам из-за передачи информации по открытым каналам сетей общего назначения, «информационных войн и электронных диверсий» конкурирующих организаций, активного промышленного шпионажа с привлечением профессионалов в области защиты информации и пр. Современный рынок безопасности насыщен средствами обеспечения информационной безопасности. Постоянно изучая существующие предложения этого рынка, многие компании видят неадекватность ранее вложенных средств в системы ИБ, например по причине морального старения оборудования и программного обеспечения. Поэтому они ищут варианты решения этой проблемы. Таких вариантов может быть два: с одной стороны - полная замена системы корпоративной защиты информации, что потребует больших капиталовложений, а с другой - модернизация существующих систем безопасности. Последний вариант менее затратный, но несет новые сложности, например требует ответа на следующие вопросы: Как совместить старые, сохраненные из имеющихся, аппаратно-программные средства безопасности с новыми элементами системы защиты информации? Как организовать централизованное управление разнородными средствами обеспечения безопасности? Как оценить, а при необходимости и переоценить информационные риски компании? Более существенная причина необходимости проведения аудита безопасности состоит в том, что при модернизации и внедрении новых технологий защиты информации их потенциал полностью не реализуется. Здесь аудит дает возможность анализировать текущую безопасность функционирования корпоративной информационной системы, оценивать и прогнозировать риски, управлять их влиянием на бизнес-процессы компании, корректно и обоснованно подойти к вопросу поддержания безопасности ее информационных активов - стратегических планов развития, маркетинговых программ, финансовых и бухгалтерских ведомостей, содержимого корпоративных баз данных. В итоге грамотно проведенный аудит безопасности корпоративной информационной системы позволяет добиться максимальной отдачи от средств, инвестируемых в создание и обслуживание систем безопасности.

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

В настоящее время многие поставщики средств защиты информации декларируют поставку полного, законченного решения в области безопасности корпоративных систем. К сожалению, в лучшем случае все сводится к проектированию и поставке соответствующего оборудования и программного обеспечения. Построение комплексной корпоративной системы безопасности «остается в тени» и к решению, как правило, не прилагается. Поэтому у ТОР-менеджеров компаний зачастую возникает целый ряд вопросов:

• Соответствует ли наша корпоративная система информационной безопасности целям и задачам бизнеса компании?
• Адекватна ли принятая в компании политика безопасности целям и задачам бизнеса?
• Каким образом эффективно контролировать реализацию и выполнение политики безопасности в компании?
• Когда следует провести модернизацию системы безопасности? Как обосновать необходимость модернизации и затрат?
• Как быстро окупятся инвестиции в корпоративную систему безопасности? Где здесь точка безубыточности?
• Насколько правильно и корректно сконфигурированы и настроены штатные средства поддержания информационной безопасности компании?
• Как убедиться в том, что существующие в компании средства защиты - межсетевые экраны (firewall), системы обнаружения вторжений (IDS), антивирусные шлюзы, VPN-шлюзы - эффективно справляются со своими задачами?
• Как решаются вопросы обеспечения конфиденциальности, доступности и целостности?
• Как оценить работу подрядных организаций и компаний, которые выполнили проектирование, поставку, монтаж и пуско-наладку средств безопасности? Есть ли недостатки, и если да, то какие?
• Как обеспечить столь необходимую в практике «вертикаль власти» для централизованного управления безопасностью компании?
• Как контролировать состояние информационной безопасности компании? Какие методы и средства здесь требуются?
• Что делать после того, как корпоративная система обеспечения безопасности построена (имеются стратегический и тактический планы защиты компании, планы работы при возникновении чрезвычайных ситуаций)?
• Есть ли необходимость постоянно обучать сотрудников службы информационной безопасности компании? И если да, то какие бюджетные средства нужны?
• Как управлять информационными рисками компании? Какие инструментальные средства для этого необходимо задействовать?
• Удовлетворяет ли организация информационной безопасности компании требованиям международных стандартов оценки и управления безопасностью, например ISO 15408, ISO 17799 (BS 7799), BSI?

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

Как оценить уровень безопасности КИС?

Современные методики анализа рисков информационной безопасности, проектирования и сопровождения систем безопасности дают возможность:

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

 Основные понятия и определения

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

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

• РД Гостехкомиссии при президенте РФ 1992-1998 гг.;
• Практические рекомендации по управлению информационной безопасностью - стандарт BS 7799 (Великобритания);
• Управление в информационных технологиях - CobiT (Международная ассоциации аудита и управления информационными системами);
• стандарты NIST (США) по обеспечению ИБ NIST 800-16, 800-18, 800-30.

В российской нормативно-методической базе основными терминами являются: сертификация средств защиты информации и аттестация объектов информатизации.

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

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

В стандартах NIST аналогичные термины определяются следующим образом.

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

Аккредитация (Accreditation) — разрешение использования информационной системы общего применения или специализированных приложений (имеющих специальные требования к ИБ) для обработки информации. Основанием для выдачи разрешения служит сертификация выбранных решений на соответствие заданным требованиям по ИБ.

Ответственный за выдачу разрешения (Designated Approving Authority) - лицо, уполномоченное принять решение о допустимости определенного уровня рисков для рассматриваемой информационной системы или технологии обработки информации.

Сравнение приведенных определений показывает, что:

• термин сертификация понимается одинаково;
• приблизительным аналогом российского термина «аттестация объектов информатизации» является термин «аккредитация» - с одним существенным отличием: в американском варианте явно указано, что аккредитация производится специалистами, уполномоченными принять решение о допустимости определенного уровня рисков для рассматриваемой информационной системы или технологии.

При этом в российской нормативно-методической базе аспект рисков, допустимый уровень остаточных рисков, ответственность за принятие определенного уровня рисков не рассматриваются. После аккредитации информационной системы возможно проведение независимой экспертизы существующего режима ИБ -аудит ИБ в информационной системе. Этот термин также встречается в англоязычной литературе и трактуется следующим образом [124]. Аудит ИБ в информационной системе - процесс сбора сведений, позволяющих установить, поддерживается ли безопасность ресурсов организации (включая данные); обеспечиваются ли необходимые параметры целостности и доступности данных; достигаются ли цели организации в части эффективности информационных технологий.

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

В российских РД не предусматривается возможность проведения аудита ИБ, вместо этого допускается повторная аттестация (возможно, другим органом по аттестации).

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

• большое внимание к выбору и формальному описанию целей, которые ставятся в области ИБ для конкретной информационной системы. Используются механизмы оценки соответствия декларированных целей существующим показателям ИБ;
• учет аспектов, связанных с рисками, что позволяет оптимизировать построение подсистемы безопасности по критериям «цена-эффективность»;
• лучший учет таких составляющих ИБ, как целостность и доступность. Российские РД в основном ориентированы на обеспечение конфиденциальности;
• большая степень формализации требований к подсистеме ИБ. В современных стандартах и руководствах формальные требования и рекомендации излагаются в нескольких сотнях подразделов. Соответственно методики построения подсистем ИБ более конкретны, процедуры проведения аудита ИБ достаточно формализованы.

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

• на соответствие Британскому стандарту BS 7799, часть 2;
• на соответствие требованиям Ассоциации аудита и управления информационными системами (The Information Systems Audit and Control Association & Fondation - ISACA);
• на соответствие требованиям Американского института общественных бухгалтеров (AICPA);

Рассмотрим наиболее распространенные в Европе BS 7799 и COBIT.

 Аудит безопасности в соответствии с BS 7799, часть 2

 Сертификация и аудит: организационные аспекты

Международный стандарт ISO/IEC 17799:2000 (BS 7799-1:2000) «Информационные технологии - управление информационной безопасностью» (Information technology - Information security management) на сегодняшний день наиболее распространен. Он был разработан на основе первой части Британского стандарта BS 7799-1 «Практические рекомендации по управлению информационной безопасностью» (Information security management, Part 1: Code of practice for information security management), однако не включает вторую часть стандарта BS 7799-2:2002, посвященного вопросам аудита безопасности. Таким образом, можно говорить о соответствии информационной системы требованиям ISO/IEC 17799:2000 (BS 7799-1:2000), но сертификацию информационной системы можно выполнять только в соответствии с BS 7799-2:2002 (Part II). Сертификация информационной системы подтверждает ее соответствие требованиям BS 7799-1 со стороны независимого аудитора.

Вопросами сертификации в Великобритании ведает Британский институт стандартов (British Standards Institution - BSI) (www.bsi-global.com) под его контролем организация UKAS (United Kingdom Accredited Service) занимается аккредитацией организаций на право аудита ИБ в соответствии со стандартом BS 7799. Сертификаты, выданные этими организациями, признаются не только в Великобритании, но и во многих странах мира.

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

Сертификаты выдаются после завершения аудита подсистемы ИБ на соответствие стандартам BS 7799 и действительны в течение 3 лет.

Общими вопросами управления информационной безопасности компаний и организаций, а также развитием аудита безопасности занимаются международный комитет Joint Technical Committee ISO/IEC JTC 1 совместно с институтом стандартов BSI и, в частности, служба UKAS. Эта служба производит аккредитацию организаций на право аудита информационной безопасности в соответствии со стандартом BS 7799-1.

Обсудим процедуру проведении аудита информационных систем.

 Методика проведения аудита

Рассмотрим основные положения методики проведения аудита и рекомендованные средства и способы оценки рисков Guide to BS 7799 risk assessment and risk management [145], Guide to BS 7799 auditing [167]. Эти рекомендации вполне применимы к отечественным условиям и могут быть использованы при разработке соответствующих методик. Особенно полезными представляются простейшие годы оценки рисков и управления ими, не требующие установки сложного и дорогостоящего программного обеспечения.