Что такое изолированная программная среда

В чем заключается отличие ИПС от ЗПС (изолированной программной среды от замкнутой).

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

Объясните принципы функционирования механизма изолированной программной среды (ИПС).

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

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

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

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

Ресурсом может быть файл, каталог, переменная реестра, ключ реестра.

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

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

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

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

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

1. Для любого объекта ОС существует владе­лец.

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

3. Для каждой четверки субъект-объект-метод-процесс возможность доступа определена однозначно.

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

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

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

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

Изолированная программная среда не защищает от утечки конфи­денциальной информации.

В чем заключается отличие ИПС от ЗПС (изолированной программной среды от замкнутой).

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

(в замкнутой системе может попасть вирус)

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

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

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

— пользователь может работать только с теми программами, запуск которых разрешен в UEL-списке (список разрешенных для запуска программ, UserExecutableList), Этот список формируется индивидуально для каждого пользователя;

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

— замкнутая программная среда может использоваться в одном из двух режимов работы: «мягком» или «жестком».

Источник

Защита от РПВ. Изолированная программная среда

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

Общие методы защиты программного обеспечения от РПВ:

1. Контроль целостности системных областей, запускаемых прикладных

программ и используемых данных. Следует помнить, что контроль

целостности информации может быть обойден злоумышленником

· навязывания конечного результата проверок;

· влияния на процесс считывания информации;

· изменения хеш-значений, хранящихся в общедоступных файлах.

2. Контроль цепочек прерываний и фильтрация вызовов критических

для безопасности системы прерываний. Данные методы действенны

лишь тогда, когда контрольные элементы не подвержены воздействию

закладок и разрушающее воздействие входит в контролируемый класс.

3. Создание безопасной и изолированной операционной среды.

4. Предотвращение результирующего воздействия вируса или закладки.

Например, запись на диск должна вестись только в зашифрованном

виде на уровне контроллера, либо должен быть реализован запрет

записи на диск на аппаратном уровне.

Специализированные методы борьбы с РПВ

К ним можно отнести:

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

· Поиск критических участков кода методом семантического анализа фрагментов кода на выполняемые ими функции, часто сопряженный с дизассемблированием или эмуляцией выполнения [22].

В качестве одной из возможных эвристических методик выявления РПВ в BIOS, ассоциированных с существенно важными прерываниями, следует рассмотреть эвристическую методику выявления РПВ в BIOS[23].

Эвристическая методика выявления РПВ в BIOS

1. Выделяется группа прерываний, существенных с точки зрения обработки информации программой, относительно которой проводится защита. Обычно это прерывания int 13h (запись информации на внешние магнитные накопители прямого доступа), int 14h (обмен с RS232 портом), int 10h (обслуживание видеотерминала), а также в обязательном порядке прерывания таймера int 8h, int 1Ch и прерывания клавиатуры int 9h и int 16h.

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

В цепочках исполняемых команд выделяются:

— команды работы с портами;

— команды передачи управления;

— команды пересылки данных.

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

групп. Определяется присутствие в прерываниях команд:

· работы с недокументированными портами. Наличие таких

команд, как правило, указывает на передачу информации некоторому

устройству, подключенному к параллельному интерфейсу (общей

шине), например, встроенной радиопередающей закладке.

· работы с портами, участвующими в работе другого класса

· перемещения данных из BIOS в оперативную память;

· передачи управления в оперативную память или в сегменты

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

Защита от РПВ путем создания изолированной программной среды

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

Потенциально злоумышленными действиями в этом случае могут быть следующие:

· проверенные программы будут использованы на другой ПЭВМ с другим BIOS и в этих условиях могут использоваться некорректно;

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

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

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

· На ПЭВМ c проверенным BIOS установлена проверенная ОС.

· Достоверно установлена неизменность ОС и BIOS для данного сеанса

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

· Исключен запуск проверенных программ в какой-либо иной ситуации, т.е. вне проверенной среды.

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

При выполнении перечисленных выше условий программная среда называется изолированной (ИПС – изолированная программная среда).

Основными элементами поддержания ИПС являются контроль целостности и активности процессов.

· невозможность запуска программ помимо контролируемых ИПС событий;

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

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

Источник

Изолированная программная среда – сферический конь в вакууме или …?

1. Немного про физику и лирику

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

И что самое характерное – работает! Уравнение Менделеева-Клапейрона прекрасно описывает вполне реальный газ, а классическая механика великолепно справляется с расчетом движения тел различного масштаба (пока этот масштаб не уходит в микромир или наоборот – в область действия общей теории относительности).

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

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

2. Как моделирование безопасности стало наукой

Но начнем мы с истории вопроса: в 70-ые годы прошлого века произошло одно крайне важное событие для сферы информационной безопасности: министерство обороны США купило компьютер. Примерно такой:

Компьютер Honeywell-6080. Девушка на фото то ли для привлечения внимания, то ли для масштаба…

Поскольку это были времена, когда деревья были маленькими, а компьютеры большими – у Министерства обороны США хватило денег (или места) только на один такой компьютер. Естественно, на нем предполагалось обрабатывать какие-то секретные данные министерства, но в это же время уже появился предвестник Интернета – ARPANET, и сотрудникам министерства очень хотелось не только работать с секретными данными, но и постить котиков…

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

Так и появился Project No. 522B – научно-исследовательский проект, задачей которого было… Ну, судя по результатам этого проекта, его задачей было создать дисциплину «Теоретические основы компьютерной безопасности» – практически все концепции, используемые в защитных мерах современных программных продуктах, были описаны в отчетах по проекту 522B.

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

Можно отдельную статью написать (и, если будет интересно – обязательно напишу!) про результаты исследований проекта 522B, а также про легендарных личностей мира информационной безопасности, которые в нем участвовали. Но нас интересует лишь только конкретное направление: субъектно-объектная модель целостности компьютерной системы.

3. Субъектно-объектная модель целостности компьютерной системы простыми словами

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

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

Однако, это слишком уж упрощенная модель… Давайте попробуем сделать ее немного ближе к реальности:

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

2. На поведение субъекта могут влиять объекты. Например, если объект – это конфигурация процесса.

3. Объекты могут меняться (зачем-то же субъекты получают к ним доступ? Вот и будем считать, что для того, чтобы что-то поменять).

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

5. И у монитора безопасности тоже есть связанные объекты, которые влияют на его работу – те, что содержат описание P_L.

Ну и чтобы совсем усложнить жизнь, давайте также отметим, что доступ субъекта S к объекту O в момент времени t₁ и момент времени t₂, это, вообще говоря, два разных доступа – потому что за прошедшее с момента t₁ время и субъект S, и объект O могли поменяться. А это значит, что наше множество P уже так запросто не описать – оно содержит бесконечное число элементов!

В моменты t1 и t2 субъект S1 получает доступ к объекту O2, но это уже совсем другой субъект и совсем другой объект…

Как же в таком хаосе гарантировать, что доступы будут только из P_L, если теперь даже непонятно, как это P_L описать?

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

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

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

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

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

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

Цепочка сломалась на том, что изменение объекта O1 в момент времени t1 уже не позволило создать измененный субъект S1

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

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

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

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

4. Изолированная программная среда в реальной жизни

Для начала решим (спустя полвека) задачу Министерства обороны США: Чтобы обеспечить безопасную работу пользователей за их единственным большим компьютером, необходимо реализовать:

1. Расширение ОС, которое будет контролировать целостность исполняемого файла перед запуском ПО. Если целостность нарушена – ничего запускаться не будет.

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

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

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

1. Мы можем контролировать целостность субъектов. Однако не всегда есть возможность предотвратить создание субъекта, если целостность нарушена (как остановить загрузку ПО коммутатора, если мы обнаружили изменение его сохраненной конфигурации?).

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

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

Что же можно сделать с учетом перечисленных ограничений?

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

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

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

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

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

1. Вести каталог сетевых объектов и их сетевых параметров.

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

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

И вот мы получили перечень основных функций ICS Asset Management решений. Как говорится: «Совпадение? Не думаю!»:-)

Функции решений ICS Asset Management по версии Dale Peterson

Сегодня на рынке представлено достаточно много решений класса ICS Asset Management и Detection, но базовые функции у всех примерно одинаковые. А вы теперь знаете почему…

Источник