Основные свойства и показатели эффективности системы защиты информации

5.1

Основные свойства и показатели эффективности системы защиты информации

Содержание

1.Характеристика «Общих критериев оценки безопасности информационных

3.Обобщенный методический подход к обеспечению информационной

5.2

Основные свойства и показатели эффективности системы защиты информации

Введение

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

На сегодня существует два подхода к выбору показателей (критериев) защищенности информации:

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

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

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

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

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

Всемирная Торговая Организация, членом которой является Россия, в мае 1998 г. приняла решение о введе нии беспошлинной электронной торговли.

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

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

Следуя по пути интеграции, в 1990 г. Международная организация по стандартизации (ISO), a также Междуна родная Электротехническая комиссия (ТЕС) составили специализированную систему по мировой стандартиза ции, a ISO начала создавать международные стандарты по критериям оценки безопасности информационных технологий для общего использования, названные «Common Criteria for Information Technology Security Evaluation» или просто «Common Criteria». В их разработке участвовали: Национальный институт стандартов и технологии и Агентство национальной безопасности (США), Учреждение безопасности коммуникаций (Канада), Агентство информационной безопасности (Германия), Агентство национальной безопасности коммуникаций (Нидерланды), Органы исполнения Программы безопасности и сертификации ИТ (Англия), Центр обеспечения безопасности систем (Франция).

В дальнейшем «Общие критерии» неоднократно редактировались. Международный стандарт ISO/IEC 15408 под названием «Общие критерии оценки безопасности информационных технологий» (ОК) 8 июня 1999 года утвержден ISO. Ведущие мировые производители перестроили производство оборудования информа ционных технологий в соответствии с требованиями общих критериев.

1. Характеристика «Общих критериев оценки безопасности информационных технологий ISO/IEC 15408»

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

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

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

5.3

Основные свойства и показатели эффективности системы защиты информации

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

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

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

Общие критерии могут быть использованы как при задании требований к продуктам и системам информаци онных технологий, так и при оценке их безопасности на всех этапах жизненного цикла. Во время проведения оценок такие продукты и системы IT известны как Цели оценок (Target of Evaluations TOEs), включают, на пример, операционные системы, компьютерные сети, распределенные системы и прикладные программы.

ОК состоят из трех частей.

Часть первая, введение и основная модель, является введением в Common Criteria. Она определяет основные концепции и принципы оценки защиты IT (Information Technology) и представляет основную модель оценки. Здесь также представлены конструкции для представления целей защиты, для выбора и определения требо ваний к защите IT и для создания спецификаций для продуктов и систем.

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

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

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

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

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

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

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

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

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

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

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

5.4

Основные свойства и показатели эффективности системы защиты информации

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

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

Исходными положениями в оценке конкретного TOE являются перечень требований к защите TOE (изложены в Security Target целях защиты), критерии, методология и схема проведения оценки.

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

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

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

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

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

Среда защиты строится на базе двух типов спецификаций:

•спецификация РР (Protection Profiles);

•спецификация ST (Security Targets).

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

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

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

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

•определить имущество, требующее защиты с помощью элементов TOE (обычно это файлы и базы дан ных);

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

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

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

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

•оператор наличия организационной политики защиты.

Эти операторы включаются в состав спецификации ST.

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

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

5.5

Основные свойства и показатели эффективности системы защиты информации

ССпредставляют требования защиты следующего типа:

• функциональные требования;

• гарантированные требования.

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

Гарантированные требования определяют степень гарантированной защиты; они могут быть различными для конкретного набора функциональных требований и потому включаются в перечень функциональных требований в виде гарантированных компонент. Гарантированные требования СС определены в третьей части стандарта. Там же расположены материалы по шкале уровней оценок EAL (Evaluation Level). Гаран тированные требования корректируют действия разработчиков TOE и специалистов по проведению оце нок по защите TOE. Примерами гарантированных требований могут служить требования по выявлению и анализу атаки по потенциально уязвимым местам.

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

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

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

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

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

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

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

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

Между компонентами может существовать зависимость. Зависимости возникают, когда компонента не явля ется самодостаточной и полагается на присутствие другой компоненты. Зависимости могут существовать между функциональными компонентами, между гарантированными компонентами и между функциональными и га рантированными компонентами. Описания компонентных зависимостей являются частью определений ком понент СС и включаются в PPs и STs.

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

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

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

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

ССопределяют три типа конструкций для записи требований: пакет, РР, ST.

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

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

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

Уровень гарантированной оценки (EAL evaluation assurance level) определяет гарантированный пакет тре бований по защите. Весь набор уровней гарантированных оценок образует шкалу гарантированных требова ний СС.

5.6

Основные свойства и показатели эффективности системы защиты информации

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

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

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

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

Источниками требований по защите TOE могут быть:

•существующие PPs;

•существующие пакеты (набор предварительно определенных пакетов в критериях EALs приведен в час ти 3; гарантированные требования TOE, изложенные в РР или ST, должны включать EAL из части 3);

•существующие компоненты функциональных и гарантированных требований (компоненты, используе мые в РР или ST, могут быть выбраны из частей 2 и 3);

•расширенные требования.

В стандарте рассматриваются три типа оценок: РР, ST, TOE.

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

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

Целью оценки TOE является стремление продемонстрировать, что TOE поддерживает требования по защите, изложенные в ST.

Таким образом Общие критерии характеризуются следующими основными качествами.

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

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

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

Задание по безопасности это полная комбинация требований, являющихся необходимыми для создания и оценки ИБ конкретной системы или продукта ИТ.

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

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

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

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

5.7