Содержание статьи
Безопасная ОС от Kaspersky Lab? Будет или нет? Слухи на этот счет давно муссируются, но без каких-либо подробностей. Ясность появилась на организованной Международным союзом электросвязи конференции, которая прошла в октябре в Дубае, где компания впервые официально подтвердила, что ведет разработку ОС для промышленных объектов.
Довольствоваться общими словами о незащищенности промышленной инфраструктуры и историями-баянами про Stuxnet мы не хотели. Нужна была конкретика: пишется ли система с нуля или на базе уже имеющейся ОС (например, QNX), как она может решить проблему, когда наружу в интернет торчат тысячи программируемых контроллеров (PLC) с реальных промышленных объектов, и почему эта система будет более безопасна, чем многие другие? Пришлось постараться, чтобы лично пообщаться с человеком, который непосредственно отвечает за разработку новой ОС, — Андреем Духваловым. Еще до начала интервью стало ясно, что это один из выдающихся сотрудников компании: именно ему удалось решить проблему с тормознутостью продуктов, за которую Kaspersky Lab серьезно доставалось пять-шесть лет назад. Сейчас он занимает должность с говорящим названием Chief Strategy Architect и руководит направлением разработки безопасной ОС. Вот что он нам рассказал.
Proof-of-concept
Разработкой операционной системы 11.11 мы занимаемся давно, но этот процесс долгосрочный, поэтому пока мы находимся на ранней стадии. Это не клон Linux’а и не клон QNX — все пишется с нуля. Но мы поддерживаем стандарты POSIX, чтобы другие программы могли запускаться в нашей среде. В настоящий момент у нас есть прототип для платформы x86, но мы собираемся перенести систему и на другие платформы, в том числе ARM. Перед разработкой мы поставили себе несколько целей, а с помощью созданного прототипа сами себе доказали состоятельность идей, которые положили в основу операционной системы. Многие из подходов давно известны, но мы взяли на себя смелость реализовать все в одном месте и сделать это хорошо. Все, что я расскажу далее, касается только прототипа — того, что мы имеем сейчас.
Отсутствие точки доверия
До последнего времени при создании моделей информационной безопасности критически важных промышленных объектов бытовало мнение, что одной лишь физической изоляции объекта достаточно для его защиты. Поэтому о безопасности программного обеспечения и железа заботились в меньшей степени. Например, есть протокол MODBUS, с помощью которого взаимодействует промышленное оборудование, например, контроллер с двигателем. Этот протокол (как и многие другие) в стандарте не содержит средств аутентификации и авторизации. Любой, кто находится в этой же сети, может отправить любому промышленному устройству команду — снять данные, перепрошить firmware и так далее. Сам софт дырявый. Согласно исследованию университета Карнеги — Меллона, количество ошибок в военном и промышленном программном обеспечении составляет в среднем от пяти до десяти на тысячу строк кода. Самым лучшим решением было бы поменять все программное обеспечение и железо. Как вы понимаете, это невозможно. Но есть другой способ решить проблемы, которые возникают в индустриальной среде. Мы хотим сделать так, чтобы взаимодействие между узлами было под контролем. Если посмотреть на типичную схему сети корпоративного предприятия, в которой находится множество разных узлов, и задаться вопросом, какой из этих сущностей можно доверять, выяснится, что никакой! Наша цель — построить такую точку доверия и на ее основе выстраивать защиту.
Где будет работать ОС?
Чтобы стало понятнее, приведу пример. В самом простом случае промышленная инфраструктура выглядит примерно так: есть сенсоры, есть контроллеры, в которых заложена логика управления оборудованием, и есть рабочая станция со SCADA, которая умеет отдавать контроллеру команды «перевести в тот режим», «перевести в другой», «сделать больше», «сделать меньше» и прочие. Практически все устройства работают через протоколы MODBUS, Profibus или другие промышленные протоколы поверх привычных TCP/IP-протоколов, при этом физически подключены к обычным маршрутизаторам (например, Cisco). Ничто не мешает поставить «рядом» еще один компонент, который на основе заранее заданных правил (специально разработанных для каждой конкретной системы) сможет мониторить и контролировать все, что передается между системами, в том числе гарантируя, что данные передаются от легитимного источника и без изменений. В случае тревоги мы можем активировать противоаварийную защиту — в любой АСУ есть такие автоматизированные механизмы, которые реагируют на внештатные ситуации. Наша задача — сделать такую противоаварийную защиту с учетом информационной среды. Но для этого важно решить еще одну сложную задачу — мы на 100% должны быть уверены в безопасности нашей системы.
Безопасная ОС
Софт может делать больше того, для чего предназначен. Основной принцип, который лежит в основе требований к архитектуре 11.11, — недопустимо исполнение незаявленной функциональности. Этот принцип разработки ОС позволяет надеяться, что внутри ОС происходит ровно то, что мы ожидаем. На любом телефоне есть калькулятор: кто может гарантировать, что в момент, когда мы умножаем два на два, он не отправляет SMS? В 11.11 мы уверены, что каждый модуль делает только то, что он должен делать. Сложность в том, что этот принцип должен быть реализован в архитектуре системы. Нельзя сделать отдельный слой поверх ядра ОС, предоставляющий такие гарантии, потому что в этом случае в ядре остаются уязвимости.
Код без ошибок
Говорят, что программ без ошибок не бывает. На самом деле существует так называемая формальная верификация кода, с помощью которой можно доказать, что ошибок в нем нет. Утверждение об отсутствии ошибок доказывается как математическая теорема. То есть можно дать на вход некоторые постулаты и предоставить исходный код программы, реализующий эти постулаты. Существует система, которая с помощью математических выводов способна доказать, что исходный код реализует именно эти постулаты и никакие другие. Еще в 2009 году в рамках проекта L4.verified была проведена первая формальная верификация ядра операционной системы — микроядра seL4. Доказательство было составлено и проведено с помощью программы Isabelle/HOL, предназначенной специально для доказательства теорем. Для этого потребовалось написать более 200 000 строк специальных скриптов-доказательств. Всего было проверено более 8700 строк C-кода и 600 строк, написанных на ассемблере. С помощью такого подхода удалось обнаружить 160 багов в ядре seL4. У нас стоит цель — верифицировать таким образом свое ядро. Мы закладываем постулаты и имеем исходный код ядра. Далее с помощью математических методов доказываем, что эти постулаты соответствуют этому коду.
Недопущение исполнения незаявленной функциональности
Этот базовый принцип достигается за счет того, что каждый из модулей ядра помещается в песочницу. Они могут общаться друг с другом посредством механизма, который жестко контролирует ОС. Для этого мы реализовали специальные методы IPC, через которые мониторится взаимодействие. И у модулей не будет другого способа общаться друг с другом, кроме как через нашу IPC. Основная задача ядра ОС — это выносить вердикты, можно ли модулям общаться друг с другом в данный момент и при данных условиях или же нельзя. Все основные модули системы, которые мы привыкли относить к сервисам ядра, работают в рамках таких же правил. И те же правила применяются для пользовательских приложений.
Другие компоненты ядра
Компьютерная наука развивается более 50 лет, и за это время было реализовано много хороших идей, которые мы готовы перенять. Трудность заключается в том, что наши базовые принципы не позволяют нам, условно говоря, взять уже готовый драйвер и использовать его как есть. Это невозможно, потому что драйвер должен работать в соответствии с принципом недопустимости исполнения незаявленного функционала. Поэтому мы разбираемся, как он работает, и реализуем у себя. Это объемная работа, и мы не собираемся делать ее сами. Наша задача — сделать платформу, чтобы строить безопасные системы. Мы открыты для привлечения партнеров: работы много, одним нам не справиться. Мы видим свою цель — написать фреймворк, который позволяет другим разработчикам подменять модули ядра на свои собственные. Микроядерная технология во всей своей красе! Простой пример. В тех применениях, где критически важна конфиденциальность, может понадобиться особенный менеджер памяти, который будет обнулять память, когда она высвобождается. Разработчик сможет использовать свой модуль для управления памятью и таким образом выполнить это требование конфиденциальности.
Как можно контролировать?
Что касается контроля взаимодействия между разными компонентами взаимодействия промышленной инфраструктуры — по сути, те же самые принципы и математические доказательства, которые мы используем внутри ядра, работают и на более высоком уровне. Если будет рефери, который контролирует взаимодействие между компонентами системы, то получится взять без изменений промышленную систему и добавить туда дополнительные элементы, которые повысят ее безопасность.
Модели безопасности
Многие из используемых нами подходов существуют 20–30 лет, но их не часто можно встретить в реализации ОС. Моделями безопасности компьютерных систем занимается дискретная математика. Существует много теоретических наработок, и есть практические результаты. Дискреционная и мандатная модели безопасности очень распространены, и они на слуху. Но кроме них существует огромное число моделей безопасности: например type enforsments, Белла — ЛаПадула и другие. Каждая из них хороша в определенных условиях применения. Теория в этом направлении шагнула далеко — мы взяли смелость реализовать инструмент, с помощью которого можно будет воплотить те или иные модели безопасности на практике для тех или иных условий применения. Однако нужно еще время, чтобы довести этот во многом исследовательский проект до готового продукта.
