Библиотека

Наши друзья

Менеджмент.com.ua .:. Интернет-портал для управленцев Consulting.ru Организация времени - тайм менеджмент и управление временем

О сайте

Проект “Vernikov.ru” — это библиотека, содержащая в себе уникальную и качественную подборку аналитических материалов по вопросам экономики, менеджмента и информационных технологий. Материалов в Интернете очень много. Мы не пытаемся опубликовать всё. Мы экономим Ваше время и публикуем только лучшее.

Помимо доступа к материалам, на сайте “Vernikov.ru” любой посетитель, столкнувшись с новыми и сложными задачами, может быстро и бесплатно получить консультацию у профессионалов.

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

Автор: В.Ю. Гайкович, Д.В. Ершов. 29 Июля 2009, 15:01

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

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

  • Анализ международных и национальных стандартов по вопросам защиты от проникновения в компьютерные системы и сети и несанкционированного доступа к   информации
    • Стандарт ISO
    • Стандарты ECMA
    • Система стандартов МО США
    • Критерии оценки безопасности компьютерных систем Великобритании
    • Руководящие документы России
  • Сравнение стандартов России и США

 

Рассмотрим    основные    направления стандартизации, нашедшие отражение в международных и национальных стандартах и руководящих документах, а именно в:

     1) директиве 5200.28 и стандарте  5200.28  STD  Министерства обороны США [1];

     2) международных стандартах ISO 2382/8 и ISO 7498/2 [7,8]  и рекомендациях по их применению [7];

     3)  отчетах технических  групп Европейской Ассоциации Производителей Компьютеров по безопасности открытых распределенных систем (European Computer Machinery Association  -
ECMA) [9,10];

     4) руководящих документах по обеспечению безопасности систем обработки информации Великобритании [11];

     5) руководящих документах по защите от  несанкционированного доступа к информации Гостехкомиссии России [12-16].

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


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

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

4.2.1.1. Стандарт ISO

     Для обеспечения безопасности распределенных систем Международная организация стандартов ISO разработала дополнение к базовой эталонной модели взаимодействия открытых   систем  и выпустила в 1988 году стандарт ISO 7498-2  Security  Architecture (Архитектура безопасности) [8].
     Этот стандарт определяет угрозы безопасности и устанавливает требования к безопасности в среде взаимодействия открытых систем.
     Архитектура безопасности охватывает общее описание средств защиты  данных  и  методов,  связанных  с   их   работой.   Защита предусматривает:
     - предотвращение чтения сообщений любыми лицами;
     - защиту трафика от его анализа посторонними;
     - обнаружение изменений блоков данных;
     - управление методами кодирования информации.

     Одной из  важнейших  составляющих  архитектуры  безопасности является политика безопасности,  то  есть  совокупность  законов, правил и требований, регламентирующих  деятельность организации по управлению,  защите  и  распределению  чувствительной  информации [17].  Обычно,  вначале  политика  безопасности описывается на естественном языке. Естественный язык прост для понимания, однако он  допускает  возможность  неоднозначного  трактования  понятий. Поэтому для описания модели политики безопасности  применяются
формальные языки (математические нотации, алгоритмические языки, языки программирования или языки спецификаций).
     Реализация формальной модели политики безопасности  строится с использованием так называемой Доверительной Вычислительной Базы (ДВБ,Trusted  Computing  Base-TCB),  включающей общие механизмы внутренней  защиты системы (аппаратные, микропрограммные и программные),  комбинация которых обеспечивает реализацию требований политики  безопасности, образует базовое окружение защиты и поддерживает пользовательские службы, необходимые в защищенных компьютерных системах.

Требования стандарта ISO по номенклатуре услуг, предоставляемых системой безопасности

     Система безопасности в соответствии со стандартом ISO должна обеспечивать следующие услуги безопасности:

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

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

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

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

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

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

     7.  Конфиденциальность трафика предотвращает получение информации путем наблюдения трафика.

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

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

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

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

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

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

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

     Распределение услуг безопасности по уровням эталонной модели ISO приведено в таблице 4.2.1.

Таблица 4.2.1

Услуги безопасности Уровни Эталонной модели OSI
1 2 3 4 5 6 7
Аутентификация однорангового объекта     * *     *
Аутентификация источника данных     * *     *
Контроль доступа     * *     *
Конфиденциальность соединения * * * *   * *
Конфиденциальность без установления соединения   * * *   * *
Конфиденциальность выделенного поля           * *
Конфиденицальность трафика *   *       *
Целостность соединения с восстановлением       *     *
Целостность соединения без восстановления     * *     *
Целостность выделенного поля с установлением соединения             *
Целостность блока данных без установления соединения     * *     *
Целостность выделенного поля без установления соединения             *
Доказательство источника             *
Доказательство доставки             *

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

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

 Управление безопасностью

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

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

4.2.1.2. Стандарты ECMA

 Стандарты ECMA разработаны 9-ой Технической группой 32-го Технического Комитета (TG9/TC32) ECMA.
 Основной стандарт, получивший название TR/46 (Technical Report), был опубликован в июле 1988 года [9]. В нем приводится некоторая абстрактная модель, внутри которой определяются
стандарты безопасного взаимодействия распределенных систем. Основными выводами этого документа являются:
  стандарты безопасности не должны зависеть от выбранной политики безопасности;
  подсистема безопасности в открытых системах должна распознавать различные области защиты, представленные различными администраторами.
 Позже был разработан стандарт ECMA-138 "Security in Open Systems - Data Elements and Service Definitions" [10], который определяет услуги безопасности, нуждающиеся в дальнейшей
стандартизации. Этот стандарт предназначен для разработчиков стандартов прикладных служб (другие группы в TC32, группы ISO и CCITT). Этот стандарт показывает как добавить средства
безопасности в разрабатываемые приложения в соответствии с общей моделью и как достичь взаимодействия (interoperability) с другими приложениями.
 В дальнейшем модель, предложенная в стандарте TR/46 развивается в связи с двумя основными факторами :
  переход от открытых систем (open systems), в смысле Эталонной модели ISO к распределенным системам вообще, в которых модель ISO представляет собой лишь некоторую часть. Это позволяет учесть деятельность ISO по стандартизации в области открытых распределенных вычислений (Open Distributed Processing - ODP);
  новая генерация TR/46 описана в терминах объектов для облегчения дальнейших работ по стандартизации.

  Сферы защиты.

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

  +------------------------------------------------------------+
  ¦                                                            ¦
  ¦ +----------+                                   +----------+¦
  ¦ ¦Пользова- ¦                                   ¦Пользова- ¦¦
  ¦ ¦тель      ¦+---------------------------------+¦тель      ¦¦
  ¦ +----------+¦  +---------------+              ¦+----------+¦
  ¦    +--------+  ¦ +--+          ¦              +-------+    ¦
  ¦    ¦ +----+    ¦ ¦  ¦   +--+   ¦  +----+  +----+      ¦    ¦
  ¦    ¦ ¦    ¦    ¦ +--+   ¦  ¦   ¦  ¦    ¦  ¦    ¦      ¦    ¦
  ¦    ¦ +----+    ¦ +--+   +--+   ¦  +----+  +----+      ¦    ¦
  ¦    +--------+  ¦ +--+     ¦    ¦----+-------+ --------+    ¦
  ¦ +----------+¦  +----------+----+    ¦         ¦+----------+¦
  ¦ ¦Пользова- ¦+------------++---------+---------+¦Пользова- ¦¦
  ¦ ¦тель      ¦      ¦      ¦¦         ¦          ¦тель      ¦¦
  ¦ +----------+      ¦      ¦¦         ¦          +----------+¦
  ¦                   ¦      ¦¦         ¦                      ¦
  +-------------------+------++---------+----------------------+
                      ¦      ¦¦         ¦
  Первое кольцо ------+      ¦¦         +--- Объекты системы
     защиты                  ¦¦
                             ¦¦
  Второе кольцо -------------++--------------- Третье кольцо
 защиты                                         защиты

               Рис. 4.2.1.  Компоненты модели ECMA

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

 Основные определения и термины, встречающиеся в  стандартах ECMA


 Управляющие атрибуты (Control Attributes) - атрибуты, связанные с объектом защиты и используемые вместе с атрибутами привилегий для управления доступом к этому объекту.
 Атрибуты привилегий (Privileged Attributes) - атрибуты, связанные с объектом защиты, которые будучи использованными совместно с управляющими атрибутами при доступе к объекту,
определяют права доступа субъекта по отношению к этому объекту.
 Сертификат атрибутов привилегий (Privileged Attributes Certificate) - набор атрибутов привилегий и информации, управляющей их использованием, находящихся под криптографической
защитой.
 Объект защиты (Security Object) - сущность, доступ к которой управляется политикой безопасности. Например - рабочая станция, файл, элемент данных.
 Субъект защиты (Security Subject) - сущность, в активном режиме запрашивающая доступ к объекту защиты. Объект защиты может состоять из нескольких компонентов, каждый из которых обладает своими атрибутами привилегий.

 Информация о полномочиях

 Ключевая концепция модели безопасности для открытых распределенных систем заключается в использовании информации о полномочиях (security information). Информация о полномочиях генерируется определенными службами безопасности в ответ на аутентифицированные запросы к ним и затем используется другими службами безопасности для разрешения или запрещения определенных действий.
 Информация о полномочиях есть средство при помощи которого сведения о полномочиях (security knowledge) распространяются внутри распределенной системы. Это означает, что эта информация должна быть надежной, а также что ее можно легко передавать любому, даже незащищенному объекту.
 При построении модели сделано предположение об отсутствии существования защищенных объектов. Защищенными предполагаются только службы безопасности и инфраструктура безопасности. Инфраструктура безопасности есть часть инфраструктуры распределенной системы, которая управляет безопасностью. Информация о полномочиях, передаваемая в распределенной системе упакована и защищена от нежелательного использования. После получения она проверяется получателем (обычно одной из служб безопасности) и затем используется для определения прав доступа. В этом случае информация о полномочиях использована для распространения доверия и привилегий в распределенной системе.
 В рамках стандарта разработан единый формат для передачи информации о полномочиях внутри распределенной системы. Он назван сертификатом атрибутов привилегий (privileged attribute certificate - PAC). Информация о полномочиях кодируется как набор атрибутов безопасности, совпадающих с атрибутами, используемыми в стандарте ISO "Information Processing Systems Open Systems
Interconnection The Directory" [7]. Сам PAC защищен от изменения и незаконного использования.

 Службы безопасности

 Классы служб безопасности, предусмотренные в модели представлена на рис.4.2.2.

                         +-------------------------+
                    ¦Классы служб безопасности¦
                    +-------------------------+
               +------------------+---------------------+
        +--------------+    +---------------+    +--------------+
        ¦  Информация о¦    ¦  Управление   ¦    ¦ Слежение за  ¦
        ¦  полномочиях ¦    ¦ безопасностью ¦    ¦безопасностью ¦
        +--------------+    +---------------+    +--------------+
  +------------+            +-----+                     ¦
  ¦ +---------------------+ ¦+-----------------+  +-------------+
  +-¦Служба аутентификации¦ +¦Служба безопасно-¦  ¦ Служба сбора¦
  ¦ +---------------------+ ¦¦го взаимодействия¦  ¦ информации о¦
  ¦ +---------------------+ ¦+-----------------+  ¦ безопасности¦
  +-¦Служба атрибутов     ¦ ¦+------------------+ +-------------+
  ¦ +---------------------+ +¦Служба авторизации¦
  ¦ +---------------------+  +------------------+
  +-¦Служба обмена между  ¦
    ¦областями безопас-   ¦
    ¦ности                ¦
    +---------------------+


                 Рис. 4.2.2. Службы безопасности

 Класс служб информации о полномочиях (Security Information Class) создает информацию о полномочиях, используемая внутри распределенной системы. Он включает в себя службы аутентификации, атрибутов и обмена между областями безопасности.
 Основное назначение службы аутентификации заключается в получении от пользователя некоторых "опознавательных знаков" (credentials), их проверке и выдаче мандата (certified indentity). Большинство механизмов аутентификации предназначены для пользователей, однако они могут быть применены и к объектам. Для решения проблемы аутентификации объектов и пользователей используется концепция "поручителя объекта". В качестве поручителя для объекта выступает инфраструктура, порождающая объект и выделяющая ресурсы для его существования. Для пользователя в модели предусмотрен "поручитель субъекта", функцией которого является с одной стороны - взаимодействие с пользователем с целью получения его "опознавательных знаков" (пароль, биометрические признаки и др.), а с другой стороны взаимодействие со службой аутентификации соответствующим образом. Служба аутентификации с "поручителем субъекта" образует внешнее кольцо защиты.
 Служба атрибутов предназначена для чтения мандата или установки проверяемых привилегий и некоторых действий и возврата большого множества проверенных привилегий. В модели учтено что синтаксис атрибутов может быть различным в разных частях распределенной системы. Эта служба также выполняет преобразование представления PAC для различных сред (но не для различных областей).
 В различных областях безопасности (security domains) могут быть реализованы различные политики безопасности, а также области могут управляться различными администраторами безопасности. Различные области безопасности будут иметь различные полномочия для подписи PAC, а также, возможно, различия в синтаксисе и семантике.Назначение службы обмена между областями безопасности преобразование формата PAC при переходе из одной области в другую.
 Класс служб управления (Security Control Class) обеспечивает внутреннее управление распределенной системой. Он читает, проверяет и интерпретирует информацию о полномочиях для
управления деятельностью сущностей в распределенных системах.
 Служба безопасного взаимодействия (Secure Assosiation Service) создана для обеспечения безопасной связи включая всю необходимую коммуникационную безопасность между двумя любыми объектами системы независимо от того, в какой области безопасности они находятся. Составная часть этой службы находится на каждом конце объединения. Предполагается, что взаимодействие объектов невозможно без обращения к этой службе.
 Назначение службы авторизации - принимать решения по управлению доступом. Она считывает атрибуты привилегий инициатора, управляющие атрибуты цели, описания операции и другую
необходимую информацию. Служба возвращает результат решения: "ДА", "НЕТ" или "ОШИБКА". Службы безопасного взаимодействия и авторизации образуют кольцо безопасности вокруг каждого объекта.
 Класс служб слежения за безопасностью (Security Monitoring Class) обеспечивает внутреннее слежение и управление безопасностью в распределенной системе в целом. Он представлен
только одной службой - службой сбора информации о безопасности системы (Security Audit Information Collection Service).
 Служба сбора информации о безопасности системы предназначена не только для сбора некоторой информации, но также и для ее обработки и анализа и управления восстановлением безопасности.
 Модель безопасности, разработанная TG9/TC32, предусматривает минимальные ограничения для разработчика прикладных систем.
 Главная особенность модели заключается в том, что эта модель независима от любой политики безопасности или механизма управления доступом. Так, например, она поддерживает
избирательную политику (списки доступа) или полномочную политику безопасности.
 Логический сервис модели может быть реализован различными путями: в виде отдельных прикладных приложений на отдельных компьютерах или в виде единой операционной системы на каждом из компьютеров.
 Взаимодействия между службами не ограничивают разработчика прикладных систем, что позволяет ему самостоятельно решать каким образом манипулировать передачей информации о привилегиях для достижения максимального удобства для пользователя.

  Стандарты второй группы


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

4.2.1.3. Система стандартов Министерства обороны США в области  компьютерной безопасности.

 В период с 1983 по 1988 год в США Министерством обороны (Department of Defence, DoD) и Национальным комитетом по компьютерной безопасности (National Committee of Computer
Security, NCSC) была разработана система стандартов в области компьютерной безопасности. Она включает следующие документы :
 - "Критерий оценки безопасности компьютерных систем" [1], больше известный как "Оранжевая книга";
 - "Программа оценки безопасности продуктов"[2];
 - "Руководство по применению критерия оценки безопасности компьютерных систем в специфических средах" [3], известный под названием "Желтая книга";
 - комплект документов под общим названием "Радужная серия" (Rainbow Series), включающий "Разъяснение критерия оценки безопасности компьютерных систем для безопасных сетей" [4], "Разъяснение критерия оценки безопасности компьютерных сетей для безопасных СУБД" [5], "Разъяснение критерия оценки безопасности компьютерных систем для отдельных подсистем безопасности" [6].
 Ниже будет несколько подробнее рассмотрена "Оранжевая книга", как основной критерий оценки безопасности компьютерных систем.

 "Оранжевая книга" необходима :

 - пользователям, для того,чтобы они могли оценить степень доверия системе, выбираемой для обработки конфиденциальной информации;
 - производителям, чтобы они знали требования предъявляемые к системам защиты информации и учитывали это в своих коммерческих продуктах.
 - разработчикам стандартов для обеспечения основы разработки других стандартов в области безопасности.
 В ней изложена единые для МО США требования к политике безопасности, требования безопасности, порядок определения классов защищенности информации в компьютерных системах МО США.
 В документе выделены общие требования по обеспечению безопасности обрабатываемой информации, затем определен перечень показателей (показатели защищенности), характеризующих реализацию общих требований. Совокупность этих показателей определяет уровень безопасности рассматриваемой системы.
 Документ определяет шесть основных требований безопасности. Четыре из них относятся к управлению доступом к информации (политика безопасности, маркировка, идентификация и учет), а два к предоставляемым гарантиям (уверенность в системе и непрерывность защиты).
 Эти основные требования конкретизируются в показателях защищенности. Эти показатели приведены в Таблице 4.2.2. В документе подробно описывается требования к реализации каждого показателя защищенности для соответствующего класса.
 Класс защищенности присваивается системе при прохождении ею сертификации. Во время сертификации специалисты NCSC на основании представленных исходных текстов программ и документации на систему оценивают уровень реализации той или иной возможности системы по защите информации.
 Следует отметить, что сертификации подвергается вся система в целом, а класс защищенности присваивается только в том случае, когда самый "слабый" показатель удовлетворяет требованиям класса защищенности.

Таблица 4.2.2

  Наименование показателя  
С1 С2 B1 B2 B3 A1
Security Policy
1. Discretionary Access Control + + + = = =
2. Mandatory Access Control  - - + + = =
3. Labels - - + + = =
4. Labels Integrity - - + = = =
5. Working Labels - - - + = =
6. Label Frequency - - + = = =
7. Object Reuse - + = + = =
8. Resource Encapsulation - + = - - -
9. Exported Machine Readable Output - - + = = =
10. Exported Human-Readable Labels - - + = = =
 ACCOUNTABILITY
 11. Indentification & Authentification  + + =  = = =
 12.  Audit  - +  +  +  + =
 13.  Trusted Path  - -  - + =  =
        ASSURANCE
 14.  Design Specification&Verification  -  -  +  +  +  +
 15.  System Architecture  +  =  =  +  +  =
 16.  System Integrity  +  = =  =  =  =
 17.  Security Testing  + +  +  +  + =
 18.  Trusted Recovery  - -  -  -  +  =
 19.  Configuration Management  -  -  -  +  +  +
 20.  Trusted Facility Management  - -  -  +  + =
 21.  Trusted Distribution  -  -  -  - +  =
 22.  Covert Channel Analysis  -  -  -  +  =  +
        DOCUMENTATION
 23.  Security Features User's Guide  +  =  =  =  =  =
 24.  Trusted Facility Manual  +  +  +  +  +  =
 25.  Test Documentation  +  =  =  +  =  +
 26.  Design Documentation  +  =  +  +  =  +

Обозначения:

  "-" - нет требований к данному классу;
  "+" - новые или дополнительные требования,
  "=" - требования совпадают с требованиями к предыдущему классу.

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

Класс D : минимальная защищенность.

 Класс D присваивается тем системам, которые не прошли испытаний на более высокий уровень защищенности, а также системы, использующие для защиты лишь отдельные функции (подсистемы) безопасности. Структура этого класса приведена в документе [6].
 В класс D включаются те системы, которые не прошли испытаний на более высокий уровень защищенности, а также системы, использующие для защиты лишь отдельные функции (подсистемы) безопасности. В документах [1,18] по реализуемым функциям все подсистемы разделены на четыре основных группы :
  подсистемы обеспечения избирательного управления доступом (Discretionary Access Control, DAC);
  подсистемы обеспечения очистки памяти перед повторным использованием объектов (Object Reuse, OR);
  подсистемы обеспечения идентификации и аутентификации субъектов (Identification & Authentication, I&A) ;
  подсистемы контроля (Audit, AUD).
 В отличие от 7 класса защищенности, предусмотренного в РД ГТК России, в классе D выделяются три подуровня: D1, D2 и D3.
 Класс D1 сопоставляется подсистемам, соответствующим интерпретации требований, предъявляемых к системам класса C1.
 Класс D2 сопоставляется подсистемам, соответствующим интерпретации требований, предъявляемых к системам класса C2.
 Класс D3 зарезервирован для подсистем избирательного управления доступом и подсистем контроля, соответствующих интерпретациям функциональных требований B3 (см. Таблицу 4.2.3).

   Таблица 4.2.3

Функция подсистемы Класс безопасности Возможные рейтинги
Избирательное управление доступом DAC/D

DAC/D1

DAC/D2

DAC/D3

Повторное использование объекта OR/D OR/D2
Идентификация и аутентификация I&A/D

I&A/D1

I&A/D2

Контроль AUD/D

AUD/D2

AUD/D3


Класс С1: избирательная защита.

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

Класс С2: управляемый доступ.

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

 Системы класса B


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

 Класс B1: меточная защита.

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

 Класс B2: структурированная защита

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

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

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

 Класс A1: верифицированная разработка.

 Системы этого класса отличаются от класса B3 тем, что для проверки спецификаций применяются формальные методы.

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

 Для целей криптографической защиты широко используется стандарт DES [20], утвержденный в США Национальным институтом стандартов и технологий (National Institute of Standarts and
Technologies - NIST).

4.2.1.4. Критерии оценки безопасности компьютерных систем Великобритании

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

 Требования безопасности подразделяются на два типа:

 а) управление безопасностью - обязательные (X1 - X6)

 X1 Возможность учета (Accountability)
 X2 Аутентификация (Autentication)
 X3 Разрешение (Permission)
 X4 Защита объектов (Object Protection)
 X5 Повторное использование объектов (Object Reuse)
 X6 Отсутствие отказов (No Repudiation);

 б) цели безопасности - необязательные (Y1 - Y5)

 Y1 Отсутствие добавлений (No addition)
 Y2 Отсутствие потерь (No loss)
 Y3 Ограничения (Confinement)
 Y4 Своевременность (Timeliness)
 Y5 Отсутствие отказов ресурсов (No denial of resources).

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

 4.2.1.5. Руководящие документы России

 Разработкой руководящих документов в области защиты информации в России занимается специальное подразделение Гостехкомиссия России при Президенте РФ. Все приведенные ниже
документы обязательны для исполнения только в государственном секторе. Для коммерческих структур они носят рекомендательно-консультативный характер. Для получения этих
документов обращайтесь по телефону 293-95-04.
 Руководящие документы Гостехкомиссии России включают [12-16]:
 1) Концепцию защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа (НСД) к информации. Этот документ содержит определение НСД, основные способы осуществления НСД, модель нарушителя, основные направления и принципы организации работ по защите информации от НСД;
 2) Термины и определения в области защиты от НСД к информации. Этот документ вводит в действие основные термины и определения, используемые в других документах;
 3) Показатели защищенности СВТ от НСД к информации. Этот документ устанавливает классификацию СВТ по уровню защищенности от НСД к информации на базе перечня показателей защищенности и совокупности описывающих их требований;
 4) Классификацию автоматизированных систем и требования по защите информации. Документ устанавливает классификацию автоматизированных систем (АС), подлежащих защите от НСД к информации, и требования по защите информации в АС различных классов.
 5) Временное положение о государственном лицензировании деятельности в области защиты информации. Документ устанавливает основные принципы, организационную структуру системы лицензирования деятельности предприятий в сфере оказания услуг в области защиты информации, а также правила осуществления лицензирования и надзора за деятельностью предприятий, получивших лицензию.
 Эти документы изданы в конце 1992 года.
 Здесь мы кратко рассмотрим содержание только одного документа "Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели
защищенности." В этом документе определены семь классов защищенности СВТ от НСД к информации. Самый низкий класс - седьмой, самый высокий первый. Каждый класс наследует требования защищенности предыдущего класса.
 Изложенные ниже требования к показателям защищенности предъявляются к общесистемным программным средствам и операционным системам.
 Совокупность всех средств СВТ защиты образует комплекс средств защиты (КСЗ).
 В зависимости от реализованных моделей защиты и надежности их проверки классы подразделяются на четыре группы. Первая группа включает только один седьмой класс (минимальная защищенность).
 Вторая группа характеризуется избирательной защитой и включает шестой и пятый классы. Избирательная защита предусматривает контроль доступа поименованных субъектов к
поименованным объектам системы. При этом для каждой пары "субъект-объект" должны быть определены разрешенные типы доступа. Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).
 Третья группа характеризуется полномочной защитой и включает четвертый, третий и второй классы. Полномочная защита предусматривает присвоение каждому субъекту и объекту системы классификационных меток, указывающих место субъекта (объекта) в соответствующей иерархии. Классификационные метки на объекты устанавливаются пользователем системы или специально выделенным субъектом. Обязательным требованием для классов, входящих в эту группу, является реализация диспетчера доступа (в иностранной литературе - reference monitor, монитор ссылок). Контроль доступа должен осуществляться применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов. Решение о санкционированности запроса на доступ должно приниматься только при одновременном разрешении его и избирательными и полномочными правилами разграничения доступа (ПРД).
 Четвертый класс характеризуется верифицированной защитой и содержит только первый класс.
 Для присвоения класса защищенности система должна содержать руководство администратора по системе, руководство пользователя, тестовую и конструкторскую (проектную) документацию.
 Перечень показателей по классам защищенности СВТ приведен в таблице 4.2.4. Их краткое описание приведено ниже. За полным текстом документа обращайтесь в Гостехкомиссии России.

 Таблица 4.2.4

  Наименование показателя Класс защищенности
6 5 4 3 2 1
Политика безопасности
1. Избирательная политика безопасности + + + = + =
2. Полномочная политика безопасности - - + = = =
3. Повторное использование объектов - + + + = =
4. Изоляция модулей - - + = + =
5. Маркировка документов - - + = = =
6. Защита ввода и вывода на отчуждаемый физический носитель информации - - + = = =
7. Сопоставление пользователя с устройством - - + = = =
Учет
8. Идентификация и аутентификация + = + = = =
9. Регистрация - + + + = =
10. Взаимодействие пользователя с КСЗ - - - + = =
Гарантии
11. Гарантии проектирования  -  +  +  +  +  +
12. Гарантии архитектуры  -  -  -  -  -  +
13.  Надежное восстановление -  -  -  + =  =
14. Целостность КСЗ  - +  + + = =
15. Контроль модификации  - -  -  - + =
16. Контроль дистрибуции  -  -  -  -  +  =
17. Тестирование  +  +  +  +  +  =
        Документация
 18. Руководство пользователя  +  =  =  =  =  =
 19. Руководство по КСЗ  +  +  =  +  +  =
 20. Тестовая документация  + +  +  +  +  =
 21. Конструкторская (проектная) документация  +  +  +  +  +  +


Обозначения:

 "-" - нет требований к данному классу;
 "+" - новые или дополнительные требования,
 "=" - требования совпадают с требованиями к СВТ предыдущего класса.

Шестой класс защищенности

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

Пятый класс защищенности

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

 Четвертый класс защищенности

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

 Третий класс защищенности

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

 Второй класс защищенности

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

 Первый класс защищенности

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

Таблица 4.2.5

  Название показателя по РД Гостехкомиссии Название показателя по "Orange Book"
1. Дискреционный принцип контроля доступа  Discretionary Access Control (DAC)
2. Мандатный принцип контроля доступа

 Mandatory Access Control Labels

Labeb Integrity

Subject Sensivity Labels

Label Frequency

3. Очистка памяти  Object Reuse
4. Изоляция модулей  Аналогичного термина нет.
5. Маркировка документов  Supported Human-Readable Labels
6. Защита ввода и вывода на отчуждаемый физический носитель информации  Exported Machine-Readable Output
7. Сопоставление пользователя с устройством  Trusted path
8. Идентификация и аутентификация  Identification & Authentication
9. Гарантии проектирования  Design Specification & verification
10. Регистрация  Audit
11. Взаимодействие пользователя с КСЗ  Trusted Path
12. Надежное восстановление  Trusted Recovery
13. Целостность КСЗ  System Integrity
14. Контроль модификации

 Trusted Facility Management

Configuration Management

15. Контроль дистрибуции  Trusted Distribution
 16. Гарантии архитектуры  System Architecture
 17. Тестирование  System Testing
 18. Руководство пользователя  Security Features User's Guide
 19.  Руководство по КСЗ  Trusted Facility Manual
 20. Тестовая документация  Test documentation
 21. Конструкторская документация  Design Documentation
 22. Аналогичного термина нет  Covert Channel Analysis

 

 Ниже приводятся результаты сопоставления перечней функциональных требований безопасности и классов защищенности средств и систем, определенных в Руководящих документах ГТК
России и стандарте МО США.
 Анализ терминов показывает, что в некоторых случаях они неудачно переведены (например Discretionary Access Control переведен как "дискреционный принцип контроля доступа", в то
время как целесообразнее перевести его как "избирательный принцип" или "избирательное управление доступом").
 В мандатный (лучше полномочный) принцип доступа в РД ГТК объединены сразу несколько показателей защищенности стандарта МО США, связанные с установкой и поддержанием целостности меток безопасности.
 В контроль модификации объединены два важных показателя управление безопасностью (Trusted Facility Management) и управление конфигурацией (Configuration Management).
 В РД Гостехкомиссии отсутствует показатель "Covert Channel Analysis" (анализ скрытых каналов), присутствующий в стандарте МО США.
 В то же время добавлен новый показатель "Изоляция модулей", который в стандарте МО США отсутствует.
 Сравнительный анализ структуры и содержания РД Гостехкомиссии и стандарта МО США позволяет утверждать следующее:
 1. Отечественный документ менее структурирован, чем его американский прообраз, что затрудняет его понимание и применение;
 2. В отечественном документе применение концепции диспетчера доступа требуется в четвертом классе защищенности, в то время как в американском стандарте это необходимо только на уровне B3. Это усиливает требования по безопасности.
 3. Американский документ конкретнее определяет содержимое документации на КСЗ, в том числе функции администратора безопасности и оператора системы по управлению безопасностью.
 4. В отечественном документе отсутствует упоминание о групповой аутентификации (в классе C1 американского стандарта).
 5. В отечественном документе отсутствует понятие "скрытый канал доступа" и, следовательно, меры по защите от такого типа угроз.
 Сопоставляя содержимое таблиц 4.2.5 и 4.2.6 а также содержание обоих документов можно сделать следующие выводы:
 - несмотря на большое сходство РД Гостехкомиссии являются самостоятельным документом;
 - требования классов безопасности отечественного документа не имеют прямого соответствия классам стандарта МО США.

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

Л И Т Е Р А Т У Р А

 1. DoD Trusted Computer System Evaluation Criteria.
 2. The Trusted Product Evaluation Program.
 3. CSC-STD-003-85, Computer Security Requirements Guidance for Applying the Department of Defense System Evaluation Criteria in Specific Environments.
 4. NCSC-TG-005, Version-1 Trusted Network Interpretation of the trusted Computer System Evaluation Criteria.
 5. NCSC-TG-021, Version-1 Draft Trusted Database Management System Interpretation of the Trusted Computer System Evaluation Criteria.
 6. NCSC-TG-009, Version-1, Computer Security Subsystem Interpretation of the Trusted Computer System Evaluation Criteria.
 7. ISO/DIS 2382/8. Data processing. - Vocabulary - Part 8: Control, integrity and security. - ISO ,1985, 35 p.
 8. ISO/DIS 7498/2. Information Processing Systems - Open Systems Interconnection Reference Model. Part 2: Security Architecture. -ISO, 1989.
 9. ECMA, Security in Open Systems: A Security Framework, TR46.ECMA, 1988, 71p.
 10. ECMA, Security in Open Systems - Data Elements and Service Definitions, ECMA-138,ECMA, December 1989.
 11. Evaluation and Certification Manual, Department of Trade and Industry, Computer Security Branch, Kingsgate House, 66-74, V23.
 12. Гостехкомиссия России. Руководящий документ. Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации. М., Военное издательство, 1992- 12 с.
 13. Гостехкомиссия России. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения. М.:Военное издательство, 1992.-12с.
 14. Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. - М.:Военное издательство, 1992. - 24с.
 15. Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации.-М.:Военное издательство, 1992.-39с.
 16. Гостехкомиссия России. Руководящий документ. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от НСД в автоматизированных системах и средствах вычислительной техники.,- М.:Военное издательство, 1992. 29с.
 17. I.M.Olson, M.D.Abrams, Computer Acces Policy Choices, Computer& Security, volume 9(1990), number 8, p.p.699-714.
 18. Моисеенков И. Американская классификация и принципы оценивания безопасности компьютерных систем//Компьютер-пресс.-1992.-N2,N 3.- с.47-54.
 19. Моисеенков И. Основы безопасности компьютерных систем//Компьютерпресс.-1991.-N10.- с.19-24, N11.-с.7-21, N12.
 20. National Bureau of Standards, "Data Encryption Standard", January 1977, NIST NBS-FIPS PUB 46.
 21. В.И. Удалов, Я.П. Спринцис. Безопасность в среде взаимодействия открытых систем//Автоматика и вычислительная техника.- 1990.- N3,- с.3-11.










 


 

Защитный код
Обновить