36238

Оценка обычных программ

Доклад

Информатика, кибернетика и программирование

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

Русский

2013-09-21

116.5 KB

1 чел.

Оценка обычных программ

8.1.1. Качество программ

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

8.1.2. Надежность программ

Надежность программы проще всего определить как ее устойчивость в работе. Из-за очень высокой сложности современных программ далеко не все из них работают безошибочно. Точнее говоря, редко в какой программе не обнаруживались ошибки после успешного прохождения отладки и тестирования. И во многих программах обнаруженные в процессе эксплуатации ошибки даже не исправляются – их просто переводят в разряд документированных особенностей, и пользователям предлагается использовать обходной путь, приводящий к желаемому результату и не вызывающий ошибки. Некоторые ошибки проявляются очень редко и почти случайным образом, что делает их локализацию и исправление чрезвычайно трудной задачей. Так, например, почти любой пользователь Microsoft Office сталкивался с ситуацией, когда Word закрывался с сообщением об ошибке и результаты работы, выполненной с момента последнего сохранения (или автосохранения), оказывались потерянными. Но условия, при которых Word дает сбой, у каждого пользователя могут быть индивидуальными. Более того, ошибка вполне могла произойти не в самой программе текстового редактора, а в одном из общих компонентов Microsoft Office или Windows, используемых редактором Word. Можно сказать, что надежность программы характеризует безотказность ее работы во всех необходимых пользователю режимах, и чем выше число обнаруженных отказов за определенный период эксплуатации, тем ниже надежность программы.

8.1.3. Экономическая эффективность программ

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

8.2. Оценка средств защиты

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

8.2.1. Качество защиты

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

8.2.2. Надежность защиты

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

8.2.3. Экономическая эффективность защиты

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

Концепция изолированной программной среды [26]

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

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

При рассмотрении понятия «злоумышленник» практически всегда выделяется объект его воздействия – часть КС, связанная с теми или иными действиями злоумышленника («объект атаки»). Следовательно, можно выделить три компоненты, связанные с нарушением безопасности КС: «злоумышленник» – внешний по отношению к КС источник нарушения свойства «безопасность», «объект атаки» – часть, принадлежащая КС, на которую злоумышленник производит воздействие, «канал воздействия» – среда переноса злоумышленного воздействия.

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

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

Можно сформулировать три аксиомы защищенных КС:

Аксиома 1. В защищенной КС всегда присутствует субъект, выполняющий контроль операций субъектов над объектами. Этот субъект фактически отвечает за реализацию некоторой ПБ.

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

Аксиома 3. Все вопросы ИБ описываются доступами субъектов к объектам.

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

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

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

  1.  Формулирование и изучение ПБ.
  2.  Реализация ПБ.
  3.  Гарантирование заданной ПБ.
  4.  Управление безопасностью.

Типовой жизненный цикл КС состоит из следующих стадий:

  1.  Проектирование КС и проектирование ПБ.
  2.  Моделирование ПБ и анализ корректности ПБ, включающий установление адекватности ПБ и целевой функции КС.
  3.  Реализация ПБ и механизмов ее гарантирования, а также процедур и механизмов управления безопасностью.
  4.  Эксплуатация защищенной КС.

Модели, связанные с реализацией ПБ, не учитывают возможности субъектов по изменению КС, которые могут привести к изменению ее свойств и как предельный случай к полной неприменимости той или иной модели к описанию отношений «субъект-объект» в измененной КС. Этот факт не является недостатком ПБ. Достоверность работы механизмов реализации ПБ считается априорно заданной, поскольку в противном случае невозможна формализация и анализ моделей. Однако вопрос гарантий ПБ является ключевым как в теории, так и в практике.

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

  1.  Человек-пользователь воспринимает объекты и получает информацию о состоянии КС через субъекты, которыми он управляет и которые производят отображение информации в воспринимаемом человеком виде.
  2.  Угрозы компонентам КС, рассматриваемой в модели потоков или состояний, исходят от субъектов как активной компоненты, порождающей потоки и изменяющей состояние объектов КС.
  3.  Субъекты могут влиять друг на друга через изменяемые ими объекты, связанные с другими субъектами, порождая в конечном итоге в КС субъекты (или состояния КС), которые представляют угрозу для безопасности информации или для работоспособности самой КС.

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

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

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

Аксиома 4. Субъекты в КС могут быть порождены только субъектами из объектов.

При этом можно говорить, что в результате выполнения операции порождения субъекта активизирующий субъект порождает порожденный субъект из объекта-источника. Очевидно, что операция порождения субъектов зависит как от свойств активизирующего субъекта, так и от содержания объекта-источника. Так, практически во всех ОС существует понятие исполняемого файла – объекта, могущего быть источником для порождения субъекта. Например, для MS DOS файл edit.com является объектом-источником для порождения субъекта-программы текстового редактора, а порождающим субъектом является, как правило, командный интерпретатор shell (объект-источник – command.com). Из архитектуры фон Неймана следует также, что с любым субъектом связан (или ассоциирован) некоторый объект (объекты), отображающий его состояние, - например, для активной программы (субъекта) ассоциированным объектом будет содержание участка оперативной памяти с исполняемым кодом данной программы.

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

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

Доступ данного субъекта к данному объекту – это порождение потока информации между некоторым объектом (например, ассоциированным с данным субъектом) и данным объектом.

Выделим все множество потоков P для фиксированной декомпозиции КС на субъекты и объекты во все моменты времени (множество потоков является объединением потоков по всем моментам дискретного времени) и произвольным образом разобьем его на два непересекающихся подмножества: N и L, . Обозначим: N – подмножество потоков, характеризующее НСД; L – подмножество потоков, характеризующих легальный доступ. Дадим некоторые пояснения к разделению множеств L и N. Понятие «безопасности» подразумевает наличие и некоторого состояния «опасности» – нежелательных состояний какой-либо КС. Будем считать парные категории типа «опасный – безопасный» априорно заданными для КС и описываемыми ПБ, а результатом применения ПБ к КС – разделение на множество «опасных» потоков N и множество «безопасных» L. Деление на L и N может описывать как свойство целостности (потоки из N нарушают целостность КС) или свойство конфиденциальности (потоки из N нарушают конфиденциальность КС), так и любое другое произвольное свойство.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 9.2. Ядро безопасности с учетом контроля порождения субъектов

Из базового свойства ИПС следует, что для создания гарантированно защищенной КС (выполнение ПБ) необходимо:

1) убедиться в попарной корректности субъектов, замыкаемых в ИПС (либо убедиться в корректности любого субъекта относительно МБО и МБС);

2) спроектировать и реализовать программно (или программно-аппаратно) МБС так, чтобы:

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

3) реализовать МБО для априорно сформулированной ПБ.

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

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

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

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

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

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

Поясним требование невозможности прекращения выполнения субъекта каким-либо иным образом, кроме предопределенного. В данном случае необходимо учитывать, что во множестве субъектов, замкнутых в ИПС, выделены два особых субъекта – МБС и МБО. Прекращение существования МБС означает нарушение условия замкнутости среды, а прекращение существования МБО означает НСД.

Шаг 3 заключается в проектировании и разработке программных или программно-аппаратных средств защиты в КС, а затем и их тестировании. Он подразумевает проектирование и реализацию в заданном множестве субъектов МБС и МБО. Практически шаги 1-3 могут быть выполнены исходя из описанных в литературе методик разработки и тестирования ПО.

Шаг 4 заключается в «замыкании» всего комплекса ПО, включая и средства защиты, в ИПС.

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

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

  •  качественный алгоритм КЦ;
  •  контроль реальных данных, т.е. тождественное отображение состояния контролируемого и эталонного объектов в ассоциированные объекты-данные субъекта КЦ.

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

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

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

Аксиома 5. Генерация ИПС рассматривается в условиях неизменности конфигурации тех субъектов КС, которые активизируются до старта процедур КЦ объектов, входящих в процедуры активизации КС и объектов, описывающих последовательность активизации компонент. Неизменность данных субъектов обеспечивается внешними по отношению к самой КС методами и средствами. При анализе или синтезе защитных механизмов свойства указанных субъектов являются априорно заданными.

При решении практических вопросов генерации ИПС можно выделить три самостоятельных направления.

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


База данных защиты

Ядро безопасности

убъект

Объект

Рис. 9.1. Классическая модель ядра безопасности

АО

Субъект

МБО

МБС

ОУ

Объект

Субъект


 

А также другие работы, которые могут Вас заинтересовать

12781. ЧТО ТАКОЕ CSS 24.99 KB
  ВВЕДЕНИЕ Каскадные таблицы стилей/Cascading Style Sheets CSS это поразительное изобретение для улучшения вида ваших webсайтов. Оно поможет сэкономить уйму времени и предоставит вам совершенно новые возможности в дизайне webсайтов. CSS совершенно необходим каждому работающему с we...
12782. Шрифты. Семейство шрифта 18.13 KB
  Шрифты На этой лабораторной работе вы изучите работу со шрифтами с помощью CSS. Мы рассмотрим также вопрос о том что конкретный шрифт выбранный для webсайта может отображаться только в том случае если этот шрифт установлен на PC с которого выполняется доступ к этому webса...
12783. Цвет и фон. Цвет переднего плана: свойство color 52.81 KB
  Цвет и фон На этой лабораторной работе вы научитесь использовать цвета и фон на ваших webсайтах. Мы рассмотрим также продвинутые методы позиционирования и управления фоновым изображением. Будут разъяснены следующие CSSсвойства: color backgroundcolor backgroundimage bac...
12784. Текст. Отступы. Выравнивания текста 12.22 KB
  Текст Форматирование и установка стиля текста ключевая проблема для любого webдизайнера. На лабораторной вы увидите впечатляющие возможности CSS при отображении текста. Будут рассмотрены следующие свойства: textindent textalign textdecoration letterspacing texttransform ...
12785. Ссылки. Что такое псевдокласс 15.12 KB
  Ссылки Всё изученное в предыдущих уроках вы можете применять и для ссылок/links например изменять шрифт цвет подчёркивание и т. д. Новым будет то что в CSS эти свойства можно определять поразному в зависимости от того посетили уже ссылку активна ли она находится ли указ...
12786. Идентификация и группирование элементов (class и id) 15.12 KB
  Идентификация и группирование элементов class и id Иногда вам нужно будет применить особый стиль к определённому элементу или конкретной группе элементов. В этой лабораторной работе мы подробно разберём как можно использовать class и id для специфицирования свойств выбран
12787. Группирование элементов (span и div) 15.67 KB
  Группирование элементов span и div Элементы span и div используются для структурирования документа часто совместно с атрибутами class и id. В этом уроке мы подробно рассмотрим как использовать span и div поскольку эти элементы HTML имеют важнейшее значение в CSS. Группиро...
12788. Боксовая модель в CSS 24.21 KB
  Боксовая модель Боксовая модель в CSS описывает боксы генерируемые для HTMLэлементов. Боксовая модель также имеет детальные опции для определения полей рамок заполнения и содержимого каждого элемента. На диаграмме далее показано как построена боксовая модель: Боксов...
12789. Поля и заполнение 13.38 KB
  Поля и заполнение В предыдущем уроке мы рассмотрели боксовую модель. В этом уроке объясним как можно изменять представление элементов свойствами margin и padding. Установим поля элемента Установим заполнение элемента Установим поля элемента У элемента ест