Дмитрий Лукиян: KasperskyOS позволяет использовать доказуемую безопасность — быть прозрачным при высоком уровне защищённости

Дмитрий Лукиян, руководитель управления корпоративных продуктов KasperskyOS, и Максим Карпухин, директор по развитию бизнеса и продажам «Апротех» (дочерней компании «Лаборатории Касперского»), рассказали Anti-Malware.ru о неочевидных особенностях безопасной операционной системы KasperskyOS и продуктов на её базе. Эксперты ответили на вопросы о преимуществах микроядерной архитектуры, о концепциях MILS и FLASK, о настоящем и будущем кибериммунности, о планах развития экосистемы и многом другом.

У меня сложилось впечатление, что коллеги по рынку не очень хорошо понимают основные принципы KasperskyOS. В чём «соль», каковы её основные архитектурные отличия, например, от Linux?

Д. Л.: Постараюсь объяснить простым языком. Очевидно, что любая безопасность строится на доверии. Например, мы приходим в некое здание и нас встречает охранник — организация, куда мы пришли, доверила ему задачу по проверке и допуску людей в это здание. В информационных системах происходит то же самое. Та часть, которой мы доверяем, в терминах компьютерной науки называется «trusted computing base», то есть доверенная вычислительная база. Логично утверждать, что чем она меньше, тем лучше. Маленькой базе проще доверять, её легче верифицировать.

Теперь обратимся к архитектуре современных операционных систем. Ещё в 60-х или 70-х годах в семействе UNIX была заложена та архитектура, которой все мы пользуемся и поныне: есть ядро ОС и есть та часть, где запускаются пользовательские приложения. Она восходит ещё к Деннису Ричи и Кеннету Томпсону. Получается, что ядро является той самой базой, которой мы доверяем. Очевидно, что уменьшение ядра минимизирует доверенную вычислительную базу и повышает безопасность за счёт сокращения поверхности атаки.

Давайте теперь посмотрим на то, какие архитектуры ядер бывают. Типичная архитектура ядра, которая используется в Linux, — это монолит. Есть также микроядерная архитектура. Эти два варианта являются сейчас основными. И если монолитное ядро может насчитывать порядка 9–10 миллионов строчек кода (за счёт интеграции в него драйверов и других компонентов), то микроядро — лишь несколько десятков тысяч. Сразу видна разница: на три порядка.

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

Может возникнуть логичный вопрос о том, почему тогда люди так долго и так часто используют монолитные ядра. В девяностых годах был очень горячий спор на эту тему между Линусом Торвальдсом и Эндрю Таненбаумом. Причина того, что монолит победил, связана с вычислительными ресурсами. При микроядерной архитектуре увеличиваются накладные расходы.

Нужно выполнять больше операций?

Д. Л.: Не совсем. Как, например, происходит вызов функции, передача информации из пользовательского пространства в сторону ядра? В процессоре есть определённый механизм, который называется «trap» — одна из разновидностей прерывания, когда процессор переключается из одного режима в другой, что вызывает серьёзные накладные расходы. При монолитной архитектуре всё, что нужно для работы с оборудованием, находится в ядре и подобные прерывания не нужны; в микроядерной архитектуре драйверы работают в пользовательском пространстве и «трапы» являются накладными расходами. На момент, когда зарождался Linux, вычислительные ресурсы были малы по сравнению с текущими возможностями процессоров, поэтому применение монолитного ядра было оправданно. Впрочем, уже тогда велось много исследований и на тему микроядер.

Логично, что небольшое ядро безопаснее. Но скептик мог бы возразить, что можно просто взять монолит и выкинуть из него всё лишнее, получив в итоге такой же эффект.

Д. Л.: Верно. Поэтому здесь в игру вступает вторая интересная концепция — MILS, Multiple Independent Levels of Security. Смысл её — в следующем: можно создать специализированные изолированные контейнеры, в которых будет запускаться ПО, и гарантировать невозможность пробить брешь в контейнерах в программном смысле слова. Это научная теория. Есть разные способы её реализации; мы применили эту концепцию внутри операционной системы KasperskyOS.

Важно понимать, что в KasperskyOS три научные теории — микроядро, MILS и ещё одна, о которой я скажу позже, — работают вместе и дают особый эффект. В частности, то, что в микроядерной архитектуре драйверы функционируют в пользовательском пространстве и фактически являются приложениями, в сочетании с MILS позволяет изолировать в контейнере любой из этих драйверов. Мы пошли ещё дальше: создали возможность изолировать часть приложения. Да, зараза может проникнуть в этот контейнер; но она автоматически запирается там, и достать её оттуда уже невозможно — то есть она не в состоянии выбраться из контейнера и повлиять на другие части системы.

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

Д. Л.: Да. Таким образом можно, например, поместить в контейнер некую недоверенную библиотеку: возможно, она представляет угрозу для содержимого именно этого контейнера, но благодаря изоляции больше ни на что не сможет повлиять. Эта концепция позволяет обойти те ограничения, которые есть в Linux, потому что там пробравшийся в ядро злоумышленник может пробить бреши в другие части системы, повысить привилегии и так далее. Есть множество вирусов, которые эксплуатируют подобные уязвимости. Здесь же угроза замкнётся в небольшой области. Если всё делать грамотно, умно и в соответствии с нашей концепцией и методологией, то можно добиться той самой «кибериммунности» — когда определённый набор нужных функций будет исполняться всегда, даже при ранее неизвестной атаке.

Отступлю здесь немного в сторону. Есть такая концепция, как Secure by Design. Она зародилась много лет назад и всё ещё «тревожит умы» многих ведущих компаний и специалистов. Цель хороша: сделать систему, которая гарантированно работает даже под атакой. Вопрос в том, как эту хорошую и понятную цель реализовать. Мы предложили подход, который позволяет её достичь, и для этого нам пришлось создать операционную систему с новыми возможностями и новой архитектурой. Так, собственно, и родилась KasperskyOS, которая воплощает идею кибериммунности.

Максим Карпухин

Директор по развитию бизнеса и продажам НПО «Адаптивные Промышленные Технологии» («Апротех»)

Максим Карпухин по образованию инженер-математик. Его первый серьёзный коммерческий результат появился после работы в IBM, в отделе продаж серверного оборудования на архитектуре x86. В течение всего профессионального пути Максим занимается созданием и развитием бизнес-моделей в различных отраслях экономики. В «Апротехе» работает с основания компании в 2018 году.

Вы назвали две из трёх основ этой ОС. А какова третья?

Д. Л.: FLASK — Flux Advanced Security Kernel. Смысл этого компонента очень интересен. В зарубежной практике есть понятие «security policy hell», то есть «ад политик безопасности». Представим себе ситуацию: у вас есть UNIX с её дискреционной системой безопасности, где у пользователя имеется доступ к определённым файлам — а в этой ОС всё является файлом, так уж исторически сложилось. Файл можно создать, удалить, прочитать, записать или запустить; больше никаких вариантов нет. Возникает вопрос: а что если я хочу прочитать этот файл, скажем, с пяти до шести часов вечера? UNIX тебе на это «ответит»: мол, я дал тебе API, засучи рукава и действуй. Я, конечно, рукава засучу и всё сделаю; кто-то другой, у кого такая же политика безопасности, тоже всё старательно сделает — но по-своему. Один напишет на Python, другой — на «шелле», третий — на C++. В итоге на одной операционной системе функционируют разные приложения и никто не понимает, какая политика безопасности там работает в реальности. Что делать? Ответ напрашивается сам собой: мы ставим антивирус, которому делегируем задачу, и пусть он сам разбирается — использует, скажем, эвристические механизмы и определяет, можно ли запускать что-либо.

FLASK решает эту проблему. Эту архитектуру безопасности создали в США в сотрудничестве с университетом Юты. Разработчики предложили сделать так, чтобы за политики безопасности отвечал отдельный модуль — и только он. Иначе говоря, при запуске любого приложения все запросы по безопасности направляются туда. Модуль, соответственно, отвечает, можно или нельзя делать что-либо.

При таком подходе, во-первых, получается единая точка работы с политикой безопасности. Во-вторых, мы можем создать единый язык для описания политик, решая тем самым проблему «security policy hell». Также он позволит вывести безопасника на уровень разработчиков, даст ему возможность стать активным игроком в процессе разработки. Конечно, Secure Development Lifecycle есть и сейчас; но в этом жизненном цикле безопасник — нечто дополнительное, внешнее. Он может сделать пентест, после чего прийти «с дубинкой», сказать разработчику, что тот написал некачественный код, и заставить переделывать. Теперь же разработчики занимаются бизнес-логикой, а безопасник сам пишет политики и сам их проверяет. Такой сценарий становится возможным благодаря FLASK.

Ещё один важный момент, который со всем этим связан: архитектура KasperskyOS позволяет использовать «provable security», доказуемую безопасность. Разработав архитектуру и написав политики безопасности, вы можете всё это раскрыть публично — и уровень защищённости системы нисколько не снизится, потому что подобная информация не даёт атакующему никаких дополнительных ресурсов. При этом вы полностью прозрачны, а политику легко проверить.

А если потенциальный злоумышленник возьмёт KasperskyOS, выполнит реверс-инжиниринг и узнает, как всё работает изнутри — например, найдёт уязвимости, — то позволит ли это ему реализовать какие-либо атаки?

Д. Л.: Невзламываемых систем и систем без ошибок практически не бывает, поэтому поставим вопрос иначе: есть ли вероятность того, что в каком-либо модуле KasperskyOS будет ошибка? Такое возможно. Но эта вероятность крайне мала в сравнении с другими операционными системами. Мы предпринимаем целый ряд действий для того, чтобы её снизить: занимаемся внутренним и внешним пентестингом, например. К тестированию на проникновение привлекались очень квалифицированные специалисты, но, к счастью, пока им ничего не удалось сделать. Микроядерная архитектура и другие особенности, о которых мы уже говорили, уменьшают риск ещё сильнее. Фактически он стремится к нулю.

Что ж, это обнадёживает. Принцип Secure by Design прослеживается чётко. В то же время у меня есть некоторый скепсис по поводу кибериммунности. Иммунность, как я её понимаю, предполагает, что есть угрозы, мы на них реагируем и самообучаемся таким образом. Должна быть активная реакция: мы получили негативный опыт, закалились и стали ещё сильнее. Сейчас такого вроде бы ещё нет.

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

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

Д. Л.: Всё верно. На мой взгляд, по уровню потенциала модернизации мы находимся примерно в той же точке, что и UNIX на момент её появления. Тогда появилась концепция — ядро, мультиприложения и так далее; прошло сорок лет, и мы продолжаем её использовать и развивать. В области безопасности KasperskyOS — это примерно такой же уровень задумки, идея, которая в дальнейшем за десятилетия пройдёт сильнейшую модернизацию и будет двигаться в том числе и в сторону иммунности с точки зрения реакции. Идей много, просто нужно столь же много работать, чтобы их внедрить: проверять, стыковать с оборудованием и так далее. Мы, кстати, надеемся, что некоторые из этих идей найдут отражение и в аппаратном обеспечении — как это случилось, например, с операционными системами: оборудование должно «подтягиваться», чтобы эффективно и быстро реализовывать на практике те или иные концепции.

Уже сейчас у нас очень много сложных и интересных задач помимо тех, что я уже описал. В развитии KasperskyOS участвует множество групп: в разработке безопасной платформы одна отвечает за микроядро, другая — за драйверы устройств и поддержку аппаратных платформ, третья разрабатывает Kaspersky Security System и язык описания политик безопасности и так далее. Самая большая — это группа разработки системных компонентов, которая отвечает за графическую подсистему, реализацию файловых систем, слой совместимости с POSIX, инструменты разработки и многое другое. Сейчас формируется ещё одна группа. Ей предстоит создавать сервисы для сборки и тестирования, анализа дампов и логов — всего, что может потребоваться для CI / CD и поддержки наших решений.

В разработке продуктов на базе KasperskyOS тоже несколько команд: одна разрабатывает решения для устройств «с экраном» (платформы для мобильных устройств и тонких клиентов), другая занимается решениями для (I)IoT и умных автомобилей, в третьей ведётся разработка сетевых решений и решений встроенной безопасности (in-chip security), в четвёртой — подготовка SDK для партнёров, а также разработка решений для электроэнергетики. И, конечно же, нам надо тестировать все наши продукты, над этой задачей работает пятая группа — команда контроля качества.

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

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

Д. Л.: Компания «Апротех», которую представляет Максим, родилась не просто так. Мы создали отдельное предприятие, независимое от «Лаборатории Касперского», специально для того, чтобы оно давало нам обратную связь от людей, которые будут писать приложения под нашу ОС. Мы стремимся к тому, чтобы снижать барьер входа в экосистему; конечно, мы будем улучшать и продвигать инструменты, предлагать различные популярные фреймворки. Например, уже доступен POSIX — привычный стандарт для UNIX-разработчиков. Он, правда, предлагается в ограниченном виде, потому что не все его возможности соответствуют требованиям KasperskyOS, но основная часть функций доступна. Это позволяет портировать приложения с UNIX.

Если мы говорим, например, про тонкий клиент, то есть партнёры, которые разрабатывают на Qt. Это тоже довольно известный фреймворк в «юниксовой» разработке.

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

М. К.: Кстати, по поводу значения и значимости. Недавно на саммите одного из наших дистрибьюторов мы впервые представили широкой публике новый класс кибериммунных решений, на котором могут зарабатывать в том числе и интеграторы. Если раньше ИТ и ИБ в этом смысле были разными мирами, то теперь кибериммунные решения их объединяют. Тем самым мы показываем, что появляется новый рынок, и привлекаем партнёров в экосистему. Даже если они пока не разрабатывают, например, новые компоненты KasperskyOS, они по крайней мере используют продукт, видят, как всё это работает, и понимают, что в перспективе на этом можно зарабатывать. Здесь мы себя видим не только как компанию, которая выпускает продукты, но и как создателей бизнес-моделей.

Какие сценарии применения KasperskyOS вы видите на данный момент — помимо очевидных, таких как использование в АСУ ТП?

Д. Л.: Мы инвестируем в различные продукты на базе KasperskyOS. Из тех, которые близки к производству и коммерческой реализации, можно выделить шлюз безопасности Kaspersky IoT Secure Gateway 100, который выпускает компания «Апротех». Скоро появится его более мощная версия с двунаправленной передачей данных, детекторами, межсетевым экраном и так далее. Эту линейку мы будем совместно развивать. Она позволит решать задачи безопасности не только в промышленности, но и, например, в построении умных городов, где нужен интернет вещей. Мы стремимся дать нашим партнёрам возможность разрабатывать приложения для шлюзов такого рода, потому что есть много различного индустриального оборудования и необходимо создавать «протоколлеры», которые будут с ним соединяться и трансформировать его протоколы, понятные различным облачным платформам.

Я прочитал в комментариях к одной из публикаций у себя на фейсбуке такой вопрос: а что если вся красота операционной системы разобьётся об уязвимости на уровне «железа», такие как Spectre? Мы же не контролируем оборудование, а там может быть что угодно — начиная от закладок «стратегических партнёров» и заканчивая банальными ошибками.

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

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

Д. Л.: Здесь важно помнить, что сертификация — это требования регулятора. Если регулятор предъявляет требования, то мы будем им соответствовать. Если он будет, например, в дальнейшем обогащаться нашими идеями, то, возможно, и сама сертификация изменится — появится, скажем, отдельный класс для систем типа Secure by Design. Регулирование — это очень инерционная зона, в ней всегда всё происходит медленно и поступательно.

Актуальным требованиям ФСТЭК и ФСБ России мы, конечно, будем соответствовать, в этом мы никаких проблем не видим. Более того, KasperskyOS потенциально к этому готова: нет никаких архитектурных особенностей, которые бы этому препятствовали. Мы движемся по дорожной карте и обязательно сделаем сертификацию в определённое для неё время.

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

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

Если взять продукты «Апротеха», то благодаря кибериммунному шлюзу данных KISG 100 можно, например, получать информацию с важного производственного оборудования. При этом развёртывание в облаке займёт пару дней, а клиент будет точно уверен, что не будет никакой возможности атаковать подключённое к KISG 100 оборудование, скажем, с выступающего наружу интернет-соединения. В дополнение к традиционным межсетевым экранам и другим подобным комплексам наложенной безопасности (чья защита, увы, не всегда эффективна по причине появляющихся уязвимостей) появляется эффективность защиты подключения промышленного оборудования к платформе IIoT. Представители промышленного сектора вообще до последнего не верят, что можно в такие сжатые сроки всё подключить и обеспечить при этом высокий уровень безопасности — в то время как эти подходы уже применяются на технологических участках российских предприятий, в том числе в рамках пилотирования на ЧТПЗ (входит в «Трубную Металлургическую Компанию») и оборудовании «СтанкоМашКомплекс».

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

Спасибо за беседу! Всего доброго!