Полная версия

Главная arrow Информатика arrow ЗАЩИТА ИНФОРМАЦИИ: ОСНОВЫ ТЕОРИИ

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>

Формирование требований для систем защиты информации повышенного уровня защиты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требование. В качестве объектов доступа в разграничительной политике должны выступать все системные объекты — системные файловые объекты и объекты реестра ОС.

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

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

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

Два основных потенциально опасных действия процесса, как следует из анализа матрицы контроля доступа, предполагают:

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

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

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

Рассмотрим, в чем состоит эта задача ЗИ.

Как отмечали, в широко распространенных ОС семейства Windows для идентификации субъектов, выполняющих в системе различные действия, используются идентификаторы защиты {security identifiers, SID). SID имеются у пользователей, локальных и доменных групп локальных компьютеров, доменов и членов доменов. Все работающие в системе процессы и потоки выполняются в контексте защиты того пользователя, от имени которого они так или иначе были запущены, а для идентификации контекста защиты процесса или потока используется объект, называемый маркером доступа {access token). В процессе регистрации в системе создается начальный маркер, представляющий пользователя, который входит в систему, и сопоставляет его с процессом оболочки, применяемой для регистрации пользователя.

Маркер может быть основным (идентифицирует контекст защиты процесса) или олицетворяющим (применяется для временного заимствования потоком другого контекста защиты — обычно другого пользователя). Олицетворение {impersonation) — средство, часто используемое в модели защиты Windows, предоставляющее возможность отдельному потоку выполняться в контексте защиты, отличном от контекста защиты процесса, т.е. действовать от лица другого пользователя. Олицетворение, в частности, используется в модели программирования «клиент-сервер». При заимствовании прав сервер временно принимает профиль защиты клиента, который обращается к ресурсу. Тогда сервер может работать с ресурсом от имени клиента, а система защиты — проводить проверку его прав доступа. Приведенная схема обслуживания клиентского запроса показана на рис. 9.3.

Обслуживание клиентского запроса на доступ к ресурсу с использованием олицетворения

Рис. 9.3. Обслуживание клиентского запроса на доступ к ресурсу с использованием олицетворения

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

Подобная возможность присутствует и в механизме идентификации Unix-подобных систем. В Unix существуют два типа идентификаторов пользователя: реальный и эффективный. Реальным идентификатором пользователя данного процесса является идентификатор пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа процесса к ресурсам системы (в первую очередь к ресурсам файловой системы). Обычно реальный и эффективный идентификаторы совпадают, т.е. процесс имеет в системе те же права, что и пользователь, запустивший его. Однако существует возможность задать процессу более широкие права, чем права пользователя, путем установки бита SUID, когда эффективному идентификатору присваивается значение идентификатора владельца выполняемого файла (например, пользователя root). Таким образом, процесс выполняется от лица пользователя — владельца исполняемого файла, причем заимствование прав происходит прозрачно (не требуется дополнительная аутентификация) для пользователя, запустившего процесс.

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

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

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

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

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

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

Требование. СЗИ должна обеспечивать возможность контроля и разграничения прав доступа к сервисам олицетворения.

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

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

Рассмотрим модель контроля доступа к сервисам олицетворения. Будем считать, что множество С = {С,, ..., С,} — линейно упорядоченное множество пользователей (учетных записей), зарегистрированных в системе.

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

В любой момент времени система описывается своим текущим состоянием Q = (С, С, /); М[С, С] — ячейка матрицы, содержит право смены имен пользователей: «1» — смена имени разрешена, «О» — запрещена. Условимся строками матрицы обозначать первичные, а столбцами — эффективные имена пользователей. Будем обозначать Cf(l)C; разрешение изменения первичного имени пользователя С, при доступе к объекту на эффективное имя Су, i = 1,/; j = 1,/, i # j. Запрет доступа будем обозначать следующим образом: С?0)Сг Следует говорить, что доступ к объекту осуществляется без смены имени пользователя в случае Cf(l)C;, i= 1,/.

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

Как говорили, потенциальная возможность утечки права доступа R состоит в возможности олицетворения субъекта доступа С; с субъектом доступа С; (получения субъектом С, прав доступа к объектам, заданным в матрице доступа М для субъекта доступа С;).

Рассмотрим на примере матрицы Мдва правила олицетворения — С,(1)С2 и С2( 1 )С,. Как видим, правило С,(1)С2 не приводит к повышению привилегий, так как при таком олицетворении субъект доступа С, лишь потеряет права доступа к объекту О, (w и d). Правило же С2(1)С, наделит субъект доступа С2 дополнительными правами доступа (w и d) к объекту О,, т.е. его привилегии в отношении доступа к объекту О, в этом случае будут повышены, в результате чего произойдет утечка прав доступа (w и d) субъекта С2 к объекту О,. Как следствие, данное правило олицетворения требуется запретить. [1]

Утверждение. Расширение диагональной матрицы контроля смены имен пользователей при доступе субъектов к объектам / (для которой не предполагается разрешения олицетворений с другими субъектами доступа) возможно при соблюдении правила: С,(1)С,у ^ г, допустимо (корректно) в том случае, если множество прав доступа субъекта С; к каждому объекту из множества О = (О,,OJ является подмножеством прав доступа субъекта С, к каждому соответствующему объекту из множества О = {О,,OJ или совпадает с ним.

Доказательство. Только при выполнении данного условия введение в диагональную матрицу контроля смены имен пользователей при доступе субъектов к объектам I правило олицетворения С,(1)С,,j ^ i не приведет к повышению привилегий субъекта С,, как следствие, в этом случае отсутствует утечка прав R.

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

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

В данном случае разрешаемое правило олицетворения может быть представлено следующим образом: C,(Mi)(l)C)(M;). Обратимся к матрице контроля доступа Мш(/)):

Видим, что любое подобное олицетворение С,(М;)(1)С;(М.) при j * i приводит к утечке прав доступа R. Как следствие, можем сформулировать

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

Требование. Мандатный контроль доступа к сервисам олицетворения должен контролировать п разграничивать права на смену идентификатора пользователя, т.е. олицетворение С,(М;)(1)С/(М^), при доступе субъектов к объектам. Олицетворение, расширяющее диагональную матрицу олицетворения: Cj(M,)(l)C;(M;),y ^ г, недопустимо.

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

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

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

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

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

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

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

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

Пусть на линейно упорядоченном множестве вероятностей обнаружения и присутствия уязвимостей реализации Р = {Р(, ..., Р,} в процессах из множества субъектов доступа С = {С,,С,} задано следующее отношение: Р, <ЗС Р2 <ЗС... РЛ Тогда матрица контроля доступа Мкб, описывающая максимально безопасную разграничительную политику доступа при рассматриваемом условии, будет выглядеть так:

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

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

Замечание. Максимальный уровень безопасности обработки информации

критичными процессами обеспечивается при полной изоляции обработки ими

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

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

С учетом сказанного уже можем сформулировать соответствующее требование.

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

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

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

Для решения данной задачи защиты эффективно применение метода перенаправления запросов доступа.

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

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

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

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

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

С учетом сказанного можем сформулировать следующее соответствующее требование.

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

Требование. Поскольку в данном случае изолируется обработка информации в определенной роли (сессии), идентифицируемой учетными записями пользователей, процессы должны задаваться в правилах доступа маской «*» — любой.

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

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

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

Требование. Чтобы изолировать роли по критичным процессам, необходимо в правила доступа включить субъект доступа, идентифицируемый следующим образом — «пользователь, процесс», где в качестве пользователей указываются учетные записи, идентифицирующие критичные роли, в качестве процессов — критичные процессы.

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

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

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

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

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

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

Исходя из требований к защите обрабатываемой информации от нарушения конфиденциальности, матрица сессионного контроля доступа М, в предположении о том, что чем выше полномочия субъекта и уровень конфиденциальности объекта, тем меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов С = (С,,..., С,} и О = (О,,..., О,}), и тем меньшее значение метки безопасности М;, i = 1,..., / им присваивается, т.е.: М, < М2 < М;) < ... <М,, имеет следующий вид:

При разрешении записи и при выполнении условия: Мс > М0 (где Мс — метка безопасности субъекта (группы субъектов) доступа, М0 — метка безопасности объекта (группы объектов) доступа), что не нарушает требования к защите от понижения категории обрабатываемой информации, матрица контроля доступа Мт(р):

Исходя из сформулированного выше требования, в части защиты от атак, основанных на наделении процессов вредоносными свойствами за счет прочтения ими внедренных в систему вредоносных командных файлов (скриптов и т.д.), можем построить матрицу сессионного контроля доступа М,я(ц), при том же предположении о том, что чем выше полномочия субъекта и уровень конфиденциальности объекта, тем меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов — С = {С1?..., С/} и О = {01?О,}) и тем меньшее значение метки безопасности М,, i = 1,..., / им присваивается, т.е.: М, < М2 < М3 < ... < М7, имеющую совершенно иной вид:

Замечание. Аналогичный вид матрица мандатного контроля доступа имеет для так называемой модели целостности Биба [18], суть которой состоит во включении в систему иерархического признака «целостность», отображаемого в разграничительной политике доступа мандатом или меткой безопасности.

В модели целостности Биба вводятся уровни целостности, сопоставляемые с субъектами и объектами доступа, которым в соответствии с заданным уровнем присваивается метка безопасности.

Формализованные мандатные правила контроля доступа при этом имеют следующий вид.

  • 1. Субъект С имеет доступ к объекту О в режиме «Чтения», если выполняется условие: Мс > М0.
  • 2. Субъект С имеет доступ к объекту О в режиме «Записи», если выполняется условие: Мс < М0.

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

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

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

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

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

  • 1. Субъект С имеет доступ к объекту О в режиме «Чтения», «Записи», «Удаления», если выполняется условие Mt. = М0.
  • 2. При выполнении условия М(. # Мп, субъект С не имеет доступа к объекту О.

Данные правила описываются диагональной матрицей М:

Сформулируем соответствующее требование.

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

Требование к автоматической реакции СЗИ на зарегистрированное событие НСД. Обнаружение НСД процессов к ресурсам можно позиционировать как решение задачи обнаружения и предотвращения вторжений, при этом собственно попытка НСД СЗИ предотвращается.

Вместе с тем процесс, наделенный вредоносными свойствами (осуществляющий 11СД к ресурсам), при этом продолжает функционировать в системе и может совершить следующую, уже совершенно иную, атаку.

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

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

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

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

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

  • [1] В общем случае под повышением привилегий будем понимать приобретение субъектом в результате олицетворения некоторого права доступаиз множества R в отношении какого-либо объекта, исходно отсутствовавшего для этого субъекта (т.е. действие, связанное с утечкой права R).
 
<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>