Анализ рисков, управление рисками

2.3 Определение сферы (границ) системы управления ИБ и конкретизация целей ее создания

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

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

1. Структура организации. Описание существующей структуры и изменений, которые предполагается внести в связи с разработкой (модернизацией) автоматизированной системы.

2. Размещение средств СВТ и поддерживающей инфраструктуры.

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

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

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

2.4 Постановка задачи оценки рисков

На данном этапе должна быть поставлена задача оценки рисков и обоснованы требования к методике оценки рисков.

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

Минимальные требованиям к режиму ИБ

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

Повышенные требования к режиму ИБ

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

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

Возможные подходы к выбору дополнительных требований рассмотрены в [8].

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

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

• уменьшение риска;
• уклонение от риска;
• изменение характера риска;
• принятие риска.

Уменьшение риска

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

Уклонение от риска

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

Изменение характера риска

Если не удается уклониться от риска или эффективно его уменьшить, можно принять некоторые меры страховки. Примеры:

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

Принятие риска

Многие риски не могут быть уменьшены до пренебрежимо малой величины.

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

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

2.6 Выбор контрмер, обеспечивающих режим ИБ

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

2.7 Аудит системы управления ИБ

Целью проведения аудита является проверка соответствия выбранных контрмер декларированным в политике безопасности целям. Вопросы аудита и процедура сертификации информационной технологии на соответствие требованиям ИБ рассматриваются в [9]. В результате должен быть создан документ «Ведомость соответствия», в котором содержится анализ эффективности контрмер. Основные разделы этого документа:

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

3. Базовый уровень ИБ

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

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

3.1 Британские стандарты BS7799

Документ «BS7799: Управление ИБ» состоит из двух частей.

В «Части 1: Практические рекомендации», 1995 г. [2], определяются и рассматриваются следующие аспекты ИБ:

• Политика безопасности.
• Организация защиты.
• Классификация и управление информационными ресурсами.
• Управление персоналом.
• Физическая безопасность.
• Администрирование компьютерных систем и сетей.
• Управление доступом к системам.
• Разработка и сопровождение систем.
• Планирование бесперебойной работы организации.
• Проверка системы на соответствие требованиям ИБ.

«Часть 2: Спецификации системы», 1998 г.

[9], рассматривает эти же аспекты с точки зрения сертификации информационной системы на соответствие требованиям стандарта.

Краткое содержание стандартов рассмотрено в Приложении 1.

Другие методические материалы

Британский институт стандартов BSI выпустил серию практических рекомендаций [8, 10-17], посвященных различным аспектам: оценке и управлению рисками, аудиту режима ИБ, сертификации информационной системы на соответствие стандартам BS7799, организации работы персонала. Эта серия существенно дополняет стандарт BS7799.

3.2 Базовые требования в области ИБ в США

В США имеется похожий по подходу и степени подробности документ «Руководство по политике безопасности для автоматизированных информационных систем» [18], в котором рассмотрены:

• общие положения политики безопасности;
• поддержание безопасности на протяжении жизненного цикла;
• минимальные (базовые) требования в области ИБ.

3.3 Германский стандарт BSI

В 1998 году вышло «Руководство по защите информационных технологий для базового уровня». Руководство представляет собой гипертекст объемом около 4 МБ (в формате HTML). Общая структура документа приведена на рис 3.1.

Можно выделить следующие блоки:

• Методология управления ИБ (организация менеджмента в области ИБ, методология использования Руководства).
• Компоненты информационных технологий:
• Основные компоненты (организационный уровень ИБ, процедурный уровень, организация защиты данных, планирование действий в чрезвычайных ситуациях).
• Инфраструктура (здания, помещения, кабельные сети, организация удаленного доступа).
• Клиентские компоненты различных типов (DOS, Windows, UNIX, мобильные компоненты, прочие типы).
• Сети различных типов (соединения «точка-точка», сети Novell NetWare, сети с ОС UNIX и Windows, разнородные сети).
• Элементы систем передачи данных (электронная почта, модемы, межсетевые экраны и т.д.).
• Телекоммуникации (факсы, автоответчики, интегрированные системы на базе ISDN, прочие телекоммуникационные системы).
• Стандартное ПО.
• Базы данных.
• Каталоги угроз безопасности и контрмер (около 600 наименований в каждом каталоге). Каталоги структурированы следующим образом.

Угрозы по классам:

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

Контрмеры по классам:

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

Все компоненты рассматривается по следующему плану: общее описание, возможные сценарии угроз безопасности (перечисляются приме-

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

Фактически сделана попытка описать с точки зрения ИБ наиболее распространенные компоненты информационных технологий и максимально учесть их специфику. К примеру, существуют разделы с описанием сетей на базе Novell Netware 3.x и Novell Netware 4.x.

Предполагается оперативное пополнение и обновление стандарта по мере появления новых компонент. Версии стандарта на немецком и английском языках имеются на Web-сервере [5].

3.4 Сравнение подходов, используемых в британском и германском стандартах

В британском стандарте декларируются некоторые общие принципы, которые предлагается конкретизировать применительно к исследуемым информационным технологиям. Во второй части основное внимание уделено сертификации информационной системы на соответствие стандарту, то есть формальной процедуре, позволяющей убедиться, что декларируемые принципы реализованы. Объем стандарта сравнительно невелик – менее 120 страниц в обеих частях. В германском стандарте, напротив, рассмотрено много «частных случаев» – различных элементов информационных технологий. Объем документа очень велик – несколько тысяч страниц; несомненно, он будет возрастать. Такой подход имеет свои достоинства и недостатки. Достоинство – учет специфики различных элементов. В частности, гораздо лучше, по сравнению с британским стандартом, рассмотрены особенности обеспечения ИБ в современных сетях. Другим достоинством является использование гипертекстовой структуры, что позволяет оперативно вносить изменения и корректировать связи между частями стандарта. Последняя версия стандарта всегда доступна на Web. Недостаток – невозможность объять необъятное – все множество элементов современных информационных технологий на одинаковом уровне детализации. Неизбежно приходится вводить раздел «прочее», в котором в общем виде рассматриваются менее распространенные элементы. В свою очередь, недостатком британского стандарта являются высокие требования к квалификации специалистов, осуществляющих проверку на соответствие требованиям стандарта. Кроме того, в нем недостаточно учитывается специфика современных распределенных систем. Таким образом, оба подхода имеют свои достоинства и недостатки, эволюционируют и только практика их использования позволит выявить лучший или, возможно, предложить иной подход.

3.5 Ведомственные стандарты и спецификации базового уровня ИБ

Ряд организаций и ведомств предложил свои спецификации для базового уровня ИБ.

Консорциум X/Open выпустил документ под названием «Спецификации сервисов базового уровня ИБ» [3]. Спецификация применима к информационным системам, построенным на базе типовых проектных решений. Предполагается, что концепция обеспечения ИБ организации соответствует стандарту BS 7799. При разработке спецификации использовалось понятие профиля защиты с компонентами, удовлетворяющими требованиям «хорошей практики», формализованным в виде четких критериев (см. Приложение 2).

Ведомственный стандарт NASA «Безопасность информационных технологий. Минимальные требования к базовому уровню защищенности» [4] соответствует документу «Руководство по политике безопасности для автоматизированных информационных систем»[18] и конкретизирует его положения. Используется дифференцированный подход: вводится 4 уровня критичности технологии, для которых по 30 позициям специфицируются требования. Следует отметить, что подобный подход – определение нескольких вариантов базовых требований для различных типов технологий, безусловно, оправдан и позволяет учесть их специфику.

4. Обеспечение повышенных требований к ИБ

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

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

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

Следующий шаг – выбор контрмер, снижающих риски до приемлемых уровней.

4.1 Основные этапы полного анализа рисков

Рассмотрим основные этапы полного анализа рисков.

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

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

Примерами внешних элементов являются сети связи, внешние сервисы и т.п.

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

Построение модели информационной технологии

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

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

Выбор контрмер

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

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

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

5. Инструментальные средства для анализа рисков и управления рисками

5.1 Средства анализа рисков и управления рисками для базового уровня безопасности

Применение каких-либо инструментальных средств не является обязательным, однако оно позволяет уменьшить трудоемкость проведения анализа рисков и выбора контрмер. В настоящее время на рынке есть около десятка программных продуктов для анализа и управления рисками базового уровня безопасности. Демо-версии некоторых продуктов доступны по Интернет.

Примером является BSS (Baseline Security Survey), рис. 5.1. Демо-версия (без библиотеки контрмер) доступна по адресу: ftp://ftp.rmcs.CRANFIELD.AC.UK/pub/department/ess/bss.

5.2 Средства и методы для проведения полного анализа и управления рисками

При выполнении полного анализа рисков приходится решать ряд сложных проблем:

• Как определить ценность ресурсов?
• Как составить полный список угроз ИБ и оценить их параметры?
• Как правильно выбрать контрмеры и оценить их эффективность?

Для решения этих проблем существуют специально разработанные инструментальные средства, построенные с использованием структурных методов системного анализа и проектирования (SSADM – Structured Systems Analysis and Design), которые обеспечивают:

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

В настоящее время на рынке присутствует несколько программных продуктов этого класса. Наиболее популярный из них, CRAMM [19, 20], рассмотрен ниже.

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

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

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

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

В настоящее время CRAMM является, судя по числу ссылок в Интернет, самым распространенным методом анализа и контроля рисков.

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

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

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

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

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

Исследование ИБ системы с помощью СRAMM проводится в три стадии.

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

Стадия 2: рассматривается все, что относится к идентификации и оценке уровней угроз для групп ресурсов и их уязвимостей. В конце стадии 2 заказчик получает идентифицированные и оцененные уровни рисков для своей системы.

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

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

Пример

Для иллюстрации использования метода рассмотрим рис. 5.2 – информационную систему поддержки принятия решений аварийно-спасательной службы. Система состоит из следующих элементов:

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

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

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

Стадия 1: Идентификация ресурсов и построение модели ИС

Основные шаги:

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

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

Стадия 1 начинается с решения задачи определения границ исследуемой системы. Для этого собирается следующая информация:

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

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

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

Проводится идентификация ресурсов: физических (для рассмотренного примера – рис 5.3), программных и информационных, содержащихся внутри границ системы. Каждый ресурс необходимо отнести к одному из предопределенных классов. В версии 3 метода используется 15 классов физических ресурсов, 5 классов программных ресурсов и один класс для данных. Классификация физических ресурсов дана в Приложении 3.

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

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

Метод позволяет определить ценность ресурсов. Этот шаг является обязательным в полном варианте анализа рисков.

Ценность физических ресурсов в данном методе определяется ценой их восстановления в случае разрушения.

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

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

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

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

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

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

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

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

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

Стадия 2: Анализ угроз и уязвимостей

На стадии 2:

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

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

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

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

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

Уровень угроз оценивается, в зависимости от ответов, как (см. рис 5.7):

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

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

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

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

На основе этой информации рассчитываются уровни рисков в дискретной шкале с градациями от 1 до 7.

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

Стадия 3: Выбор контрмер

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

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

На этой стадии возможно провести сравнительный анализ эффективности различных вариантов защиты.

6. Заключение

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

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

7. Литература

1. Кобзарь М., Калайда И. Общие критерии оценки безопасности информационных технологий и перспективы их использования. – Jet Info, 1998, 1.

2. Code of practice for Information security management. British Standard BS7799, 1995.

3. X/Open Baseline Security Services Specification (XBSS). C529, X/Open company, 1996. http://www.opengroup.org/public/tech/security/bsec96/download.htm

4. Information Technology Security (ITS) Minimum Baseline Protective Requirements. http://esdis.dsfo.nasa.gov/SECURITY/REQ/BASEREQ/bas ereqlist.html

5. Bundesamt fur Sicherheit in der Informationstechnik. IT Baseline Protection Manual, 1998, http://www.bsi.bund.de/gshb/english/etc/econten.htm

6. Галатенко В. Информационная безопасность. Обзор основных положений. – Jet Info, 1996, 1-3.

7. Бетелин В., Галатенко В. Информационная Безопасность в России. Опыт составления карты. – Jet Info, 1998, 1.

8. Guide to BS 7799 risk assessment and risk management. DISC PD 3002, 1998.

9. Information security management. Part 2. Speci-

fication for information security managementsystems. British Standard BS7799, Part 2, 1998.

10. Information security management: an introduction. DISC PD 3000, 1998.

11. Preparing for BS 7799 certification. DISC PD 3001, 1998.

12. Are you ready for a BS7799 audit? DISC PD 3003, 1998.

13. Guide to BS 7799 auditing. DISC PD 3004, 1998.

14. Code of practice for IT management. DISC PD 0005, 1998.

15. Guide to the Code of practice for Information Security Management. DISC PD 0007, 1995.

16. Code of practice for legal admissibility of information stored on electronic document management systems. DISC PD 0008, 1995.

17. Principles of good practice for information management. DISC PD 0010, 1997.

18. Automated Information Systems Security Policy Manual, NTIS, CIS HB 1400-14, http://fedworld.gov

19. CRAMM User Guide. 1996.

20. A practical guide to the use of CRAMM. 1998.

8. Термины и определения

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

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

Информационная Безопаснсоть (ИБ) (Information Security) – защищенность ресурсов ИС от факторов, представляющих угрозу для:

• конфиденциальности
• целостности;
• доступности.

Угроза (Threat) – совокупность условий и факторов, которые могут стать причиной нарушения целостности, доступности, конфиденциальности.

Уязвимость (Vulnerability) – слабость в системе защиты, которая делает возможной реализацию угрозы.

Анализ рисков – процесс определения угроз, уязвимостей, возможного ущерба, а также контрмер.

Базовый уровень безопасности (Baseline Security) – уровень, соответствующий критериям CCTA Baseline Security Survey. Обязательный минимальный уровень защищенности для информационных систем государственных учреждений Великобритании.

Базовый (Baseline) анализ рисков – анализ рисков, проводимый в соответствии с требованиями базового уровня защищенности. Прикладные методы анализа рисков, ориентированные на данный уровень, обычно не рассматривают ценность ресурсов и не оценивают эффективность контрмер. Методы данного класса применяются в случаях, когда к информационной системе не предъявляется повышенных требований в области информационной безопасности.

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

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

Риск нарушения ИБ (Security Risk) – возможность реализации угрозы.

Оценка рисков (Risk Assessment) – идентификация рисков, выбор параметров для их описания и получение оценок по этим параметрам.

Управление рисками (Risk Management) – процесс определения контрмер в соответствии с оценкой рисков.

Система управления ИБ (Information Security Management System) – комплекс мер, направленных на обеспечение режима ИБ на всех стадиях жизненного цикла ИС.

Класс рисков – множество угроз ИБ, выделенных по определенному признаку (например, относящихся к определенной подсистеме или типу ресурса).

Приложение 1. Основные положения стандарта BS7799

Напомним, что этот стандарт состоит из двух частей (см. [1, 2]), которые в тексте приложения рассматриваются параллельно и идентифицируются метками «Часть 1:» и «Часть 2:» соответственно.

Раздел 1. Политика ИБ

Цель: Сформулировать цель и обеспечить поддержку мер в области информационной безопасности со стороны руководства организации.

Часть 1: Высшее руководство должно поставить четкую цель и показать свою поддержку и заинтересованность в вопросах ИБ, распространении политики безопасности среди сотрудников организации.

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

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

Часть 2: Формальных требований к политике безопасности не предъявляется.

Раздел 2. Организация защиты Инфраструктура ИБ

Цель: Управлять ИБ в организации.

Часть 1: Для обеспечения режима ИБ необходимо создать в организации соответствующую

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

Часть 2: Должно быть проведено независимое тестирование. Возможно проведение тестирования внешней организацией либо внутренни-

ми аудиторами, не занимающимися данной системой управления ИБ.

Обеспечение безопасности при доступе сторонних пользователей и организаций

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

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

Часть 2: Анализ договорных требований и проверка их выполнения.

Раздел 3. Классификация ресурсов и их контроль Ответственность за ресурсы

Цель: Обеспечить надлежащую защиту ресурсов организации.

Часть 1: Все основные информационные ресурсы должны быть учтены и иметь ответственных. Кроме того, следует назначить ответственных за реализацию защитных мер.

Часть 2: При проведении аудита необходимо проверить список ресурсов, в котором как минимум указаны:

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

Классификация информации

Цель: Обеспечить надлежащий уровень защиты информационных ресурсов.

Часть 1: Для того, чтобы задать приоритеты в области обеспечения ИБ, следует классифицировать информацию по категориям критичности.

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

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

Раздел 4. Управление персоналом

Вопросы безопасности в должностных инструкциях по доступу к ресурсам

Цель: Уменьшить риск ошибок персонала, краж, мошенничества или незаконного использования ресурсов.

Часть 1: Аспекты, связанные с безопасностью, следует учитывать еще на стадии набора персонала, включать их в должностные инструкции и договоры, а также контролировать в течение всего времени работы данного сотрудника. Руководители должны убедиться в том, что в должностных инструкциях отражена вся присущая данной должности ответственность за безопасность. Следует надлежащим образом проверить принимаемых на работу лиц, особенно если они будут работать с критичной информацией. Весь персонал организации и пользователи информационных ресурсов из сторонних организаций должны подписать обязательство о конфиденциальности (неразглашении).

Часть 2: Аудиторы должны проверить должностные инструкции персонала и процедуру отбора кандидатов на должности, связанные с доступом к критически важной информации.

Обучение пользователей

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

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

Часть 2: Проверка выполнения требований, изложенных в части 1.

Реагирование на события, таящие угрозу безопасности

Цель: Минимизация ущерба от нарушений режима ИБ и недопущение повторений инцидентов.

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

Часть 2: Аудиторы должны проверить, существует ли четкое определение того, что является нарушением режима ИБ, и знает ли персонал об этом.

Раздел 5. Физическая безопасность Зоны безопасности

Цель: Предотвратить несанкционированный доступ к СВТ, сервисам, их повреждение и вмешательство в работу.

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

Часть 2: Аудиторы должны проверить, что критически важные ресурсы размещены в зонах безопасности, имеющих соответствующий пропускной режим.

Защита оборудования

Цель: Предотвратить потерю, повреждение и компрометацию ресурсов, а также перебои в работе организации.

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

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

Раздел 6. Администрирование информационных систем

Правила эксплуатации и ответственные за их соблюдение

Цель: Обеспечить правильную и надежную работу информационных систем.

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

Часть 2: Аудиторы должны проверить наличие правил по эксплуатации, разработке, сопровождению, тестированию, убедиться, что все необходимые операции должным образом документированы.

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

Цель: Свести риск отказов информационных систем к минимуму.

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

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

Часть 2: Аудиторы должны проверить критерии приемки информационных систем, оценки их производительности, планы восстановительных работ по каждому сервису.

Защита от вредоносного программного обеспечения

Цель: Обеспечить целостность данных и программ

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

Часть 2: Аудиторы должны убедиться, что процедуры, препятствующие внедрению вредоносного программного обеспечения, должным образом документированы, приняты адекватные меры предосторожности, случаи заражения регистрируются.

Обслуживание систем

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

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

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

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

Цель: Обеспечить защиту информации в сетях.

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

Часть 2: Аудиторы должны проверить защитные меры, применяемые в организации. Защита носителей информации

Цель: Предотвратить повреждение информационных ресурсов и перебои в работе организации. Часть 1: Необходимо контролировать носители информации и обеспечивать их физическую защиту. Следует определить процедуры для защиты носителей информации (магнитные ленты, диски, кассеты), входных/выходных данных и системной документации от повреждения, хищения и несанкционированного доступа.

Часть 2: Аудиторы должны проверить установленные процедуры контроля, режим хранения носителей информации.

Обмен данными и программным обеспечением

Цель: Предотвратить потери, модификацию и несанкционированное использование данных.

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

Часть 2: Аудиторы должны проверить существующие меры защиты электронного обмена данными, меры ИБ внутреннего электронного документооборота.

Раздел 7. Управление доступом Управление доступом к служебной информации

Цель: Обеспечить контроль доступа к информации.

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

Часть 2: Аудиторы должны проверить соответствие установленных правил доступа к информации существующей производственной необходимости.

Управление доступом пользователей

Цель: Предотвратить несанкционированный доступ к информационной системе.

Часть 1: Для управления процессом предоставления прав доступа к информационным системам требуются формальные процедуры. Эти процедуры должны включать в себя все стадии жизненного цикла управления доступом пользователей – от начальной регистрации до удаления учетных записей пользователей, для которых доступ закрывается. Особое внимание следует уделить процессу предоставления суперпользовательских прав, позволяющих обойти средства системного контроля.

Часть 2: Аудиторы должны проверить формальные процедуры регистрации и соответствие фактического положения вещей установленным процедурам. Следует проконтролировать использование особых привилегий.

Обязанности пользователей

Цель: Предотвратить несанкционированный доступ пользователей.

Часть 1: Важным условием поддержания режима ИБ является помощь зарегистрированных пользователей. Пользователи должны знать свои обязанности по обеспечению контроля доступа, особенно в части использования паролей и защиты пользовательского оборудования.

Часть 2: Аудиторы должны проверить знание пользователями своих обязанностей и фактическое их выполнение.

Управление доступом к сети

Цель: Предотвратить несанкционированный доступ к сервисам, включенным в сеть.

Часть 1: Подключение сервисов в сеть следует контролировать. Это необходимо для того, чтобы защитить другие сетевые сервисы. В число средств контроля должны входить:

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

Часть 2: Аудиторы должны проверить, что пользователи имеют доступ только к тем сервисам, которые им необходимы. Если проводится политика управления маршрутизацией, необходимо выяснить, как она реализуется на практике.

Управление доступом к компьютерам

Цель: Предотвратить несанкционированный доступ к компьютерам.

Часть 1: Доступ следует предоставлять только зарегистрированным пользователям. Многопользовательские системы должны:

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

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

Часть 2: Аудиторы должны проверить как минимум использование парольной защиты: периодичность смены паролей, использование общих паролей, длину и структуру паролей. При необходимости проверяются прочие механизмы: идентификация терминалов для некоторых соединений, система сигнализации о попытках несанкционированного доступа.

Управление доступом к приложениям

Цель: Предотвратить несанкционированный доступ к информации, хранимой в информационных системах.

Часть 1: Для управления доступом к прикладным системам и данным необходимо использовать средства логического контроля доступа.

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

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

Слежение за доступом к системам и их использованием

Цель: Выявить несанкционированные действия.

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

Часть 2: Аудиторы должны проверить соответствие политики управления доступом существующей практике.

Раздел 8. Разработка и сопровождение информационных систем

Требования к ИБ систем

Цель: Обеспечить встраивание средств защиты в информационные системы.

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

Часть 2: Аудиторы должны убедиться, что на стадии проектирования был проведен анализ вопросов безопасности.

Средства обеспечения ИБ в прикладных системах

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

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

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

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

Защита файлов

Цель: Обеспечить информационную безопасность при разработке и поддержке информационных систем.

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

Часть 2: Аудиторы должны выяснить, как устанавливаются и тестируются новые версии, регистрируются изменения, хранятся рабочие версии ПО.

Безопасность в среде разработки и эксплуатационной среде

Цель: Обеспечить информационную безопасность прикладного ПО и данных.

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

Часть 2: Аудиторы должны проверить наличие процедур контроля на всех этапах жизненного цикла.

Раздел 9. Планирование бесперебойной работы организации

Вопросы планирования бесперебойной работы организации

Цель: Составить планы предотвращения перебоев в работе организации.

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

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

Раздел 10. Проверка системы на соответствие требованиям ИБ

Выполнение требований действующего законодательства

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

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

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

Проверка режима ИБ на соответствие политике безопасности

Цель: Обеспечить соответствие режима ИБ политике и стандартам безопасности организации.

Часть 1: Состояние ИБ системы необходимо регулярно проверять.

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

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

Меры безопасности при тестировании

Цель: Минимизировать вмешательство в процесс тестирования и воздействие тестирования на штатную работу.

Часть 1: Необходимо иметь средства для защиты рабочих и тестируемых систем.

Часть 2: Аудиторы проверяют наличие планов тестирования и организацию доступа к инструментальным средствам тестирования.

Приложение 2. Спецификация XBSS

XBSS – спецификация сервисов безопасности базового уровня В спецификации определены:

• требования в области ИБ к сервисам информационной системы;
• параметры, устанавливаемые по умолчанию, соответствующие требованиям ИБ.

Примечание. Используемое в тексте понятие «База данных» означает состоящую из одной или нескольких компонент (включая СВТ и ПО) часть системы, имеющую собственные механизмы безопасности и защищенную в соответствии с политикой безопасности.

Требования к подсистеме идентификации и аутентификации:

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

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

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

Минимальные требования к протоколированию/аудиту:

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

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

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

Требования к подсистеме защиты повторного использования объектов:

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

Требования к защите критичной информации:

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

Требования к средствам обеспечения целостности:

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

Требования к средствам обеспечения доступности:

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

Обеспечение безопасности порождения и получения информации:

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

Требования к средствам управления ИБ:

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

Приложение 3. Классификация физических ресурсов, используемая в методе CRAMM.

Несетевые серверы:

• несетевые серверы общего назначения;
• прочие несетевые серверы.

Сетевые серверы:

• сетевые файл-серверы;
• сетевые серверы БД;
• сетевые серверы общего назначения;
• прочие сетевые серверы.

Несетевые рабочие станции:

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

Сетевые рабочие станции:

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

Локальные запоминающие устройства:

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

Сетевые запоминающие устройства:

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

Локальные печатающие устройства:

• принтер.

Сетевые печатающие устройства печати:

• сервер печати;
• сетевой принтер;
• принтер;
• другие сетевые устройства печати.

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

• мост;
• коммутатор;
• маршрутизатор;
• повторитель;
• модем;
• мультиплексор;
• узел коммутации ATM;
• узел коммутации Х.25;
• оконечный сетевой элемент;
• спутниковая станция связи;
• станция радиосвязи;
• прочие сетевые распределительные компоненты.

Сетевые шлюзы:

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

Управление сетью и управляющие серверы:

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

Сетевые интерфейсы:

• постоянное соединение:
• синхронное;
• асинхронное.
• коммутируемое соединение:
• PSTN;
• ISDN;
• радиосоединение;
• прочие типы соединений. сетевые сервисы:

сетевые сервисы:

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

Сервисы конечного пользователя:

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

Коммуникационные протоколы:

• SDLS/HDLS;
• IP;
• CLNP (Connectionless Network Protocol);
• ATM;
• Frame Relay;
• TDM;
• протоколы спутникового обмена информацией;
• Ethernet;
• Token Ring;
•  прочие протоколы.

Носители данных (Media)

Неэлектронные носители:

• устройства ввода;
• устройства вывода;
• важные записи;
• прочие виды носителей.

Электронные носители: 

• магнитные ленты;
• диски;
• прочие виды носителей.

Приложение 4. Угрозы в методе CRAMM:

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

Приложение 5. Классы контрмер в методе CRAMM:

• идентификация и аутентификация;
• логическое управление доступом;
• протоколирование;
• аудит;
• безопасность многократного использования объектов;
• тестирование систем;
• контроль целостности ПО;
• управление вводом/выводом;
• управление безопасностью в сети;
• обеспечение неотказуемости;
• обеспечение конфиденциальности вне соединения;
• управление доступом в сети;
• физическая безопасность сети;
• защита сообщений;
• обеспечение целостности данных вне соединения;
• сохранение правильной последовательности сообщений;
• пополнение трафика;
• контроль операций в системе;
• контроль действий системного администратора;
• контроль действий прикладных программистов;
• контроль операций по поддержке прикладного ПО;
• контроль операций по обслуживанию СВТ;
• контроль пользователей;
• контроль ввода/вывода приложений;
• финансовая отчетность;
• контроль выходных документов;
• контроль носителей данных;
• контроль транспортировки физических носителей данных;
• резервное копирование и восстановление для серверов;
• резервирование и восстановление сетевых интерфейсов;
• резервирование и восстановление сетевых сервисов;
• восстановление помещений;
• резервирование и восстановление носителей данных;
• планирование восстановления;
• резервное копирование данных;
• планирование потребностей в ресурсах;
• защита от сбоев СВТ;
• обеспечение физической безопасности помещений;
• оптимизация расположения СВТ в помещениях;
• организация зон безопасности;
• защита от краж;
• физическая защита СВТ;
• контрмеры против террористов и экстремистов;
• защита средств контроля доставки;
• обнаружение бомб и взрывчатых веществ;
• защита от минирования со стороны сотрудников и посторонних лиц;
• защита от пожара;
• защита от затоплений;
• защита от природных катаклизмов;
• защита источников электропитания;
• защита поддерживающей инфраструктуры;
• защита персонала;
• обучение персонала;
• политика безопасности;
• инфраструктура безопасности;
• оповещение об инцидентах;
• проверка жалоб.