Законадательная база Механизмы безопасности «Оранжевая книга»

Были впервые определены такие понятия как «политика безопасности», ядро безопасности, уровень гарантированности, доверие. Предусмотрено классов безопасности– C1, C2, B1, B2, B3, A1. Чтобы в результате процедуры сертификации систему можно было отнести к некоторому классу, ее политика безопасности и уровень гарантированности должны удовлетворять заданным требованиям.

Отличительной чертой этого доку­мента является его ориентация на системы военного применения, в основном на операционные системы.

Недостатки:отодвинуты такие требования:

как извещение о нарушении защиты,

конфигурационное управление,

безопасный запуск и восстановление после сбоев,

коммуникационный аспект..

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

В 1992 году Гостехкомиссия (ГТК) опубликовала пять Руково­дящих документов,

1. Защита от НСД. Термины и определения

2. Концепция защиты СВТ и АС от НСД к информации

3. АС. Защита от НСД. Классификация Ас и требования по ЗИ

4. Средства ВТ от НСД. Показатели защищенности

5. Временное положение по организации разработки, изготовлению и эксплуатации программных и тех. средств ЗИ от НСД в АС и СВТ

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

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

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

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

Классы -Семейства -Компонент Элемент.

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

Функциональные –требования, предъявляемые к функциям безопасности и реализующим их механизмам. Сгруппированы на основе выполняемой роли или цели безопасности. Существует 11 функциональных классов, 66 семейств, 135 компонентов. Перечислим классы функциональных требований ОК:

идентификация и аутентификация;

• защита данных пользователя;

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

• управление безопасностью (управление атрибутами и параметрами безопасности);

• аудит безопасности;

• доступ к объекту оценки;

• приватность (защита идентификационных данных пользователя);

• использование ресурсов (доступность информации);

• криптографическая поддержка;

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

• доверенный маршрут/канал (для связи с сервисами безопасности).

Недостатки.

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

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

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

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

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

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

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

• разработка;

• поддержка жизненного цикла;

• тестирование;

• оценка уязвимостей;

• поставка и эксплуатация;

• управление конфигурацией;

• руководства;

• поддержка доверия (поддержка этапов жизненного цикла после сертификации);

К требованиям доверия введены 7 оценочных уровней:

1. Анализ функциональной спецификации, спецификации интерфейсов, эксплуатационной документации, независимое тестирование. Уровень применим, когда угрозы не рассматриваются как серьезные.

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

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

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

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

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

7. Предусматривает формальную верификацию проекта объекта оценки.