На промышленных объектах ключевыми системами информационной инфраструктуры являются автоматизированные системы управления технологическими процессами (АСУТП), а также средства противоаварийной защиты (ПАЗ). От корректной и стабильной работы этих систем зависит безопасность всего объекта.
Для АСУТП характерна ярко выраженная программная и аппаратная неоднородность. В типовую технологическую сеть предприятия, как правило, входят серверы SCADA под управлением Windows либо Linux, серверы СУБД (SQL Server либо Oracle), множество программируемых логических контроллеров (PLC) различных производителей, панели оператора (HMI), интеллектуальные датчики и канал связи с системами бизнес-уровня ERP. При этом, согласно результатам последних исследований DHS, в среднем технологическая сеть имеет 11 (!) точек прямого подключения к корпоративной сети.
Точка доверия
В настоящее время назрела необходимость в создании решений, способных обеспечить надежную защиту и критически важных промышленных объектов, и прочих объектов и организаций, чувствительных к проникновению и утечке информации. Однако как бы хорошо ни работали такие решения, использование в АСУТП уязвимых ОС и ПО не позволит производителям средств защиты гарантировать безопасность системы. А в случае с критическими объектами такие гарантии необходимы.
Рассчитывать на то, что все разработчики АСУТП срочно займутся тотальной проверкой и обновлением всего используемого ими ПО, а руководители предприятий оперативно обновят уже установленные у них решения, не приходится. А если учесть, что жизненный цикл таких систем исчисляется десятилетиями, то станет очевидно, что по эволюционному сценарию внедрение защищенных АСУТП потребует значительного количества времени.
Однако глобальное решение проблемы уязвимости – не единственно возможное решение, способное обеспечить безопасность работы промышленных объектов.
В чем опасность наличия уязвимого ПО? Уязвимости – это бреши, которые могут быть использованы для проникновения вредоносных программ. Любой компонент АСУТП может быть заражен. А зараженный компонент может осуществлять в технологической сети вредоносные действия, ведущие к катастрофе, и при этом дезинформировать оператора.
В сложившейся ситуации оператор критически важной системы вынужден управлять техпроцессами, не имея никаких гарантий того, что информация, на основе которой он принимает решения, верна. По сути это одна из ключевых проблем безопасности системы – ведь цена ошибки на такого рода объектах очень высока.
Для безопасной работы промышленного объекта оператору критически важно получать достоверную информацию и управлять производством, исходя из этой информации. Это позволит избежать ошибок управления и поможет при необходимости вовремя остановить производство, не допустив аварии.
В настоящее время не существует ОС и ПО, которые могли бы быть применены в промышленных средах и результатам работы которых мы могли бы полностью доверять. И это не оставило нам иного пути, кроме как приступить к самостоятельной разработке таких средств.
Базовым средством обеспечения безопасности является операционная система. Мы считаем, что для контроля информации, которая циркулирует в промышленной сети, в первую очередь необходимо использовать саму операционную систему. Это даст гарантию, что информация корректна, достоверна и не содержит вредоносной составляющей.
Безопасная OС
Каким требованиям должна соответствовать максимально безопасная среда для контроля информационной инфраструктуры?
ОС не может быть основана на каком-то уже существующем программном коде, поэтому должна быть написана с нуля.
В целях гарантии безопасности она не должна содержать ошибок и уязвимостей в ядре, контролирующем остальные модули системы. Как следствие, ядро должно быть верифицировано средствами, не допускающими существования уязвимостей и кода двойного назначения.
По той же причине ядро должно содержать критический минимум кода, а значит, максимальное возможное количество кода, включая драйверы, должно контролироваться ядром и исполняться с низким уровнем привилегий.
Наконец, в такой среде должна присутствовать мощная и надежная система защиты, поддерживающая различные модели безопасности.
В соответствии с этим мы создаем собственную операционную систему, основной особенностью которой является принципиальная невозможность выполнения в ней незаявленной функциональности.
Только на основе такой ОС можно построить решение, позволяющее оператору не только видеть то, что реально происходит с производством, но и управлять им. Вне зависимости от производителей конкретных ОС, СУБД, SCADA и PLC, вне зависимости от степени их защищенности или наличия в них уязвимостей. Более того – вне зависимости от степени их зараженности.
Фактически речь идет об интеллектуальной системе противоаварийной защиты нового поколения. Системе защиты, учитывающей весь комплекс показателей предприятия сразу. Системе защиты, не позволяющей привести к аварии ни в результате неправильных действий оператора, ни в результате ошибок в ПО АСУТП, ни в результате кибератак. Помимо прочего, такая система сможет дополнить традиционные средства ПАЗ, что позволит отслеживать более сложные и комплексные сценарии происходящего.
Такое решение должно встраиваться в уже существующие АСУТП с целью их защиты и обеспечения достоверного мониторинга или учитываться при проектировании новых АСУТП – и в том, и в другом случае обеспечивая применение современных принципов безопасности.
Заключение
Мир изменился. Государства активно осваивают кибероружие, и это требует наличия адекватных средств защиты. Несмотря на то что ключевые системы информационной инфраструктуры имеют исключительную важность, средств, способных обеспечить их гарантированную защиту, в настоящее время нет.
На основе существующих ОС создать новые, современные и реально работающие средства защиты КСИИ невозможно. Создать новую ОС для всех компонентов АСУТП – задача очень сложная, ее решение требует времени. А проблему безопасности промышленных объектов надо решать уже сейчас.
Поэтому надо находить ключевые проблемы информационной безопасности и в первую очередь устранять именно их. Одна из таких проблем состоит в том, что системы информационной безопасности промышленных объектов опираются на недоверенные источники информации. Пока в технологической сети не появится компонент, которому оператор или некоторый контролирующий программный комплекс могли бы доверять, говорить о возможности построения системы безопасности не представляется возможным. Необходимо создать такую «доверенную базу», на основе которой можно строить систему обеспечения безопасности более высокого уровня. Такая «доверенная база» требует как минимум наличия доверенной ОС.
Мы создаем ОС, на которой будут работать компоненты системы безопасности, обеспечивающие доверенной информацией все составляющие АСУТП. В основу ОС мы заложили ряд фундаментальных принципов, соблюдение которых позволит гарантировать, что она в любой момент времени будет функционировать именно так, как было задумано разработчиком, и функционировать по-другому не может. Архитектурно операционная система построена таким образом, что даже взлом любых ее компонентов или приложений не позволит злоумышленнику получить контроль над нею или запустить вредоносный код. Этот подход позволяет нам считать такую ОС доверенной и использовать ее в качестве доверенного источника информации, который может являться базисом для построения системы защиты более высокого уровня.
Касперский – один из лучших антивирусов в борьбе с вредоносными программами, однако иногда возникают проблемы, из-за которых Касперский не устанавливается на операционную систему Windows 7 или 8.
Особенности операционной системы Касперского
.
Фирменное микроядро и независимый механизм безопасности.
Операционная система Касперского основана на надежном микроядре, которое реализует единственный способ общения. Это легкое микроядро может быть применено на различных платформах. В то же время механизм безопасности позволяет заменить микроядро другим ядром, если это необходимо.
Различные политики по обеспечению соответствий.
Независимый механизм безопасности может обеспечить соблюдение политики, которая наилучшим образом соответствует определенным целям безопасности. Политика безопасности также может быть настроена индивидуально для каждого приложения в системе.
Разделение домена безопасности.
Операционная система Касперского эффективно разделяет домены безопасности - ограничивается группами приложений с ограниченным влияния друг на друга. Это не исключает возможности меж доменным связей, если это явно разрешено.
Разделение функций приложения из функций безопасности.
Архитектура безопасности предназначена для разделения функций безопасности от бизнес-логики приложения, что делает обе настройки политик безопасности и разработки приложений проще и быстрее.
Обязательное идентификация и маркировка.
Все приложения в операционной системе Касперского сопровождаются их конфигурацией безопасности. Никто не может установить приложение, не установив его соответствующей конфигурации поведения. Аппаратные средства и ресурсам прикладного уровня (файлы, базы данных, сетевые порты и т.д.) помечены соответствующими атрибутами безопасности. Невозможно получить доступ к ресурсу, который не имеет метки безопасности.
Совместимость с многоуровневостью.
В то время как система поддерживается в основном POSIX - совместимыми, использование нативного API дополнительно гарантирует безопасное поведение приложений. Разработчик может выбрать, как сохранить надлежащий баланс между совместимостью программного кода и безопасностью.
Области использования Kaspersky OS
Операционная система Касперского помогает уменьшить кибер-риски, связанные с применением телекоммуникационного оборудования, в том числе дистанционных атак на аппаратные средства с целью изменить его конфигурацию или изменить его встроенное программное обеспечение (прошивку). И использования бэкдор или известных уязвимостей для перехвата трафика чтобы получить контроль над оборудованием. А также для удовлетворения конкретных потребностей таких устройств, как:
1. необходимость работать автономно без обслуживания или обновления программного обеспечения в течение длительных периодов времени;
2. собственное встроенного программного обеспечения;
3. постоянное прямое подключение к Интернету и так далее. И, наконец, свести к минимуму время, необходимое для разработки средств защиты.
Операционная система Касперского была построена для парадигмы безопасности в виду, и этот подход идеально подходит для современных и будущих связанных транспортных средств. В этом отношении Операционная система Касперского по может автомобильной промышленности и части производителей проектирующих и разрабатывающих подключаемых электронных блоков. Операционная система Касперского, защищенная операционная система, основанная на архитектуре, которая предназначена для обеспечения программного обеспечения надежностью, в том числе не защищенных приложений. Кроме того, Операционная система Касперского обеспечивает защиту в случае случайных ошибок программного обеспечения, которое помогает поддерживать заданный уровень безопасности.
Машина 2 машины и Интернет вещей
.
Основной опорой встроенной безопасности для IoT является собственной политики безопасности. В связи с разнообразием применений IoT, механизмы обеспечения политики безопасности должны быть:
1. адаптироваться, насколько это возможно;
2. определение политики должны быть ясными и простыми, но достаточно выразительным, чтобы правила были без недостатков и упущений;
3. механизмы безопасности не должны ослабить существующие меры безопасности, затруднять функционирование системы или значительно уменьшать систему, приложения и производительность устройства. Операционная система Касперского помогает решить проблему кибер безопасности для Интернет вещей, в то же время свести к минимуму время, необходимое для разработки функций безопасности.
Промышленная среда.
Операционная система Касперского помогает поставщикам промышленной автоматизации добавить возможность кибер-безопасности, к их новому подключаемому к Интернету оборудованию, сохраняя при этом безопасность, качество, надежность, производительность, время выхода на рынок и открытость программного обеспечения. Операционная система Касперского также помогает снизить риски, связанные с использованием программного обеспечения 3-го уровня, которые потенциально может иметь уязвимости. Мы приносим кибер-безопасности в безопасном промышленном мире автоматизации.
Вижу следующее сообщение: "Требуется установить перед началом работы в системе. Программное обеспечение для работы с интернет-банком". Для этого, скачиваю
Операционная система Касперского для интернет вещей (pdf 94Кб)
В «Лаборатории Касперского» уже четыре года идет работа над собственной защищенной операционной системой, однако знают о ней в основном профессионалы. Дело в том, что это не обычная ОС, и ее цель - защитить производственные процессы от хакерских атак. В этой статье мы расскажем о том, какие именно принципы безопасности лежат в основе KasperskyOS.
16 октября 2012 года Евгений Касперский, генеральный директор всем известной софтверной компании, рассуждал на страницах своего ЖЖ о будущем. Естественно, не о светлом и безоблачном (такие пассажи - дело политиков), а о жутком будущем, наполненном кибернетическими угрозами, которые обрушиваются не столько на мирных владельцев ПК, планшетов и смартфонов (основных клиентов его компании), сколько на информационные системы «заводов, газет, пароходов», официально именуемые ICS - Industrial Control Systems.
Системы эти управляют технологическими процессами и базируются на программном обеспечении, которое зачастую, прекрасно выполняя свою основную функцию, нисколько не заботится об информационной безопасности этого самого процесса. Возможно, при разработке такого ПО вопросы кибербезопасности и не были приоритетными, просто теперь на них перестали смотреть как на угрозы, высосанные из пальца.
Проекты, подобные первопроходцу Stuxnet, успешные проникновения в системы авионики лайнеров через мультимедийные системы пассажирских кресел и публичные бортовые сети + Wi-Fi - далеко не живописание апокалиптического будущего, а самая что ни на есть реальность.
Касперский, однако, не только давал мрачные прогнозы. В том посте он, по сути, описывал принципы, которые были заложены в основу новой разработки - операционной системы, архитектурно ориентированной на системное решение проблемы киберзащиты технологических процессов.
То был далекий 2012 год. Что стало с этой задумкой через три года? Из намерений и описаний принципов операционная система «Лаборатории Касперского» превратилась в реальность - KasperskyOS. Вернее, в комплексное решение Kaspersky Security System, встроенное «из коробки» в KasperskyOS и доступное для встраивания в операционные системы других производителей, а также реализованное в защищенном гипервизоре.
Теперь это решение, вдоволь обкатанное на многочисленных конференциях и форумах по кибербезопасности, шагнуло из лабораторных стен в реальные проекты.
Тот пост из ЖЖ Касперского был фактически публичным представлением проекта «11.11», который ЛК инициировала, судя по всему, еще в ноябре 2011 года («ноябрь 2011-го» - это и есть «11.11»), то есть за год до официального анонса. Оно и правильно. Выходить на публику стоит не с мифологией, а с подтверждением работоспособности идеи или как минимум с четким пониманием того, как она должна работать.
][ после анонса проекта «11.11» одним из первых пообщался с его идеологом - Андреем Петровичем Духваловым, который ныне возглавляет управление перспективных технологий «Лаборатории Касперского». В этой беседе обсуждались принципы, положенные в основу проекта «ОС Касперского», и, что немаловажно, были получены ответы на вопросы «зачем?» и «почему?».
Зачем пытаться защитить ICS-системы с помощью системного ПО, если достаточно поместить их под колпак контролируемой зоны, обрубив возможные каналы несанкционированного доступа? Зачем начинать делать собственную операционную систему, если сейчас полно готовых решений? Почему «Лаборатории Касперского» стала интересна тема операционных систем, пусть даже и в узкой области применения?
На все эти вопросы были даны ответы, которые спустя три года развития проекта Kaspersky Security System все еще актуальны, поскольку определяют парадигму проекта. Сводится она к следующему. Все современные операционные системы в той или иной степени уязвимы. И связано такое положение дел не с кривыми руками их разработчиков, а с тем фактом, что проектировались они без четкого представления о безопасности и о комплексной цели, которую должна решать подсистема безопасности ОС.
Поскольку операционные системы совершенствуются одновременно с железом, они, независимо от изначально заложенной архитектуры, развиваются по принципу помещичьей усадьбы: главное здание со временем обрастает многочисленными флигелями, пристройками, чердаками и подвалами. Растущая сложность организации с точки зрения безопасности несет две проблемы: внедряемые механизмы безопасности, как встраиваемые, так и «навешиваемые», просто не в состоянии охватить целиком все «закоулки» «ОСобняка». Отсюда и появление разнообразных бэкдоров.
Но это проблема принципиальной реализуемости механизмов безопасности. Сложная организация операционных систем существенно затрудняет как анализ потенциальной уязвимости компонентов, так и эффективность применяемых механизмов безопасности. Будь все иначе, та же «Лаборатория Касперского» с ее антивирусными решениями просто осталась бы не у дел.
Вывод из всего этого достаточно банален. Уж если что-то делать в области защищенных ОС, то делать это с нуля, рассматривая проблемы безопасности в качестве основополагающих требований и учитывая их влияние на всех этапах проектирования системы. Именно поэтому главный российский борец с вирусами и замахнулся на разработку собственной операционной системы. Но, понимая всю сложность создания новой системы общего назначения вроде Windows или UNIX, решил начать со специфической. Удачно выбрана и область - промышленные информационные системы до сих пор не были избалованы надежной защитой. С одной стороны, это важное дело, с другой - возможность получить бесценный опыт, который, глядишь, можно будет распространить и на другие области применения операционных систем.
Решиться на разработку собственной ОС, в которой механизмы безопасности станут фундаментом, можно, только основательно изучив, что же вообще в этой области наработано. Команда KasperskyOS так и поступила. В первую очередь взгляд был брошен на материалы «Радужной серии» (Rainbow Series) - набора стандартов информационной безопасности, разноцветные тома которых были изначально опубликованы в Министерстве обороны США, а затем в Центре национальной компьютерной безопасности США.
Стандарты эти охватывают самые разные аспекты информационной безопасности, от терминологического базиса до руководств пользователей и сотрудников службы безопасности. Важнейшая часть «Радужной серии» - это «Оранжевая книга», где задаются критерии определения безопасности компьютерных систем. Ее ратифицированным в международном масштабе аналогом является стандарт ISO/IEC 15408.
Главный постулат «Оранжевой книги» заключается в том, что безопасность компьютерных систем никогда не была и никогда не будет идеальной. Любая эксплуатируемая или вновь проектируемая система безопасна ровно настолько, насколько мы доверяем ей решение этого важного вопроса. А значит, правильнее говорить не о безопасных, а о доверенных системах.
Именно поэтому совокупность механизмов, которые в информационной системе реализуют ту или иную политику безопасности и определяют степень доверия к этой системе, в «Оранжевой книге» именуют ДВБ - доверенная вычислительная база (Trusted Computer Base).
Какую функцию в информационной системе выполняет ДВБ? Единственно верную: контролирует любые взаимодействия компонентов информационной системы между собой, с системными функциями и аппаратной базой системы. Ни одно обращение любого компонента системы не должно остаться без пристальной проверки ДВБ с точки зрения поддерживаемого ею механизма (или механизмов) безопасности. В «Оранжевой книге» эту функцию ДВБ именуют мониторингом обращений.
Мониторинг обращений фактически означает, что компоненты информационной системы напрямую ни между собой, ни с ядром системы, ни с аппаратурой не взаимодействуют. Все происходит по указанию ДВБ. Разрешила ДВБ - вперед! Запретила - взаимодействию не быть. Выходит, ДВБ - это такая штука, которая позволяет изолировать друг от друга компоненты информационной системы. Старый как мир принцип властвования - через разделение.
«Доверенная» в аббревиатуре ДВБ означает, что мы вынуждены доверять ей. А сделать это проще, если ДВБ прозрачна как с точки зрения своей организации, так и с точки зрения способов проверки правильности ее работы. Добиться такой прозрачности можно разными способами. Самые действенные из них - это простота и компактность организации ДВБ, а также возможность использовать для ее проверки некоторый набор формальных методов. Он позволит дать однозначный ответ о том, насколько ДВБ (ну и информационная система на ее основе) соответствует своему предназначению (это называется «валидация») и насколько полно принципы, заложенные в основу при проектировании, были воплощены на этапах разработки (верификация).
Теперь-то и становится ясно, что команда проекта KasperskyOS занялась созданием собственного варианта этой самой ДВБ. Ну, почти собственного. Идеологическим предком ДВБ «Лаборатории Касперского» стал проект FLASK (Flux Advanced Security Kernel) - архитектурное решение подсистемы безопасности в ОС, которое позволяет гибко внедрять и настраивать политики безопасности под конкретное применение.
К слову сказать, FLASK - это предок не только KasperskyOS, но и таких реализаций подсистем безопасности, как SELinux и TrustedBSD. Модель системы безопасности на основе модулей LSM, которую используют в современных проектах на основе GNU/Linux, - это тоже вариация на тему FLASK. Вот только в системах на Linux и BSD такой монитор обращений - это все же внешний довесок. В проекте же KasperskyOS - это основа системы.
Давай подробнее глянем на архитектуру 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.
Помещенный в код сущности объектный код интерфейса обеспечивает формирование функций 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-сообщение адресату. Отрицательный вердикт приведет к задержанию и уничтожению послания. Это метод, известный со времен царской охранки с ее перлюстрацией всей почтовой переписки. Простой, но действенный!
Разобравшись с тем, как устроены программы, которые выполняются под управлением KasperskyOS, можно взглянуть и на самого «перлюстратора» - подсистему KSS.
Состоит Kaspersky Security System из трех частей: модуля Security Runtime, интегрированного с механизмом IPC, модуля Security Server, который принимает решение о вердикте в соответствии с той или иной политикой безопасности, и структуры Decision Cache, которая хранит вердикты по отдельным политикам безопасности для повышения производительности перлюстрации IPC-сообщений.
Функции каждого из этих модулей в составе KSS вполне предсказуемы. Security Runtime сидит на перехвате и десериализации IPC-сообщений, пролетающих туда-сюда по многочисленным IPC-каналам взаимодействующих пар сущностей. Извлеченные при десериализации параметры функций или результаты их выполнения Security Runtime передает в Security Server. Последний представляет собой набор политик безопасности, специфичных для поддерживаемой системы.
Например, для офисной ИС с такими сетевыми сервисами, как почта, веб, базы данных и файловый обмен, Security Server может иметь реализации дискреционной, мандатной и ролевой политик безопасности. Тогда к каждой из них будет привязан соответствующий политике контекст безопасности. В случае же системы, управляющей технологическим процессом (например, роботизированным станком или механизмами авионики самолета), политика безопасности будет определять легитимную для этого технологического процесса последовательность функций, не приводящую к его краху или необычным результатам. Описание политик безопасности для подобных случаев выполняется с помощью удобного для валидации формального аппарата, например в терминах темпоральных логик.
Но каким образом 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.
Крупные предприятия испытывают серьезные сложности с обновлением своих систем.
Недавняя волна атак с использованием вымогательского ПО 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 в апреле текущего года.
