Касперский операционная система – «Официально выпущена операционная система KasperskyOS» в блоге «Информационные технологии»

alexxlab
alexxlab
14.04.2020

Содержание

Ответы на вопросы о KasperskyOS

Мальчики и девочки! Сегодня слишком прекрасный день, чтобы три раза не сказать «ура!». Вот так: УРА, УРА, УРА-А-А-А!!!

А почему?

Потому что мы — следите за слогами! — прото-типи-рова-ли, прототипировали и наконец выпрототипировали (а теперь попробуйте повторить по-трезвому! :)). Да, мы официально выпустили нашу безопасную операционную систему для сетевых устройств, автоматизированных систем управления и прочего Интернета вещей! И да, мы долго запрягали — позади 14 лет кропотливой работы (проект начался 11 ноября — отсюда и название такое — 11–11) и даже успели совершить практическое внедрение. Теперь же ОСь готова к потреблению доступна для внедрения всеми заинтересованными сторонами, в различных вариантах.

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

Зачем нам еще один Linux?

Это один из самых распространенных вопросов. И ответ на него феноменально прост — это не Linux. То есть совсем и вообще не Linux, от него там нет ни строчки кода. Мы разработали ОСь с нуля и для решения абсолютно других задач.

Для создателей Linux, Windows, OS X и многих других самое важное — совместимость и универсальность. Разработчики этих систем пытаются максимально популяризировать свои творения, для чего донельзя упростили процесс создания новых приложений и инструментов под них. А для нашей целевой аудитории (разработчики железа, АСУ ТП и т.д.) это неприемлемо, здесь главное — безопасность.

Для создания такой безопасной среды нужен глобальный Default Deny на уровне системных процессов, завернутый в микроядерную архитектуру. То есть система, которая могла бы выполнять только то, что нужно, и не могла бы (физически) делать что-то еще. В традиционных операционных системах это сделать невозможно.

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

по определению.

Ой, да делали уже безопасные ОС! И что?

Мы, собственно, и не говорим, что сделали что-то уникальное по своему гениальному замыслу. Разумеется, безопасную ОС пытались создать и раньше. И в ряде случаев даже добились успеха, но по стоимости эти проекты были сравнимы с самолетом (часто в самолетах и применялись) и потому широкого распространения не получили.

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

Мы же идем от практической задачи — разработали систему так, чтобы ее можно было задействовать в конкретных областях, с возможностью тонкой настройки степени безопасности для выполнения специфических задач. В результате у нас, по сути, получилось три продукта. Собственно ОСь (KOS), отдельный гипервизор (KSH) и отдельная система для обеспечения безопасности взаимодействия компонентов (KSS). При этом они могут принести пользу и по отдельности, в зависимости от применения.

Например, немецкая компания SYSGO лицензирует только третий компонент (KSS) для собственной разработки PikeOS. Некоторые производители проявляют интерес только к гипервизору (KSH), под которым можно запускать работающие системы управления без необходимости их модификации. А для свитчей Kraftway такого уровня интеграции было недостаточно, и в них применяется ОСь целиком.

Короче говоря, преимущество нашей ОСи заключается в том, что ее практическое применение — это не гипотетический вопрос, а дело настройки и доводки под конкретные нужды.

Как вы докажете, что ОСь позволяет выполнять только документированные операции?

Разумеется, как только мы говорим, что наша система безопасна by design, находятся люди, которые не верят. И это абсолютно нормально, в кибербезопасности вообще опасно верить на слово.

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

В остальном система будет делать только то, что вы ей велите. Злоумышленники не смогут воспользоваться даже ошибкой в коде прикладной программы, написанной под эту ОС. Да, можно написать длиннющий код с кучей ошибок. Но чтобы этот код смог отработать, ему нужно еще и соответствовать политикам, которые объясняют, что код может делать, а что нет.

Хорошая идея, но под ней ничего не будет работать

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

Ну и не следует забывать о возможности портирования на ОСь стороннего кода — для этого в составе системы есть защищенный гипервизор, который позволит запустить в качестве надстройки практически все что угодно (ну, к примеру, сервер Apache).

Да, если бы у вас была возможность взять этот сервер, поделить на множество изолированных частей и прописать, как они будут взаимодействовать друг с другом, то мы бы получили куда больший уровень безопасности. Но это адский труд. Впрочем, нет ничего невозможного — были бы желание и средства 🙂

Именно поэтому мы предоставляем возможность запуска надстройки через гипервизор. Да, в этом случае мы получим заведомо безопасную ОСь, с заведомо небезопасной надстройкой. Что будет происходить внутри этой надстройки — неизвестно. Но мы получим возможность контролировать то, как она взаимодействует с железом, как будет общаться с другими надстройками и с внешним миром. А это уже немало. При такой реализации «побег из песочницы» крайне маловероятен.

Да ладно, она все равно будет передавать данные

Само по себе ядро системы ничего никуда не передает — в этом несложно убедиться, изучив исходный код (см. выше). В микроядре нет практически ничего. Все драйверы вынесены вовне. То есть, чтобы передавать что-либо, надо написать дополнительный кусок. И он будет виден — тут даже не надо смотреть в исходники кода. Потому что это прописывается в инструкциях, в политиках безопасности. И заказчик всегда может провести их аудит независимо от кода. Если в них не прописано ничего о передаче данных куда-либо, то значит, что система их не передает.

Ну да, и стоить она будет как крыло от «Боинга»

Честно говоря, мы очень давно не покупали крыльев от «Боинга» и навскидку не помним современную цену. Однако сравнение в принципе некорректно. Потому что наша ОС — это не конечный продукт, а скорее проектный. Мы не продаем коробку с готовым волшебным снадобьем, а сотрудничаем с производителями и разработчиками (например, сетевое оборудование, промышленная автоматизация, автомобильные системы… да хоть умные холодильники!), предоставляем код и помогаем адаптировать систему под конкретные требования. Соответственно, и стоимость решения зависит непосредственно от задачи, от количества труда, который придется вложить в финализацию продукта.

Все в мире ломается, и вашу ОС тоже сломают!

Согласен, в мире нет ничего абсолютного, кроме числа 42 🙂 Поэтому могут произойти любые случаи. Однако это не повод накрыться простыней и медленно ползти на кладбище! Смысл кибербезопасности — максимально усложнить задачу кибернегодяям, задрать стоимость успешной атаки до потолка, сделать эту атаку экономически невыгодной. И в этом равных нашей ОСи пока нет.

На этом все. Вопросы — в соцсетях. Более подробная информация — на сайте.

Операционная система от «Лаборатории Касперского». Как устроена KasperskyOS — «Хакер»

Содержание статьи

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

 

Интро

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

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

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

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

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

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

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

Ладно, а как же должен выглядеть правильно написанный софт для 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-интерфейсов всех функций, входящих в состав компонента.

Код интерфейсов для связи сущностей и их объединения в компоненты автоматически генерируется на основе языков 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 может иметь реализации дискреционной, мандатной и ролевой политик безопасности. Тогда к каждой из них будет привязан соответствующий политике контекст безопасности. В случае же системы, управляющей технологическим процессом (например, роботизированным станком или механизмами авионики самолета), политика безопасности будет определять легитимную для этого технологического процесса последовательность функций, не приводящую к его краху или необычным результатам. Описание политик безопасности для подобных случаев выполняется с помощью удобного для валидации формального аппарата, например в терминах темпоральных логик.

INFO


За использование темпоральных логик в качестве средства формальной верификации программ и систем следует благодарить ученого Амира Пнуели. В 1996 году за эту работу он получил престижнейшую премию Тьюринга.
Организация 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.

KasperskyOS начали тестировать на смартфонах и процессорах «Мультикор» / Habr


Коммутатор Kraftway под управлением KasperskyOS (источник: блог Евгения Касперского)

«Лаборатория Касперского» продолжает разработку защищённой операционной системы KasperskyOS, первый релиз которой состоялся в августе 2016 года. Как сказал основатель и гендиректор «Лаборатории» Евгений Касперский, ОС полностью разрабатывалась с нуля и не имеет ничего общего с Linux, ни одной строчки кода.

Первоначально ОС была предназначена для индустриальных систем и не позиционировалась как замена системам широкого применения. Но со временем ситуация изменилась. Стало ясно, что защищённая ОС нужна на мобильных устройствах: «А то ходят люди, управляют турбинами, а у них там стоит Android. Речь идет о корпоративном и enterprise-сегментах, которые управляют критической инфраструктурой», — говорил Касперский в интервью «Ведомостям».

Поэтому KasperskyOS портировали на смартфоны.

«Лаборатория Касперского» начала тестировать применимость KasperskyOS в смартфонах, рассказал руководитель направления по развитию бизнеса KasperskyOS Григорий Сизов в комментарии «Коммерсанту».

По словам Сизова, сейчас компания разрабатывает концепцию, изучает бизнес-модели и ведёт переговоры с производителями чипсетов и вендоров, а в конце 2020 года планирует объявить первый защищённый смартфон под управлением KasperskyOS.

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

Не пускать устройство на массовый рынок — логичное решение. Защищённый корпоративный телефон будет оставаться надёжным только до тех пор, пока не станет популярным, считает директор центра разработки компании Artezio Дмитрий Паршин: «Появление такой разработки — вызов для технического сообщества и криминальных структур», — уверен он.

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

Несколько дней назад стало известно о неудаче подобного проекта под названием «Тайгафон», который пыталась реализовать группа Infowatch Натальи Касперской. Разработка аппарата велась с 2014 года, за несколько лет было создано специальное программное обеспечение для его платформы, а в 2017 году была выпущена первая тестовая партия смартфонов, которую даже опробовал один из заказчиков. Но проект был свёрнут «из-за слабых технических характеристик, отсутствия программного обеспечения и необходимости масштабных инвестиций в продвижение», сообщало 6 декабря издание Cnews.

Проект «Лаборатории Касперского» принципиально отличается, уверен Григорий Сизов. Он пояснил, что смартфон Infowatch работал на «ещё одной реинкарнации Android Linux», а это принципиально неправильный подход: «Сотни тысяч людей и компаний работают на Linux или системах, связанных с ним, это высококонкурентная среда, и тут сложно сказать, что ты сделал что-то новое. В отличие от этого проекта, у нас наша операционная система, созданная с нуля», — объяснил Сизов.

UPD 14.02.2019. Григорий Сизов заявил, что в ходе расширения поддерживаемых ею процессорных архитектур компания «рассчитывает к концу 2020 г. охватить порядка 80% наиболее распространённых на рынке решений, используемых в телекоме, на транспорте, для интернете вещей, в промышленности, а также для больших и малых экранов. Ближайшей адаптацией ОС под отечественный процессор станет инсталляция на один из готовящихся к выходу чипов зеленоградского научно-производственного центра «Элвис», известного своей процессорной линейкой «Мультикор».

Речь идет о четырёхъядерном процессоре на архитектуре ARM. Ориентировочно он выйдет в 2020 году, поэтому портирование ОС пока не ведётся — компания сначала должна получить в свое распоряжение инженерные образцы.

KasperskyOS уже поддерживает работу появившегося в середине 2012 г. трёхъядерного процессора «Мультикор» 1892ВМ10Я.

В 2014 году «Элвис» выпустил чип MCom-02 (1892ВМ14Я): система на кристалле, которая содержит два центральных ядра ARM Cortex-A9, два DSP-ядра ELcore-30M и графический процессор MALI-300.

Часто задаваемые вопросы и поддержка

1. Что нового вы предлагаете в своей безопасной ОС?

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

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

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

Кроме того, безопасность не бывает абстрактной, это всегда безопасность чего-то. Безопасность сервера базы данных, индустриального контроллера и решения для интернета вещей — не одно и то же. Но все существующие безопасные ОС, за исключением KasperskyOS, строятся вокруг какой-либо единственной модели безопасности — например, object capability. Это не позволяет обеспечить требуемые характеристики во всех необходимых случаях.

Для KasperskyOS создано (как адаптировано из open source, так и разработано «с нуля») множество компонентов, готовых к использованию. Кроме того, средствами KasperskyOS обеспечивается возможность максимально детализированного определения и гибкой настройки именно тех свойств безопасности, которые требуются в каждом конкретном случае в зависимости от специфики решения.

Мы создали не один продукт, а три: операционную систему (KasperskyOS, или KOS), безопасный гипервизор (KSH) — решение для виртуализации, и специализированную систему Kaspersky Security System (KSS), которая вычисляет вердикты и разрешает или запрещает действия в зависимости от заданных политик безопасности. Эти компоненты могут использоваться по отдельности или в комплексе, что позволяет решать различные функциональные задачи без каких-либо компромиссов, связанных с безопасностью.

Особенности антивирусной защиты промышленных систем. Анонс безопасной ОС Касперского

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

В то же время, промышленная ИТ-инфраструктура должна решать совершенно другие задачи. В первую очередь речь идет о том, чтобы обеспечивать контроль состояния и управление промышленным оборудованием в реальном времени. В этом случае отказ оборудования, зависшая программа или проблемы в сети могут очень быстро привести к фатальным последствиям — вспомнить хотя бы блэк-аут Восточного побережья США 2003 года, где в глобальной катастрофе виновен во многом отказ системы мониторинга. Поэтому если зараженный корпоративный сервер вполне возможно отключить, а потом, запустившись с внешнего источника, аккуратно почистить его, то для промышленных систем это невозможно, т. к. простой сервера для них недопустим.

В отличие от быстро обновляемых компонентов ИТ-инфраструктуры обычного предприятия промышленное оборудование рассчитано на очень длительный срок службы, в среднем речь идет о сроках в 30-50 лет. Так что значительная часть из работающего сейчас оборудования была разработана и введена в строй десятилетия назад. Системы контроля и управления там не соответствуют современному уровня даже с аппаратной точки зрения (например, поддерживают только аналоговые датчики и не могут работать с цифровым контроллером). Еще печальнее дело обстоит с программной составляющей: очень часто в основе систем до сих пор лежит ОС MS-DOS! Ко всему, обновление промышленного ПО — весьма сложная и нетривиальная задача. Перед применением обновлений их необходимо очень тщательно тестировать на совместимость, чтобы исключить даже теоретическую возможность последующего конфликта и сбоя. Очень часто производитель или эксплуатирующая организация просто полностью запрещают обновление ПО, чтобы сохранить стабильность рабочей среды.

Наконец, часто (причем где угодно, разницы между США и Россией тут практически нет) предприятия используют в работе специализированное ПО для реализации их специфических задач, написанное десятилетия назад. Как правило, в компании уже не осталось на него документации, а разработчики давно уволились, так что остается только молиться, чтобы все продолжало хоть как-то работать.

Если подходить с точки зрения безопасности, то из вышеизложенного можно сделать два вывода:

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

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

Атаки на современные промышленные системы

Перед разговором о защите промышленных систем стоит начать с разговора о противной, так сказать, стороне — о нападении.

Атаки на ИТ-инфраструктуру крупных предприятий или промышленных производств организуются совсем не так, как «потребительские» атаки. Кстати, что забавно, в этом плане построение и запуск вредоносного ПО не сильно отличается от маркетинга, например, ноутбуков (что подтверждает старую мысль: маркетинг — зло). Если говорить очень упрощенно, то:

  • Потребительские ноутбуки создаются под некий современный «средний технический уровень» и с учетом тенденций дизайна. После этого они ставятся на полки магазинов в окружении разных ярких и обращающих на себя внимание штук, которые должны привлечь внимание именно к этому ноутбуку и заставить (скорее, через всякие хитрые маркетинговые механизмы, чем через достоинства модели) купить именно его. После акта покупки производитель теряет к покупателю интерес.
  • В отношении корпоративных моделей применяется совсем другой подход. Анализируются потребности пользователей, под них создается «костяк» модели, который потом может очень сильно кастомизироваться и затачиваться под конкретного клиента, чтобы соответствовать его предпочтениям. Ключевым параметром является не стоимость покупки, а стоимость владения (стоимость покупки + стоимость обслуживания в течение срока службы модели), а задача производителя — не только продать ноутбук, но и заставить клиента не отказаться от покупки следующего поколения. Важно отметить, что в последнее время наметилась тенденция все же к более «блоковому подходу», когда требования укрупняют с тем, чтобы модель подходила для как можно более широкого круга корпоративных клиентов — и при этом стоила дешевле и была проще в производстве.

При создании и выпуске в жизнь вирусов их создатели руководствуются в среднем теми же приоритетами.

«Потребительский» вирус получает механизм(ы) распространения и запускается в свободное плавание, после чего создатель не может прогнозировать, кого он зацепит, но это и неважно: важно просто количество систем, которые вирус инфицировал и которые подчиняются командам либо выполняют свою определенную задачу (например, воруют информацию). А что это за системы — какая разница? Важны количество и послушность.

Корпоративные атаки, как правило, сложнее по форме, но главное отличие — цель. Организаторов интересует какое-то определенное предприятие или группа предприятий, а все остальное им уже не очень интересно.

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

  • Сбор информации о системе, схеме ее работы, компонентах, системах защиты и пр. Очень часто на этом этапе работа идет даже не с предприятием-целью, а с его подрядчиками, которые собирали и налаживали ИТ-инфраструктуру (как правило, речь идет о системных интеграторах). У них часто остается очень много нужной информации, при этом они не уделяют большого внимания безопасности этих данных. Кроме того, частенько у них есть возможность входа в защищенную систему заказчика, что позволяет злоумышленникам получить авторизованный доступ в нужную систему.
  • Анализ добытой информации и принятие решения о том, как именно будет осуществляться проникновение. На этом этапе решается, какие уязвимости использовать, какая функциональность вредоносной программы нужна, как именно и на что она будет воздействовать.
  • В случае, если это возможно — тестирование вируса на аналогичной системе, чтобы проверить, что он будет действовать так, как надо.
  • Выбор способа, которым вирус будет запущен в систему.
  • Старт!

Защита корпоративных систем

Учитывая активное распространение вредоносного ПО и рост сетевых атак, участники рынка активно думают над тем, как защитить промышленные системы от вирусных атак. Как правило, они идут по двум направлениям:

  • Изоляция, в том числе физическая, всей промышленной инфраструктуры с максимальным ограничением доступа. Хотя в данном случае возможности для проникновения все равно остаются, в т. ч. человеческий фактор. Как показывает опыт, если оператор решит посмотреть на служебном компьютере фильм с зараженной флэшки — он его посмотрит.
  • Максимальная завеса секретности, направленная на то, чтобы любая документация и любая информация отсутствовала в открытом доступе, а найти ее было либо очень сложно, либо и вовсе невозможно. Однако, как опять же показывает практика, информация об уязвимостях все равно попадает в сети. Например, в сети доступен даже специальный поисковый сервер, который ищет возможность подключиться к незащищенным устройствам, в т. ч. промышленным.

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

И что же делать?

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

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

Безопасная операционная система Евгения Касперского

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

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

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

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

По словам разработчиков, ключевой особенностью созданного ими ядра является возможность постоянной самоверификации. Т. е. система постоянно контролирует все компоненты ядра, что позволяет гарантировать, что системные компоненты «чистые» и не содержат никакого несанкционированного кода. Сейчас эта задача достигнута в первом приближении: у разработчиков есть некий вариант ядра, который может убедиться в собственной чистоте.

Возможности новой системы очень сильно урезаны в пользу безопасности и защитных свойств. По словам Евгения Касперского, эта система не ориентирована на то, чтобы можно было поиграть в Half-Life и заняться видеоредактированием. Однако для тех задач, для которых она создается, ее возможностей должно хватать.

Кроме того, очень сильно ограничены возможности приложений по взаимодействию с системой, и это сознательное ограничение. ОС Касперского будет работать на принципе «что не разрешено — то запрещено», т. е. использовать «белый список» разрешенных команд. Для каждого приложения, внешнего модуля, интерфейса, удаленного терминала и пр. будет создаваться список разрешенных команд, который будет храниться в самой ОС. Таким образом, приложение сможет, например, отправлять только те команды, на которые у него есть разрешение, и только на определенные устройства. Любые запросы и действия, которые явно не прописаны в системе как разрешенные, система будит игнорировать (а может, не только игнорировать, но и «сообщать куда надо»). В качестве такого примера нам приводили систему разрешений, реализованную в ОС Android. Там приложение имеет список системных функций, к которым ему необходим доступ, и при установке пользователь обязан ознакомиться со списком и согласиться на такое взаимодействие. Однако это очень грубая и несовершенная система, имеющая много недостатков.

Причем система может контролировать не только типы инструкций, но и их исполнение в целом. Например, одним из вариантов атаки может быть посылка вирусом такой команды оборудованию, которая переведет его в аварийный режим и выведет из строя. Например, он может дать команду разогнать турбину или центрифугу до 10 000 об/мин, тогда как верхний безопасный предел составляет для нее 7500 об/мин. Если в системе прописан максимальный безопасный предел, то внешнее устройство не сможет отправить на контроллер турбины сигнал о раскрутке до 10 000 об/мин, система просто не пропустит такую команду.

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

По словам Евгения Касперского, на данный момент компания не планирует выпускать ОС на рынок как готовый продукт в коробке, который инсталлировал — и всё. Скорее, создатели видят ее как платформу с набором API. А набор приложений, которые будут на ней работать, зависит в основном от функциональности, которая нужна пользователям этой платформы (т. е. либо производителям промышленного оборудования, либо тем, кто занимается его развертыванием, либо тем, кто им пользуется), поэтому им предлагается разрабатывать его самостоятельно. В этой связи Евгений Касперский несколько раз подчеркивал, что компания не справится с разработкой системы самостоятельно, да и не ставит перед собой такой цели. Вместо этого она приглашает все заинтересованные стороны к тесному сотрудничеству, которое позволит и учесть пожелания участников, и создать более функциональный, удобный и безопасный продукт.

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

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

Что такое ОС Касперского в техническом плане?

Еще меньше информации о технических деталях, касающихся работы новой ОС, поэтому остается чрезвычайно много возможностей и времени для разных спекуляций. Плюс, разработчики очень и очень аккуратны в выборе слов и избегают ответов в стиле «это — вот это», предпочитая ответы в стиле «нееет, на это совсем не похоже». Во многих случаях удается о чем-то догадаться, но максимум, что получаешь в ответ — легкий кивок головой. Самый откровенный человек — это сам Евгений Касперский, но он виртуозно перекинул все вопросы, касающиеся деталей, на главного разработчика, так что… Так что большую часть информации стоит воспринимать как неофициальную либо просто как догадки.

Итак, ранее мы уже говорили о том, что современные SCADA-системы имеют большое количество дыр. Заниматься выявлением и закрытием уязвимостей — очень долго и дорого (и не всегда возможно), переписывать все платформы с учетом современных требований — еще дольше и дороже. ОС Касперского в этом плане может предложить некую более дешевую, но при этом вполне функциональную альтернативу. Как выразился Евгений, она может «завернуть небезопасную систему в безопасный конверт, который будет отсекать попытки атаки и контролировать внешние коммуникации системы». Это как минимум позволит избежать новых появлений Stuxnet и его аналогов.

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

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

С точки зрения инфраструктуры, ключевой особенностью ОС также должен стать полный контроль всех сетевых коммуникаций в сети предприятия (включая и промышленные устройства, и контрольные станции, и рабочие компьютеры, и все-все-все). В этой связи можно поднять еще один интересный вопрос: понятно, что на рабочие компьютеры почти всегда можно установить промежуточный слой виртуализации и контроля доступа. А вот как быть с устройствами типа датчиков с сетевыми интерфейсами, теми же программируемыми контроллерами, о которых так много говорили представители Лаборатории и другими железками? Там может просто не оказаться возможности установить безопасный слой (или безопасную ОС), которые могли бы контролировать сетевые коммуникации и управление устройством, а также авторизовывать и верифицировать посылаемую им в сеть информацию.

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

Неспровоцированное личное мнение

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

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

Во-первых, промышленные системы сейчас защищены слишком слабо, и можно сказать с уверенностью, что в ближайшее время ситуация не изменится. Ситуация с безопасностью промышленных систем сама по себе не улучшится, а текущие методы защиты явно недостаточны. Физическая изоляция хотя и поможет против «пионеров», но от более серьезных атак не убережет. Сокрытие информации может помочь, когда имеет место один случай за 10 лет — а если они пойдут косяком?

Во-вторых, сетевых атак на самые разные предприятия будет становиться все больше. И на государственном, и на частном уровне. Тем более, Касперский прямо отметил растущую роль хактивистов, а уж эти ребята гораздо более креативны, чем любые профессионалы или, тем более, госструктуры. Долго ли ждать, пока зеленые помимо приковывания себя к заборам начнут использовать и другие средства воздействия (aka шантажа) против промышленных предприятий?

Однако есть и не менее серьезные аргументы «против»:

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

Во-вторых, текущая ситуация, при которой информация о кибератаках и проникновении в системы максимально скрывается, очень сильно способствует преуменьшению масштаба проблем. А ведь финальные решения принимают не эксперты по безопасности, а руководство компании, на которое постоянно давят акционеры с целью минимизировать расходы. В этом случае дополнительные средства обеспечения безопасности вполне могут пойти под нож, т. к. «это же происходит настолько редко, а у нас стоит антивирус…».

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

В-четвертых, важную роль будут играть технические сложности. Безопасная ОС безопасна не сама по себе, «из коробки». Ее безопасность — продукт долгой кропотливой работы по настройке разрешений, согласованию работы разных систем и т. д. Все это будет требовать огромных ресурсов при настройке, и практически каждый клиент будет задумываться, нужно ли ему это (см. аргументы один и два выше). Понятно, что после крупномасштабного взлома заказчики могут стать существенно сговорчивее (и тогда хорошо, что ОС может устанавливаться на уже существующие и развернутые промышленные системы), но даже тогда — не факт, совсем не факт…

Заключение

В общем, пока рано делать какие-то выводы о системе — ведь работа еще далека от завершения. Столь же сложно сейчас предсказывать ее успех или неудачу на рынке. Мне лично кажется, что ее путь будет долгим и тернистым, но посмотрим.

К тому же, не стоит думать, что новая ОС сможет «решить все проблемы». Да, она станет еще одной линией обороны, и, возможно, сильной линией. Но как современные мощные и многофункциональные антивирусы все равно то и дело обманываются новым вредоносным ПО, так же и не факт, что внедрение безопасной ОС позволит разом избавиться ото всех вирусных угроз, нависающих сейчас над промышленными ИТ-инфраструктурами. Тем не менее, разработка и внедрение такой ОС на важных инфраструктурных предприятиях уже способна заметно улучшить ситуацию с безопасностью их ИТ-инфраструктуры.

Kaspersky Secure Hypervisor | KasperskyOS

Kaspersky Secure Hypervisor содержит два программных компонента: один работает в привилегированном режиме ядра, а другой – в пользовательском режиме. Привилегированный компонент ядра отвечает за управление ресурсами (такими как память, CPU) и предоставляет доступ к устройствам ввода-вывода. Компоненты пользовательского режима KSH включают в себя обычные хостовые драйверы пользовательского режима и специальный гостевой драйвер, который предоставляет каналы коммуникации между доменами или между доменом и самим гипервизором.

Kaspersky Secure Hypervisor использует поддержку виртуализации для аппаратных средств для создания виртуальных доменов (сред), которые используют общие CPU и память.

Функции аппаратной виртуализации, если они есть, могут использоваться для доступа устройств PCI (таких, как видеоадаптер, сетевой адаптер, контроллер жёсткого диска, USB) к гостевой ОС. Данная технология улучшает производительность этих устройств, но делает невозможным их совместное использование.

Если же требуется совместное использование устройств, мы применяем технологию эмуляции устройств в пользовательском пространстве. Идея состоит в том, чтобы запустить драйвер пользовательского пространства KasperskyOS с прямым  доступом к устройству, которое нужно использовать. Драйвер обеспечивает эмуляцию устройства, т.е. предоставляет гостевой ОС интерфейс, который может использоваться для доступа к устройству. При этом гостевая ОС не знает, что устройство виртуальное. Одним из преимуществ эмуляции устройств с точки зрения безопасности является то, что гипервизор может перехватывать все взаимодействия между гостевой ОС и устройством (сетевой картой, SATA контроллером) и применять дополнительные меры безопасности (фильтрацию трафика, шифрование), которые гостевая ОС не может обойти. Эмуляция устройств также может использоваться, когда функция виртуализации аппаратного обеспечения недоступна.

«Официально выпущена операционная система KasperskyOS» в блоге «Информационные технологии»

Мальчики и девочки! Сегодня слишком прекрасный день, чтобы три раза не сказать «ура!». Вот так: УРА, УРА, УРАААА!!!А почему?

Потому что мы — следите за слогами! — прото-типи-рова-ли, прототипировали и наконец выпрототепировали (а теперь попробуйте повторить по-трезвому! 🙂 Да, мы официально выпустили нашу безопасную операционную систему для сетевых устройств, автоматизированных систем управления и прочего Интернета Вещей! И, да, мы долго запрягали — позади 14 лет кропотливой работы (проект начался 11 ноября — отсюда и название такое — 11-11) и даже успели совершить практическое внедрение. Теперь же ОСь готова к потреблению доступна для внедрения всеми заинтересованными сторонами, в различных вариантах.

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

Зачем нам ещё один Linux?

Это один из самых распространённых вопросов. И ответ на него феноменально прост — это не Linux. Т. е. совсем и вообще не Linux, от него там нет ни строчки кода. Мы разработали ОСь с нуля и для решения абсолютно других задач.Для создателей Linux, Windows, OS X и многих других самое важное — совместимость и универсальность. Разработчики этих систем пытаются максимально популяризировать свои творения, для чего донéльзя упростили процесс создания новых приложений и инструментов под них. А для нашей целевой аудитории (разработчики железа, АСУТП и т. д.) это неприемлемо — здесь главное безопасность.Для создания такой безопасной среды нужен глобальный Default Deny на уровне системных процессов, завёрнутый в микроядерную архитектуру. То есть система, которая могла бы выполнять только то, что нужно и не могла бы (физически) делать что-то ещё. В традиционных операционных системах это сделать невозможно.Встроить в уже работающую систему защитные механизмы — можно. По сути именно этим мы и занимаемся в основном бизнесе. И для решения многих задач этого хватает. Однако есть области, в которых недопустим даже потенциальный шанс успешной атаки. И если нужны гарантии, то нужно создавать что-то новое. Безопасное по определению.

Ой, да делали уже безопасные ОС! И что?

Мы, собственно, и не говорим, что сделали что-то уникальное по своему гениальному замыслу. Разумеется, безопасную ОС пытались создать и раньше. И в ряде случаев даже добились успеха, но по стоимости эти проекты были сравнимы с самолётом (часто в самолётах и применялись) и потому широкого распространения не получили.А в большинстве же случаев такие проекты ограничились научными исследованиями и ограниченной практической реализацией. Например, сделали микроядро, выпили шампанского, обнялись, поздравили друг друга и разошлись. До полноценного ввода в промышленную эксплуатацию, коммерческого продукта дело не доходило. Автомобиль — это не только двигатель, система подвески или колёса.Мы же идём от практической задачи — разработали систему так, чтобы её можно было задействовать в конкретных областях, с возможностью тонкой настройки степени безопасности для выполнения специфических задач. В результате у нас, по сути, получилось три продукта. Собственно ОСь (KOS), отдельный гипервизор (KSH) и отдельная система для обеспечения безопасности взаимодействия компонентов (KSS). При этом они могут принести пользу и по отдельности, в зависимости от применения.Например, немецкая компания SYSGO лицензирует только третий компонент (KSS) для собственной разработки PikeOS. Некоторые производители проявляют интерес только к гипервизору (KSH), под которым можно запускать работающие системы управления без необходимости их модификации. А для свичей Kraftway такого уровня интеграции было недостаточно и в них применяется ОСь целиком.

Короче говоря, преимущество нашей ОСи заключается в том, что её практическое применение — это не гипотетический вопрос, а дело настройки и доводки под конкретные нужды.

Как вы докажете, что ось позволяет выполнять только документированные операции?

Разумеется, как только мы говорим, что наша система безопасна by design, находятся люди, которые не верят. И это абсолютно нормально, в кибербезопасности вообще опасно верить на слово.Архитектура нашей операционной системы основана на делении объектов на максимальное количество изолированных сущностей. Заказчики могут ознакомиться с исходным кодом ядра, чтобы убедиться — внутри системы нет недокументированных возможностей. Всё остальное в принципе создается с участием клиента, в виде политик, которые описывают буквально каждый чих.В остальном система будет делать только то, что вы ей велите. Злоумышленники не смогут воспользоваться даже ошибкой в кодеприкладной программы, написанной под эту ОС. Да, можно написать длиннющий код с кучей ошибок. Но чтобы этот код смог отработать, ему нужно ещё и соответствовать политикам, которые объясняют, что код может делать, а что нет.

Хорошая идея, но под ней ничего не будет работать

Как раз напротив, у нас исключительно гибкая система! В принципе, её можно «допилить» даже до уровня обычной «ширпотребной», но на это уйдет очень много времени и ресурсов. Пока у нас таких планов нет — мы будем работать только в узкоспециализированном сегменте.Ну и не следует забывать о возможности портирования на ОСь стороннего кода — для этого в составе системы есть защищённый гипервизор, который позволит запустить в качестве надстройки практически все что угодно (ну, к примеру, сервер Apache).Да, если бы у вас была возможность взять этот сервер, поделить на множество изолированных частей, прописать как они будут взаимодействовать друг с другом, то мы бы получили куда больший уровень безопасности. Но это адский труд. Впрочем, нет ничего невозможного — было бы желание и средства :)Именно поэтому мы предоставляем возможность запуска надстройки через гипервизор. Да, в этом случае мы получим заведомо безопасную ось, с заведомо небезопасной надстройкой. Что будет происходить внутри этой надстройки — неизвестно. Но мы получим возможность контролировать, как она взаимодействует с железом, как будет общаться с другими надстройками и как будет общаться с внешним миром. А это уже немало. При такой реализации «побег из песочницы» крайне маловероятен.

Да ладно, она всё равно будет передавать данные

Само по себе ядро системы ничего не куда не передает — в этом не сложно убедиться, изучив исходный код (см. выше). В микроядре нет практически ничего. Все драйверы вынесены вовне. То есть чтобы передавать что-либо, надо написать дополнительный кусок. И он будет виден — тут даже не надо смотреть в исходники кода. Потому что это прописывается в инструкциях, в политиках безопасности. И заказчик всегда может провести их аудит независимо от кода. Если в них не прописано ничего о передаче данных куда-либо, то значит, что система не передает.

Ну да, и стоить она будет как крыло от «Боинга»

Честно говоря, мы очень давно не покупали крыльев от «Боинга» и на вскидку не помним современную цену. Однако, сравнение в принципе некорректно. Потому что наша ОС — это не конечный продукт, а скорее проектный. Мы не продаем коробку с готовым волшебным снадобьем, а сотрудничаем с производителями и разработчиками (например: сетевое оборудование, промышленная автоматизация, автомобильные системы… да хоть умные холодильники!) предоставляем код и помогаем адаптировать систему под конкретные требования. Соответственно и стоимость решения зависит непосредственно от задачи, от количества труда, который придется вложить в финализацию продукта.

Всё в мире ломается и вашу ОС тоже сломают!

Согласен — в мире нет ничего абсолютного, кроме числа 42 🙂 Поэтому могут случиться любые случаи. Однако это не повод накрыться простынёй и медленно ползти на кладбище! Смысл кибербезопасности — максимально усложнить задачу кибернегодяям, задрать стоимость успешной атаки до потолка, сделать эту атаку экономически невыгодной. И в этом равных нашей ОСи пока нет.

На этом всё. Вопросы — в комментах. Более подробная информация на сайте.

Разное

Отправить ответ

avatar
  Подписаться  
Уведомление о