Контрольная работа № 1 (стр. 13 )

 

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

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

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

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

 

Посыл 4

 

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

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

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

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

 

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

 

Теперь рассмотрим возможные подходы к формированию требований каждой группы.

 

Требования к корректности реализации механизмов защиты

 

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

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

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

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

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

Требования должны быть технически реализуемы.

 

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

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

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

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

Однозначность идентификации субъекта доступа, права доступа которого к объектам разграничиваются.

Однозначность идентификации объекта доступа, права доступа субъектов к которому разграничиваются.

Возможность разграничить права доступа любого субъекта к любому объекту.

 

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

Прокомментируем сказанное, для чего пойдем от обратного. Рассмотрим, почему в данных предположениях, на наш взгляд, можно считать, что механизм избирательного контроля доступа, например, ОС Windows XP, реализован некорректно (не будем детально исследовать данный механизм, остановимся лишь на некоторых примерах):

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

Не реализуется возможность разграничить права доступа любого субъекта к любому объекту. Относительно субъектов – подобная возможность не реализуется для учетной записи System, как следствие, появляется множество атак на расширение привилегий, использующих уязвимость ОС – возможность получение под учетной записью систем неограниченных прав доступа к ресурсам. Относительно объектов. К некоторым файловым объектам средствами ОС при обеспечении корректной работы системы и приложений разграничить права доступа невозможно, например, к папке Documents and Settings\All Users на системном диске. Следовательно, не представляется возможным изолировать возможности обработки конфиденциальной информации для пользователей (о полномочных принципах контроля доступа здесь вообще говорить не приходится);

 

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

На начальном этапе проектирования СВТ должна быть построена модель защиты. Модель должна включать в себя ПРД к объектам и не противоречивые правила изменения ПРД.

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

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

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