Главная страница
Навигация по странице:

  • 4.4.2. Модель Миллена – модель распределения ресурсов

  • 5. Основные критерии защищенности АС. Классы защищенности 5.1. Стандарт оценки безопасности компьютерных систем TCSEC («Оранжевая книга»)

  • Общая структура требований TCSEC

  • Политика безопасности Требование 1.

  • Подотчетность Требование 3

  • Гарантии (корректность) Требование 5

  • Классы защищенности компьютерных систем no TCSEC

  • Группа D. Минимальная защита

  • Группа С. Дискреционная защита Группа С характеризуется наличием дискреционного управления доступом и аудитом действий субъектов. Класс С1

  • Группа В. Мандатное управление доступом

  • ОИБ. основы информ. безопасности. Учебное пособие Томск


    Скачать 1.99 Mb.
    НазваниеУчебное пособие Томск
    Дата22.10.2021
    Размер1.99 Mb.
    Формат файлаpdf
    Имя файлаосновы информ. безопасности.pdf
    ТипУчебное пособие
    #253135
    страница12 из 27
    1   ...   8   9   10   11   12   13   14   15   ...   27
    4.4. Механизм защиты от угрозы отказа в обслуживании
    4.4.1. Мандатная модель
    Мандатная модель включает в себя многие характеристики моделей Белла–Лападула и
    Биба.
    Субъектам системы соответствуют приоритеты, которые могут быть одинаковы, ниже или выше по сравнению с приоритетом любого другого субъекта. Объектам соответствуют степени критичности, имеющие аналогичную иерархическую структуру. Субъект может

    90 требовать услугу у вычислительной системы, запрашивая доступ к объектам системы.
    Говорят, что субъект получает отказ в обслуживании, если его запрос зарегистрирован, но не удовлетворен в течение соответствующего MWT (максимальное время ожидания).
    Рассмотрим правила, описывающие эту модель.
    1. Правило «никаких отказов вверх» (NDU): ни каким объектам с более низким приоритетом не позволено отказывать в обслуживании субъектам с более высокими приоритетами. Но некоторым субъектам с более высоким приоритетом (например администратору) должна предоставляться возможность отказывать в обслуживании объектам с более низким приоритетом, если первые того желают.
    2. Правило NDU(C) – обобщение NDU: субъекты с более низким приоритетом не должны препятствовать запросам услуг субъектов с более высокими приоритетами, производимых через объекты из конкретного множества С. Услуги, предоставляемые для объектов, находящихся в С, никогда не должны устаревать.
    Главное преимущество этих правил – введение понятия приоритета. Недостаток – эти правила имеют смысл для систем с несколькими приоритетами.
    4.4.2. Модель Миллена – модель распределения ресурсов
    В основе модели лежит идея о том, что для выполнения нужного задания субъектам необходимы определенные временные и пространственные требованияк ресурсам.Отказ происходит только в том случае, если распределение пространства и времени для некоторого процесса не отвечает соответствующим требованиям.
    Введем некоторые обозначения:
    Р - множество активных процессов;
    R - множество пассивных ресурсов;
    C – некоторая фиксированная граница (обозначает максимальное число единиц для всех типов ресурсов);
    А
    р
    – вектор распределения – число единиц ресурса, выделенных для процесса р в некотором состоянии;
    СPU – ресурс, используемый для формирования информации о том является ли процесс текущим или застывшим. Если А
    р
    (CPU) =1, то истинным является running(p), если
    А
    р
    (CPU) = 0, то - asleep(p);
    S
    Qp
    – вектор пространственных требований - число единиц каждого ресурса, выделенных процессом р для выполнения необходимого задания в некотором состоянии;
    Т(р) – функция, показывающая когда в последний раз изменились часы для процесса, с целью отражения реального времени;
    Т
    Q
    p
    - вектор временных требований – объем времени, необходимого каждому ресурсу процесса р для выполнения работы.
    Далее представим восемь правил, необходимых для описания модели.
    1. Сумма единиц выделенных ресурсов для всех процессов из Р должна быть меньше системной границы С, т.е. S А
    р

    C.
    2. Текущие процессы должны иметь нулевые пространственные требования, т.е.
    If running(p) then
    S
    Q
    p
    = 0.
    3. В некотором состоянии процесс является текущим и остается текущим и в следующем состоянии, т. е. If running(p) and running(p)
    1
    then А
    р
    1
    = А
    р
    4. Часы процесса изменяются только с изменением СРU, т.е. if А
    р
    (CPU)
    1
    = А
    р
    (CPU), then T(p)
    1
    = T(p).
    5. Часы процесса изменяются только для того, чтобы отразить увеличение во времени, т. е. if А
    р
    (CPU)
    1

    А
    р
    (CPU) then T(p)
    1
    > T(p).
    6. Пространственные требования устанавливаются для застывших процессов, т.е. if asleep(p) then
    S
    Q
    p
    1
    =
    S
    Q
    p
    + А
    р
    - А
    р
    1

    91 7. Временные требования для застывших процессов не устанавливаются, т.е. if asleep(p) then
    Т
    Q
    p
    1
    =
    Т
    Q
    p
    8. Переходы в результате которых процесс останавливается, перераспределяют только ресурсы CPU, т.е. If running(p) and asleep (p)
    1
    then А
    р
    1
    = А
    р
    - CPU.
    5. Основные критерии защищенности АС. Классы защищенности
    5.1. Стандарт оценки безопасности компьютерных систем TCSEC
    («Оранжевая книга»)
    "Критерии оценки безопасности компьютерных систем" (Trusted Computer System
    Evaluation Criteria - TCSEC) [8], получившие неформальное "Оранжевая книга" (по цвету обложки первоначального издания), были разработаны и опубликованы Министерством обороны США в 1983г. с целью определения требований безопасности, предъявляемых к аппаратному, программному и специальному программному и информационному обеспечению компьютерных систем, и выработки методологии и технологии анализа степени поддержки политики безопасности в компьютерных системах в основном военного назначения.
    "Оранжевая книга" поясняет понятие безопасной системы, которая управляет, посредством соответствующих средств, доступом к информации, так что только должным образом авторизованные лица или процессы, действующие от их имени, получают право читать, писать, создавать и удалять информацию. Очевидно, однако, что абсолютно безопасных систем не существует, что это абстракция. Любую систему можно "взломать", если располагать достаточно большими материальными и временными ресурсами. Есть смысл оценивать лишь степень доверия, которое разумно оказать той или иной системе
    Общая структура требований TCSEC
    В «Оранжевой книге» предложены три категории требований безопасности: политика безопасности, аудит и корректность, в рамках которых сформулированы шесть базовых требований безопасности. Первые четыре требования направлены непосредственно на обеспечение безопасности информации, а два последних - на качество средств защиты.
    Рассмотрим эти требования подробнее.
    Политика безопасности
    Требование 1. Политика безопасности. Система должна поддерживать точно определенную политику безопасности. Возможность доступа субъектов к объектам должна определяться на основании их идентификации и набора правил управления доступом. Там, где это необходимо, должна использоваться политика мандатного управления доступом, позволяющая эффективно реализовать разграничение доступа к информации различного уровня конфиденциальности.
    Требование 2. Метки. С объектами должны быть ассоциированы метки безопасности, используемые в качестве исходной информации для процедур контроля доступа. Для реализации мандатного управления доступом система должна обеспечивать возможность присваивать каждому объекту метку или набор атрибутов, определяющих степень конфиденциальности (гриф секретности) объекта и режимы доступа к этому объекту.

    92
    Подотчетность
    Требование 3. Идентификация и аутентификация. Все субъекты должны иметь уникальные идентификаторы. Контроль доступа должен осуществляться на основании результатов идентификации субъекта и объекта доступа, подтверждения подлинности их идентификаторов (аутентификации) и правил разграничения доступа. Данные, используемые для идентификации и аутентификации, должны быть защищены от несанкционированного доступа, модификации и уничтожения и должны быть ассоциированы со всеми активными компонентами компьютерной системы, функционирование которых критично с точки зрения безопасности.
    Требование 4. Регистрация и учет. Для определения степени ответственности пользователей за действия в системе, все происходящие в ней события, имеющие значение с точки зрения безопасности, должны отслеживаться и регистрироваться в защищенном протоколе (т.е. должен существовать объект компьютерной системы, потоки от которого и к которому доступны только субъекту администрирования). Система регистрации должна осуществлять анализ общего потока событий и выделять из него только те события, которые оказывают влияние на безопасность для сокращения объема протокола и повышения эффективности его анализа. Протокол событий должен быть надежно защищен от несанкционированного доступа, модификации и уничтожения.
    Гарантии (корректность)
    Требование 5. Контроль корректности функционирования средств защиты. Средства защиты должны содержать независимые аппаратные и/или программные компоненты, обеспечивающие работоспособность функций защиты. Это означает, что все средства защиты, обеспечивающие политику безопасности, управление атрибутами и метками безопасности, идентификацию и аутентификацию, регистрацию и учет, должны находиться под контролем средств, проверяющих корректность их функционирования. Основной принцип контроля корректности состоит в том, что средства контроля должны быть полностью независимы от средств защиты.
    Требование 6. Непрерывность защиты. Все средства защиты (в том числе и реализующие данное требование) должны быть защищены от несанкционированного вмешательства и/или отключения, причем эта защита должна быть постоянной и непрерывной в любом режиме функционирования системы защиты и компьютерной системы в целом. Данное требование распространяется на весь жизненный цикл компьютерной системы. Кроме того, его выполнение является одной из ключевых аксиом, используемых для формального доказательства безопасности системы.
    Классы защищенности компьютерных систем no TCSEC
    «Оранжевая книга» предусматривает четыре группы критериев, которые соответствуют различной степени защищенности: от минимальной (группа D) до формально доказанной (группа А). Каждая группа включает один или несколько классов.
    Группы D и А содержат по одному классу (классы D и А соответственно), группа С - классы С1, С2, а группа В три класса - В1, В2, ВЗ, характеризующиеся различными наборами требований защищенности. Уровень защищенности возрастает от группы D к группе А, а внутри группы - с увеличением номера класса. Таким образом имеем всего шесть классов безопасности - C l , C2, Bl, B2, ВЗ, А1. Усиление требований осуществляется с постепенным смещением акцентов от положений, определяющих наличие в системе каких- то определенных механизмов защиты, к положениям обеспечивающих высокий уровень гарантий того, что система функционирует в соответствии требованиям политики безопасности.

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

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

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

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

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

    94
    Класс С2. Системы, построенные на основе управляемого дискреционного разграничения доступа.
    Системы, сертифицированные по данному классу, должны удовлетворять всем требованиям, изложенным в классе С1. Однако, системы класса С2 поддерживают более тонкую, чем в классе С1, политику дискреционного разграничения доступа, делающую пользователя индивидуально ответственным за свои действия после процедуры аутентификации в системе, а также аудит событий, связанных с безопасностью системы.
    Политика безопасности. В дополнение к С1, права доступа должны гранулироваться с точностью до пользователя. Механизм управления должен ограничивать распространение прав доступа - только авторизованный пользователь (например, владелец объекта) может предоставлять права доступа другим пользователям. Все объекты должны подвергаться контролю доступа. При выделении хранимого объекта из пула ресурсов надежной вычислительной базы необходимо ликвидировать все следы предыдущих использований.
    Подотчетность. В дополнение к С1, каждый пользователь системы должен уникальным образом идентифицироваться. Каждое регистрируемое действие должно ассоциироваться с конкретным пользователем.
    Надежная вычислительная база должна создавать, поддерживать и защищать журнал регистрационной информации, относящейся к доступу к объектам, контролируемым базой. Должна быть возможность регистрации следующих событий:

    использование механизма идентификации и аутентификации,

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

    удаление объектов;

    действия системных операторов, системных администраторов, администраторов безопасности;

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

    дата и время события;

    идентификатор пользователя;

    тип события;

    результат действия (успех или неудача).
    Для событий идентификации/аутентификации регистрируется также идентификатор устройства (например, терминала). Для действий с объектами регистрируются имена объектов. Системный администратор может выбирать набор регистрируемых событий для каждого пользователя.
    Гарантии. В дополнение к С1, надежная вычислительная база должна изолировать защищаемые ресурсы в той мере, как это диктуется требованиями контроля доступа и подотчетности. Тестирование должно подтвердить отсутствие очевидных недостатков в механизмах изоляции ресурсов и защиты регистрационной информации.
    Документация. Руководство администратора по средствам безопасности в дополнение к С1, должны описываться процедуры обработки регистрационной информации и управления файлами с такой информацией, а также структура записей для каждого типа регистрируемых событий.
    Группа В. Мандатное управление доступом
    Основные требования этой группы - мандатное (полномочное) управление доступом с использованием меток безопасности, реализация некоторой формальной модели политики безопасности, а также наличие спецификаций на функции ТСВ. В системах этой группы постепенно к классу ВЗ должен быть реализован монитор ссылок (или МБО), который должен контролировать все доступы субъектов к объектам системы.

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

    96
    Должно быть представлено неформальное или формальное описание модели политики безопасности, проводимой в жизнь надежной вычислительной базой. Необходимо наличие аргументов в пользу достаточности избранной модели для реализации политики безопасности.
    Должны быть описаны защитные механизмы базы и их место в модели.
    1   ...   8   9   10   11   12   13   14   15   ...   27


    написать администратору сайта