Операційна система від «Лабораторії Касперського». Як влаштована KasperskyOS

1. Зміст статті У «Лабораторії Касперського» вже чотири роки йде робота над власною захищеною операційною...
2. Помаранчеве небо, помаранчева книга
3. Верифікуйте це. Компонентна модель і IPC-листи
4. Kaspersky Security System. Перлюстратор і суддя в одному флаконі
5. Від демонстраційних стендів до авіалайнерам. Перші кроки в реальний світ
6. Висновок

Зміст статті

У «Лабораторії Касперського» вже чотири роки йде робота над власною захищеною операційною системою, проте знають про неї в основному професіонали. Справа в тому, що це не звичайна ОС, і її мета - захистити виробничі процеси від хакерських атак. У цій статті ми розповімо про те, які саме принципи безпеки лежать в основі KasperskyOS.

інтро

16 жовтня 2012 року Євген Касперський, генеральний директор всім відомої софтверної компанії, міркував на сторінках свого ЖЖ про майбутнє. Звичайно, не про світле і безхмарне (такі пасажі - справа політиків), а про страшному майбутньому, наповненому кібернетичними погрозами, які обрушуються не стільки на мирних власників ПК, планшетів і смартфонів (основних клієнтів його компанії), скільки на інформаційні системи «заводів, газет, пароплавів », офіційно іменовані ICS - Industrial Control Systems.

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

Основа типової інформаційної системи ICS - мережа управління технологічним процесом, яка може бути ніяк не захищена від доступу зі звичайної корпоративної мережі

Проекти, подібні першопрохідникові Stuxnet, успішні проникнення в системи авіоніки лайнерів через мультимедійні системи пасажирських крісел і публічні бортові мережі + Wi-Fi - далеко не живописання апокаліптичного майбутнього, а як там не є реальність.

У 2013 році консультант з безпеки Хьюго Тесо шокував виробників авіалайнерів, отримавши доступ до систем авіоніки Airbus через бортову Wi-Fi-мереж за допомогою програми для Android

Касперський, однак, не тільки давав похмурі прогнози. У тому пості він, по суті, описував принципи, які були закладені в основу нової розробки - операційної системи, архітектурно орієнтованої на системне вирішення проблеми кіберзахисту технологічних процесів.

То був далекий 2012 рік. Що стало з цією задумкою через три роки? З намірів і описів принципів операційна система «Лабораторії Касперського» перетворилася в реальність - KasperskyOS. Вірніше, в комплексне рішення Kaspersky Security System, вбудоване «з коробки» в KasperskyOS і доступне для вбудовування в операційні системи інших виробників, а також реалізоване в захищеному гіпервізора.

Тепер це рішення, вдосталь обкатати на численних конференціях і форумах з кібербезпеки, зробило крок з лабораторних стін в реальні проекти.

Помаранчеве небо, помаранчева книга

Той пост з ЖЖ Касперського був фактично публічним представленням проекту «11.11», який ЛК ініціювала, судячи з усього, ще в листопаді 2011 року ( «листопад 2011-го» - це і є «11.11»), тобто за рік до офіційного анонса . Воно й правильно. Виходити на публіку коштує не з міфологією, а з підтвердженням працездатності ідеї або як мінімум з чітким розумінням того, як вона повинна працювати.

] [Після анонса проекту «11.11» одним з перших поспілкувався з його ідеологом - Андрієм Петровичем Духваловим, який нині очолює управління перспективних технологій «Лабораторії Касперського». У цій бесіді обговорювалися принципи, покладені в основу проекту «ОС Касперського», і, що важливо, були отримані відповіді на питання «навіщо?» І «чому?».

Навіщо намагатися захистити ICS-системи за допомогою системного ПО, якщо досить помістити їх під ковпак контрольованої зони, обрубавши можливі канали несанкціонованого доступу? Навіщо починати робити власну операційну систему, якщо зараз повно готових рішень? Чому «Лабораторії Касперського» стала цікава тема операційних систем, нехай навіть і в вузькій області застосування?

На всі ці питання були дані відповіді, які через три роки розвитку проекту Kaspersky Security System все ще актуальні, оскільки визначають парадигму проекту. Зводиться вона до наступного. Всі сучасні операційні системи в тій чи іншій мірі уразливі. І пов'язано такий стан справ не з кривими руками їх розробників, а з тим фактом, що проектувалися вони без чіткого уявлення про безпеку і про комплексну мети, яку повинна вирішувати підсистема безпеки ОС.

Оскільки операційні системи удосконалюються одночасно з залізом, вони, незалежно від спочатку закладеної архітектури, розвиваються за принципом поміщицької садиби: головний будинок з часом обростає численними флігелями, прибудовами, горищами та підвалами. Зростаюча складність організації з точки зору безпеки несе дві проблеми: впроваджуються механізми безпеки, як вбудовані, так і «навішує», просто не в змозі охопити повністю всі «закутки» «Особняк». Звідси і поява різноманітних бекдор.

Але це проблема принципової можливості бути реалізованим механізмів безпеки. Складна організація операційних систем істотно ускладнює як аналіз потенційної уразливості компонентів, так і ефективність застосовуваних механізмів безпеки. Будь все інакше, та ж «Лабораторія Касперського» з її антивірусними рішеннями просто залишилася б без роботи.

Висновок з усього цього досить банальна. Якщо вже щось робити в області захищених ОС, то робити це з нуля, розглядаючи проблеми безпеки в якості основних вимог і враховуючи їх вплив на всіх етапах проектування системи. Саме тому головний російський борець з вірусами і замахнувся на розробку власної операційної системи. Але, розуміючи всю складність створення нової системи загального призначення на кшталт Windows або UNIX, вирішив почати зі специфічною. Вдало обрана і область - промислові інформаційні системи досі не були розпещені надійним захистом. З одного боку, це важлива справа, з іншого - можливість отримати безцінний досвід, який, дивись, можна буде поширити і на інші області застосування операційних систем.

Зважитися на розробку власної ОС, в якій механізми безпеки стануть фундаментом, можна, тільки грунтовно вивчивши, що ж взагалі в цій області напрацьовано. Команда KasperskyOS так і вчинила. В першу чергу погляд був кинутий на матеріали «Райдужній серії» (Rainbow Series) - набору стандартів інформаційної безпеки, різнокольорові томи яких були спочатку опубліковані в Міністерстві оборони США, а потім в Центрі національної комп'ютерної безпеки США.

Стандарти ці охоплюють найрізноманітніші аспекти інформаційної безпеки, від термінологічного базису до керівництв користувачів і співробітників служби безпеки. Найважливіша частина «Райдужній серії» - це «Помаранчева книга», де задаються критерії визначення безпеки комп'ютерних систем. Її ратифікованим в міжнародному масштабі аналогом є стандарт ISO / IEC 15408.

«Помаранчева книга» - один з численних томів «Райдужній серії», присвяченій кібербезпеки

Головний постулат «Помаранчевої книги» полягає в тому, що безпека комп'ютерних систем ніколи не була і ніколи не буде ідеальною. Будь-яка експлуатується або знову проектована система безпечна рівно настільки, наскільки ми довіряємо їй рішення цього важливого питання. А значить, правильніше говорити не про безпечні, а про довірених системах.

Саме тому сукупність механізмів, які в інформаційній системі реалізують ту чи іншу політику безпеки і визначають ступінь довіри до цієї системи, в «Помаранчевої книзі» називають ДВБ - довірена обчислювальна база (Trusted Computer Base).

Яку функцію в інформаційній системі виконує ДВБ? Єдино вірну: контролює будь-які взаємодії компонентів інформаційної системи між собою, з системними функціями і апаратною базою системи. Жодне звернення будь-якого компонента системи не повинно залишитися без пильної перевірки ДВБ з точки зору підтримуваного нею механізму (або механізмів) безпеки. У «Помаранчевої книзі» цю функцію ДВБ називають моніторингом звернень.

Моніторинг звернень фактично означає, що компоненти інформаційної системи безпосередньо ні між собою, ні з ядром системи, ні з апаратурою не взаємодіють. Все відбувається за вказівкою ДВБ. Дозволила ДВБ - вперед! Заборонила - взаємодії не бути. Виходить, ДВБ - це така штука, яка дозволяє ізолювати один від одного компоненти інформаційної системи. Старий як світ принцип владарювання - через поділ.

Контроль, контроль і ще раз контроль! Ось основна функція довіреної обчислювальної бази

«Довірена» в абревіатурі ДВБ означає, що ми змушені довіряти їй. А зробити це простіше, якщо ДВБ прозора як з точки зору своєї організації, так і з точки зору способів перевірки правильності її роботи. Досягти такої прозорості можна різними способами. Найдієвіші з них - це простота і компактність організації ДВБ, а також можливість використовувати для її перевірки деякий набір формальних методів. Він дозволить дати однозначну відповідь про те, наскільки ДВБ (ну і інформаційна система на її основі) відповідає своєму призначенню (це називається «валідація») і наскільки повно принципи, закладені в основу при проектуванні, були втілені на етапах розробки (верифікація).

Тепер-то і стає ясно, що команда проекту 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 надає процесам механізм обміну повідомленнями. І безперервно контролює його за допомогою Kaspersky Security System

Гаразд, а як же повинен виглядати правильно написаний софт для KasperskyOS? Для софтопісателей розробники KasperskyOS пропонують спеціальний підхід, який іменується «компонентна модель». Фактично ця модель служить для прикладних програмістів зручною абстракцією, що дозволяє створити коректне з точки зору KasperskyOS додаток. Крім того, підтримка компонентної моделі забезпечується інфраструктурно - набором засобів розробки.

В основі компонентної моделі програми лежить поняття «сутність» (Entity). Сутністю може бути окрема програма, що надає (сервер) або споживає (клієнт) функції для інших сутностей. Або ж їй може бути реалізація якоїсь окремої функції програми. У загальному випадку сутність - це набір компонентів, кожен з яких включає в себе одну або більше внутрікомпонентную сутність. У самому виродженим випадку компонентної моделі сутність - це один компонент з одного внутрікомпонентной сутністю. Саме суті, реалізуючи свої функції, спілкуються один з одним за допомогою IPC-повідомлень. Тобто виконання складно влаштованої програми або клієнт-серверного сервісу, створених за ідеологією компонентної моделі, - це IPC-листування сутностей, за якою і стежить KSS. Щоб сутність могла брати участь в такому діалозі, в її складі поряд з базовим кодом повинен бути присутнім код інтерфейсу доступу до механізму IPC мікроядра.

І ось тут починається найцікавіше. Створення коду цього інтерфейсу покладається не на розробника програми. Код інтерфейсу автоматично генерується з його опису на мові IDL (Interface Definition Language) - С ++ подібного мови специфікації інтерфейсів в розподілених системах. Що дає використання IDL? Можливість тієї самої верифікації коректності взаємодії однієї сутності з іншого сутністю. Сувора типізація IDL цьому сприяє і дозволяє спеціально розробленим компілятору Nk перед автогенерація коду інтерфейсу перевірити його на безпомилковість з точки зору компонентної моделі. Исходник інтерфейсу на IDL після компіляції Nk перетворюється в об'єктний код в необхідної розробнику нотації. Звичайно ж, підтримуються С і С ++, а також мову функціонального програмування Haskell.

Поміщений в код суті об'єктний код інтерфейсу забезпечує формування функцій Proxy (в клієнтських додатках) і Dispatch (в серверних додатках). Чому вони важливі з точки зору архітектури KasperskyOS? Клієнтську програму, викликаючи ту чи іншу функцію серверного додатка або ядра системи, передає її параметри інтерфейсної функції Proxy, яка серіалізуются їх (упаковує в формат IPC-повідомлення), а потім викликає транспортну функцію механізму IPC в мікроядрі і передає їй створене IPC-повідомлення. Тепер Proxy-функції залишається тільки чекати відповідного IPC-повідомлення з результатом, щоб десеріалізовать його і передати зробив виклик базового коду клієнта.

Функція Dispatch на серверній стороні робить протилежне: отримавши IPC-повідомлення, вона десеріалізует його (розпаковує параметри для функції, що викликається), передає їх базового коду пов'язаного з даним інтерфейсом сервісу і, отримавши від нього результат, серіалізуются його в IPC-повідомлення.

Але що робити, якщо сутність (наприклад, сервер якого-небудь сервісу) містить безліч компонентів, а з них кожен складається з різних функцій, до яких може звертатися сутність-клієнт? Адже по ідеології компонентної моделі з кожної такою функцією має бути пов'язаний власний Dispatch-інтерфейс. Як механізм IPC визначить, яким з них передавати IPC-повідомлення? І знову на допомогу програмісту приходять мови специфікацій. При упаковці декількох функцій з їх Dispatch-інтерфейсами в один компонент програміст описує його мовою CDL (Component Definition Language). Компілятор Nk на основі CDL-опису компонента генерує його код з єдиним в рамках компоненту інтерфейсом, який насправді є сукупністю Dispatch-інтерфейсів всіх функцій, що входять до складу компонента.

Код інтерфейсів для зв'язку сутностей та їх об'єднання в компоненти автоматично генерується на основі мов IDL, CDL і EDL

Для багатокомпонентної суті є своя мова специфікацій EDL (Entity Definition Language). На ньому описуються всі компоненти, які входять до складу суті, а також (якщо такі є) окремі функції з власними Dispatch-інтерфейсами. В результаті компіляції EDL-файлу формується загальний код суті з єдиним глобальним Dispatch-інтерфейсом, який, по суті, є точкою входу IPC-повідомлення в сутність.

Знайти ж адресата для нього - конкретний Dispatch-інтерфейс конкретної функції (окремої або в складі компонента) - можна по його унікальним ідентифікатором Runtime Interface ID (RIID). Він генерується на етапі компіляції EDL-опису сутності. Така вкладеність строго типізованих специфікацій дозволяє розробнику створити скільки завгодно складну програму, кожна функція якої буде забезпечена власним Proxy- або Dispatch-інтерфейсом.

Приклад Опису гіпотетічної суті Foo на декларативну мову EDL

Вище Було сказано, что Виконання програми, розробленої за ідеологією компонентної моделі, є діалогом функцій, тобто їх листування IPC-повідомленнями строго Певного формату. Важливо, що це саме діалог, а не какофонія, оскільки IPC-взаємодія - справа двох сутностей, щось на зразок peer-to-peer. Однак, на відміну, наприклад, від пірінгових протоколів, IPC-взаємодія в KasperskyOS здійснюється за принципом рандеву.

Посередником, звичайно ж, виступає механізм IPC мікроядра. А щоб рандеву відбулося, тобто був налаштований канал обміну IPC-повідомленнями між конкретними сутностями, канал цей створюється механізмом IPC шляхом виділення сутностей спеціальних глобальних системних об'єктів хендлов (handle) - покажчиків, які ідентифікують суті відправника і одержувача. На час взаємодії суті стають власниками своїх хендлов, що і дає їм право використовувати відкривається IPC-канал.

Хоча канал IPC-взаємодії пов'язує дві сутності між собою, кожна з них поінформована про нього тільки наполовину. Точка їх рандеву - механізм IPC в мікроядрі

При такій організації IPC-взаємодії кожна сутність має уявлення тільки про виділений їй хендла. Про парі хендлов відправника і одержувача знає тільки механізм IPC. Тому-то процедура формування IPC-каналу обміну повідомленнями і називається «спарюванням хендлов» (handles pairing). Після такого спарювання вклинитися в діалог сутностей не може ніхто сторонній. IPC-канал буде існувати до тих пір, поки взаємодіючі суті залишатимуться власниками спарених хендлов.

Модель 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 може мати реалізації дискреционной, мандатної та рольової політик безпеки. Тоді до кожної з них буде прив'язаний відповідний політиці контекст безпеки. У разі ж системи, що управляє технологічним процесом (наприклад, роботизованим верстатом або механізмами авіоніки літака), політика безпеки визначатиме легітимну для цього технологічного процесу послідовність функцій, які не приводить до його краху або незвичайним результатами. Опис політик безпеки для подібних випадків виконується за допомогою зручного для валідації формального апарату, наприклад в термінах темпоральних логік.

Організація Security Server дозволяє реалізовувати ті політики безпеки, потреба в яких є у захищається інформаційної системи

Але яким чином Security Server, який здатний підтримувати безліч політик безпеки, визначає, яку з них застосувати для валідації того чи іншого IPC-повідомлення? Щоб зв'язати конкретні дії сутностей з конкретними політиками безпеки, командою KasperskyOS був розроблений декларативний мову конфігурацій безпеки CFG.

Якби функції калькулятора були критично важливими з точки зору безпеки, то його конфігурація CFG виглядала б так Дії контролера, який керує дрилем, і самої дрилі можна узгодити, використовуючи формалізм лінійної темпоральної логіки. І створити на його основі специфікацію властивостей безпеки

CFG дозволяє вказати, яку з політик, реалізованих в Security Server, застосовувати для винесення вердикту щодо дій конкретної сутності. Конфігурація безпеки, описана на мові CFG, а також IDL-опис інтерфейсу суті дозволяють компілятору Nk згенерувати пов'язану з сутністю структуру Gate, унікально ідентифіковану SID'ом (Security ID). Вона пов'язує дії сутності (її автономного виконання без IPC-взаємодії, IPC-взаємодія з іншими сутностями або прямий запит до KSS) з конкретною політикою безпеки.

Такий маппинг забезпечує Security Server точним зазначенням того, яку політику застосовувати для винесення вердикту в кожному конкретному випадку. Відсутність структури Gate у сутності робить її ізгоєм KasperskyOS. За замовчуванням KSS до неї застосовує політику default deny.

Пов'язана з кожної сутністю структура Security Gate автоматично генерується на основі конфігурації безпеки CFG і IDL-опису сутності

Від демонстраційних стендів до авіалайнерам. Перші кроки в реальний світ

Безумовно, вище дано тільки саме загальне уявлення принципів організації KasperskyOS. Мікроядерна архітектура, заснована на обміні IPC-повідомленнями, компонентна модель додатків, що виконуються під управлінням KasperskyOS, IPC-канал на основі спарених хендлов і, головне, повністю формально верифікується код інтерфейсів, компонентів і сутностей, який автоматично створюється на основі специфікацій на мовах IDL, CDL і EDL.

Ну і нарешті, KSS - та сама довірена обчислювальна база - монітор звернень, скрупульозно перевіряє всі дії додатків на відповідність політикам безпеки, з якими вони пов'язані. Її ядро, Security Server, отримує точні вказівки про те, яку з них використовувати в конкретному випадку на основі мови опису конфігурацій CFG. Все це лише верхівка айсберга KasperskyOS.

Представляючи своє творіння, розробники на форумах з інформаційної безпеки і виставках демонструють можливості системи, використовуючи стенд з макетом технологічної лінії - свердлильним верстатом з ЧПУ.

На цій моделі технологічної лінії з свердлильним верстатом розробники KasperskyOS демонструють можливості свого рішення на виставках і конференціях

Активне спілкування з потенційними партнерами незабаром привело розробників KasperskyOS до думки про те, що не завжди існує сувора необхідність в заміні ОС. Адже така заміна неминуче пов'язана з повною перебудовою прикладної інфраструктури у відповідності з ідеологією компонентної моделі.

Ось так представляється інтеграція OEM-рішення KSS в інформаційну систему з трьома різними з точки зору безпеки доменами

Саме тому на нинішній стадії розвитку проект KasperskyOS - це портфельний OEM-рішення. У деяких випадках досить інтегрувати KSS з уже існуючою ОС. Саме так у «Лабораторії Касперського» виникло стратегічне партнерство з компанією SYSGO - розробником гипервизора на базі микроядерной ОС реального часу PikeOS, яка застосовується у вбудованих рішеннях, зокрема для управління модульною системою авіоніки цивільних лайнерів Airbus A350 і військових Airbus A400M. Інтеграція Security Runtime KSS з мікроядром PikeOS забезпечує реалізацію можливостей довіреної обчислювальної бази, аналогічної KasperskyOS, при мінімальних витратах на модифікацію прикладних програм.

Гипервизор PikeOS фірми SYSGO - перший приклад комерційного застосування Kaspersky Security System

Досвід співпраці з SYSGO показав, що система безпеки KSS може успішно застосовуватися в якості окремого вбудованого OEM-рішення. Її нескладно інтегрувати в існуючі інформаційні інфраструктури, які потребують підвищеної безпеки.

Висновок

Команда KasperskyOS продовжує удосконалювати своє дітище, нарощуючи можливості системи. Додається підтримка різних процесорних архітектур, файлових систем і периферійних пристроїв. Проводяться експерименти з реалізаціями нових політик безпеки. Більш того, на базі проекту KasperskyOS ведеться активна розробка власного довіреної гипервизора.

І хто знає, можливо, через пару-трійку років про його особливості можна буде розповісти так само, як зараз про KasperskyOS.