Основные требования и средства

Политики

Политики безопасности должны быть подробными, четко определёнными и обязательными для компьютерной системы. Есть две основных политики безопасности:

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

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

Маркирование системы предназначено для предоставления и сохранения целостности меток управления доступом и хранения меток, если объект перемещён.

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

Ответственность

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

Существует три требования по условиям ответственности:

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

Авторизация — проверка разрешения индивидуальному пользователю на получение информации определённого рода.

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

Гарантии

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

Для достижения этих целей необходимо два типа гарантий и соответствующих им элементов:

Механизмы гарантий:

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

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

Гарантии непрерывной защиты — надёжные механизмы, обеспечивающие непрерывную защиту основных средств от преступных и/или несанкционированных изменений.

Документирование

Оформление документации является необходимым условием для подтверждения гарантии надежности ИС и одновременно – инструмент проведения политики безопасности.

Без документации пользователи не будут знать, какой политике следовать и что для этого нужно делать.

Согласно "Оранжевой книге", в комплект документации надежной системы должны входить следующие основные тома:

Руководство пользователя по средствам безопасности.

Руководство администратора по средствам безопасности.

Тестовая документация.

Описание архитектуры.

На практике требуется еще по крайней мере один том - Письменное изложение политики безопасности данной организации.

Руководство пользователя по средствам безопасности

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

Руководство должно давать ответы по крайней мере на следующие вопросы:

Как входить в систему? Как вводить имя и пароль? Как менять пароль? Как часто это нужно делать? Как выбирать новый пароль?

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

Как импортировать и экспортировать информацию, не нарушая правил безопасности?

Как уживаться с системными ограничениями? Почему эти ограничения необходимы? Какой стиль работы сделает ограничения необременительными?

Руководство администратора по средствам безопасности

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

Типичное оглавление Руководства администратора включает в себя следующие пункты:

Каковы основные защитные механизмы?

Как администрировать средства идентификации и аутентификации? В частности, как заводить новых пользователей и удалять старых?

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

Как администрировать средства протоколирования и аудита? Как выбирать регистрируемые события? Как анализировать результаты?

Как администрировать средства принудительного управления доступом? Какие уровни секретности и категории выбрать? Как назначать и менять метки безопасности?

Как генерировать новую, переконфигурированную надежную вычислительную базу?

Как безопасно запускать систему и восстанавливать ее после сбоев и отказов? Как организовать резервное копирование?

Как разделить обязанности системного администратора и оператора?

Тестовая документация

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

Описание архитектуры

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