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

Предпосылки создания KasperskyOS

Что это такое?
Проприетарная частично POSIX-совместимая микроядерная операционная система
Для чего?
Цель разработки — сделать мир умных устройств и M2M-коммуникаций безопасным
Как?
Код операционной системы написан «с нуля», и не основывается на каком-либо существующем проекте
Kaspersky Operating System
KasperskyOS

Вакансии

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

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

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

Для решения этой задачи в Лаборатории Касперского было создано отдельное подразделение, первоочередной задачей которого было взглянуть на мировой опыт решения проблемы создания безопасной операционной системы. В начале 2000-х уже существовало большое количество теоретических исследований на тему безопасности операционных систем. В частности, еще в далеком 1972 году Джеймс Андресон ввел понятие безопасной операционной системы и описал концепцию «Монитора вызовов» (Reference Monitor), позже в 1981 году Джон Рашби предложил концепцию «Separation Kernel», которая легла в основу MILS (Multiple Independent Level Architecture) архитектуры, а в 1999 г. была представлена архитектура FLASK (Flux Advanced Security Kernel). Эти идеи, а также ряд собственных разработок легли в основу Kaspersky Operating System.

Архитектура Kaspersky Operating System

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

Микроядерная архитектура

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

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

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

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

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

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

Для реализации данного требования в Kaspersky OS любое приложение представляет из себя отдельную сущность, которая называется «Entity» (см. рис. 1). Для запуска в Kaspersky OS каждая «Entity» должна предоставить перечень интерфейсов, которые позволяют с ней взаимодействовать, а также политику безопасности, описывающую правила взаимодействия. По аналогии с концепцией «Entity», в Kaspersky OS все драйвера изолированы друг от друга, выполняются в своем окружении и не могут получить доступ к произвольному оборудованию. И также должны предоставлять перечень интерфейсов для взаимодействия. Правила обращения к интерфейсам, как и в случае с «Entity» должны быть зафиксированы в политике безопасности.

Рис. 1 Высокоуровневая архитектура Kaspersky OS

Система контроля доступа

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

Большая часть этих вопросов была теоретически проработана и проверена на прототипах в рамках разработки FLASK архитектуры. При разработке Kaspersky OS были использованы результаты этих исследований.

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

Для устранения этого недостатка в Kaspersky OS предусмотрен целый ряд механизмов. Во-первых, описание политик безопасности и бизнес логика каждой «Entity» разнесены. Конфигурация политики безопасности поставляется в отдельном файле с расширением: .cfg (см. рис. 2). Во-вторых, для обеспечения поддержки нескольких моделей безопасности, а также их комбинирования в рамках одной политики в Kaspersky OS проверка и вынесение вердикта выполнения операции вынесена в отдельную сущность, которая называется Kaspersky Security System или кратко KSS (см. рис. 2).

Рис. 2 Kaspersky Security System (KSS)

В-третьих, для увеличения производительности системы безопасности в Kaspersky OS реализован механизм кэширования вердиктов, который хорошо себя показал в прототипах FLASK архитектуры. В-четвертых, любые взаимодействия между различными «Entity» в Kaspersky OS строго типизированы, т.е. фактически допустим обмен данными только через механизм IPC.

Такие технические решения позволяют комбинировать в Kaspersky OS в одной политике безопасности несколько моделей безопасности и добиться необходимой гибкости в их описании. Например, в текущей версии KasperskyOS можно в рамках одной политики комбинировать следующие модели безопасности: ролевой доступ (RBAC), Object Capability, Type Enforcement, Finite automat, а также экзотические модели на базе тэмпоральных логик. Это, в свою очередь, исключает необходимость интеграции логики, связанной с информационной безопасностью в само приложение, снижая тем самым его стоимость и трудоемкость, а также позволяет вынести вопросы информационной безопасности из зоны разработки в зону конфигурирования, что значительно повышает уровень информационной безопасности приложения.

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

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

Всем нескучного программирования и поменьше багов!!!

А тем, кто дочитал до конца — откликайтесь на наши вакансии и приходите спасать мир от киберугроз вместе с нами!