Методики оценки рисков

Принятие риска

Меры безопасности

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

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

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

Меры безопасности могут быть применены к:

· окружающей среде,

· персоналу,

· руководству,

· аппаратному/программному обеспечению,

· линиям связи.

Принципиальные меры по снижению риска:

· избежать риска,

· передать риск (страхование),

· уменьшить степень угрозы,

· минимизировать уязвимости,

· снизить возможные последствия,

· вовремя обнаружить и отразить нежелательные воздействия.

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

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

· временные

· финансовые

· технические

· социологические

· природные

· законодательные

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

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

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

Контрольные вопросы

1. Что такое риск?

2. Что такое угроза?

3. Что такое остаточный риск?

4. Как можно качественно оценить риск?

5. Какие существуют методы количественной оценки рисков?

Лекция 15.

ВЕРИФИКАЦИЯ ЗАЩИТЫ

Доказательная база надежности реализации политики безопасности

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

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

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

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

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

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

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

· верификация на основе формальных методов доказательства;

· математические модели гарантированно защищенных систем.

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

Если модель ПБ удается достаточно подробно и четко формализовать математически, то высока вероятность получить аналитически или путем строгих логических рассуждений доказательство гарантии выполнения объектом защиты ПБ. Для относительно простых систем и перечисленных выше моделей ПБ в условиях достаточно "жестких" дополнительных ограничений получить такие оценки можно. Их удается получить, например, в рамках модели "Take-Grant", описывающей с помощью теории графов способы распространения прав доступа в системах с дискреционной ПБ, или теоретико-множественных моделей "Белла- Лападула", а также ряда других.

Однако практические системы, подлежащие защите, являются более сложными и, как правило, распределенными.

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

Возможны два подхода к анализу и оценке защищенности распределенной системы:

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

2. Все компоненты и связи между ними составляют единое целое. В этом случае существует лицо (центр), которое берет на себя обязательство обеспечить безопасность в сети. Здесь эта безопасность относится к сети в целом, несмотря на неопределенный периметр и изменяемую конфигурацию. Тогда должна существовать некоторая политика безопасности и средства сети, поддерживающие эту политику (NТСВ – Network Trusted Computing Base). При этом средства поддержки безопасности в сети вовсе не должны составлять полный комплекс (удовлетворяющий стандарту ОК) механизмов защиты в каждом отдельном компоненте. Однако они, в целом, должны составлять единый механизм защиты, который в случае использования дискреционной и мандатной политики может анализироваться на предмет соответствия стандарту ОК. В частности, для класса ВЗ и выше NTCB должна реализовывать монитор обращения во всей сети. Отсюда возникает задача синтеза из отдельных компонентов NTCB, поддерживающей политику в сети, а также задача оценки защитных функций компонентов, из которых NTCB возможно синтезировать. Для анализа и синтеза таких систем применяется подход, который состоит в том, чтобы по сети построить гипотетическую монолитную систему с ТСВ, совпадающей по функциям с NTCB, и ее оценивать. С другой стороны, при создании распределенной системы можно сначала создать гипотетический проект монолитной защищенной системы, а затем провести декомпозицию его по компонентам распределенной системы с сохранением защитных свойств. И, наконец, всем известна "слабость" ОК, состоящая в том, что слабо отработана проблема контроля защищенности при модификациях или замене подсистем. Если для монолитной вычислительной системы эта слабость была преодолима, то в распределенных системах проблема наращивания компонентов без переоценки всего в целом становится принципиальной.

Синтез и декомпозиция защиты в распределенных системах

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

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

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

Теорема 1. Пусть выполнены следующие условия.

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

2. Каждый субъект может иметь доступ только к объектам своего компонента.

3. Каждый компонент содержит отнесенный к этому компоненту монитор обращений, который рассматривает только обращения субъектов этого компонента к объектам этого компонента.

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

Тогда совокупность мониторов обращения компонентов является монитором обращения в сети.

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

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

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

2) Монитор обращения каждого компонента по определению гарантированно защищен. Поэтому объединение их гарантированно защищено.

3) Функционирование всех мониторов обращения компонентов полностью тестируется (то есть существует полная система тестов). Тогда совокупность тестов компонентов полностью тестирует М.

Теорема доказана.

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

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

Некоторые компоненты монитора обращений NTCB могут быть вырожденными. Кроме того, наличие монитора обращений вовсе не означает, что в компоненте есть все функции ТСВ системы защиты по какому-либо классу. Единая распределенная система тем и хороша, что ТСВ сети можно построить из компонентов, не содержащих в отдельности все функции защиты.

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

1. Безопасность связи ¾ устойчивость к несанкционированным раскрытию или модификации передаваемой ценной информации.

2. Надежность связи ¾ не допускает отказ от доставки сообщения, неправильную доставку, доставку ошибочных данных.

3. Имитозащита ¾ не допускает изменений в критичной для этого информации (метки и т.д.).

4. Не допускает скрытые каналы утечки за счет модуляции параметров канала.

Анализ компонентов распределенной системы

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

При анализе возникают две проблемы.

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

2. Какими критериями надо пользоваться при анализе компонентов и как из результатов для компонентов синтезировать общую оценку.

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

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

• поддержки дискреционной политики (Д);

• поддержки мандатного контроля (М);

• функции идентификации/аутентификации (I);

• аудита (А).

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

Примеры включения таких подсистем.

Пример 1. (см. рис. 15.1) Пусть дан М – компонент (то есть подсистема, единственной функцией которой является поддержка мандатного контроля доступа). Пусть также эта подсистема обладает монитором обращений, оценена как самостоятельная система по классу А1. Тогда ее можно включить как компонент в гарантированно защищенную распределенную систему обработки информации, например, для выполнения функций многоуровневой коммутации пакетов. Это можно проиллюстрировать схемой, взятой из "Красной книги".

На приведенной схеме показана взаимосвязь М – компонента с другими компонентами и, в частности, с подсистемами ТСВ. Минимальное взаимодействие необходимо с системой аудита.

Пример 2. (см. рис. 15.2) Данный пример из "Красной книги" показывает использование Д-компонента в качестве одноуровневого файлового сервера сети.

Рис. 15.1. Взаимосвязь компонента M с другими компонентами системы

Рис. 15.2. Взаимосвязь компонента Д с другими компонентами системы

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

Контрольные вопросы

1. Что такое "гарантированная защита"?

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

3. При каких условиях совокупность мониторов обращения компонентов является монитором обращения в сети?

4. В чем заключается безопасность связи?

5. Что такое имитозащита?

Лекция 16.

ПРЕДСТАВЛЕНИЕ ПОЛИТИК БЕЗОПАСНОСТИ

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

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

1. Закрытые политики безопасности.

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

2. Открытые политики безопасности.

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

3. Гибридные политики безопасности.

При описании гибридных политик безопасности должны быть определены все запрещенные и разрешенные виды доступа.

4. Гибридные политики безопасности с разрешенными противоречиями.

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

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

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

Существует несколько методов описания политик безопасности:

· аналитические;

· графовые;

· объектные;

· логические.

Аналитические методы

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

1. В терминах теории множеств определяется система и ее состояния.

2. Задаются функции переходов системы из состояния в состояние.

3. Определяются критерии безопасности системы.

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

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

Рассмотрим пример применения АМ для описания ПБ системы, построенной на базе дискреционной модели. Представление системы S (Q, R, C) состоит из элементов:

· конечные исходные наборы субъектов S 0 = { s 1, …, sn } и объектов O 0 ={ o 1, …, om }, где S 0 Ì O 0;

· конечный набор прав доступа R = { r 1, …, rn };

· исходная матрица доступа M 0 с правами доступа субъектов к объектам;

· конечный набор команд C = { ai (x 1, …, xk)}, каждая из которых состоит из условий выполнения и интерпретации в терминах элементарных операций:

command a (x 1, …, xk) if r 1 in M [ xs 1, xo 1] and r 2 in M [ xs 2, xo 2] and … rm in M[ xsm, xom ] then op 1, op 2, …, opn,

где a — имя команды; xi — параметр команды, являющийся идентификатором субъектов и объектов; si и oi — индексы субъектов и объектов в диапазоне от 1 до k; opi — элементарная операция.

Поведение системы во времени моделируется с помощью последовательности состояний { Qi }, в которой каждое последующее состояние является результатом применения некоторой команды из множества C к предыдущему: Qn +1 = Cn (Qn). Пространство состояний — декартово произведение O ´ S ´ R. Состояние Q — кортеж (S, O, M), где M — матрица прав доступа. Ячейка M [ s, o ] содержит набор прав субъекта s к объекту o, принадлежащих множеству прав доступа R. Начальное состояние Q 0 = (S 0, O 0, M 0) является безопасным относительно права r, если не существует применимой к Q 0 последовательности команд, в результате которой r будет занесено в ячейку матрицы M, в которой оно отсутствовало в состоянии Q 0.

Графовые методы

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

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

Показательным примером графового метода является визуальный язык объектных ограничений LaSCO (Language for Security Constraints on Objects).

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

Объектные методы

Объектные методы базируются на теории объектно-ориентированного проектирования, где в качестве объектов выступают правила ПБ, группы правил, роли. Каждый объект принадлежит к определенному типу — классу, — который занимает свое место в иерархии типов. Сущности системы (субъекты и объекты) также подразделяются на типы, называемые доменами.

Представление и анализ ПБ проводится как объектная декомпозиция системы и оценка безопасных/небезопасных состояний. Анализ системы проводится по следующей схеме:

1. Задание типов и объектов данных типов для сущностей системы.

2. Связывание объектов в иерархию.

3. Определение методов доступа к объектам, т.е. правил доступа.

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

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

Синтаксис правила авторизации в языке Ponder:

inst (auth+ | auth-) имя_правила "{" subject домен; target домен; action список_допустимых_операций; [ when ограничения;] "}"

Такие слова как inst, auth+, action выполняют роль служебных слов языка Ponder:

· inst — объявление правила;

· auth+ — позитивная (действия, указанные как значения action);

· auth- — негативная авторизация;

· subject — сущность или множество сущностей, для которых задается авторизация;

· target — сущность или множество сущностей, над которыми применяется правило;

· action — действия, на которые авторизован subject над target;

· when — ограничения, в рамках которых действует авторизация.

Альтернативные выражения заключены в круглые скобки "()", разделенные символом '|'. Необязательные элементы описываются в квадратных скобках "[]". Повторения описываются с помощью фигурных скобок "{}". Ограничения являются необязательными во всех типах правил и могут применяться для ограничения применимости правил, основанных на времени или значениях атрибутов сущностей, к которым относится правило.

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

С помощью языка Ponder правила чтения и записи в ИС, использующей дискреционную модель безопасности, можно смоделировать следующим образом:

inst auth + read { subject s=Subjects; target o=Objects; action read(); when in(r, rights(s,o));}

inst auth + write { subject s=Subjects; target o=Objects; action read(); when in(w,rights(s,o));}

Субъекты — сущности типа Subjects — могут производить операции чтения и записи над объектами — сущностями типа Objects — только в том случае, если они обладают соответствующими правами доступа (rights(s,o)), проставленными в соответствующей ячейке матрицы доступа.

Рис. 16.1. Иерархия правил в языке Ponder

Делегирование полномочий моделируется правилом deleg:

inst deleg+ (read, write) giverights{ grantee Subjects; subject s=Subjects; target o=Subjects; when in(ga,s.rights(o))}

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

Логические методы

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

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

Моделирование ПБ проводится в терминах логики предикатов. Вводятся множества S, O и A — множества субъектов S = U È G — множество субъектов (U — множество пользователей, G — множество групп пользователей), объектов и действий субъектов, соответственно. Система DS представляется как кортеж множеств (O, T, S, A), где Т — множество типов объектов. Термом авторизации называется совокупность (s, o, a), где ее элементы — константы или переменные, определенные на множествах S, O и A. Политика безопасности ¾ набор термов авторизации. Термы (s, o, a) в политике P устанавливают доступ, разрешенный политикой. В ПБ формулируются условия выполнения термов и правила логического вывода новых термов.

Язык авторизаций состоит из ограничений, которые задаются как факты с аргументами из множеств S, O, A, и логических правил, построенных на основе термов авторизации вида (s, o, a) L 1 Ù … Ù Ln, где Li ¾ терм авторизации. Основу ЯА составляет фиксированный набор предикатов (табл. 16.1.) вместе с их отрицаниями.

Таблица 16.1

Предикаты языка авторизаций

Предикат	Назначение
cando	разрешение доступа субъекта к объекту
dercando	аналогичен cando с учетом логического вывода
do	разрешение доступа конкретного субъекта к конкретному объекту
done	разрешение, если субъект ранее уже выполнял указанное действие над объектом
error	ошибка авторизации
dirin, in	прямое и косвенное включение субъектов в группы
typeof	тип объекта
owner	принадлежность конкретного объекта определенному субъекту

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

Однако известные решения на базе ЛМ, в том числе и ЯА, не обладают универсальностью, необходимой для моделирования и анализа ПБ в реальных ИС, поскольку имеют ряд ограничений:

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

2. Отсутствие математических операций сравнения (например, >, <, =, ³, £, ¹) применительно к описанию отношений "субъект-объект", что усложняет процесс моделирования политик мандатного управления доступом. Так, например, правило "нет чтения вверх", или простое свойство безопасности модели Белла-ЛаПадулы, содержит сравнение уровней безопасности. Отсутствие сравнений делает невозможным описание такого рода правил.

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

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

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

Общая характеристика методов моделирования политик безопасности

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

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

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

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

Контрольные вопросы

1. Какие типы политик безопасности существуют?

2. Приведите пример применения аналитических методов для описания системы.

3. Каким образом проводится анализ системы при использовании объектных методов?

4. Какая иерархия правил существует в языке Ponder?

5. В чем заключаются преимущества логических методов моделирования?

Лекция 17.

УПРАВЛЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТЬЮ

Дата добавления: 2014-11-20