МИНИСТЕРСТВО ОБРАЗОВАНИЯ И
НАУКИ
РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное
бюджетное образовательное учреждение
высшего профессионального
образования
КАЗАНСКИЙ ГОСУДАРСТВЕННЫЙ
ЭНЕРГЕТИЧЕСКИЙ УНИВЕРСИТЕТ
Кафедра информатики и информационно-управляющих
систем
Дисциплина «Информационная
безопасность и защита информации»
Контрольное задание
Информационные системы и требования
безопасности к ним
Студент Заляева Илюса Ильфатовна
Группа ЗДВУ 1-09
Шифр ЗДВУ 3-09
КАЗАНЬ – 2014
Стандарт ISO/IEC 15408 "Критерии оценки
безопасности информационных технологий"
(издан 1 декабря 1999 года) относится к оценочным
стандартам. Этот международный стандарт
стал итогом почти десятилетней работы
специалистов нескольких стран. Он вобрал
в себя опыт существовавших к тому времени
документов национального и межнационального
масштаба. Именно поэтому этот стандарт
очень часто называют "Общими критериями".
"Общие критерии" являются
метастандартом, определяющим инструменты
оценки безопасности информационных
систем и порядок их использования.
В отличие от "Оранжевой книги",
ОК не содержат предопределенных "классов
безопасности". Такие классы можно строить,
исходя из требований безопасности, существующих
для конкретной организации и/или конкретной
информационной системы.
С программистской точки зрения
ОК можно считать набором библиотек, помогающих
писать содержательные "программы"
- задания по безопасности, типовые профили
защиты и т.п. Программисты знают, насколько
хорошая библиотека упрощает разработку
программ, повышает их качество. Без библиотек,
"с нуля", программы не пишут уже очень
давно; оценка безопасности тоже вышла
на сопоставимый уровень сложности, и
"Общие критерии" предоставили соответствующий
инструментарий.
Важно отметить, что требования
могут быть параметризованы, как и полагается
библиотечным функциям.
Как и "Оранжевая книга",
ОК содержат два основных вида требований
безопасности:
>функциональные, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности и реализующим их механизмам;
>требования доверия, соответствующие пассивному аспекту, предъявляемые к технологии и процессу разработки и эксплуатации.
Требования безопасности предъявляются,
а их выполнение проверяется для определенного
объекта оценки - аппаратно-программного
продукта или информационной системы.
Очень важно, что безопасность
в ОК рассматривается не статично, а в
привязке к жизненному циклу объекта оценки.
Выделяются следующие этапы:
>определение назначения, условий применения, целей и требований безопасности;
>проектирование и разработка;
>испытания, оценка и сертификация;
>внедрение и эксплуатация.
В ОК объект оценки рассматривается
в контексте среды безопасности, которая
характеризуется определенными условиями
и угрозами.
В свою очередь, угрозы характеризуются
следующими параметрами:
>уязвимые места, которые могут быть использованы;
>ресурсы (активы), которые могут пострадать.
Уязвимые места могут возникать
из-за недостатка в:
>требованиях безопасности;
Слабые места по возможности
следует устранить, минимизировать или
хотя бы постараться ограничить возможный
ущерб от их преднамеренного использования
или случайной активизации.
С точки зрения технологии программирования
в ОК использован устаревший библиотечный
(не объектный) подход. Чтобы, тем не менее,
структурировать пространство требований,
в "Общих критериях" введена иерархия
класс-семейство-компонент-элемент.
Классы определяют наиболее
общую, "предметную" группировку
требований (например, функциональные
требования подотчетности).
Семейства в пределах класса
различаются по строгости и другим нюансам
требований.
Компонент - минимальный набор
требований, фигурирующий как целое.
Элемент - неделимое требование.
Как и между библиотечными функциями,
между компонентами ОК могут существовать
зависимости. Они возникают, когда компонент
сам по себе недостаточен для достижения
цели безопасности. Вообще говоря, не все
комбинации компонентов имеют смысл, и
понятие зависимости в какой-то степени
компенсирует недостаточную выразительность
библиотечной организации, хотя и не заменяет
объединение функций в содержательные
объектные интерфейсы.
Как указывалось выше, с помощью
библиотек могут формироваться два вида
нормативных документов: профиль защиты
и задание по безопасности.
Профиль защиты (ПЗ) представляет
собой типовой набор требований, которым
должны удовлетворять продукты и/или системы
определенного класса (например, операционные
системы на компьютерах в правительственных
организациях).[3]
Задание по безопасности содержит
совокупность требований к конкретной
разработке, выполнение которых обеспечивает
достижение поставленных целей безопасности.
Выше мы отмечали, что в ОК нет
готовых классов защиты. Сформировать
классификацию в терминах "Общих критериев"
- значит определить несколько иерархически
упорядоченных (содержащих усиливающиеся
требования) профилей защиты, в максимально
возможной степени использующих стандартные
функциональные требования и требования
доверия безопасности.
Выделение некоторого подмножества
из всего множества профилей защиты во
многом носит субъективный характер. По
целому ряду соображений (одним из которых
является желание придерживаться объектно-ориентированного
подхода) целесообразно, на наш взгляд,
сформировать сначала отправную точку
классификации, выделив базовый (минимальный)
ПЗ, а дополнительные требования компоновать
в функциональные пакеты.
Функциональный пакет - это
неоднократно используемая совокупность
компонентов, объединенных для достижения
определенных целей безопасности. "Общие
критерии" не регламентируют структуру
пакетов, процедуры верификации, регистрации
и т.п., отводя им роль технологического
средства формирования ПЗ.
Базовый профиль защиты должен
включать требования к основным (обязательным
в любом случае) возможностям. Производные
профили получаются из базового путем
добавления необходимых пакетов расширения,
то есть подобно тому, как создаются производные
классы в объектно-ориентированных языках
программирования.
Функциональные требования
Функциональные требования
сгруппированы на основе выполняемой
ими роли или обслуживаемой цели безопасности.
Всего в "Общих критериях" представлено
11 функциональных классов, 66 семейств,
135 компонентов. Это, конечно, значительно
больше, чем число аналогичных сущностей
в "Оранжевой книге".
Перечислим классы функциональных
требований ОК:
>идентификация и аутентификация;
>защита данных пользователя;
>защита функций безопасности (требования относятся к целостности и контролю данных сервисов безопасности и реализующих их механизмов);
>управление безопасностью (требования этого класса относятся к управлению атрибутами и параметрами безопасности);
>аудит безопасности (выявление, регистрация, хранение, анализ данных, затрагивающих безопасность объекта оценки, реагирование на возможное нарушение безопасности);
>доступ к объекту оценки;
>приватность (защита пользователя от раскрытия и несанкционированного использования его идентификационных данных);
>использование ресурсов (требования к доступности информации);
>криптографическая поддержка (управление ключами);
>связь (аутентификация сторон, участвующих в обмене данными);
>доверенный маршрут/канал (для связи с сервисами безопасности).
Опишем подробнее два класса,
демонстрирующие особенности современного
подхода к ИБ.[1]
Класс "Приватность" содержит
4 семейства функциональных требований.
Анонимность. Позволяет выполнять
действия без раскрытия идентификатора
пользователя другим пользователям, субъектам
и/или объектам. Анонимность может быть
полной или выборочной. В последнем случае
она может относиться не ко всем операциям
и/или не ко всем пользователям (например,
у уполномоченного пользователя может
оставаться возможность выяснения идентификаторов
пользователей).
Псевдонимность. Напоминает
анонимность, но при применении псевдонима
поддерживается ссылка на идентификатор
пользователя для обеспечения подотчетности
или для других целей.
Невозможность ассоциации.
Семейство обеспечивает возможность неоднократного
использования информационных сервисов,
но не позволяет ассоциировать случаи
использования между собой и приписать
их одному лицу. Невозможность ассоциации
защищает от построения профилей поведения
пользователей (и, следовательно, от получения
информации на основе подобных профилей).
Скрытность. Требования данного
семейства направлены на то, чтобы можно
было использовать информационный сервис
с сокрытием факта использования. Для
реализации скрытности может применяться,
например, широковещательное распространение
информации, без указания конкретного
адресата. Годятся для реализации скрытности
и методы стеганографии, когда скрывается
не только содержание сообщения (как в
криптографии), но и сам факт его отправки.
Еще один показательный (с нашей
точки зрения) класс функциональных требований
- "Использование ресурсов", содержащий
требования доступности. Он включает три
семейства.
Отказоустойчивость. Требования
этого семейства направлены на сохранение
доступности информационных сервисов
даже в случае сбоя или отказа. В ОК различаются
активная и пассивная отказоустойчивость.
Активный механизм содержит специальные
функции, которые активизируются в случае
сбоя. Пассивная отказоустойчивость подразумевает
наличие избыточности с возможностью
нейтрализации ошибок.