Метод оценки безопасности компьютерных систем или сетей

Обновлено: 04.07.2024

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Требования доверия к безопасности

Information technology. Security techniques. Evaluation criteria for IT security. Part 3.
Security assurance requirements

Дата введения 2004-01-01

1 РАЗРАБОТАН Центром безопасности информации, 4 ЦНИИ Министерства обороны РФ, Центром "Атомзащитаинформ", ЦНИИАТОМИНФОРМ, ВНИИстандарт при участии экспертов Международной рабочей группы по Общим критериям

ВНЕСЕН Гостехкомиссией России, Техническими комитетами по стандартизации ТК 362Р "Защита информации" и ТК 22 "Информационные технологии"

2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 4 апреля 2002 г. N 133-ст

4 ВВЕДЕН ВПЕРВЫЕ

Введение

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

ГОСТ Р ИСО/МЭК 15408 содержит общие критерии оценки безопасности информационных технологий.

1 Область применения

Настоящий стандарт определяет требования доверия к безопасности и включает в себя оценочные уровни доверия (ОУД), определяющие шкалу для измерения доверия, собственно компоненты доверия, из которых составлены уровни доверия, и критерии для оценки ПЗ и ЗБ.

Настоящий стандарт состоит из следующих разделов:

1 - введение и парадигма;

3-5 - краткое введение в критерии оценки ПЗ и ЗБ, сопровождаемое детализированными объяснениями семейств и компонентов, которые применяют для этих оценок;

6 - детализированные определения оценочных уровней доверия;

7 - краткое введение в классы доверия;

15-16 - краткое введение в критерии оценки поддержки доверия с детализированными определениями применяемых семейств и компонентов.

Приложение А содержит сводку зависимостей между компонентами доверия.

Приложение Б содержит перекрестные ссылки между ОУД и компонентами доверия.

1.2 Парадигма доверия

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

1.2.1 Основные принципы ГОСТ Р ИСО/МЭК 15408

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

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

1.2.2 Подход к доверию

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

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

1.2.2.1 Значимость уязвимостей

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

Нарушения безопасности ИТ возникают вследствие преднамеренного использования или случайной активизации уязвимостей при применении ИТ по назначению.

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

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

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

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

1.2.2.2 Причины уязвимостей

Уязвимости могут возникать из-за недостатков:

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

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

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

1.2.2.3 Доверие в ГОСТ Р ИСО/МЭК 15408

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

1.2.2.4 Доверие через оценку

Оценка является традиционным способом достижения доверия, и она положена в основу ГОСТ Р ИСО/МЭК 15408. Методы оценки могут, в частности, включать в себя:

а) анализ и проверку процессов и процедур;

б) проверку, что процессы и процедуры действительно применяются;

в) анализ соответствия между представлениями проекта ОО;

г) анализ соответствия каждого представления проекта ОО требованиям;

д) верификацию доказательств;

е) анализ руководств;

ж) анализ разработанных функциональных тестов и полученных результатов;

и) независимое функциональное тестирование;

к) анализ уязвимостей, включающий предположения о недостатках;

л) тестирование проникновения.

1.2.3 Шкала оценки доверия в ГОСТ Р ИСО/МЭК 15408

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

а) области охвата, т.е. увеличении рассматриваемой части продукта или системы ИТ;

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

в) строгости, т.е. применении более структурированного и формального подхода.

2 Требования доверия к безопасности

Следующие подразделы описывают конструкции, используемые в представлении классов, семейств и компонентов доверия, оценочных уровней доверия (ОУД), и их взаимосвязь.

На рисунке 2.1 показаны требования доверия, определенные в настоящем стандарте. Наиболее общую совокупность требований доверия называют классом. Каждый класс содержит семейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия. Классы и семейства используют для обеспечения таксономии классифицируемых требований доверия, в то время как компоненты применяют непосредственно для спецификации требований доверия в ПЗ/ЗБ.

Рисунок 2.1 - Иерархическая структура представления требований доверия: класс-семейство-компонент-элемент

2.1.1 Структура класса

Рисунок 2.1 иллюстрирует структуру класса доверия.

2.1.1.1 Имя класса

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

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

2.1.1.2 Представление класса

Каждый класс доверия имеет вводный подраздел, в котором описаны состав и назначение класса.

2.1.1.3 Семейства доверия

Каждый класс доверия содержит по меньшей мере одно семейство доверия. Структура семейств доверия описана в следующем пункте.

Некоторые вопросы оценки уровня безопасности компьютерных систем.

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

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

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

1. Trusted Computer System Evaluation Criteria или “Оранжевая книга” Минобороны США [5].

2. “Российский стандарт” - “Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации”, “Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации.”[6].

3. Information Technology Security Evaluation Criteria или “Европейский критерий” [4].

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

Таблица 1. Сравнительный анализ критериев стандартов, предусматривающих единую шкалу оценки.

Повторное использование объектов

Анализ скрытых каналов

Безопасность обмена данными

На уровне экспорта

На уровне экспорта и импорта

Критерии "Российского стандарта" опущены в силу их идентичности критериям, представленным в “Оранжевой книге”.

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

1. “Federal Criteria for Information Technology Security” или “Федеральный критерий”.

2. Canadian Trusted Computer Product Evaluation Criteria или “Канадский критерий”.

3. Common Criteria for Information Technology Security Evaluation или “Единый критерий”.

“Федеральный критерий“ [3] закрепил различие между продуктом информационных технологий (ПИТ) и системой обработки информации, чего не было ранее, и ввел понятие профиля защиты, предусматривая создание на общегосударственном уровне картотеки профилей защиты. Частные шкалы оценки уровня безопасности в “Федеральном критерии” зависят от 15 разделов требований безопасности, разделенных на: требования потребителей(Функциональные); требования к разработчикам (Технологии разработки); требования, проверяемые экспертами в процессе квалификационного анализа.

“Канадский критерий” [1], заменил понятие “субъект” модели описания процесса взаимодействия, парой “пользователь” - “процесс”. При этом стало возможным процессы, проинициализированные одним пользователем отличать от процессов, инициализированных другими участниками взаимодействия. Степень безопасности КС согласно “Канадскому критерию”, определяется частным показателем обеспечиваемого уровня безопасности (по функциональным критериям) и обобщенным параметром – уровнем адекватности реализации политики безопасности. Разделение соответствующих групп критериев можно представить структурой, приведенной на рис.1.

Предотвращение угроз несанкционированного доступа к информации

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

Противостояние угрозам отказа в обслуживании

Предотвращение угроз фальсификации протоколов и манипулирования с внутрисистемной информацией

Рис. 1. Структура функциональных критериев.

“Единый критерий” [2] дополнил введенные “Федеральным критерием” понятия “проектом защиты”. Проект защиты является описанием ПИТ, используемым в ходе квалификационного анализа. “Единый критерий” разделяет требования безопасности аналогично “Канадскому критерию”, отказавшись от упорядоченных частных шкал оценки и сформировав функциональные требования к средствам защиты в иерархическую структуру, а не в упорядоченный список. Частные шкалы оценки уровня безопасности оказываются лишь частично упорядоченными. Иллюстрация схемы построения частично упорядоченных шкал оценки приведена на рис.2.

Восстановление после сбоя

4.С возможностью отката

3.С минимизацией потерь

Без возможности отката

Рис. 2. Схема построения частично упорядоченных шкал оценки на примере восстановления после сбоя. Номера вершин составляют набор частных шкал оценки, удовлетворяющих следующим соотношениям:

(1-2)

В 1999 году в Украине были приняты “Критерии оценки защищенности информации в КС от несанкционированного доступа" или "Украинские критерии". "Украинские критерии" заменили понятие "субъект" суперпозицией "объект-пользователь" и "объект-процесс" и оценивают способности КС обеспечить защиту информации от несанкционированного доступа (НСД) с учетом требований двух видов:

1. К функциям защиты (или услугам безопасности);

2. К гарантиям защиты.

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

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

Данный нормативно-технический акт дополнен "Классификацией автоматизированных систем и стандартными функциональными профилями защищенности обрабатываемой информации от несанкционированного доступа". Рекомендация профиля защищенности учитывает назначение автоматизированной системы и сферу ее применения. Так, представлены стандартные функциональные профили защищенности в КС, входящих в состав автоматизированных систем, предназначенных для: автоматизации деятельности органов государственной власти; автоматизации банковской деятельности; управления технологическими процессами; справочно-поисковых систем.

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

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

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

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

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

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

При использовании эмпирического метода оценки уровня защищенности на протяжении длительного периода времени производится сбор и обработка фактических данных о реальных проявлениях угроз информации и о размерах имевшего место ущерба. Зависимости между потенциально-возможным ущербом и частотами проявления соответствующих угроз устанавливаются на основе предложенной в [7] оценки:

(1.1)

где Ri - ожидаемый ущерб от проявления угрозы;

А – некоторая постоянная;

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

Vi – параметр, характеризующий значение возможного ущерба при возникновении угрозы.

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

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

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

, (1.2)

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

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

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

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

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

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

1. Canadian Trusted Computer Product Evaluation Criteria. Canadian System Security Center Communication Security Establishment, Government of Canada. Version 3.0e. January 1993.

2. Common Criteria for Information Technology Security. . National Institute of Standards and Technology & National Security Agency (USA), Communication Security Establishment (Canada), UK IT Security and Certification Scheme (United Kingdom), Bundestamt fur Sichereit in der Informationstechnik (Germany), Service Central de la Securite des Systemes (France), National Communications Agency (Netherlands). Version 0.6.11.01.97.

3. Federal Criteria for Information Technology Security. National Institute of Standards and Technology & National Security Agency. Version 1.0, December 1992.

4. Information Technology Security Evaluation Criteria. Harmonized Criteria of France-Germany-Netherlands-United Kingdom.-Department of Trade and Industry, London, 1991.

6. Б. А.Федоренко, И. В.Макаров. Безопасность сетевых ОС. М., Эко-Трендз. 1999.

7. Вопросы защиты информации. 1995, №1.

8. Л. Г.Черныш. Нечеткие модели оценки уровня защищенности. В сб. МНТК “Повышение эффективности систем защиты информации”. “Защита –97”. К. 1997. 230С. С.49-51.

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

Коваль Елена Владимировна, старший преподаватель Академии государственной налоговой службы Украины, аспирант НТУУ «КПИ».

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Курочкин С.И., Заводцев И.В.

В статье рассматриваются методы оценки уровня защищенности информационных систем. Анализ существующих методов. Модель применения системы защиты информации на объектах информатизации. Структура критериев оценки соответствия уровня защищенности.

Текст научной работы на тему «МЕТОДЫ ОЦЕНКИ УРОВНЯ ЗАЩИЩЕННОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ»

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

1. Кузнецова О.Б. Информатизация маркетинговой деятельности в корпорации: учебное пособие / О.Б. Кузнецова, И.Л. Андреевский. - СПб.: СПбГИЭУ 2009. - 110 с.

2. Кузнецова О.Б. Развитие системы маркетинга на базе геоинформационных систем / О.Б. Кузнецова, И.Л. Андреевский // Материалы международной научно-практической конференции «Европейский Север: инновационное освоение морских ресурсов (образование-наука-производство)», Мурманск, 14-17 марта 2012. - Электронный текст дан. (Мб). - Мурманск: МГТУ 2012.

4. Кузнецова О.Б. Развитие транспортной инфраструктуры Севера на основе интеллектуальных транспортных систем / О.Б. Кузнецова // Материалы международной научно-практической конференции «Современные проблемы и тенденции инновационного развития Европейского Севера, Мурманск, 09-11 апреля 2014. - Электронный текст дан. (Мб). - Мурманск: МГТУ 2014.

5. Кузнецова, О.Б. Особенности управления транспортной инфраструктурой Мурманской области на базе интеллектуальных технологий: монография / О.Б. Кузнецова - Мурманск: НОУ ВПО «МАЭУ», 2014. - 96 с.

МЕТОДЫ ОЦЕНКИ УРОВНЯ ЗАЩИЩЕННОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ

1 2 © Курочкин С.И. , Заводцев И.В.

Нижегородский государственный технический университет, г. Нижний Новгород Кубанский институт информзащиты, г. Краснодар

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

1 Аспирант Нижегородского государственного технического университета.

2 Доцент Кубанского института информзащиты, кандидат технических наук.

менения системы зашиты информации на объектах информатизации. Структура критериев оценки соответствия уровня защищенности.

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

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

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

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

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

Рассмотрим существуют качественные и количественные методы анализа эффективности СЗИ. Более точным являются количественные методы. Но для того, чтобы «измерить» эффективность, необходимо иметь обоснованный критерий (показатель оценки эффективности системы). На практике встречаются следующие типы критериев:

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

- критерии, позволяющие оценить качество СЗИ по заданным показателям и исключить те варианты, которые не удовлетворяют заданным ограничениям. При этом используются методы многокритериальной оптимизации, восстановления функций и функционалов, методы дискретного программирования;

- искусственно сконструированные критерии, позволяющие оценивать интегральный эффект (например, «линейная свертка» частных показателей, методы теории нечетких множеств) [7, 8].

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

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

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

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

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

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

- анализ и управление рисками безопасности информационной системы (ИС);

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

Исходя из этого, необходимо произвести выбор показателей, используемых при разработке СЗИ, и сформировать требования к ней (рис. 1).

Рис. 1. Модель применения системы защиты информации на объектах информатизации организации (компании)

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

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

- формировании графа атак и зависимостей сервисов на основе данных о топологии сети;

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

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

- вычислении показателей защищенности на основе этих данных.

Однако предлагаемые автором методики находятся в стадии проработки и

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

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

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

Общий перечень уязвимостей и рисков (СУЕ)

— Программа оценки уровня

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

платформ (СРЕ) аппаратного обеспечения

Общий перечень конфигураций (ССЕ) _ (СУББ 3.0)

Инструментальный контроль 1

количество хостов с критичными уязвимостями 1 > Сетевые сканеры и сканеры безопасности

Период сканирования МЯХРЯТЗСИ

Слабые места (CWE)

Количество хостов с устраненным РПВ

Эффективность устранения уязвимостей

Слабость хоста относительно других хостов

Количество срабатываний по группам хостов

Количество заблокированных попыток заражения РПВ

Средства антивирусной защиты

Степень защищенность активов от вредоносного ПС^^ ^

Значения текущих оценок соответствия

уровня защищенности информационной системы организации (компании)

Рис. 2. Структура критериев оценки соответствия уровня защищенности

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

Показатель уязвимость хоста определим на основе известных уязвимостей и базовой оценки CVSS:

Уи1пегаЫШу(Нк) = £?=1 СгШса1ВаБе5согв(1,0,

где Яд - хост в составе информационной системы с к-ым порядковым номером, к = 1,М.

Задание параметра р производится в процессе настройки системы и варьируется в интервале от 1 до 10. В работе [4] предлагается граничный параметр р установить на значении равном 7. Однако, на наш взгляд, столь

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

Показатель Слабость хоста определяется на основе стандартов CWE и CWSS:

Weakness(_Hk) = £™=i Critical,

где Нк - хост в составе информационной системы с к-ым порядковым номером, к = 1,М.

Задание параметра со производится в процессе настройки системы и варьируется в интервале от 1 до 100. В работе [4] предлагается граничный параметр со установить на значении равном 60. Однако, и в этом случае, целесообразно данный параметр также сделать изменяемым, что бы пользователь системы мог корректировать его самостоятельно.

Рассмотрим показатели защищенности системного уровня, основанные на функционировании информационной системы.

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

где Нк - хост в составе информационной системы с к-ым порядковым номером, к = 1,М.

Polsec(Hk) - нормированное значение отношения количества реализуемых на хосте Hk политик безопасности к возможному их количеству:

где 1р0! ес - количество политик безопасности реализованных на хосте Нк; шахРо1_^,ес(Нк) - максимально возможное количество политик безопасности, подлежащих реализации на этом хосте с учетом требований организации.

Показатель выполнение требований безопасности - оценка соотношения количества реализуемых в ИС требований по безопасности к общему количеству задаваемых требований:

где /„.,;, ,ес - количество требований безопасности реализованных в информационной системе, I = 1, п; тахТгеЬ ,\ес - максимально возможное число

требований безопасности, подлежащих реализации в ИС с учетом требований организации.

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

Показатель защищенности активов от разрушающих программных воздействий - оценка эффективности функционирования антивирусной защиты:

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

где Нк - хост в составе информационной системы с к-ым порядковым номером, к = 1, М:

БЬк_Ма1ау - процент хостов с устраненным вредоносным ПО - количество срабатываний САВЗ. - весовые коэффициенты значений, подбираются экспертным методом, на этапе формирования модели ИС.

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

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

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

где t = l, N,j — 1, М, ф Е , с Е и гр, - i-й частный показатель защищенности СЗИ; Cj - j-ая характеристика, в виде трапециевидного нечеткого числа, i-го частного показателя защищенности СЗИ; Wj - j-й весовой коэффициент, в виде треугольного нечеткого числа, i-го частный показатель защищенности СЗИ; Z - множество частных показателей защищенности; C -множество характеристик частного показателя защищенности.

1. ГОСТ Р 18044-2007 Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности.

2. ГОСТ Р ИСО/МЭК 27001-2006 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента ИБ. Требования.

3. Тихонов Д.В. Оценка эффективности систем защиты информации // Вестник ИНЖЭКОНа. Сер. Экономика. Вып. 7 (26). - СПб.: 2008. - С. 210-212.

6. Котенко И.В. Общее перечисление и классификация шаблонов атак (CAPEC): описание и примеры применения [Текст] // Защита информации. INSIDE. - 2012. - № 4.

7. Dantu R., Kolan P., Cangussu J. Network risk management using attacker profiling // Security and Communication Networks. - 2009. - V 2, N 1. - P. 83-96.

АЛГОРИТМ ПОИСКА И УСТРАНЕНИЯ ДУБЛИКАТОВ ОБЪЕКТОВ В ИНФОРМАЦИОННЫХ СИСТЕМАХ ОБРАБОТКИ ПЕРСОНАЛЬНЫХ ДАННЫХ

Севастопольский государственный университет, г. Севастополь

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

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

Любая корпоративная компьютерная сеть, даже небольшая, требует постоянного внимания к себе. Как бы хорошо она ни была настроена, насколько бы надежное ПО не было установлено на серверах и клиентских компьютерах – нельзя полагаться лишь на внимание системного администратора; необходимы автоматические и непрерывно действующие средства контроля состояния сети и своевременного оповещения о возможных проблемах.

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

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

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

Ниже мы рассматриваем базовые методы мониторинга работы сети и контроля ее защищенности.

Методы мониторинга состояния сети

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

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

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

Следующий этап – проверка принципиальной работоспособности критичных служб. Как правило, это означает TCP-подключение к соответствующему порту сервера, на котором должна быть запущена служба, и, возможно, выполнение тестового запроса (например, аутентификации на почтовом сервере по протоколу SMTP или POP или запрос тестовой страницы от веб-сервера).

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

Способы проверки этих величин варьируются, но один из основных, доступных почти всегда – проверка по SNMP-протоколу. Помимо этого, можно использовать специфические средства, предоставляемые ОС проверяемого оборудования: к примеру, современные серверные версии ОС Windows на системном уровне предоставляют так называемые счетчики производительности (performance counters), из которых можно «считать» довольно подробную информацию о состоянии компьютера.

Наконец, многие окружения требуют специфических проверок – запросов к БД, контролирующих работу некоего приложения; проверка файлов отчетов или значений настроек; отслеживание наличия некоторого файла (например, создаваемого при «падении» системы).

Контроль безопасности сети

Безопасность компьютерной сети (в смысле защищенности ее от вредоносных действий) обеспечивается двумя методами: аудитом и контролем. Аудит безопасности – проверка настройки сети (открытых портов, доступности «внутренних» приложений извне, надежности аутентификации пользователей); методы и средства аудита выходят за рамки данной статьи.

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

Использование Alchemy Eye для мониторинга состояния сети и контроля ее безопасности

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

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

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

Чтобы добавить проверку в программ, откройте диалог создания нового сервера (меню «Сервер>Добавить сервер>Новый») – рис 1. На основной закладке этого диалога нужно задать логическое имя для объекта мониторинга, интервал между проверками, и тип проверки.

Рис.1. Выбор типа проверки сервера.

Скриншот на рис.1 может продемонстрировать лишь небольшое количество типов проверок, доступных в программе (полный список вы можете посмотреть самостоятельно). Для ориентировки можно привести соответствия между задачами, описанными выше, и некоторыми проверками, доступными в Alchemy Eye:

Рис.2. Браузер дерева MIB – выбор переменной для SNMP-мониторинга.

Рис.3. Браузер счетчиков производительности Windows – выбор параметра для мониторинга.

В случае сложных окружений, для которых недостаточно встроенных проверок, можно использовать одну из возможностей расширения, доступных в Alchemy Eye: запуск скриптовых функций (VBScript, JavaScript, ActivePerl) или внешних приложений, а так же подсистему плагинов.

После выбора типа проверки нужно задать ее параметры – как правило, они включают адрес проверяемого сервера и несколько других, очевидных либо в деталях объясняемых всплывающими подсказками. На рис.4 показана страница выбора параметров ICMP-проверки.

Когда объекты мониторинга созданы, главное окно Alchemy Eye само по себе становится инструментом анализа текущей ситуации, наглядно отображая состояния серверов (рис.5). Если заданных проверок больше чем 4-5 (и к тому же, они имеют разную степень критичности), лучше всего разбить их по папкам (впоследствии это даст дополнительные «приятности», вроде возможности сгенерировать отчеты только для проверок из конкретной папки).

Рис.5. Главное окно Alchemy Eye – мониторинг серверов (3 успешных проверки, 1 сбой).

Все проверки Alchemy Eye «бинарные» (проверка либо прошла, либо нет), но на количество однотипных проверок никаких ограничений не накладывается. Таким образом, встроенных средств программы вполне достаточно для реализации сложных сценариев: например, две независимые проверки загрузки процессора одного и того же сервера – одна будет «ловить» загрузку выше 95% и немедленно сообщать о проблеме техническим специалистам, а другая – загрузку выше 80% для статистического учета и последующего анализа.

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

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

Читайте также: