Содержание статьи
В «Лаборатории Касперского» уже четыре года идет работа над собственной защищенной операционной системой, однако знают о ней в основном профессионалы. Дело в том, что это не обычная ОС, и ее цель — защитить производственные процессы от хакерских атак. В этой статье мы расскажем о том, какие именно принципы безопасности лежат в основе KasperskyOS.
Интро
16 октября 2012 года Евгений Касперский, генеральный директор всем известной софтверной компании, рассуждал на страницах своего ЖЖ о будущем. Естественно, не о светлом и безоблачном (такие пассажи — дело политиков), а о жутком будущем, наполненном кибернетическими угрозами, которые обрушиваются не столько на мирных владельцев ПК, планшетов и смартфонов (основных клиентов его компании), сколько на информационные системы «заводов, газет, пароходов», официально именуемые ICS — Industrial Control Systems.
Системы эти управляют технологическими процессами и базируются на программном обеспечении, которое зачастую, прекрасно выполняя свою основную функцию, нисколько не заботится об информационной безопасности этого самого процесса. Возможно, при разработке такого ПО вопросы кибербезопасности и не были приоритетными, просто теперь на них перестали смотреть как на угрозы, высосанные из пальца.
Проекты, подобные первопроходцу Stuxnet, успешные проникновения в системы авионики лайнеров через мультимедийные системы пассажирских кресел и публичные бортовые сети + Wi-Fi — далеко не живописание апокалиптического будущего, а самая что ни на есть реальность.
Касперский, однако, не только давал мрачные прогнозы. В том посте он, по сути, описывал принципы, которые были заложены в основу новой разработки — операционной системы, архитектурно ориентированной на системное решение проблемы киберзащиты технологических процессов.
То был далекий 2012 год. Что стало с этой задумкой через три года? Из намерений и описаний принципов операционная система «Лаборатории Касперского» превратилась в реальность — KasperskyOS. Вернее, в комплексное решение Kaspersky Security System, встроенное «из коробки» в KasperskyOS и доступное для встраивания в операционные системы других производителей, а также реализованное в защищенном гипервизоре.
Теперь это решение, вдоволь обкатанное на многочисленных конференциях и форумах по кибербезопасности, шагнуло из лабораторных стен в реальные проекты.
INFO
Первоначальное название проекта «11.11» несколько раз менялось. Примерно в середине пути он именовался KAKOS.
Оранжевое небо, оранжевая книга
Тот пост из ЖЖ Касперского был фактически публичным представлением проекта «11.11», который ЛК инициировала, судя по всему, еще в ноябре 2011 года («ноябрь 2011-го» — это и есть «11.11»), то есть за год до официального анонса. Оно и правильно. Выходить на публику стоит не с мифологией, а с подтверждением работоспособности идеи или как минимум с четким пониманием того, как она должна работать.
][ после анонса проекта «11.11» одним из первых пообщался с его идеологом — Андреем Петровичем Духваловым, который ныне возглавляет управление перспективных технологий «Лаборатории Касперского». В этой беседе обсуждались принципы, положенные в основу проекта «ОС Касперского», и, что немаловажно, были получены ответы на вопросы «зачем?» и «почему?».
Зачем пытаться защитить ICS-системы с помощью системного ПО, если достаточно поместить их под колпак контролируемой зоны, обрубив возможные каналы несанкционированного доступа? Зачем начинать делать собственную операционную систему, если сейчас полно готовых решений? Почему «Лаборатории Касперского» стала интересна тема операционных систем, пусть даже и в узкой области применения?
На все эти вопросы были даны ответы, которые спустя три года развития проекта Kaspersky Security System все еще актуальны, поскольку определяют парадигму проекта. Сводится она к следующему. Все современные операционные системы в той или иной степени уязвимы. И связано такое положение дел не с кривыми руками их разработчиков, а с тем фактом, что проектировались они без четкого представления о безопасности и о комплексной цели, которую должна решать подсистема безопасности ОС.
Поскольку операционные системы совершенствуются одновременно с железом, они, независимо от изначально заложенной архитектуры, развиваются по принципу помещичьей усадьбы: главное здание со временем обрастает многочисленными флигелями, пристройками, чердаками и подвалами. Растущая сложность организации с точки зрения безопасности несет две проблемы: внедряемые механизмы безопасности, как встраиваемые, так и «навешиваемые», просто не в состоянии охватить целиком все «закоулки» «ОСобняка». Отсюда и появление разнообразных бэкдоров.
Но это проблема принципиальной реализуемости механизмов безопасности. Сложная организация операционных систем существенно затрудняет как анализ потенциальной уязвимости компонентов, так и эффективность применяемых механизмов безопасности. Будь все иначе, та же «Лаборатория Касперского» с ее антивирусными решениями просто осталась бы не у дел.
Вывод из всего этого достаточно банален. Уж если что-то делать в области защищенных ОС, то делать это с нуля, рассматривая проблемы безопасности в качестве основополагающих требований и учитывая их влияние на всех этапах проектирования системы. Именно поэтому главный российский борец с вирусами и замахнулся на разработку собственной операционной системы. Но, понимая всю сложность создания новой системы общего назначения вроде Windows или UNIX, решил начать со специфической. Удачно выбрана и область — промышленные информационные системы до сих пор не были избалованы надежной защитой. С одной стороны, это важное дело, с другой — возможность получить бесценный опыт, который, глядишь, можно будет распространить и на другие области применения операционных систем.
Решиться на разработку собственной ОС, в которой механизмы безопасности станут фундаментом, можно, только основательно изучив, что же вообще в этой области наработано. Команда KasperskyOS так и поступила. В первую очередь взгляд был брошен на материалы «Радужной серии» (Rainbow Series) — набора стандартов информационной безопасности, разноцветные тома которых были изначально опубликованы в Министерстве обороны США, а затем в Центре национальной компьютерной безопасности США.
Стандарты эти охватывают самые разные аспекты информационной безопасности, от терминологического базиса до руководств пользователей и сотрудников службы безопасности. Важнейшая часть «Радужной серии» — это «Оранжевая книга», где задаются критерии определения безопасности компьютерных систем. Ее ратифицированным в международном масштабе аналогом является стандарт ISO/IEC 15408.
Главный постулат «Оранжевой книги» заключается в том, что безопасность компьютерных систем никогда не была и никогда не будет идеальной. Любая эксплуатируемая или вновь проектируемая система безопасна ровно настолько, насколько мы доверяем ей решение этого важного вопроса. А значит, правильнее говорить не о безопасных, а о доверенных системах.
Именно поэтому совокупность механизмов, которые в информационной системе реализуют ту или иную политику безопасности и определяют степень доверия к этой системе, в «Оранжевой книге» именуют ДВБ — доверенная вычислительная база (Trusted Computer Base).
INFO
Среди томов «Радужной серии», кроме «Оранжевой книги», есть еще и «Ярко-оранжевая книга». В ней описываются подходы к организации тестирования безопасности в доверенных системах. В настоящее время эти подходы используются как разработчиками доверенных систем, так и сертифицирующими эти системы органами.
Немного о ДВБ
Какую функцию в информационной системе выполняет ДВБ? Единственно верную: контролирует любые взаимодействия компонентов информационной системы между собой, с системными функциями и аппаратной базой системы. Ни одно обращение любого компонента системы не должно остаться без пристальной проверки ДВБ с точки зрения поддерживаемого ею механизма (или механизмов) безопасности. В «Оранжевой книге» эту функцию ДВБ именуют мониторингом обращений.
Мониторинг обращений фактически означает, что компоненты информационной системы напрямую ни между собой, ни с ядром системы, ни с аппаратурой не взаимодействуют. Все происходит по указанию ДВБ. Разрешила ДВБ — вперед! Запретила — взаимодействию не быть. Выходит, ДВБ — это такая штука, которая позволяет изолировать друг от друга компоненты информационной системы. Старый как мир принцип властвования — через разделение.
«Доверенная» в аббревиатуре ДВБ означает, что мы вынуждены доверять ей. А сделать это проще, если ДВБ прозрачна как с точки зрения своей организации, так и с точки зрения способов проверки правильности ее работы. Добиться такой прозрачности можно разными способами. Самые действенные из них — это простота и компактность организации ДВБ, а также возможность использовать для ее проверки некоторый набор формальных методов. Он позволит дать однозначный ответ о том, насколько ДВБ (ну и информационная система на ее основе) соответствует своему предназначению (это называется «валидация») и насколько полно принципы, заложенные в основу при проектировании, были воплощены на этапах разработки (верификация).
Теперь-то и становится ясно, что команда проекта KasperskyOS занялась созданием собственного варианта этой самой ДВБ. Ну, почти собственного. Идеологическим предком ДВБ «Лаборатории Касперского» стал проект FLASK (Flux Advanced Security Kernel) — архитектурное решение подсистемы безопасности в ОС, которое позволяет гибко внедрять и настраивать политики безопасности под конкретное применение.
К слову сказать, FLASK — это предок не только KasperskyOS, но и таких реализаций подсистем безопасности, как SELinux и TrustedBSD. Модель системы безопасности на основе модулей LSM, которую используют в современных проектах на основе GNU/Linux, — это тоже вариация на тему FLASK. Вот только в системах на Linux и BSD такой монитор обращений — это все же внешний довесок. В проекте же KasperskyOS — это основа системы.
Верифицируй это. Компонентная модель и IPC-письма
Давай подробнее глянем на архитектуру KasperskyOS. С точки зрения общепринятой классификации архитектурных решений KasperskyOS — система микроядерная. И ее микроядро — действительно «микро»! Не более тысячи строк кода. В них втиснуты диспетчер процессов, механизм межпроцессного взаимодействия (IPC — inter-process communication) и та самая ДВБ, которая именуется KSS (Kaspersky Security System) и пристально следит за механизмом IPC.
И это все?! А как же управление памятью, периферийными устройствами? Как же драйверы файловых систем? В KasperskyOS все это — архитектурные излишества. Зачем, к примеру, содержать на балансе громоздкий диспетчер памяти, если в промышленной системе память процессам выделяется статически на этапе их создания, а механизм shared memory с точки зрения межпроцессного взаимодействия — это зло? Никаких общих адресов, хочешь общаться — пиши корректно составленное IPC-сообщение, которое будет перехвачено и перлюстрировано KSS.
Таким образом, базовый принцип KasperskyOS схож с общим подходом любых микроядерных систем. Процессы взаимодействуют между собой и с функциями ядра системы, отправляя и получая IPC-сообщения. Микроядро предоставляет им эту возможность с помощью механизма IPC. В случае KasperskyOS за этим механизмом следит KSS, которая для каждого IPC-сообщения выносит вердикт «можно» (allow) или «нельзя» (deny). При этом по умолчанию KSS реализует принцип default deny. То есть если программа по какой-то причине не реализует такую модель взаимодействия, то ни отправить, ни получить IPC-сообщения она не сможет. И останется в полной изоляции. Печалька для вирусов, малвари и криворуко написанного софта.
Ладно, а как же должен выглядеть правильно написанный софт для KasperskyOS? Для софтописателей разработчики KasperskyOS предлагают специальный подход, который именуется «компонентная модель». Фактически эта модель служит для прикладных программистов удобной абстракцией, позволяющей создать корректное с точки зрения KasperskyOS приложение. Кроме того, поддержка компонентной модели обеспечивается инфраструктурно — набором средств разработки.
В основе компонентной модели программы лежит понятие «сущность» (Entity). Сущностью может быть отдельная программа, предоставляющая (сервер) или потребляющая (клиент) функции для других сущностей. Или же ей может быть реализация какой-то отдельной функции программы. В общем случае сущность — это набор компонентов, каждый из которых включает в себя одну или более внутрикомпонентную сущность. В самом вырожденном случае компонентной модели сущность — это один компонент с одной внутрикомпонентной сущностью. Именно сущности, реализуя свои функции, общаются друг с другом с помощью IPC-сообщений. То есть выполнение сложно устроенной программы или клиент-серверного сервиса, созданных по идеологии компонентной модели, — это IPC-переписка сущностей, за которой и следит KSS. Чтобы сущность могла участвовать в таком диалоге, в ее составе наряду с базовым кодом должен присутствовать код интерфейса доступа к механизму IPC микроядра.
И вот тут начинается самое интересное. Создание кода этого интерфейса возлагается не на разработчика программы. Код интерфейса автоматически генерируется из его описания на языке IDL (Interface Definition Language) — С++ подобного языка спецификации интерфейсов в распределенных системах. Что дает использование IDL? Возможность той самой верификации корректности взаимодействия одной сущности с другой сущностью. Строгая типизация IDL этому способствует и позволяет специально разработанному компилятору Nk перед автогенерацией кода интерфейса проверить его на безошибочность с точки зрения компонентной модели. Исходник интерфейса на IDL после компиляции Nk преобразуется в объектный код в необходимой разработчику нотации. Конечно же, поддерживаются С и С++, а также язык функционального программирования Haskell.
INFO
Вариация декларативного языка IDL есть и у компании Microsoft. Она именуется MIDL (Microsoft IDL) и предлагается разработчикам клиент-серверных приложений, которые функционируют в распределенных гетерогенных системах, например Windows, UNIX и OS X. Задачи MIDL совпадают с задачами варианта IDL «Лаборатории Касперского»: описание интерфейсов клиент-серверных приложений при выполнении удаленного вызова процедур.
Помещенный в код сущности объектный код интерфейса обеспечивает формирование функций Proxy (в клиентских приложениях) и Dispatch (в серверных приложениях). Почему они важны с точки зрения архитектуры KasperskyOS? Клиентское приложение, вызывая ту или иную функцию серверного приложения или ядра системы, передает ее параметры интерфейсной функции Proxy, которая сериализует их (упаковывает в формат IPC-сообщения), а затем вызывает транспортную функцию механизма IPC в микроядре и передает ей созданное IPC-сообщение. Теперь Proxy-функции остается только ждать ответного IPC-сообщения с результатом, чтобы десериализовать его и передать сделавшему вызов базовому коду клиента.
Функция Dispatch на серверной стороне делает обратное: получив IPC-сообщение, она десериализует его (распаковывает параметры для вызываемой функции), передает их базовому коду связанного с данным интерфейсом сервиса и, получив от него результат, сериализует его в IPC-сообщение.
Но что делать, если сущность (например, сервер какого-либо сервиса) содержит множество компонентов, а из них каждый состоит из разных функций, к которым может обращаться сущность-клиент? Ведь по идеологии компонентной модели с каждой такой функцией должен быть связан собственный Dispatch-интерфейс. Как механизм IPC определит, которому из них передавать IPC-сообщение? И снова на помощь программисту приходят языки спецификаций. При упаковке нескольких функций с их Dispatch-интерфейсами в один компонент программист описывает его на языке CDL (Component Definition Language). Компилятор Nk на основе CDL-описания компонента генерирует его код с единым в рамках компонента интерфейсом, который на самом деле является совокупностью Dispatch-интерфейсов всех функций, входящих в состав компонента.
Для многокомпонентной сущности есть свой язык спецификаций EDL (Entity Definition Language). На нем описываются все компоненты, которые входят в состав сущности, а также (если таковые имеются) отдельные функции с собственными Dispatch-интерфейсами. В результате компиляции EDL-файла формируется общий код сущности с единым глобальным Dispatch-интерфейсом, который, по сути, является точкой входа IPC-сообщения в сущность.
Найти же адресата для него — конкретный Dispatch-интерфейс конкретной функции (отдельной или в составе компонента) — можно по его уникальному идентификатору Runtime Interface ID (RIID). Он генерируется на этапе компиляции EDL-описания сущности. Такая вложенность строго типизированных спецификаций позволяет разработчику создать сколь угодно сложную программу, каждая функция которой будет снабжена собственным Proxy- или Dispatch-интерфейсом.
Выше было сказано, что выполнение программы, разработанной по идеологии компонентной модели, является диалогом функций, то есть их перепиской IPC-сообщениями строго определенного формата. Важно, что это именно диалог, а не какофония, поскольку IPC-взаимодействие — дело двух сущностей, что-то вроде peer-to-peer. Однако, в отличие, например, от пиринговых протоколов, IPC-взаимодействие в KasperskyOS осуществляется по принципу рандеву.
Посредником, конечно же, выступает механизм IPC микроядра. А чтобы рандеву состоялось, то есть был настроен канал обмена IPC-сообщениями между конкретными сущностями, канал этот создается механизмом IPC путем выделения сущностям специальных глобальных системных объектов хендлов (handle) — указателей, которые идентифицируют сущности отправителя и получателя. На время взаимодействия сущности становятся владельцами своих хендлов, что и дает им право использовать открывающийся IPC-канал.
При такой организации IPC-взаимодействия каждая сущность имеет представление только о выделенном ей хендле. О паре хендлов отправителя и получателя знает только механизм IPC. Потому-то процедура формирования IPC-канала обмена сообщениями и именуется «спариванием хендлов» (handles pairing). После такого спаривания вклиниться в диалог сущностей не может никто посторонний. IPC-канал будет существовать до тех пор, пока взаимодействующие сущности будут оставаться владельцами спаренных хендлов.
Вклиниться в диалог, который ведется по IPC-каналу, нельзя, но вот просматривать бегущие в нем IPC-сообщения можно. Не кому попало, конечно, а KSS, поскольку она тесно интегрирована с механизмом IPC.
Важнейшей задачей Proxy- и Dispatch-интерфейсов сущностей является создание корректных IPC-сообщений путем строго определенной сериализации входных параметров для вызываемых функций и результатов их выполнения. Теперь становится понятно, почему сгенерированный на основе IDL-описания код интерфейсов (Proxy и Dispatch) в сущностях так важен. Именно он — гарантия того, что KSS в микроядре, перехватив IPC-сообщение, тоже сможет десериализовать его, извлечь параметры вызова функции сервера или результат ее выполнения, нужный клиенту, и проверить на валидность с точки зрения используемой модели безопасности.
Положительный вердикт KSS — сигнал механизму IPC передать IPC-сообщение адресату. Отрицательный вердикт приведет к задержанию и уничтожению послания. Это метод, известный со времен царской охранки с ее перлюстрацией всей почтовой переписки. Простой, но действенный!
Kaspersky Security System. Перлюстратор и судья в одном флаконе
Разобравшись с тем, как устроены программы, которые выполняются под управлением KasperskyOS, можно взглянуть и на самого «перлюстратора» — подсистему KSS.
Состоит Kaspersky Security System из трех частей: модуля Security Runtime, интегрированного с механизмом IPC, модуля Security Server, который принимает решение о вердикте в соответствии с той или иной политикой безопасности, и структуры Decision Cache, которая хранит вердикты по отдельным политикам безопасности для повышения производительности перлюстрации IPC-сообщений.
Функции каждого из этих модулей в составе KSS вполне предсказуемы. Security Runtime сидит на перехвате и десериализации IPC-сообщений, пролетающих туда-сюда по многочисленным IPC-каналам взаимодействующих пар сущностей. Извлеченные при десериализации параметры функций или результаты их выполнения Security Runtime передает в Security Server. Последний представляет собой набор политик безопасности, специфичных для поддерживаемой системы.
Например, для офисной ИС с такими сетевыми сервисами, как почта, веб, базы данных и файловый обмен, Security Server может иметь реализации дискреционной, мандатной и ролевой политик безопасности. Тогда к каждой из них будет привязан соответствующий политике контекст безопасности. В случае же системы, управляющей технологическим процессом (например, роботизированным станком или механизмами авионики самолета), политика безопасности будет определять легитимную для этого технологического процесса последовательность функций, не приводящую к его краху или необычным результатам. Описание политик безопасности для подобных случаев выполняется с помощью удобного для валидации формального аппарата, например в терминах темпоральных логик.
INFO
За использование темпоральных логик в качестве средства формальной верификации программ и систем следует благодарить ученого Амира Пнуели. В 1996 году за эту работу он получил престижнейшую премию Тьюринга.
Но каким образом Security Server, который способен поддерживать множество политик безопасности, определяет, какую из них применить для валидации того или иного IPC-сообщения? Чтобы связать конкретные действия сущностей с конкретными политиками безопасности, командой KasperskyOS был разработан декларативный язык конфигураций безопасности CFG.
CFG позволяет указать, какую из политик, реализованных в Security Server, применять для вынесения вердикта по действиям конкретной сущности. Конфигурация безопасности, описанная на языке CFG, а также IDL-описание интерфейса сущности позволяют компилятору Nk сгенерировать связанную с сущностью структуру Gate, уникально идентифицированную SID’ом (Security ID). Она связывает действия сущности (ее автономного выполнения без IPC-взаимодействия, IPC-взаимодействие с другими сущностями или прямой запрос к KSS) с конкретной политикой безопасности.
Такой маппинг обеспечивает Security Server точным указанием того, какую политику применять для вынесения вердикта в каждом конкретном случае. Отсутствие структуры Gate у сущности делает ее изгоем KasperskyOS. По умолчанию KSS к ней применяет политику default deny.
От демонстрационных стендов к авиалайнерам. Первые шаги в реальный мир
Безусловно, выше дано только самое общее представление принципов организации KasperskyOS. Микроядерная архитектура, основанная на обмене IPC-сообщениями, компонентная модель приложений, выполняющихся под управлением KasperskyOS, IPC-канал на основе спаренных хендлов и, главное, полностью формально верифицируемый код интерфейсов, компонентов и сущностей, который автоматически создается на основе спецификаций на языках IDL, CDL и EDL.
Ну и наконец, KSS — та самая доверенная вычислительная база — монитор обращений, скрупулезно проверяющий все действия приложений на соответствие политикам безопасности, с которыми они связаны. Ее ядро, Security Server, получает точные указания о том, какую из них использовать в конкретном случае на основе языка описания конфигураций CFG. Все это лишь верхушка айсберга KasperskyOS.
Представляя свое творение, разработчики на форумах по информационной безопасности и выставках демонстрируют возможности системы, используя стенд с макетом технологической линии — сверлильным станком с ЧПУ.
Активное общение с потенциальными партнерами вскоре привело разработчиков KasperskyOS к мысли о том, что не всегда существует суровая необходимость в замене ОС. Ведь такая замена неизбежно сопряжена с полной перестройкой прикладной инфраструктуры в соответствии с идеологией компонентной модели.
Именно поэтому на нынешней стадии развития проект KasperskyOS — это портфельное OEM-решение. В некоторых случаях достаточно интегрировать KSS с уже существующей ОС. Именно так у «Лаборатории Касперского» возникло стратегическое партнерство с компанией SYSGO — разработчиком гипервизора на базе микроядерной ОС реального времени PikeOS, которая применяется во встраиваемых решениях, в частности для управления модульной системой авионики гражданских лайнеров Airbus A350 и военных Airbus A400M. Интеграция Security Runtime KSS с микроядром PikeOS обеспечивает реализацию возможностей доверенной вычислительной базы, аналогичной KasperskyOS, при минимальных затратах на модификацию прикладных программ.
Опыт сотрудничества с SYSGO показал, что система безопасности KSS может успешно применяться в качестве отдельного встраиваемого OEM-решения. Ее несложно интегрировать в существующие информационные инфраструктуры, которые нуждаются в повышенной безопасности.
Заключение
Команда KasperskyOS продолжает совершенствовать свое детище, наращивая возможности системы. Добавляется поддержка разных процессорных архитектур, файловых систем и периферийных устройств. Проводятся эксперименты с реализациями новых политик безопасности. Более того, на базе проекта KasperskyOS ведется активная разработка собственного доверенного гипервизора.
И кто знает, возможно, через пару-тройку лет о его особенностях можно будет рассказать так же, как сейчас о KasperskyOS.
