В чем заключается отличие ИПС от ЗПС (изолированной программной среды от замкнутой).
Контрольные вопросы по лабораторной работе
Объясните принципы функционирования механизма изолированной программной среды (ИПС).
Механизм изолированной программной среды функционирует следующим образом. При загрузке системы ядро передает режим работы для пользователя и список разрешенных для запуска программ драйверу подсистемы изолированной программной среды. Драйвер контролирует запуск пользователем программ (и загрузку библиотек). Когда пользователь (или программа, запущенная пользователем) осуществляет попытку запуска какой-либо программы, драйвер проверяет, разрешен ли ее запуск и не нарушена ли ее целостность (если включен режим контроля целостности). Если программа содержится в списке разрешенных программ и ее целостность не нарушена, драйвер разрешает запуск. В противном случае запуск программы блокируется, а в журнале Secret Net фиксируется попытка несанкционированного доступа.
Механизм контроля целостностиосуществляет слежение за неизменностью контролируемых объектов с целью защиты их от модификации. Контроль проводится в автоматическом режиме в соответствии с некоторым заданным расписанием.
Механизм изолированной программной среды позволяет сформировать для любого пользователя компьютера программную среду, определив индивидуальный перечень программ, разрешенных для запуска. Перечень программ, разрешенных для запуска, может быть задан как индивидуально для каждого пользователя, так и определен на уровне групп пользователей.
На этапе настройки механизма составляется список исполняемых файлов. Список исполняемых файлов может быть сформирован автоматически по информации об установленных на компьютере программах, а также может быть задан вручную. Для файлов, входящих в этот список, можно включить режим контроля целостности. По этой причине механизм изолированной программной среды и механизм контроля целостности используют единую модель данных (табл. 3.1).
Ресурсом может быть файл, каталог, переменная реестра, ключ реестра.
Множество ресурсов, объединяемых по какому-либо признаку. Например файлы одного и того же типа. Или ресурсы, используемые в рамках определенной пользовательской задачи. Или файлы, хранящиеся в одном каталоге.
Сформированная в соответствии с политикой безопасности задача контроля определенных ресурсов. Например, контроль целостности ресурсов какой-либо прикладной программы. Или построение замкнутой среды для определенной группы пользователей.
Задача должна включать в себя как минимум одну группу контролируемых ресурсов. Одна и та же группа ресурсов может входить в несколько разных задач.
Процедура проведения контроля с заданными параметрами. К таким параметрам относят методы контроля, алгоритмы расчета контрольных сумм, расписание проведения проверок, реакция системы на обнаруженные ошибки.
Изолированная или замкнутая программная среда представляет собой расширение модели избирательного разграничения доступа. Здесь правила разграничения доступа формулируются следующим образом.
1. Для любого объекта ОС существует владелец.
2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту.
3. Для каждой четверки субъект-объект-метод-процесс возможность доступа определена однозначно.
4. Существует хотя бы один привилегированный пользователь (администратор), имеющий возможность обратиться к любому объекту по любому методу.
5. Для каждого субъекта определен список программ, которые этот
субъект может запускать.
При использовании изолированной программной среды права субъекта на доступ к объекту определяются не только правами и привилегиями субъекта, но и процессом, с помощью которого субъект обращается к объекту.
Изолированная программная среда существенно повышает защищенность ОС от разрушающих программных воздействий, включая программные закладки и компьютерные вирусы. Кроме того, при использовании данной модели повышается защищенность целостности данных, хранящихся в системе. В то же время изолированная программная среда создает определенные сложности в администрировании операционной системы. Например, при инсталляции нового программного продукта администратор должен модифицировать списки разрешенных программ для пользователей, которые должны иметь возможность работать с этим программным продуктом.
Изолированная программная среда не защищает от утечки конфиденциальной информации.
В чем заключается отличие ИПС от ЗПС (изолированной программной среды от замкнутой).
Механизм изолированной программнойсреды позволяет сформировать для любого пользователя компьютера программную среду, определив индивидуальный перечень программ, разрешенных для запуска. Перечень программ, разрешенных для запуска, может быть задан как индивидуально для каждого пользователя, так и определен на уровне групп пользователей.
(в замкнутой системе может попасть вирус)
Администратор определяет права пользователя на доступ к ресурсам компьютера. Он может ввести еще более строгие ограничения, определив для пользователя перечень доступных для запуска прикладных программ и связанных с ними файлов. В этом случае говорят, что используется режим замкнутой программной среды.
Идентификация и аутентификация пользователей осуществляется при каждом входе пользователя в систему. При загрузке компьютера у пользователя запрашивается его идентификатор и пароль.
Одним из основных защитных механизмов программно-аппаратных средств обеспечения информационной безопасности является механизм замкнутой программной среды. С его помощью реализуется схема контроля доступа, при которой пользователи и иные субъекты системы взаимодействуют только с ограниченным набором выделенных им объектов. При использовании этого механизма действуют следующие правила:
— пользователь может работать только с теми программами, запуск которых разрешен в UEL-списке (список разрешенных для запуска программ, UserExecutableList), Этот список формируется индивидуально для каждого пользователя;
— замкнутая программная среда может быть включена выборочно для отдельных пользователей;
— замкнутая программная среда может использоваться в одном из двух режимов работы: «мягком» или «жестком».
Изолированная программная среда – сферический конь в вакууме или …?
1. Немного про физику и лирику
Упрощать реальный мир, чтобы потом успешно разрабатывать всякие теории для мира вымышленного – нормальный процесс для всех наук. У физиков целый набор таких артефактов: идеальный газ, материальная точка, абсолютно твердое тело, несжимаемая жидкость и пр.
И что самое характерное – работает! Уравнение Менделеева-Клапейрона прекрасно описывает вполне реальный газ, а классическая механика великолепно справляется с расчетом движения тел различного масштаба (пока этот масштаб не уходит в микромир или наоборот – в область действия общей теории относительности).
По-умному такой процесс называется моделирование методом редуцирования – т.е. мы максимально упрощаем реальную систему, получаем математическую модель, которая позволяет прогнозировать поведение системы, а потом оказывается, что и реальная система удовлетворяет выявленным закономерностям.
Подобный подход применяется и в сфере информационной безопасности. Сегодня мы посмотрим на один из таких артефактов – изолированную программную среду и как эта среда позволяет решать задачи обеспечения ИБ в реальных системах.
2. Как моделирование безопасности стало наукой
Но начнем мы с истории вопроса: в 70-ые годы прошлого века произошло одно крайне важное событие для сферы информационной безопасности: министерство обороны США купило компьютер. Примерно такой:
Компьютер Honeywell-6080. Девушка на фото то ли для привлечения внимания, то ли для масштаба…
Поскольку это были времена, когда деревья были маленькими, а компьютеры большими – у Министерства обороны США хватило денег (или места) только на один такой компьютер. Естественно, на нем предполагалось обрабатывать какие-то секретные данные министерства, но в это же время уже появился предвестник Интернета – ARPANET, и сотрудникам министерства очень хотелось не только работать с секретными данными, но и постить котиков…
В результате возникла задача: нужно сделать так, чтобы на большом компьютере можно было обрабатывать информацию как секретную, так и несекретную. При этом среда должна быть многопользовательской, а среди пользователей будут не только сотрудники министерства, но и всякие штатские из ARPANET’а (а штатским, как известно, доверия нет).
Так и появился Project No. 522B – научно-исследовательский проект, задачей которого было… Ну, судя по результатам этого проекта, его задачей было создать дисциплину «Теоретические основы компьютерной безопасности» – практически все концепции, используемые в защитных мерах современных программных продуктах, были описаны в отчетах по проекту 522B.
Скриншоты оригинальных отчетов по проекту 522B: монитор ссылок (монитор безопасности), домены безопасности и матрица доступа – лишь малая часть теоретических концепций, разработанных за время проекта
Можно отдельную статью написать (и, если будет интересно – обязательно напишу!) про результаты исследований проекта 522B, а также про легендарных личностей мира информационной безопасности, которые в нем участвовали. Но нас интересует лишь только конкретное направление: субъектно-объектная модель целостности компьютерной системы.
3. Субъектно-объектная модель целостности компьютерной системы простыми словами
Итак, мы уже определились, что для успешного построения теоретической модели системы, в которой можно просто решить задачу обеспечения безопасности, надо исходную систему как-то упростить.
Такое упрощение нашли быстро: будем рассматривать всю систему как совокупность субъектов (т.е. активных сущностей, например, процессов) и объектов (т.е. пассивных сущностей, например, файлов данных). Субъекты будут как-то взаимодействовать с объектами, т.е. осуществлять доступ (или создавать информационный поток). Все варианты доступа (некоторое множество P) мы разделим на санкционированный доступ (PL) и несанкционированный доступ (PN).
Однако, это слишком уж упрощенная модель… Давайте попробуем сделать ее немного ближе к реальности:
1. Субъекты могут появляться и пропадать – ведь в компьютерных системах могут запускаться и останавливаться различные процессы. При этом субъект не может взяться из ниоткуда – в реальной системе есть некоторые данные, из которых создается субъект (исполняемый файл, скрипт и пр.), т.е. в начале всегда будет какой-то объект.
2. На поведение субъекта могут влиять объекты. Например, если объект – это конфигурация процесса.
3. Объекты могут меняться (зачем-то же субъекты получают к ним доступ? Вот и будем считать, что для того, чтобы что-то поменять).
4. За реализацией политики разграничения доступа (т.е. за тем, что доступ принадлежит PL) также должен следить специальный субъект (который мы назовем монитором безопасности).
5. И у монитора безопасности тоже есть связанные объекты, которые влияют на его работу – те, что содержат описание PL.
Ну и чтобы совсем усложнить жизнь, давайте также отметим, что доступ субъекта S к объекту O в момент времени t1 и момент времени t2, это, вообще говоря, два разных доступа – потому что за прошедшее с момента t1 время и субъект S, и объект O могли поменяться. А это значит, что наше множество P уже так запросто не описать – оно содержит бесконечное число элементов!
В моменты t1 и t2 субъект S1 получает доступ к объекту O2, но это уже совсем другой субъект и совсем другой объект…
Как же в таком хаосе гарантировать, что доступы будут только из PL, если теперь даже непонятно, как это PL описать?
Давайте для начала посмотрим внимательнее на объекты, которые влияют на поведение субъекта (т.е. те самые аналоги исполняемого файла, конфигурационных файлов и пр.). Пусть у нас есть всего 2 субъекта, и мы знаем все объекты, которые влияют на поведение этих субъектов. Такие объекты называют ассоциированными с субъектом.
Если мы можем гарантировать, что каждый субъект не может получить доступ (или создать информационный поток) к ассоциированным объектам своего соседа, то мы назовем такие субъекты корректными друг относительно друга. А если наборы ассоциированных объектов этих субъектов между собой не пересекаются, то мы их назовем абсолютно корректными друг относительно друга:
С этим определением мы можем сформулировать критерий гарантированного выполнения политики доступа в системе: если в начальный момент времени все субъекты абсолютно корректны друг относительно друга, и они могут осуществлять доступы (формировать потоки) только из PL, то и дальше с течением времени они смогут осуществлять доступы только из PL. Такой набор субъектов как раз и называют абсолютно изолированным множеством субъектов.
Казалось бы, вот и решение задачи! Но не тут-то было… Ведь по сути это означает, что у нас, например, в многопользовательской системе каждый пользователь работает за своим изолированным компьютером, который не может общаться с компьютером соседа. Хорошая многопользовательская система получается – весь обмен информацией возможен только через пользователей…
Не буду мучить дальнейшими математически-акробатическими номерами, а перейду сразу к более конструктивному варианту утверждения, позволяющего реализовать изолированную программную среду в реальной жизни, а не только в бурной фантазии безопасника-теоретика.
Давайте введем в нашей модели еще одну функцию безопасности: пусть создание нового субъекта S из объекта O возможно только, если объект O не менялся с начального момента времени (это называется «порождение субъекта с контролем целостности»). Это маленькое дополнение сильно меняет ситуацию:
Цепочка сломалась на том, что изменение объекта O1 в момент времени t1 уже не позволило создать измененный субъект S1
Самое важное изменение в том, что теперь у нас гарантировано конечное количество вариантов субъектов в системе, сколько бы времени она не работала. Ведь создать мы можем субъекты только из какого-то фиксированного, конечного множества объектов.
И, казалось бы, такая мелочь дает нам уже понятный алгоритм действий.
Мы можем описать множество PL для всех субъектов и всех объектов так, чтобы обеспечить свойство корректности субъектов друг относительно друга (важно, что не идет речи об абсолютной корректности, а значит субъекты могут порождаться из одного и того же объекта). Это множество конечно – так как конечно количество объектов в начальный момент, а также конечно множество создаваемых субъектов. А дальше мы можем быть уверены, что с течением времени ничего не изменится: не появится какого-то нового субъекта, который сможет обойти ограничения монитора безопасности и переписать нашу политику, так как действует порождение с контролем целостности.
Осталось убедиться, что этот подход действительно можно перевести с языка математического в функции реальной системы и сохранить полученное свойство безопасности системы. Давайте этим и займемся.
4. Изолированная программная среда в реальной жизни
Для начала решим (спустя полвека) задачу Министерства обороны США: Чтобы обеспечить безопасную работу пользователей за их единственным большим компьютером, необходимо реализовать:
1. Расширение ОС, которое будет контролировать целостность исполняемого файла перед запуском ПО. Если целостность нарушена – ничего запускаться не будет.
2. Политику разграничения доступа (например, в виде матрицы доступа), где будет прописано какое ПО к каким файлам может получать доступ (в первую очередь на запись, так как основная проблема, с которой мы боремся – это изменение алгоритма работы системы, который позволит нарушить политику безопасности системы). Причем в первую очередь нас интересуют исполняемые файлы ПО (и компоненты ядра ОС), а также всевозможные файлы данных, влияющих на алгоритм работы ПО.
Но это, когда компьютер один. Сложнее, когда у нас современная система, состоящая из множества компонентов, связанных между собой посредством локальной сети. Да, тут можно проявить железную волю и настроить не только локальное разграничение доступа, но и сетевое с помощью механизмов типа опций CIPSO протокола IP (к слову, и про это можно рассказать подробнее, если тема интересна…), но в гетерогенной среде это технически нереализуемо.
Поэтому давайте введем технические ограничения реальной системы, а затем посмотрим, как они бьются с теорией касательно изолированной программной среды:
1. Мы можем контролировать целостность субъектов. Однако не всегда есть возможность предотвратить создание субъекта, если целостность нарушена (как остановить загрузку ПО коммутатора, если мы обнаружили изменение его сохраненной конфигурации?).
2. Мы не всегда можем управлять доступом отдельных процессов к объектам. Тот же пример с коммутатором: во встроенном ПО коммутатора функционируют различные процессы, которые обращаются к различным объектам (файлам, отдельным записям, специальным объектам типа CAM-таблиц и пр.). Но штатного механизма задать какую-то матрицу доступа для этих субъектов и объектов у коммутатора нет.
3. Мы не можем управлять доступом субъектов к объектам, которые расположены на разных сетевых узлах. Точнее, теоретически это возможно – замкнуть все взаимодействие на межсетевой экран с мощной инспекцией прикладного трафика, прописать жесткую политику взаимодействия, которая будет аналогом матрицы доступа… Но на практике так делать никто не будет – от такого МЭ потребуются невероятные вычислительные ресурсы, а от его администратора – невероятная усидчивость, чтобы все это настроить.
Что же можно сделать с учетом перечисленных ограничений?
Во-первых, не надо отказываться от контроля целостности – исполняемые файлы, файлы конфигурацией (или более сложные объекты – базы данных, ключи реестра или объекты LDAP каталога) можно контролировать, в том числе, удаленно по сети.
Во-вторых, надо рассматривать взаимодействие в такой системе на двух уровнях «детализации»: когда субъекты и объекты – это сами сетевые узлы и когда это процессы и объекты внутри конкретного узла. «Контроль целостности» сетевого узла в таком случае – это неизменность состава узлов и неизменность каких-то сетевых параметров этих узлов (адрес, имя, список открытых портов и пр.).
В-третьих, матрицу доступа субъектов и объектов в масштабах сети мы можем заменить на наблюдение за сетевыми потоками (которые в данном случае аналогичны потокам между субъектами и объектами в модели): если исходить из предположения, что в начальный момент времени (который может быть совсем не моментом, а вполне себе протяженным интервалом) в системе все доступы (потоки) соответствуют множеству PL, мы можем их запомнить и считать нарушением обнаружение потока, который не попал в сформированное на начальном этапе множество. Единственное, надо понимать, что такое предположение корректно только для систем, работающих постоянно по одному и тому же алгоритму (ну или очень похожему) – по этой причине, модель изолированной программной среды хорошо подходит для всевозможных киберфизических систем, но она же будет крайне плохо применима в обычной «офисной» сети, где все может меняться каждую минуту.
Что же получается в итоге? Реализация изолированной программной среды – хороший способ обеспечения безопасности различных киберфизических систем (где, какая удача, как раз целостность является одним из наиболее важнейших свойств информации).
Изолированную программную среду для такой системы можно обеспечить путем корректной настройки механизмов безопасности отдельных узлов сети, а также с помощью выделенного устройства, которое должно уметь:
1. Вести каталог сетевых объектов и их сетевых параметров.
2. Отслеживать объекты (т.е. конфигурации, исполняемые файлы и пр.) на предмет их модификации. В частности, конфигурации мониторов безопасности отдельных устройств.
3. Контролировать схему информационных потоков между узлами сети и сигнализировать при обнаружении неизвестного потока (так как с большой вероятностью это поток из множества PN).
И вот мы получили перечень основных функций ICS Asset Management решений. Как говорится: «Совпадение? Не думаю!»:-)
Функции решений ICS Asset Management по версии Dale Peterson
Сегодня на рынке представлено достаточно много решений класса ICS Asset Management и Detection, но базовые функции у всех примерно одинаковые. А вы теперь знаете почему…
Причины появления
Изолированная программная среда
Целью реализации модели изолированной программной среды является определение порядка безопасного взаимодействия субъектов системы, обеспечивающего невозможность воздействия на систему защиты и модификации ее параметров или конфигурации, результатом которых могло бы стать изменение реализуемой системой защиты политики разграничения доступа.
Модель изолированной программной среды реализуется путем изоляции субъектов системы друг от друга и путем контроля порождения новых субъектов таким образом, чтобы в системе могли активизироваться только субъекты из предопределенного списка. При этом должна контролироваться целостность объектов системы, влияющих на функциональность активизируемых субъектов.
Защищённая загрузка терминальных клиентов — способность терминальных клиентов безопасно загружать операционную систему. Основным решением безопасной загрузки является проверка целостности и аутентичности файлов операционной системы, которые могут храниться на локальном жёстком диске, мобильном носителе или загружаться по сети
Один из основных принципов защиты информации, сформулированный в конце 20-го столетия, гласит, что вычисления, критичные с точки зрения безопасности информации, должны происходить в доверенной вычислительной среде.
Со временем происходило развитие средств вычислительной техники, увеличивалось число функциональных возможностей операционных систем, росло количество прикладного программного обеспечения. Вместе с этим формировались следующие подходы к определению понятия доверенная вычислительная среда:
¾ функционально замкнутая среда;
¾ изолированная программная среда;
¾ доверенная вычислительная среда на основе резидентных компонентов безопасности.
При построении систем защиты терминального доступа используются все три категории, которые, в основном, защищают терминальный сервер. Во время терминальных систем, когда терминал представлял собой монитор, клавиатуру и систему соединения с центральным сервером, этого было достаточно. С развитием средств вычислительной техники такое решение стало недостаточным, хотя суть терминальной сессии осталась прежней: обработка и хранения информации осуществляется на сервере, к терминалу передаётся обработанная сервером информация, а к серверу передаются данные с устройств терминала. Однако терминалы стали более функциональными, обладают собственной операционной системой, собственным жёстким диском и собственными периферийными устройствами.
В связи с тем, что терминальные клиенты являются неотъемлемой частью системы, то из мультипликативной парадигмы защиты («степень защищённости системы определяется степенью защищённости её самого «слабого» звена») следует, что для построения защищенной терминальной системы необходимо обеспечивать защиту каждого элемента.
Таким образом, считают, что не только терминальный сервер нуждается в защите, но и терминальные клиенты. Поэтому для полной защиты терминальной сессии используют решения, защищающие как сервер, так и клиент, и в состав которых входит защищённая загрузка терминальных клиентов.
Загрузка ОС терминального клиента может осуществляться различными способами:
¾ загрузка с локального жёсткого диска;
¾ загрузка с мобильного носителя;
В первых двух способах для защиты загрузки используют доверенную загрузку компьютера клиента и последующую взаимную идентификацию и аутентификацию сервер-клиент. Однако, эти способы имеют недостатки:
¾ тяжело администрировать (например, при изменении загрузочного образа требуется оснастить им терминальные клиенты)
¾ требуют от терминальных клиентов наличия некоторых дополнительных устройств (жёсткий диск или оптический привод для запуска ОС, PCI-слот для установки систем защиты информации).
Различие двух способов в том, что при локальной загрузке необходимо контролировать состав оборудования только одного терминала. А при мобильной загрузке требуется четко идентифицировать каждый терминальный клиент и контролировать состав именно того оборудования, с которого происходит загрузка.
Для загрузки по сети способ защиты немного отличается от двух предыдущих, так как образ передается по сети от некоторого сервера к терминальному клиенту. Однако он лишен недостатков, которые есть у локальных способов загрузки, то есть с точки зрения администрирования он легко масштабируем, его настройка производится централизованно, и не требует наличия на клиенте жёсткого диска или оптического привода. Последнее свойство позволяет использовать «тонкие клиенты», которые зачастую содержат минимальный набор устройств.
В то же время, распределенный характер данного способа загрузки несет в себе дополнительные угрозы несанкционированного доступа к информации. Например, одна из угроз позволяет злоумышленнику применить атаку «человек посередине» на TFTP протокол, используемый в PXE для загрузки ОС, и послать вместе с файлами ОС вредоносный код.
Для устранения угроз, как и для предыдущих способов, применяется проверка контроля целостности и аутентичности файлов ОС и оборудования. Только в данном случае проверяется не только список контролируемого оборудования терминала, с которого возможна загрузка, и загружаемый образ, но и сервер, с которого разрешено получать образы.