«А.М. БЛИНОВ ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ Учебное пособие ЧАСТЬ 1 ИЗДАТЕЛЬСТВО САНКТ-ПЕТЕРБУРГСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА ЭКОНОМИКИ И ФИНАНСОВ 2010 4 Рекомендовано научно-методическим советом университета ББК ...»

Стандарт Общие критерии также устанавливает ряд оценочных уровней доверия (Evaluation Assurance Levels, EAL), используемых при оценке продуктов. Сертификация на более высокий уровень EAL предполагает более высокую степень уверенности в том, что система защиты продукта работает правильно и эффективно. Сертификаты, полученные продуктами для уровней EAL1-EAL4, признаются всеми странами, поддерживающими стандарт Common Criteria. Сертификация для высших уровней EAL5-EAL7 проводится отдельно в каждой стране. При этом профили защиты могут разрабатываться независимо каждой страной, в том числе и с учетом национальных особенностей защиты государственных секретов. Поэтому EAL4 является высшим уровнем, которого могут достигнуть продукты, не создававшиеся изначально с учетом соответствия требованиям EAL5-EAL7.

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

Ознакомление с Федеральным стандартом США FIPS 140- "Требования безопасности для криптографических модулей" (Security Requirements for Cryptographic Modules) позволит вникнуть в проблематику, связанную с вопросами криптографии. Данный стандарт описывает внешний интерфейс криптографического модуля, общие требования к подобным модулям и их окружению. Наличие такого стандарта упрощает разработку сервисов безопасности и профилей защиты для них. Алгоритмическую сторону криптографии можно рассмотреть, изучив технические спецификации.

3.5. Сведения о стандартах на территории России Руководящие документы (РД) Гостехкомиссии России начали появляться несколько позже мировых стандартов, и уже после опубликования «Гармонизированных критериев», подтверждая разницу между автоматизированными системами (АС) и продуктами (средствами вычислительной техники, СВТ), но в общем и целом они долгое время следовали в фарватере «Оранжевой книги».

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

В 2002 году Гостехкомиссия России приняла в качестве РД русский перевод международного стандарта ISO/IEC 15408:1999 "Критерии оценки безопасности информационных технологий", что послужило толчком для кардинальной и весьма своевременной со всех точек зрения переориентации. Переход на рельсы Общих критериев является непростой, но главное разрешимой задачей.

Стандарт ISO 15408 является государственным стандартом России.

С 1 января 2004 года введены в действие следующие государственные стандарты (названия см. в таблице 2):

• ГОСТ Р ИСО/МЭК 15408-1-2002;

• ГОСТ Р ИСО/МЭК 15408-2-2002;

• ГОСТ Р ИСО/МЭК 15408-3-2002.

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

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

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

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

Чтобы разобраться в вопросах применения российских стандартов, необходимо представить себе административно-правовую структуру информационной безопасности и понять, какое место они в ней занимают.

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

Рассмотрим более подробно содержание стандартов ИСО/МЭК 15408.

В части 1 (ГОСТ Р ИСО/МЭК 15408-1-2002. Введение и общая модель) устанавливается общий подход к формированию требований оценки безопасности, на их основе разрабатываются профили защиты и задания по безопасности, представленные в классах данного стандарта:

Оценка профиля защиты APE.

Оценка задания по безопасности ASE.

Часть 2 (ГОСТ Р ИСО/МЭК 15408-2-2002. Функциональные требования безопасности) представляет собой обширную библиотеку функциональных требований к безопасности, описывающую 11 классов, 66 семейств, 135 компонентов и содержащую сведения о том, какие цели безопасности могут быть достигнуты и каким образом.

Часть 3 (ГОСТ Р ИСО/МЭК 15408-3-2002. Требования доверия к безопасности) включает в себя оценочные уровни доверия (ОУД), образующие своего рода шкалу для измерения уровня доверия к объекту оценки. Под доверием понимается «...основа для уверенности в том, что продукт или система информационных технологий отвечает целям безопасности».

Интерпретируя содержимое этих частей стандарта, можно сказать:

каркас безопасности, заложенный частью 1, заполняется содержимым из классов, семейств и компонентов в части 2, а часть 3 определяет, как оценить прочность всего «строения».

Указы и распоряжения Президента Российской Федерации Постановления Правительства Российской Федерации Организационно-распорядительные документы по защите информации Специальные нормативные документы по защите информации Рис. 4. Административно-правовая структура ИБ в России

ГЛАВА 4. ТЕХНИЧЕСКИЕ СПЕЦИФИКАЦИИ

Среди технических спецификаций на первое место, безусловно, следует поставить документ X.800 «Архитектура безопасности для взаимодействия открытых систем». Здесь выделены важнейшие сетевые сервисы безопасности:

управление доступом;

обеспечение конфиденциальности и/или целостности данных;

невозможность отказаться от совершенных действий.

Для реализации сервисов предусмотрены следующие сетевые механизмы безопасности и их комбинации:

электронная цифровая подпись (ЭЦП);

управление доступом;

контроль целостности данных;

дополнение трафика;

управление маршрутизацией;

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

Спецификация Internet-сообщества RFC 1510 «Сетевой сервис аутентификации Kerberos (V5)» относится к более частной, но весьма важной и актуальной проблеме – аутентификации в разнородной распределенной среде с поддержкой концепции единого входа в сеть. Сервер аутентификации Kerberos представляет собой доверенную третью сторону, владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности. О весомости данной спецификации свидетельствует тот факт, что клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем.

Спецификация «Обобщенный прикладной программный интерфейс службы безопасности» (Generic Security Service Application Program Interface, GSS-API) описывает интерфейс безопасности, предназначенный для защиты коммуникаций между компонентами программных систем, построенных в архитектуре клиент/сервер. Он создает условия для взаимной аутентификации общающихся партнеров, контролирует целостность пересылаемых сообщений и служит гарантией их конфиденциальности. Пользователями интерфейса безопасности GSS-API являются коммуникационные протоколы (обычно прикладного уровня) или другие программные системы, самостоятельно выполняющие пересылку данных.

Российские стандарты, регулирующие ИБ п/п 1 ГОСТ Методы и средства обеспечения безопасности.

Р ИСО/МЭК Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель. Госстандарт России 2 ГОСТ Методы и средства обеспечения безопасности.

Р ИСО/МЭК Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности. Госстандарт России 3 ГОСТ Методы и средства обеспечения безопасности.

Р ИСО/МЭК Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к 4 ГОСТ Р 50739-95 Средства вычислительной техники. Защита от 5 ГОСТ Р 50922-96 Защита информации. Основные термины и определения. Госстандарт России 6 ГОСТ Р 51188-98 Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство. Госстандарт России 7 ГОСТ Р 51275-99 Защита информации. Объект информатизации.

8 ГОСТ Р ИСО Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель.

9 ГОСТ Р ИСО Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель.

Часть 2. Архитектура защиты информации. Госстандарт России Технические спецификации IPsec [IPsec] имеют, без преувеличения, фундаментальное значение, описывая полный набор средств обеспечения конфиденциальности и целостности на сетевом уровне. Для доминирующего в настоящее время протокола IP версии 4 они носят факультативный характер; в версии IPv6 их реализация обязательна. На основе IPsec строятся защитные механизмы протоколов более высокого уровня, вплоть до прикладного, а также законченные средства безопасности, в том числе виртуальные частные сети. Разумеется, IPsec существенным образом опирается на криптографические механизмы и ключевую инфраструктуру.

Точно так же характеризуются и средства безопасности транспортного уровня (Transport Layer Security, TLS). Спецификация TLS развивает и уточняет популярный протокол Secure Socket Layer (SSL), используемый в большом числе программных продуктов самого разного назначения.

Также важны рекомендации X.500 «Служба каталогов: обзор концепций, моделей и сервисов» (The Directory: Overview of concepts, models and services) и X.509 «Служба каталогов: каркасы сертификатов открытых ключей и атрибутов» (The Directory: Public-key and attribute certificate frameworks). В рекомендациях X.509 описан формат сертификатов открытых ключей и атрибутов – базовых элементов инфраструктур открытых ключей и управления привилегиями.

Как известно, обеспечение информационной безопасности – проблема комплексная, требующая согласованного принятия мер на законодательном, административном, процедурном и программно-техническом уровнях. При разработке и реализации базового документа административного уровня – политики безопасности организации – отличным подспорьем может стать рекомендация Internet-сообщества «Руководство по информационной безопасности предприятия» (Site Security Handbook).

В нем освещаются практические аспекты формирования политики и процедур безопасности, поясняются основные понятия административного и процедурного уровней, содержится мотивировка рекомендуемых действий, затрагиваются темы анализа рисков, реакции на нарушения ИБ и действий после ликвидации нарушения. Более подробно последние вопросы рассмотрены в рекомендации «Как реагировать на нарушения информационной безопасности» (Expectations for Computer Security Incident Response). В этом документе можно найти и ссылки на полезные информационные ресурсы, и практические советы процедурного уровня.

При развитии и реорганизации корпоративных информационных систем, несомненно, окажется полезной рекомендация «Как выбирать поставщика Internet-услуг» (Site Security Handbook Addendum for ISPs).

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

ГЛАВА 5. ПОЛИТИКА БЕЗОПАСНОСТИ

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

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

5.1. Формальная и неформальная политики безопасности 5.1.1. Неформальная политика безопасности Для неформальной политики безопасности широкое распространение получило описание правил доступа субъектов к объектам в виде таблицы, наглядно представляющей правила доступа. Обычно такая таблица подразумевает, что субъекты, объекты и типы доступа определены. Это позволяет составить таблицу, содержащую колонку типов доступа и колонку соответствующего отношения, которое должно соблюдаться между субъектом и объектом для данного типа доступа (см. таблицу 5).

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

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

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

5.1.2. Формальная политика безопасности Для лучшего понимания принципов, используемых при создании формальных политик безопасности, рассмотрим основные математические методы, применяемые при формальном анализе вообще и формальном описании политик безопасности АВС в частности.

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

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

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

Первый метод заключается в доказательстве того, что система всегда «работает корректно», второй заключается в демонстрации того, что система никогда не выполняет неверных действий.

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

Второй метод выдвигает гипотезу о том, что система делает что-то некорректное, и на этой основе ведется анализ реакций системы с выявлением состояний, в которых возможно проявление данной некорректности.

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

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

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

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

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

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

Другими словами под формальными методами при анализе АВС подразумевается применение математических моделей – моделей безопасности.

Выделяя ядро ТСВ системы и рассматривая его свойства (в частности свойство безопасности) при создании модели безопасности и учитывая его компактность, можно делать выводы о свойствах безопасности системы в целом. При этом можно строить доказательство двумя способами: либо показать, что система ведет себя корректно всегда, либо показать, что система никогда не выполняет некорректных действий (т.е. от методов исследования АВС перейти к методам исследования для физических систем).

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

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

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

К модели безопасности должны предъявляться требования, общие для всех моделей:

способность к предсказанию;

ГЛАВА 6. МОДЕЛИ БЕЗОПАСНОСТИ

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

Немного о математической логике, которую будем использовать при рассмотрении моделей.

В логике существует понятие предикатов первого и второго порядка.

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

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

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

Если P – пропозициональная переменная, то P – формула.

Других соглашений нет.

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

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

Кроме того используются следующие дополнительные символы Символы переменных (обычно x,y,z,x1,y1,z1,x2,y2,z2, и т. д.), Кванторы: всеобщности и существования, Служебные символы: скобки и запятая.

Перечисленные символы вместе с символами из и образуют Алфавит логики первого порядка. Более сложные конструкции определяются индуктивно:

функциональный символ арности n, а – термы.

Атом в математической логике – простейший случай формулы; формула, которую нельзя расчленить на подформулы.

Предикат (n-местный, или n-арный) – это функция с множеством значений {0,1} (или «ложь» и «истина»), определённая на множестве. Таким образом, каждый набор элементов множества M он характеризует либо как «истинный», либо как «ложный».

Предикат можно связать с математическим отношением: если n принадлежит отношению, то предикат будет возвращать на ней 1.

Предикат – один из элементов логики первого и высших порядков.

Начиная с логики второго порядка, в формулах можно ставить кванторы по предикатам.

Предикат называют тождественно-истинным и пишут:

если на любом наборе аргументов он принимает значение 1.

Предикат называют тождественно-ложным и пишут:

если на любом наборе аргументов он принимает значение 0.

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

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

Формула – это либо атом, либо одна из следующих конструкций:

переменная.

Переменная x называется связанной в формуле F, если F имеет вид не связанна в F, ее называют свободной в F. Формулу без свободных переменных называют замкнутой формулой, или предложением. Теорией первого порядка называют любое множество предложений.

Логика второго порядка – расширяет логику первого порядка, позволяя проводить квантификацию общности и существования не только над атомами, но и над предикатами.

Логика второго порядка не упрощается к логике первого порядка.

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

где pоs – множество всех возможных последовательностей вызовов функций, предоставляемых ядром безопасности системы;

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

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

свойства безопасности системы должны быть реализованы с помощью ядра безопасности системы;

данные свойства должны быть выражены предикатом второго В анализируемых далее моделях безопасности предикат Р конкретизируется, а вместо исследования выражений, описываемых логикой второго порядка, изучаются модели состояний системы. Для модели системы необходимо доказать следующую теорему, называемую основной теоремой безопасности: «Если система начинает работу в безопасном состоянии и все переходы системы из состояния в состояние являются безопасными, то система является безопасной».

Таким образом, необходимо ввести понятия, пригодные для описания свойств состояния системы. Самыми естественными понятиями, с помощью которых можно описать состояние системы, являются понятия субъекта, объекта и доступа, которые и являются основой описания состояния моделей безопасности защищенных АВС.

Сущность – любая именованная составляющая компьютерной системы.

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

Терминалы;

Субъект – активная сущность. Она может инициировать запросы к ресурсам и использовать их для выполнения каких-либо вычислительных заданий. В процессе исполнения субъекты исполняют операции. Примеры субъектов:

Пользователь;

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

Операции чтения – такая операция, результатом которой является перенос информации от объекта к субъекту;

Операция записи – такая операция, результатом которой является перенос информации от субъекта к объекту.

Основной характеристикой субъекта является уровень безопасности.

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

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

Неклассифицированная информация;

Конфиденциальная информация;

Секретная информация;

Совершенно секретная информация.

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

Уровни безопасности – L.

Иерархические отношения – >,=А(f), С(j)>=С(f), M(j)>=M(f), uF(f).

Задавая параметры A, C, F, M, можно сформировать матрицу определения параметров безопасности.

Пользователь u Терминал T Задание j Существующий файл f(i) Новый файл f=g(f1,f2) где f1,f2 – старые файлы, f – новый файл как функция от f1 и f 5-мерное пространство безопасности Хартстона Существует 5 основных наборов:

Доступ рассматривается как ряд запросов, осуществляемых пользователями u для выполнения операции e над ресурсами R в то время, когда система находится в состоянии s. Например, запрос на доступ рассматривается в виде 4-мерного кортежа:

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

Процесс организации доступа к ресурсам будет состоять из следующих процедур:

I. Вызвать все вспомогательные программы, необходимые для предварительного принятия решения.

II. Определить из U те группы пользователей, к которым принадлежит u. Затем выбрать из A спецификации полномочий, которые соответствуют выбранной группе пользователей. Набор полномочий A(u) определяет привилегии пользователя u.

III. Определить из A набор A(e) полномочий, которые устанавливают e как основную операцию. Этот набор A(e) называется привилегией IV. Определить из A набор A(R`) – набор полномочий, которые определяют поднабор ресурсов, называемых привилегией ресурсов R`.

Общие полномочия, появляющиеся в пунктах 2-4 (A(u), A(e), A(R`)) образуют домен D полномочий для запроса q, такой что D(q)=A(u)A(e)A(R`) V. Удостовериться, что запрашиваемый ресурс R` полностью включается в домен D(q).

VI. Осуществить разбиение набора домена D(q) на эквивалентные классы так, чтобы 2 полномочия попадали в эквивалентный класс тогда и только тогда, когда они специфицируют одну единицу ресурса. Получается, что новый набор полномочий, один на каждую единицу ресурса, указанную в домене, является записью – A(u,q).

Читается как «фактическая привилегия пользователя u по отношению к запросу q».

VII. Вычислить условия фактического доступа, соответствующего запросу q, осуществляя логическое «и» или логическое «или» над условиями A(u,q).

VIII. Оценить условия фактического доступа и принять решение о доступе.

IX. Произвести запись необходимых событий.

X. Вызвать все программы, необходимые для организации доступа после принятия решения.

XI. Выполнить все вспомогательные программы, вытекающие для каждого случая из условия VIII.

XII. Если решение о доступе было положительным – завершить физическую обработку.

Автор модели Хартстон говорит о том, что не всегда нужно выполнять все 12 шагов в полном объеме. Например, шаги 2 и 6 осуществляются при регистрации пользователей в системе, и т.д.

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

К недостаткам систем, построенных на основе DAC, следует отнести проблему троянских программ (троянских коней).

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

Классическая MAC – модель Белла и Лападула (БЛМ) Появление: Белл и Лападула следили за тем, как переносятся документы на бумажных носителях между людьми в государственных организациях.

1. В правительстве США все субъекты и объекты ассоциируются с уровнями безопасности (от низких, неклассифицированных до высоких, совершенно секретных); для предотвращения утечки информации, субъектам с низкими уровнями безопасности не позволяется читать информацию из объектов с высокими уровнями безопасности.

Отсюда следует первое правило БЛМ (простое свойство безопасности, «нет чтения вверх») – NRU (no read up) – субъект с уровнем безопасности Xs может читать информацию из объекта с уровнем безопасности Xo, только если Xs преобладает над Xo.

2. В правительстве США субъектам запрещено размещать или записывать информацию в объекты, имеющие более низкий уровень секретности (например, нельзя выбрасывать бумаги в мусорное ведро).

Второе правило БЛМ («нет записи вниз») – NRD (no write down) – субъект с уровнем безопасности Xs может писать информацию в объект с уровнем безопасности Xo, только если Xo преобладает над Xs.

Именно второе правило БЛМ решает проблему троянских коней: типичная ситуация для троянских коней, когда информация переносится с более высокого уровня на более низкий, невозможна.

Формализация БЛМ:

Если S – множество субъектов, О – множество объектов, L – решетка уровней безопасности, тогда можно определить функцию F, определяющую уровни безопасности своих аргументов в данном состоянии.

Применяется к субъектам и объектам, записывается как:

V – множество состояний, которое составляется из упорядоченных пар (F, M). M – матрица доступа субъектов системы к объектам. Более того, система представляется начальным состоянием Vо, определенным множеством запросов к системе R и функцией переходов T: (V х R) ›V, то есть такой, что система переходит из состояния в состояние после исполнения запроса.

Определение Состояние (F, M) безопасно по чтению тогда и только тогда, когда для любого «s» из множества субъектов и любого «о» из множества объектов для допустимого чтения, следует, что F(S) преобладает над F(O) – Определение Состояние (F, M) безопасно по записи тогда и только тогда, когда для любого s из множества субъектов и любого о из множества объектов для допустимой записи M(S,O) означает, что F(O) преобладает над F(S) – Определение Состояние безопасно тогда и только тогда, когда оно безопасно по чтению и записи.

Три определения необходимы для того, чтобы сформулировать и доказать основную теорему безопасности:

Система (Vo, R, T), описываемая начальным состоянием Vo, множеством запросов к системе R и функцией переходов T, безопасна тогда и только тогда, когда состояние Vo безопасно и Т таково, что для любого состояния V, достижимого из Vo, после исполнения конечной последовательности запросов из R можно осуществить переход к состоянию V* [T(Vo,R)=V*], также принадлежащему множеству состояний.

Классическая модель БЛМ имеет недостатки:

1. Проблема в распределенных системах – удаленное чтение. Запросы от одного рабочего места к другому, между сервером и рабочей станции создают удаленные сеансы, при этом невозможно соблюдать правила NWD и NRU. Решение: БЛМ применять локально, а для создания сеансов удаленной работы применять другую 2. Проблема доверенных субъектов. Должен ли администратор системы подчиняться правилам БЛМ? В любой системе, на которую распространяются правила БЛМ, нужно выделять доверенные субъекты и рассматривать их в отдельности. Решение: использовать модели невыводимости и невмешательства.

3. Проблема системы Z. Джон Маклин разработал и описал эту систему: система, удовлетворяющая правилам БЛМ может, иметь ряд проблем с секретностью. Ничто в БЛМ не предотвращает систему от деклассификации объекта от «совершенно секретного» до «секретного» по желанию совершенно секретного пользователя.

Допустим, есть субъект с высокой степенью доверия А, он читает информацию из объекта с уровнем классификации тоже А. Субъект решил понизить свою степень доверия до В (A>B). После понижения своей степени доверия он может записать информацию в файл с классификацией B.

БЛМ на это отреагировать не может. Белл и Лападула предполагали такую возможность, и в их дальнейшей разработке БЛМ были введены дополнительные требования – требования сильного и слабого спокойствия.

Правило сильного спокойствия:

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

Правило слабого спокойствия:

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

Самая слабая модель – БЛМ в классической формулировке, самая сильная – модель с сильным спокойствием.

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

Логическим продолжением MAC БЛМ стало появление специализированных моделей, перекрывающих проблемы, существовавшие в БЛМ.

С целью устранения обозначенных недостатков Лендвером и МакЛином в модели передачи военных сообщений (MMS – military message system) были предложены определения; сформулированы и доказаны формальная и неформальная модели MMS.

Определение Классификация – обозначение, накладываемое на информацию, отражающее ущерб, который может быть причинен неавторизованным доступом, включающим уровни: Secret, Top secret, и метки Crypto, Nuclear и т.д. Множество классификаций и отношений между ними образуют решетки.

Определение Степень доверия пользователю – уровень благонадежности персоны.

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

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

Пользователь – это персона, уполномоченная для использования системы.

Определение Роль – это работа, исполняемая пользователем. Пользователь всегда ассоциирован как минимум с одной ролью в некоторый момент времени.

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

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

Определение Контейнер – многоуровневая информационная структура. Имеет классификацию и может содержать объекты, каждый со своей классификацией, и/или другие контейнеры. Пример контейнера – файл.

Определение Сущность – это объект или контейнер.

Определение Требования степени доверия контейнеров – атрибут некоторых контейнеров. Для некоторых контейнеров важно требовать минимум степени доверия, т.е. пользователь, не имеющий соответствующий уровень благонадежности, не может просматривать содержимое контейнера. Такие контейнеры помечаются соответствующим атрибутом – CCR. Если у нас есть пользователь со степенью доверия «confidential», то он не может просматривать параграф сообщения «confidential» из документа «top secret», если этот документ находится в CCR-контейнере. Если нужно это разрешить – документ необходимо извлечь из контейнера.

Определение Идентификатор (ID) – имя сущности без ссылки на другие сущности.

Пример – имя файла является идентификатором файла. Обычно все сущности имеют идентификатор.

Определение Ссылка на сущность является прямой, если это идентификатор сущности.

Определение Ссылка на сущность является косвенной, если это последовательность двух или более имен сущностей, из которых только первое – идентификатор.

Определение Операция – функция, которая может быть применена к сущности.

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

Определение Множество доступа – множество троек (пользовательский идентификатор или роль, операция, индекс операнда), которые связаны с сущностью.

Определение Сообщение – особый тип, реализуемый в данной модели. Является контейнером. Включает поля «куда», «откуда», «время», «предмет», «текст», «автор». Чертежные сообщения включают поле чертежа.

Пользователь получает доступ к системе только после прохождения процедуры login. Для этого пользователь предоставляет системе пользовательский идентификатор, и система производит аутентификацию, используя пароли, отпечатки пальцев или другую адекватную технику. После успешного прохождения аутентификации пользователь запрашивает у системы операции для использования функций системы. Операции, которые пользователь может запросить у системы, зависят от его Id или роли, для которой он авторизован.

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

1) Предположение безопасности:

А1: офицер безопасности системы присваивает уровни доверия, производит классификацию устройств и создает множество ролей А2: пользователь вводит корректную классификацию, когда изменяет, объединяет и переклассифицирует информацию;

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

А4: пользователь должным образом контролирует информацию объектов, требующих благонадежности;

2) Ограничение безопасности (относятся к компьютерной системе):

B1: Авторизация. Пользователь может запрашивать операции над сущностями, только если пользовательский идентификатор или текущая роль присутствуют во множестве доступа сущности вместе с этой операцией и со значением индекса, соответствующим позиции операнда, в которой сущность относят к требуемой операции.

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

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

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

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

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

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

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

B10: Уничтожение информации. Эта операции проводится только пользователем с ролью «пользователь, уничтожающий информацию».

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

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

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

Принципиальной трудностью, возникающей при формализации модели, является интерпретация «копирования», «просмотра», «вывода системы» и «авторизованной операции». Информация считается копируемой не только тогда, когда она непосредственно переносится из одной сущности в другую, но и когда она дает потенциальный вклад в другую сущность. Например, если операция сканирует файл сообщений А и копирует сообщения, выбранные фильтром Ф в файл сообщений Б, то и А, и Ф являются потенциальным вкладом в модификацию Б (и, следовательно, субъектом для ограничений, вызванных безопасностью копирования и CCR безопасностью), даже если и А, и Ф – пусты. Семантика для просмотра – проста: сущность может быть просмотрена, если операция делает ее членом выходного контейнера.

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

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

6.2.3. Достоинства и недостатки моделей предоставления прав Достоинства:

1) Интуитивная понятность.

2) Возможность реализации с высокой степенью точности.

Недостатки:

1) Возможность образования скрытых каналов утечки информации.

Скрытые каналы утечки информации обнаружить несложно, но лишь в процессе эксплуатации системы, поэтому их сложно ликвидировать.

Информационные модели определяют ограничения на предоставление ввода/вывода системы, которые достаточны для реализации системы.

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

Рассмотрим две информационные модели:

Модель невмешательства.

Модель невыводимости.

Достоинством данных моделей является:

1) Отсутствие скрытых каналов утечки.

2) Естественность их использования для реализации сетевых защищенных АВС.

Невмешательство – это ограничение, при котором ввод высокоуровневого пользователя не может смешиваться с выводом низкоуровневого пользователя. Модель невмешательства рассматривает систему, состоящую из 4-х объектов:

Высокий ввод (High In).

Низкий ввод (Low In).

Высокий вывод (High Out).

Низкий вывод (Low Out).

Рассмотрим систему, вывод которой пользователю u определён функцией out:

где hist.read (u) – это история ввода системы (traces), чей последний ввод был read (u), т.е. команда чтения, исполненная пользователем u.

Введем понятие – очищение (purge) истории ввода. Purge удаляет команды, исполненные пользователем, чей уровень безопасности не доминирует над уровнем безопасности u.

Используется также функция clearance (u), которая определяет степень доверия к пользователю.

Система удовлетворяет требованиям невмешательства, если, и только если для всех пользователей u, всех историй T и всех команд вывода c выполняется следующее равенство:

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

Верификация модели невмешательства более сложная, чем верификация модели БЛМ. Достоинство в том, что при применении данной модели не остаётся скрытых каналов утечки информации, она более интуитивно понятна по сравнению с БЛМ.

Сравнение модели БЛМ и модели невмешательства:

1. БЛМ слабее, чем модель невмешательства, за счёт того, что последняя запрещает многие скрытые каналы, которые остаются при реализации БЛМ.

2. Модель невмешательства слабее, чем БЛМ, так как она разрешает низкоуровневым пользователям копировать один высокоуровневый файл в другой высокоуровневый файл, что запрещается в последней из-за нарушения безопасности по чтению.

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

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

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

Модели разграничения доступа, использующие принципы теории вероятности, исследуют вероятность преодоления системы защиты за определённое время t. К достоинствам модели данного типа можно отнести числовую оценку стойкости системы защиты. Недостатком является то, что изначально предполагается, что система может быть преодолена. Основная задача для таких моделей – это минимизация вероятности преодоления системы защиты.

Первая из вероятностных моделей – это игровая модель. Игровая модель системы защиты строится по следующему принципу:

Разработчик создаёт первоначальный вариант системы защиты. После этого злоумышленник начинает его преодолевать. Если в момент времени T, в который злоумышленник преодолел систему защиты, и у разработчика нет нового варианта системы защиты, то считается, что система защиты преодолена. Если нет, то процесс продолжается.

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

Вторая модель – это модель системы безопасности с полным перекрытием. В данном варианте модели декларируется то, что система, использующая данную модель, должна иметь, по крайней мере, одно средство для обеспечения безопасности на каждом возможном пути проникновения в систему. В общих чертах её можно изобразить следующим образом (рис. 5):

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

Рис. 6. Двудольный граф «Объект-угроза»

Одна угроза может действовать на несколько объектов. Цель защиты состоит в том, чтобы перекрыть каждое ребро графа. Получив такой граф, можно говорить о том, что существуют рёбра. Создадим третий набор, включающий средства безопасности M. Идеальным случаем является тот, когда для каждого Mk из множества M устраняется некоторое ребро из данного графа. Получается, что набор M средств обеспечения безопасности преобразует двудольный граф в трёхдольный, и тогда существуют рёбра вида. если в системе остается ребро, то в ней существует незащищенный объект.

Нужно помнить о том, что одно и то же средство обеспечения безопасности может перекрывать более одной угрозы и/или защищать более одного объекта. Более того, отсутствие ребра не гарантирует полного обеспечения безопасности.

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

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

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

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

Биба выразил свою модель таким же способом, каким была выражена БЛМ, за тем исключением, что правила его модели являются полной противоположностью правилам БЛМ. Возможны три вариации модели Биба: мандатная модель целостности, модель понижения уровня субъекта и модель понижения уровня объекта. Фактически, общий термин «модель Биба» используется для обозначения любой или сразу всех трех моделей.

6.5.1.1. Мандатная модель целостности Биба Ее часто называют инверсией БЛМ. Это довольно точное название, поскольку основные правила этой модели просто переворачивают правила БЛМ. Мы будем ссылаться на эти правила как «нет чтения снизу» (NRD) и «нет записи наверх» (NWU) и определим их в терминах субъектов, объектов и нового типа уровней безопасности – уровней целостности, над которыми может быть введено отношение преобладания.

Правило NRD мандатной модели целостности Биба определяется как запрет субъектам на чтение информации из объекта с более низким уровнем целостности. Правило NWU мандатной модели целостности Биба определяется как запрет субъектам на запись информации в объект с более высоким уровнем целостности.

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

С другой стороны, модель представляет собой очевидное противоречие с правилами NRU и NWD. Это значит, что если необходимо построить систему, которая предотвращает угрозы как секретности, так и целостности, то одновременное использование правил моделей БЛМ и Биба может привести к ситуации, в которой уровни безопасности и целостности будут использоваться противоположными способами.

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

Начнем с представления множества субъектов и объектов. Уровни целостности субъекта или объекта х обозначаются как уровень (х), и для них введено отношение преобладания. Используя эти определения, сформулируем правила NRD и NWU мандатной модели целостности Биба в терминах булевой функции разрешить:

NRD: s S, о O: разрешить (s, o, чтение) уровень (о) > уровень (s).

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

Правило NWU просто переворачивает использование отношения преобладания, как показано в следующем определении:

NWU: s S, о O: разрешить (s, o, запись) уровень(s) > уровень(o).

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

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

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

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

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

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

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

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

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

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

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

Представим модель МКВ с помощью строгого описания основных компонентов, включенных в модель. Модель Кларка-Вилсона выражается в терминах конечного множества. За D (для данных) обозначим все наборы данных в определенной компьютерной системе.

Чтобы различать данные, обладающие и не обладающие целостностью, создатели модели разделили D на два непересекающиеся подмножества, которые называются ограниченные элементы данных (CDI) и неограниченные элементы данных (UDI). Это можно изобразить следующими определениями:

Первое определение показывает, что D является объединением CDI и UDI, а второе определение показывает, что нет элементов, принадлежащих и CDI, и UDI. Набор D разделен таким образом, потому что мы хотим показать, как может меняться целостность данных. Другими словами, данные, не имеющие целостности и находящиеся поэтому в UDI, могут быть некоторым образом модернизированы, так чтобы иметь целостность и находиться соответственно в CDI.

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

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

Правило 1. В системе должны иметься процедуры утверждения целостности, утверждающие целостность любого CDI.

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

Правило 2. Применение любой процедуры преобразования к любому CDI должно сохранять целостность этого CDI.

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

Правило 3. Только процедура преобразования может вносить изменения в CDI.

Данное правило модели МКВ не позволяет субъектам с низкой целостностью, то есть не использующим процедуру преобразования, изменять объекты с высокой целостностью, то есть CDI. В этом плане модель Кларка-Вилсона подобна мандатной модели целостности Биба.

Правило 4. Субъекты могут инициировать только определенные процедуры преобразования над определенными CDI.

Это правило предполагает, что система должна определять и поддерживать некоторые отношения между субъектами процедуры преобразования и CDI, так называемые МКВ-тройки. Каждая такая тройка определяет возможность данного субъекта применить данную процедуру преобразования к данному CDI. Например, если (s, t, d) является элементом отношения, то субъекту s разрешается применить процедуру преобразования t к CDI d. Если же эта тройка не является элементом отношения, то такой тип применения процедуры преобразования будет запрещен. Это правило гарантирует, что всегда можно определить, кто может изменить CDI и как это изменение может произойти.

Правило 5. МКВ-тройки должны проводить некоторую соответствующую политику разделения обязанностей субъектов.

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

Правило 6. Некоторые специальные процедуры преобразования могут превращать UDI в CDI.

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

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

Правило 8. Система должна распознавать субъекты, пытающиеся инициировать процедуру преобразования.

Это правило определяет механизмы предотвращения атак, при которых один субъект пытается выдать себя за другого.

Правило 9. Система должна разрешать производить изменения в списках авторизации только специальным субъектам (например, офицерам безопасности).

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

Основным преимуществом модели МКВ является то, что она основана на проверенных временем методах обращения с бумажными ресурсами. Поэтому модель МКВ не следует рассматривать как академическое исследование, а скорее как комплекс существующих методов. Модель МКВ также предоставляет исследователям методы работы с целостностью, отличные от традиционных уровне-ориентированных подходов, таких как модели БЛМ и Биба.

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

Все недостатки данной модели вытекают из-за ее неформализованности. Ее можно применять при проектировании систем для спецификации пользовательских приложений и использовать на соответствующем уровне иерархии рассмотрения защищенной вычислительной системы.

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

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

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

Глигор первым отметил, что в понятия предоставления или отказа в обслуживании должно быть включено время. Каждая услуга должна быть связана с некоторым периодом времени, называем максимальным временем ожидания (MWT). Для некоторой услуги MWT определяется как длина промежутка времени после запроса услуги, в течение которого считается приемлемым предоставление этой услуги.

Можно трактовать приведенное выше определение по-другому. А именно, рассматривать MWT как период времени, в течение которого запрашиваемая услуга не устаревает. Иными словами, если после запроса услуга обеспечивается в течение слишком долгого времени, то может случиться так, что ее нельзя будет больше использовать. Заметим, что хотя приведенное выше определение и не выражено в терминах пользователей, запрашивающих услуги, может оказаться, что для данной услуги MWT будет различным для различных пользователей.

Дав определение MWT, мы можем теперь ввести точное определение угрозы ОВО, а именно, будем говорить, что имеет место угроза ОВО всякий раз, когда услуга с соответствующим максимальным временем ожидания (MWT) запрашивается зарегистрированным пользователем в момент времени t и не предоставляется этому пользователю к моменту времени (t + MWT).

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

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

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

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

Рассмотрим правила, описывающие мандатную модель ОВО. Эти правила описывают взаимоотношения субъектов, аналогичные отношениям между субъектами и объектами в моделях БЛМ и Биба.

Первое правило – «никаких отказов вверх» (NDU) – основано на том наблюдении, что никаким объектам с более низким приоритетом не позволено отказывать в обслуживании субъектам с более высокими приоритетами. Однако некоторым субъектам с более высоким приоритетом (например, администраторам системы) должна предоставляться возможность отказывать в обслуживании объектам с более низким приоритетом, если первые того желают.

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

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

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

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

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

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

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

Данную модель, также как и модель КВМ, сложно реализовать для реальных систем.

ВОПРОСЫ К ЧАСТИ

1. Какие исторические события можно связать с понятием «нарушение информационной безопасности»?

2. Перечислите виды компьютерных преступлений.

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

4. Какие стандарты и спецификации информационной безопасности вы знаете?

5. Перечислите принципы, используемые в законе РФ «О государственной тайне».

6. Приведите список угроз безопасности информационной системы.

7. Приведите список мер противодействия угрозам информационной безопасности.

8. Выделите основную структуру требований Оранжевой книги.

9. В чем заключается различие классов безопасности по Оранжевой 10. Сколько классов безопасности выделяется в Оранжевой книге?

11. Что является целью информационной безопасности согласно стандарта BS 7799?

12. Что является основой процесса управления согласно стандарта BS 7799-2?

13. По каким параметрам происходит выделение классов в Гармонизированных критериях?

14. В чем суть Общих критериев?

15. Перечислите стандарты информационной безопасности, действующие на территории РФ.

16. Перечислите известные вам технические спецификации.

17. Какие требования предъявляются к моделям безопасности?

18. Приведите классификацию моделей безопасности.

19. В чем заключается смысл правил модели БЛМ?

20. Перечислите достоинства и недостатки моделей предоставления 21. Какие модели, построенные на основе принципов теории информации, вам известны?

22. В чем заключается принцип действия, заложенный в вероятностную модель с полным перекрытием?

23. Перечислите правила модели целостности Биба.

24. Перечислите виды моделей целостности Биба.

25. Какие понятия использует модель ОВО?

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Алешин И.В. Информационно-безопасные системы. Анализ проблемы. – СПб.: Изд-во СПбГТУ, 1996.

2. Гаухман Л.Д., Максимов С.В. Уголовно-правовая охрана финансовой среды: новые виды преступлений и их классификация: Научнопрактическое пособие. – М.: ЮрИнфоР, 1995.

3. Герасименко В.А. Защита информации в автоматизированных системах обработки данных. В 2-х кн. – М.: Энергоатомиздат, 1994.

4. Зегжда Д.П., Ивашко А.М. Основы безопасности информационных систем. – М.: Горячая линия. – Телеком, 2000. – 452 с.

5. Панфилова Е.П. Компьютерные преступления / Под общ. ред.

Б.В. Волжеккина. – М., 1999.

6. Поляк-Брагинский А.В. Сеть своими руками. – СПб.: BHV-Петербург, 2002.

7. Ярочкин В.И., Халяпин Д.В. Основы защиты информации. Службы безопасности предприятия. ИПКИР. – М., 1993.

8. Доктрина информационной безопасности РФ // Российская газета. – 2000. – 28 сент.

9. О государственной тайне: Закон РФ от 21 июля 1993 г. // Закон. – 1999. – № 2.

10. О безопасности: Закон РФ от 5 марта 1992 г. // Ведомости съезда народных депутатов РФ и Верховного Совета РФ. – 1992. – № 15.

11. Об информации, информатизации и защите информации: Федеральный закон от 20 февраля 1995 г. // СЗ РФ. – 1995. – № 8.

12. Об оперативно-розыскной деятельности: Федеральный закон от 12 августа 1995 г. // СЗ. – 1995. – № 33.

13. Об участии в международном информационном обмене: Федеральный закон от 4 июня 1996 г. // СЗ РФ. – 1996. – № 28.

14. О внесении изменений и дополнений в Закон РФ «О правовой охране программ для ЭВМ и баз данных»: Федеральный закон от 24 декабря 2002 г. // Российская газета. – 2002. – 28 дек.

15. О Перечне сведений, отнесенных к государственной тайне: Указ Президента РФ № 61 от 24 января 1998 г. // Российская газета. – 1998. – 3 февр.

16. О Перечне сведений конфиденциального характера: Указ Президента РФ № 188 от 6 марта 1997 г. // Закон. – 1998. – № 2.

17. О правовой охране программ для ЭВМ и баз данных: Закон РФ от 23 сентября 1992 г. // СЗ РФ. – 1992. – № 42.

18. Принципы безопасности банка и банковского бизнеса в России. – М.: Банковский Деловой Центр, 1997.

19. Уголовный кодекс РФ. – М., 2001.

20. Арсентьев М.В. К вопросу о понятии «информационная безопасность» // Информационное общество. – 1997. – № 4-6.

21. Дозорцев В.А. Информация как объект исключительного права // Дело и Право. – 1996. – № 4.

22. Статьев В.Ю., Тиньков В.А. Информационная безопасность распределенных информационных систем // Информационное общество. – 1997. – № 1.

23. Феоктистов Г.Г. Информационная безопасность общества // Социально-политический журнал. – 1996. – № 5.

24. Урсул А.Д. Информационная стратегия и безопасность в концепции устойчивого развития // Научно-техническая информация. Серия 1:

Организация и методика информационной работы. – 1996. – № 1.

ПРИЛОЖЕНИЯ

CSC-STS-003-85 TCSEC in Specific 25 Jun 1985 Yellow Book.

NCSC-TG- Interpretation Environments 1 August 1990 Red Book NCSC-TG- NCSC-TG-013 V2 RAMP Program Document 1 March 1995 Pink Book NCSC-TG- Trusted Recovery in Trusted 30 December (Yellow NCSC-TG- NCSC-TG-

Systems: An Introduction to

NCSC-TG- Vol. 2/ NCSC-TG- NCSC-TG- NCSC-TG- Базовые требования «Оранжевой книги»

Политика безопасности 7. Освобождение ресурсов при повторном использовании объектов Подотчетность Гарантии 14. Проектная спецификация и верификация - - + + + + 18. Доверенное восстановление после сбоев - - - - + = Документация Базовые требования «Оранжевой книги»

24. Руководство по конфигурированию системы защиты 25. Документация по тестированию +====+ «-» – нет требований к данному классу «+» – новые или дополнительные требования «=» – требования совпадают с требованиями к СВТ предыдущего класса

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. ПОНЯТИЕ И ПРИНЦИПЫ ИНФОРМАЦИОННОЙ

БЕЗОПАСНОСТИ

ГЛАВА 2. ОБЩИЕ ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

ГЛАВА 3. ОЦЕНОЧНЫЕ СТАНДАРТЫ

3.1. Критерии оценки доверенных компьютерных систем Министерства обороны США

3.2. Стандарт BS 7799-1

3.2.1. Регуляторы безопасности и реализуемые ими цели

3.2.1.1. Регуляторы общего характера

3.2.1.2. Регуляторы технического характера

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

3.3. Стандарт BS 7799-2. Четырехфазная модель процесса управления информационной безопасностью

3.4. Сведения о других международных стандартах

3.5. Сведения о стандартах на территории России

ГЛАВА 4. ТЕХНИЧЕСКИЕ СПЕЦИФИКАЦИИ

ГЛАВА 5. ПОЛИТИКА БЕЗОПАСНОСТИ

5.1. Формальная и неформальная политики безопасности

5.1.1. Неформальная политика безопасности

5.1.2. Формальная политика безопасности

ГЛАВА 6. МОДЕЛИ БЕЗОПАСНОСТИ.

6.1. Основные понятия

6.2. Классификация моделей безопасности

6.2.1. Модели безопасности, предотвращающие угрозу раскрытия.... 6.2.2. Модели разграничения доступа, построенные по принципу предоставления прав

6.2.3. Достоинства и недостатки моделей предоставления прав.......... 6.3. Информационные модели

6.3.1. Модель невмешательства

6.3.2. Модель невыводимости

6.4. Вероятностные модели

6.4.1. Игровая модель

6.4.2. Модель с полным перекрытием

6.5. Модели контроля целостности

6.5.1. Модель Биба

6.5.1.1. Мандатная модель целостности Биба

6.5.2. Модель понижения уровня субъекта

6.5.3. Модель понижения уровня объекта

6.6. Модель Кларка-Вилсона

6.6.1. Правила модели МКВ

6.7. Модели, предотвращающие угрозу отказа служб

6.7.1. Основные понятия ОВО

6.7.2. Мандатная модель ОВО

ВОПРОСЫ К ЧАСТИ 1

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

ПРИЛОЖЕНИЯ

ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

Усл. печ. л. 6,0. Тираж 150 экз. Заказ 427. РТП изд-ва СПбГУЭФ.

Издательство СПбГУЭФ. 191023, Санкт-Петербург, Cадовая ул., д. 21.