Отсутствует в списке разрешенных программ. Terminal Services RemoteApp (удаленные приложения)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Интро

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

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

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

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

То был далекий 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? Для софтописателей разработчики 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-интерфейсов всех функций, входящих в состав компонента.

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

Найти же адресата для него - конкретный Dispatch-интерфейс конкретной функции (отдельной или в составе компонента) - можно по его уникальному идентификатору Runtime Interface ID (RIID). Он генерируется на этапе компиляции EDL-описания сущности. Такая вложенность строго типизированных спецификаций позволяет разработчику создать сколь угодно сложную программу, каждая функция которой будет снабжена собственным Proxy- или Dispatch-интерфейсом.

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

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

При такой организации IPC-взаимодействия каждая сущность имеет представление только о выделенном ей хендле. О паре хендлов отправителя и получателя знает только механизм IPC. Потому-то процедура формирования IPC-канала обмена сообщениями и именуется «спариванием хендлов» (handles pairing). После такого спаривания вклиниться в диалог сущностей не может никто посторонний. 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, который способен поддерживать множество политик безопасности, определяет, какую из них применить для валидации того или иного IPC-сообщения? Чтобы связать конкретные действия сущностей с конкретными политиками безопасности, командой KasperskyOS был разработан декларативный язык конфигураций безопасности CFG.

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

Такой маппинг обеспечивает Security Server точным указанием того, какую политику применять для вынесения вердикта в каждом конкретном случае. Отсутствие структуры Gate у сущности делает ее изгоем KasperskyOS. По умолчанию KSS к ней применяет политику default deny.

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

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

Ну и наконец, KSS - та самая доверенная вычислительная база - монитор обращений, скрупулезно проверяющий все действия приложений на соответствие политикам безопасности, с которыми они связаны. Ее ядро, Security Server, получает точные указания о том, какую из них использовать в конкретном случае на основе языка описания конфигураций CFG. Все это лишь верхушка айсберга KasperskyOS.

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

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

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

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

Заключение

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

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

Касперский: Почему Windows XP используется до сих пор?

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

Недавняя волна атак с использованием вымогательского ПО WannaCry вызвала у главы компании «Лаборатория Касперского» Евгения Касперского один вопрос – почему люди до сих пор используют устаревшую, неподдерживаемую ОС Windows XP?

«Не понимаю, почему они до сих пор используют Windows XP? Если у них сотни тысяч таких компьютеров, то справиться со всем этим (атаками WannaCry) весьма дорого», - заявил Касперский журналистам ZDNet на конференции CeBIT Australia в Сиднее.

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

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

Напомним, с целью остановить распространение вымогательского ПО WannaCry компания Microsoft обновление для Windows XP, поддержка которой официально закончилась 8 апреля 2014 года. Недавно также был второй патч для уязвимости, позволяющей атакующему получить контроль над системой жертвы. Тем не менее, по последним данным, 98% инфицированных WannaCry компьютеров под управлением Windows 7.

WannaCry – вымогательское ПО, используемое в беспрецедентной по своим масштабам кибератаке, имевшей место 12 мая 2017 года. Вредонос распространяется подобно сетевому червю с помощью эксплоита для уязвимости в SMB EternalBlue и бэкдора DoublePulsar. Данные инструменты были предположительно похищены у Агентства национальной безопасности США и хакерской группировкой The Shadow Brokers в апреле текущего года.