Эволюция идеи
Изначальная идея была проста до банальности: что если попробовать изменить правила игры? Информационная безопасность всегда оперировала ответами на угрозы. Появляется угроза — разрабатываем контрмеры. Это всегда игра от обороны, заведомо невыгодная позиция. Нельзя ли поменять условия, разработать некий слой безопасности, в котором правила диктовали бы мы: изначально разрешали бы приложениям делать только то, для чего они предназначены, и ничего сверх того?
Первое время речь даже не шла о самостоятельной системе — предполагалось взять какой-нибудь из дистрибутивов Linux и докрутить его под наши задачи. Но в процессе разработки стало очевидно, что это просто невозможно. Если мы будем строить слой безопасности поверх уже существующей ОС, то в любом случае останутся лазейки, через которые можно атаковать приложения.
В результате мы пришли к необходимости написания собственного ядра, на которое приложения могли бы опираться как на доверенную базу.
Тут надо сказать, что у нас не было желания изобретать велосипед. Мы далеко не первые задумались о создании доверенной среды: существует множество уже продуманных и обкатанных подходов к ее созданию. Однако мы взяли на себя смелость объединить несколько известных подходов и добавить немного своего, уникального. Наша команда тщательно изучила существующие наработки и проанализировала те из них, которые наиболее подходили для реализации наших задач. Например, один из известных архитектурных принципов Multiple Independent Levels of Security (MILS): в нем, в частности, заложено разделение среды на домены безопасности.
Так постепенно выкристаллизовалась современная архитектура системы: разделить среду на некие изолированные области, в каждой из которых исполняется определенный компонент системы, связать их между собой детализированными интерфейсами и жестко контролировать эти интерфейсы. Упрощенно говоря — все процессы запускаются в своеобразных песочницах или, если вам угодно, в контейнерах, а мы контролируем связи между ними.
Интересно, что в какой-то момент ключевой компонент системы получил собственную жизнь: мы увидели, что инструмент, который должен был контролировать те самые взаимодействия между доменами безопасности, можно применять не только в нашей ОС. А по большому счету не только в ОС в принципе! В результате в марте 2015 года мы выпустили платформу Kaspersky Security System (KSS) в качестве встраиваемого OEM-компонента для разработчиков комплексных решений.
Ведь сетевую инфраструктуру тоже можно рассматривать как набор доменов безопасности, взаимодействия между которыми необходимо контролировать. Или, например, можно присмотреться к процессору: в каждом из них может быть 30–40 IP-ядер (IP-блоков), каждое из которых предоставляет какой-то сервис для других компонентов внутри процессора. И эти блоки тоже взаимодействуют друг с другом, с операционной системой и приложениями, а это значит, что для создания доверенной среды их взаимодействия тоже необходимо контролировать. И для этих задач может использоваться все тот же наш KSS! Впрочем, тут я немного забегаю вперед — пока это лишь исследования, а не коммерческий продукт. Но подход приобретает все более четкие очертания!
В результате была проделана колоссальная работа, в 2006 году мы получили первый патент на технологию, используемую в ОС, а сейчас наша команда имеет уже 90 патентов. По большому счету то, что получилось в финале, приобрело новые черты и не похоже на то, как это виделось нам в начале пути.
Залог успеха разработки — предвидение проблем будущего
Пожалуй, самое сложное было доказать жизнеспособность нашей идеи. Повторюсь, в нее верили далеко не все даже внутри «Лаборатории». Наверное, эта проблема актуальна для всех новых разработок: есть некая идея, в которую верит небольшая группа единомышленников. Чтобы добиться реальных результатов, нужно предпринять максимум усилий, чтобы идея стала понятна для широкого круга людей. С этим было сложно, потому что 20 лет назад мало кто видел, насколько это все будет нужно сегодня.
Концепция вроде бы была на виду — предоставить доверенную среду для исполнения приложений, чтобы конечный пользователь мог доверять системе в целом. Но ценность такой среды была достаточно призрачной. Это сейчас доверие требуется в широком диапазоне решений и разработок. А тогда для того, чтобы начать работать над системой и доказать перспективность этой работы, надо было обладать чутьем. Для разработки любого прорывного продукта требуется время, а это значит, что он может родиться только в тот момент, когда его значимость очевидна далеко не всем. В противном случае — вы опоздали. Тут уже не над идеей надо размышлять, а конкурировать с другими продуктами.
И вот сейчас, когда информационные технологии можно встретить практически во всех сферах человеческой жизни, начиная с умных бытовых приборов и заканчивая инфраструктурами индустриальных гигантов, значимость безопасности и потребности в доверенной основе для любых применений технологий стала очевидной. Может быть, в промышленности — несколько в большей мере, но в ближайшем времени это станет очевидно и домашним пользователям.
Эволюция команды
Интересно посмотреть и на то, как развивалась команда разработки системы. Начиналось все с узкого кружка единомышленников, которые обсуждали теоретическую возможность разработки. В первое время никто не посвящал этому все рабочее время — в свободные минуты мы что-то прикидывали, размышляли, набрасывали схемы.
Когда стало очевидно, что системе — быть, появилась необходимость в людях, у которых разработка ОС была бы прописана в должностных обязанностях. Но в компании не было спецов, которые имели бы опыт такой разработки. Хотя, конечно, люди с опытом низкоуровневого программирования были — все-таки в защитных решениях без этого никак: невозможно создать инструмент для перехвата системных событий без написания драйверов. Впрочем, основные сложности представляло собой не написание драйверов, а создание ядра системы, которое бы задавало правила работы для этих самых драйверов. И вот именно таких экспертов пришлось искать. Но по факту основная сложность заключалась даже не в самом поиске, а в формировании команды, члены которой, с одной стороны, имели бы нужный нам опыт, а с другой — разделяли наши идеи и устремления.
Так постепенно нашли сначала одного человека, имевшего практический опыт разработки ОС. Это был Павел Дякин, впоследствии возглавивший отдел разработки безопасной платформы. Вместе с ним мы разработали новые подходы, методологию. Потом сформировали группу. И так шаг за шагом. Требовались специалисты по абсолютно разным языкам. Для написания микроядра нужны спецы по си и ассемблеру, для приложений — по C++ или, например, Perl и PHP. Мы используем и Haskell. В процессе работы родились и собственные языки — например, язык описания политик и язык описания компонентов. В рамках этого проекта мы взяли и первого в «Лаборатории» «чистого» математика — Стаса Моисеева.
Со временем команда трансформировалась. Дело в том, что разработка новых идей требует от человека навыков исследователя. Но когда продукт обретает зрелость, выходит на рынок, от команды требуется другое: предсказуемость результата и способность поддерживать и дорабатывать существующее решение. Впрочем, и исследователи без дела не сидят — специалисты из департамента Future Technologies продолжают трудиться над развитием продукта.
А в целом команда, занимающаяся KasperskyOS, разрослась до более чем трехсот человек — там не только отдельные группы разработчиков ядра, драйверов, приложений и сервисов, но и руководители проектов, люди, ответственные за взаимодействие с партнерами, менеджеры и так далее.
Дальнейшее развитие
Сейчас над проектом работает множество разных групп, и у каждой есть свое видение развития. И это прямо праздник какой-то! Разработанная базовая идея позволяет найти KasperskyOS кучу применений, развивать одновременно несколько направлений.
Например, есть идея развития концепции кибериммунитета, которая еще больше приблизит нас к оригинальному природному понятию иммунитета, то есть способности живых организмов не просто противостоять внешним угрозам, но и реагировать и изменяться в зависимости от окружающей среды. Мы пробуем заложить похожие алгоритмы и в нашу OS. Чтобы, в случае если один из доменов безопасности переставал работать корректно, согласно разработанным для него правилам, система могла проанализировать причину и адекватно прореагировать на изменившуюся ситуацию. Если нам удастся реализовать такие механизмы в KasperskyOS, то информационные системы, построенные на ее базе, приобретут принципиально новые качества.
Плюс у нас есть много нереализованных в силу разных причин идей (хотя они до сих пор кажутся нам небезынтересными). Мне, например, очень нравится идея использования KasperskyOS в высокопроизводительных сетевых устройствах. Их архитектура такова, что все их высокопроизводительные операции происходят на достаточно несложном, но зато очень быстром железе. И для них, по сути, операционная система и не нужна. Но внутри того же устройства работает полноценный компьютер с системой, которая нужна только для конфигурирования, логирования, вспомогательных операций. И основные требования по информационной безопасности предъявляются именно к этой системе. То есть мы имеем своеобразный симбиоз — специализированный процессор, который выполняет какую-то работу в интересах определенного индустриального направления, а рядом информационный или конфигурационный чип, который служит для связи с внешним миром. И я уверен, что использование KasperskyOS для работы вот такой коммуникационной части — крайне перспективно.
Но сейчас наш приоритет в том, чтобы донести до разработчиков, до сообщества программистов понимание того, что если им необходимо реализовывать функции безопасности, то на базе KasperskyOS это можно делать дешевле и надежнее, чем на других операционных системах. Платформа подходит для создания бизнес-приложений и информационных систем самой разной направленности: разработок для видеоконференций, систем документооборота, индустриальных систем для обеспечения безопасности технологических линий и других. И мы готовы взаимодействовать с партнерами, которые могли бы достигать своих собственных целей благодаря нашим технологиям: помогать, обучать, реализовывать какие-то компоненты своими силами или совместно.
Автор:
4spirit
