На главную
На сайт СибГУТИ
МЕНЮ Информация

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

  1. Рекомендации X.800
  2. Оранжевая книга  TCSEC
  3. Интерпретация оранжевой книги
  4. Гармонизированные критерии Европейских стран ITSEC
  5. Стандарт ISO/IEC 15408 «Критерии оценки безопасности информационных технологий»
  6. Концепция защиты от НСД Гостехкомиссии при президенте РФ

1. Рекомендации X.800

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

Основная особенность этого документа – распределение функций обеспечения ИБ по уровням OSI/

 

Распределение функций безопасности по уровням эталонной семиуровневой модели OSI

 

Функции безопасности

Уровень модели OSI

1

2

3

4

5

6

7

Аутентификация

-

-

+

+

-

-

+

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

-

-

+

+

-

-

+

Конфиденциальность соединения

+

+

+

+

-

+

+

Конфиденциальность вне соединений

-

+

+

+

-

+

+

Выборочная конфиденциальность

-

-

-

-

-

+

+

Конфиденциальность трафика

+

-

+

-

-

-

+

Целостность с восстановлением

-

-

-

+

-

-

+

Целостность без восстановления

-

-

+

+

-

-

+

Избирательная целостность

-

-

-

-

-

-

+

Целостность вне соединения

-

-

+

+

-

-

+

Неотказуемость

-

-

-

-

-

-

+

 

Механизмы безопасности

  • Шифрование;
  • Электронная (цифровая) подпись;
  • Механизмы управления доступом;
  • Механизмы контроля целостности данных;
  • Механизмы аутентификации;
  • Механизмы дополнения трафика;
  • Механизмы управления маршрутизацией;
  • Механизмы подтверждения подлинности;

2. Критерии оценки надежных компьютерных систем ("Оранжевая книга" Министерства обороны США)

Данный труд, называемый чаще всего по цвету обложки "Оранжевой книгой", был впервые опубликован в августе 1983 года.

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

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

Есть смысл оценивать лишь степень доверия, которое разумно оказать той или иной системе.

 

Надежность системы

 

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

Степень доверия, или надежность систем, оценивается по двум основным критериям:

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

 

Политика безопасности

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

 

Основными элементами политики безопасности являются

  • Произвольное управление доступом;
  • Безопасность повторного использования объектов;
  • Метки безопасности;
  • Принудительное управление доступом;
  • Подотчетность.

 

Гарантированность

 

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

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

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

 

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

 

В "Оранжевой книге" определяется четыре уровня безопасности (надежности) — D, C, B и A. Уровень D предназначен для систем, признанных неудовлетворительными. В настоящее время он содержит две подсистемы управления доступом для ПК.

По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием надежности. Таким образом, всего имеется шесть классов безопасности — C1, C2, B1, B2, B3, A1.

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

Оранжевая книга

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

Надежность системы

C1

C2

B1

B2

B3

A1

1. Политика безопасности

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

+

+

=

=

+

=

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

+

=

=

=

=

1.3.1 Метки безопасности

+

+

=

=

1.3.2 Целостность меток безопасности

+

+

=

=

1.4 Принудительное управление доступом

+

+

=

=

1.5 Подотчетность

1.5.1 Идентификация и аутентификация

+

+

+

=

=

=

1.5.2 Предоставление надежного пути

+

+

=

1.5.3 Аудит

+

+

+

+

=

 

3. Интерпретация "Оранжевой книги" для сетевых конфигураций

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

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

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

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

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

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

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

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

 

4. Гармонизированные критерии Европейских стран

Европейские страны приняли согласованные критерии оценки безопасности информационных технологий (Information Technology Security Evaluation Criteria, ITSEC). опубликованные в июне 1991 года от имени соответствующих органов четырех стран — Франции, Германии, Нидерландов и Великобритании.

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

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

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

  1. конфиденциальность, то есть защиту от несанкционированного получения информации;
  2. целостность, то есть защиту от несанкционированного изменения информации;
  3. доступность, то есть защиту от несанкционированного удержания информации и ресурсов.

 

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

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

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

  1. Идентификация и аутентификация.
  2. Управление доступом.
  3. Подотчетность.
  4. Аудит.
  5. Повторное использование объектов.
  6. Точность информации.
  7. Надежность обслуживания.
  8. Обмен данными.

 

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

В Европейских Критериях таких классов десять. Пять из них (F-C1, F-C2, F-B1, F-B2, F-B3) соответствуют классам безопасности "Оранжевой книги".

 

5. Стандарт ISO/IEC 15408 "Критерии оценки безопасности информационных технологий"

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

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

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

ОК содержат два основных вида требований безопасности:

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

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

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

  1. определение назначения, условий применения, целей и требований безопасности;
  2. проектирование и разработка;
  3. испытания, оценка и сертификация;
  4. внедрение и эксплуатация.

В ОК объект оценки рассматривается в контексте среды безопасности, которая характеризуется определенными условиями и угрозами.

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

  1. источник угрозы;
  2. метод воздействия;
  3. уязвимые места, которые могут быть использованы;
  4. ресурсы (активы), которые могут пострадать.

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

  1. в требованиях безопасности;
  2. в проектировании;
  3. в эксплуатации.

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

С точки зрения технологии программирования в ОК использован устаревший библиотечный (не объектный) подход. Чтобы, тем не менее, структурировать пространство требований, в "Общих критериях" введена иерархия класс – семейство – компонент - элемент.

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

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

Компонент - минимальный набор требований, фигурирующий как целое.

Элемент - неделимое требование.

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

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

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

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

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

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

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

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

Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности. Всего в "Общих критериях" представлено 11 функциональных классов, 66 семейств, 135 компонентов. Это, конечно, значительно больше, чем число аналогичных сущностей в "Оранжевой книге".

Перечислим классы функциональных требований ОК:

  1. идентификация и аутентификация;
  2. защита данных пользователя;
  3. защита функций безопасности (требования относятся к целостности и контролю данных сервисов безопасности и реализующих их механизмов);
  4. управление безопасностью (требования этого класса относятся к управлению атрибутами и параметрами безопасности);
  5. аудит безопасности (выявление, регистрация, хранение, анализ данных, затрагивающих безопасность объекта оценки, реагирование на возможное нарушение безопасности);
  6. доступ к объекту оценки;
  7. приватность (защита пользователя от раскрытия и несанкционированного использования его идентификационных данных);
  8. использование ресурсов (требования к доступности информации);
  9. криптографическая поддержка (управление ключами);
  10. связь (аутентификация сторон, участвующих в обмене данными);
  11. доверенный маршрут/канал (для связи с сервисами

безопасности).

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

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

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

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

 

Каждый элемент требований доверия принадлежит одному из трех типов:

  1. действия разработчиков;
  2. представление и содержание свидетельств;
  3. действия оценщиков.

 

Всего в ОК 10 классов, 44 семейства, 93 компонента требований доверия безопасности. Перечислим классы:

  1. разработка (требования для поэтапной детализации функций безопасности от краткой спецификации до реализации);
  2. поддержка жизненного цикла (требования к модели жизненного цикла, включая порядок устранения недостатков и защиту среды разработки);
  3. тестирование;
  4. оценка уязвимостей (включая оценку стойкости функций безопасности);
  5. поставка и эксплуатация;
  6. управление конфигурацией;
  7. руководства (требования к эксплуатационной документации);
  8. поддержка доверия (для поддержки этапов жизненного цикла после сертификации);
  9. оценка профиля защиты;
  10. оценка задания по безопасности.

6. Руководящие документы по защите от несанкционированного доступа Гостехкомиссии при Президенте РФ

Под штатными средствами понимается совокупность программного, микропрограммного и технического обеспечения СВТ или АС.

В Концепции формулируются следующие основные принципы защиты от НСД к информации:

  1. Защита СВТ обеспечивается комплексом программно-технических средств.
  2. Защита АС обеспечивается комплексом программно-технических средств и поддерживающих их организационных мер.
  3. Защита АС должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ.
  4. Программно-технические средства защиты не должны существенно ухудшать основные функциональные характеристики АС (надежность, быстродействие, возможность изменения конфигурации АС).
  5. Неотъемлемой частью работ по защите является оценка эффективности средств защиты, осуществляемая по методике, учитывающей всю совокупность технических характеристик оцениваемого объекта, включая технические решения и практическую реализацию средств защиты.
  6. Защита АС должна предусматривать контроль эффективности средств защиты от НСД. Этот контроль может быть либо периодическим, либо инициироваться по мере необходимости пользователем АС или контролирующими органами.

 

В качестве главного средства защиты от НСД к информации в Концепции рассматривается система разграничения доступа (СРД) субъектов к объектам доступа.

 

Основными функциями СРД являются:

  1. реализация правил разграничения доступа (ПРД) субъектов и их процессов к данным;
  2. реализация ПРД субъектов и их процессов к устройствам создания твердых копий;
  3. изоляция программ процесса, выполняемого в интересах субъекта, от других субъектов;
  4. управление потоками данных с целью предотвращения записи данных на носители несоответствующего грифа;
  5. реализация правил обмена данными между субъектами для АС и СВТ, построенных по сетевым принципам.

 

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

  1. идентификацию и опознание (аутентификацию) субъектов и поддержание привязки субъекта к процессу, выполняемому для субъекта;
  2. регистрацию действий субъекта и его процесса;
  3. предоставление возможностей исключения и включения новых субъектов и объектов доступа, а также изменение полномочий субъектов;
  4. реакцию на попытки НСД, например, сигнализацию, блокировку, восстановление после НСД;
  5. тестирование;
  6. очистку оперативной памяти и рабочих областей на магнитных носителях после завершения работы пользователя с защищаемыми данными;
  7. учет выходных печатных и графических форм и твердых копий в АС;
  8. контроль целостности программной и информационной части как СРД, так и обеспечивающих ее средств.

 

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

  1. степень полноты охвата ПРД реализованной СРД и ее качество;
  2. состав и качество обеспечивающих средств для СРД;
  3. гарантии правильности функционирования СРД и обеспечивающих ее средств.

 

Устанавливается семь классов защищенности СВТ от НСД к информации.

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

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

 

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

SpyLOG

Персональный сайт преподавателя АЕК

Rambler's Top100