1. Немного про физику и лирику
Упрощать реальный мир, чтобы потом успешно разрабатывать всякие теории для мира вымышленного – нормальный процесс для всех наук. У физиков целый набор таких артефактов: идеальный газ, материальная точка, абсолютно твердое тело, несжимаемая жидкость и пр.
И что самое характерное – работает! Уравнение Менделеева-Клапейрона прекрасно описывает вполне реальный газ, а классическая механика великолепно справляется с расчетом движения тел различного масштаба (пока этот масштаб не уходит в микромир или наоборот – в область действия общей теории относительности).
По-умному такой процесс называется моделирование методом редуцирования – т.е. мы максимально упрощаем реальную систему, получаем математическую модель, которая позволяет прогнозировать поведение системы, а потом оказывается, что и реальная система удовлетворяет выявленным закономерностям.
Подобный подход применяется и в сфере информационной безопасности. Сегодня мы посмотрим на один из таких артефактов – изолированную программную среду и как эта среда позволяет решать задачи обеспечения ИБ в реальных системах.
2. Как моделирование безопасности стало наукой
Но начнем мы с истории вопроса: в 70-ые годы прошлого века произошло одно крайне важное событие для сферы информационной безопасности: министерство обороны США купило компьютер. Примерно такой:
Поскольку это были времена, когда деревья были маленькими, а компьютеры большими – у Министерства обороны США хватило денег (или места) только на один такой компьютер. Естественно, на нем предполагалось обрабатывать какие-то секретные данные министерства, но в это же время уже появился предвестник Интернета – ARPANET, и сотрудникам министерства очень хотелось не только работать с секретными данными, но и постить котиков…
В результате возникла задача: нужно сделать так, чтобы на большом компьютере можно было обрабатывать информацию как секретную, так и несекретную. При этом среда должна быть многопользовательской, а среди пользователей будут не только сотрудники министерства, но и всякие штатские из ARPANET’а (а штатским, как известно, доверия нет).
Так и появился Project No. 522B – научно-исследовательский проект, задачей которого было… Ну, судя по результатам этого проекта, его задачей было создать дисциплину «Теоретические основы компьютерной безопасности» – практически все концепции, используемые в защитных мерах современных программных продуктах, были описаны в отчетах по проекту 522B.
Можно отдельную статью написать (и, если будет интересно – обязательно напишу!) про результаты исследований проекта 522B, а также про легендарных личностей мира информационной безопасности, которые в нем участвовали. Но нас интересует лишь только конкретное направление: субъектно-объектная модель целостности компьютерной системы.
3. Субъектно-объектная модель целостности компьютерной системы простыми словами
Итак, мы уже определились, что для успешного построения теоретической модели системы, в которой можно просто решить задачу обеспечения безопасности, надо исходную систему как-то упростить.
Такое упрощение нашли быстро: будем рассматривать всю систему как совокупность субъектов (т.е. активных сущностей, например, процессов) и объектов (т.е. пассивных сущностей, например, файлов данных). Субъекты будут как-то взаимодействовать с объектами, т.е. осуществлять доступ (или создавать информационный поток). Все варианты доступа (некоторое множество P) мы разделим на санкционированный доступ (PL) и несанкционированный доступ (PN).
Однако, это слишком уж упрощенная модель… Давайте попробуем сделать ее немного ближе к реальности:
1. Субъекты могут появляться и пропадать – ведь в компьютерных системах могут запускаться и останавливаться различные процессы. При этом субъект не может взяться из ниоткуда – в реальной системе есть некоторые данные, из которых создается субъект (исполняемый файл, скрипт и пр.), т.е. в начале всегда будет какой-то объект.
2. На поведение субъекта могут влиять объекты. Например, если объект – это конфигурация процесса.
3. Объекты могут меняться (зачем-то же субъекты получают к ним доступ? Вот и будем считать, что для того, чтобы что-то поменять).
4. За реализацией политики разграничения доступа (т.е. за тем, что доступ принадлежит PL) также должен следить специальный субъект (который мы назовем монитором безопасности).
5. И у монитора безопасности тоже есть связанные объекты, которые влияют на его работу – те, что содержат описание PL.
Ну и чтобы совсем усложнить жизнь, давайте также отметим, что доступ субъекта S к объекту O в момент времени t1 и момент времени t2, это, вообще говоря, два разных доступа – потому что за прошедшее с момента t1 время и субъект S, и объект O могли поменяться. А это значит, что наше множество P уже так запросто не описать – оно содержит бесконечное число элементов!
Как же в таком хаосе гарантировать, что доступы будут только из PL, если теперь даже непонятно, как это PL описать?
Давайте для начала посмотрим внимательнее на объекты, которые влияют на поведение субъекта (т.е. те самые аналоги исполняемого файла, конфигурационных файлов и пр.). Пусть у нас есть всего 2 субъекта, и мы знаем все объекты, которые влияют на поведение этих субъектов. Такие объекты называют ассоциированными с субъектом.
Если мы можем гарантировать, что каждый субъект не может получить доступ (или создать информационный поток) к ассоциированным объектам своего соседа, то мы назовем такие субъекты корректными друг относительно друга. А если наборы ассоциированных объектов этих субъектов между собой не пересекаются, то мы их назовем абсолютно корректными друг относительно друга:
С этим определением мы можем сформулировать критерий гарантированного выполнения политики доступа в системе: если в начальный момент времени все субъекты абсолютно корректны друг относительно друга, и они могут осуществлять доступы (формировать потоки) только из PL, то и дальше с течением времени они смогут осуществлять доступы только из PL. Такой набор субъектов как раз и называют абсолютно изолированным множеством субъектов.
Казалось бы, вот и решение задачи! Но не тут-то было… Ведь по сути это означает, что у нас, например, в многопользовательской системе каждый пользователь работает за своим изолированным компьютером, который не может общаться с компьютером соседа. Хорошая многопользовательская система получается – весь обмен информацией возможен только через пользователей…
Не буду мучить дальнейшими математически-акробатическими номерами, а перейду сразу к более конструктивному варианту утверждения, позволяющего реализовать изолированную программную среду в реальной жизни, а не только в бурной фантазии безопасника-теоретика.
Давайте введем в нашей модели еще одну функцию безопасности: пусть создание нового субъекта S из объекта O возможно только, если объект O не менялся с начального момента времени (это называется «порождение субъекта с контролем целостности»). Это маленькое дополнение сильно меняет ситуацию:
Самое важное изменение в том, что теперь у нас гарантировано конечное количество вариантов субъектов в системе, сколько бы времени она не работала. Ведь создать мы можем субъекты только из какого-то фиксированного, конечного множества объектов.
И, казалось бы, такая мелочь дает нам уже понятный алгоритм действий.
Мы можем описать множество PL для всех субъектов и всех объектов так, чтобы обеспечить свойство корректности субъектов друг относительно друга (важно, что не идет речи об абсолютной корректности, а значит субъекты могут порождаться из одного и того же объекта). Это множество конечно – так как конечно количество объектов в начальный момент, а также конечно множество создаваемых субъектов. А дальше мы можем быть уверены, что с течением времени ничего не изменится: не появится какого-то нового субъекта, который сможет обойти ограничения монитора безопасности и переписать нашу политику, так как действует порождение с контролем целостности.
Осталось убедиться, что этот подход действительно можно перевести с языка математического в функции реальной системы и сохранить полученное свойство безопасности системы. Давайте этим и займемся.
4. Изолированная программная среда в реальной жизни
Для начала решим (спустя полвека) задачу Министерства обороны США: Чтобы обеспечить безопасную работу пользователей за их единственным большим компьютером, необходимо реализовать:
1. Расширение ОС, которое будет контролировать целостность исполняемого файла перед запуском ПО. Если целостность нарушена – ничего запускаться не будет.
2. Политику разграничения доступа (например, в виде матрицы доступа), где будет прописано какое ПО к каким файлам может получать доступ (в первую очередь на запись, так как основная проблема, с которой мы боремся – это изменение алгоритма работы системы, который позволит нарушить политику безопасности системы). Причем в первую очередь нас интересуют исполняемые файлы ПО (и компоненты ядра ОС), а также всевозможные файлы данных, влияющих на алгоритм работы ПО.
Но это, когда компьютер один. Сложнее, когда у нас современная система, состоящая из множества компонентов, связанных между собой посредством локальной сети. Да, тут можно проявить железную волю и настроить не только локальное разграничение доступа, но и сетевое с помощью механизмов типа опций CIPSO протокола IP (к слову, и про это можно рассказать подробнее, если тема интересна…), но в гетерогенной среде это технически нереализуемо.
Поэтому давайте введем технические ограничения реальной системы, а затем посмотрим, как они бьются с теорией касательно изолированной программной среды:
1. Мы можем контролировать целостность субъектов. Однако не всегда есть возможность предотвратить создание субъекта, если целостность нарушена (как остановить загрузку ПО коммутатора, если мы обнаружили изменение его сохраненной конфигурации?).
2. Мы не всегда можем управлять доступом отдельных процессов к объектам. Тот же пример с коммутатором: во встроенном ПО коммутатора функционируют различные процессы, которые обращаются к различным объектам (файлам, отдельным записям, специальным объектам типа CAM-таблиц и пр.). Но штатного механизма задать какую-то матрицу доступа для этих субъектов и объектов у коммутатора нет.
3. Мы не можем управлять доступом субъектов к объектам, которые расположены на разных сетевых узлах. Точнее, теоретически это возможно – замкнуть все взаимодействие на межсетевой экран с мощной инспекцией прикладного трафика, прописать жесткую политику взаимодействия, которая будет аналогом матрицы доступа… Но на практике так делать никто не будет – от такого МЭ потребуются невероятные вычислительные ресурсы, а от его администратора – невероятная усидчивость, чтобы все это настроить.
Что же можно сделать с учетом перечисленных ограничений?
Во-первых, не надо отказываться от контроля целостности – исполняемые файлы, файлы конфигурацией (или более сложные объекты – базы данных, ключи реестра или объекты LDAP каталога) можно контролировать, в том числе, удаленно по сети.
Во-вторых, надо рассматривать взаимодействие в такой системе на двух уровнях «детализации»: когда субъекты и объекты – это сами сетевые узлы и когда это процессы и объекты внутри конкретного узла. «Контроль целостности» сетевого узла в таком случае – это неизменность состава узлов и неизменность каких-то сетевых параметров этих узлов (адрес, имя, список открытых портов и пр.).
В-третьих, матрицу доступа субъектов и объектов в масштабах сети мы можем заменить на наблюдение за сетевыми потоками (которые в данном случае аналогичны потокам между субъектами и объектами в модели): если исходить из предположения, что в начальный момент времени (который может быть совсем не моментом, а вполне себе протяженным интервалом) в системе все доступы (потоки) соответствуют множеству PL, мы можем их запомнить и считать нарушением обнаружение потока, который не попал в сформированное на начальном этапе множество. Единственное, надо понимать, что такое предположение корректно только для систем, работающих постоянно по одному и тому же алгоритму (ну или очень похожему) – по этой причине, модель изолированной программной среды хорошо подходит для всевозможных киберфизических систем, но она же будет крайне плохо применима в обычной «офисной» сети, где все может меняться каждую минуту.
Что же получается в итоге? Реализация изолированной программной среды – хороший способ обеспечения безопасности различных киберфизических систем (где, какая удача, как раз целостность является одним из наиболее важнейших свойств информации).
Изолированную программную среду для такой системы можно обеспечить путем корректной настройки механизмов безопасности отдельных узлов сети, а также с помощью выделенного устройства, которое должно уметь:
1. Вести каталог сетевых объектов и их сетевых параметров.
2. Отслеживать объекты (т.е. конфигурации, исполняемые файлы и пр.) на предмет их модификации. В частности, конфигурации мониторов безопасности отдельных устройств.
3. Контролировать схему информационных потоков между узлами сети и сигнализировать при обнаружении неизвестного потока (так как с большой вероятностью это поток из множества PN).
И вот мы получили перечень основных функций ICS Asset Management решений. Как говорится: «Совпадение? Не думаю!»:-)
Сегодня на рынке представлено достаточно много решений класса ICS Asset Management и Detection, но базовые функции у всех примерно одинаковые. А вы теперь знаете почему…
Описанная в статье технология имеет практическое применение в CL DATAPK, флагманском продукте компании СайберЛимфа для защиты систем автоматизации. Больше информации о компании и разработках СайберЛимфа доступно на сайте компании.
