Операционная система не соответствует. Верифицируй это

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

Предыдущая версия Касперского неправильно удалена

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

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

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

Скачали? Отлично! Запустите программу, и она по умолчанию автоматически и быстро определит, какая именно версия антивирусного ПО была на вашем компьютере установлена ранее. Вам же останется лишь нажать на кнопку «Удалить» - и проблема решена.

Внимание! Возможно, что в обычном режиме утилита работать не захочет либо не сумеет произвести очистку системы. В таком случае вам следует запустить программу в безопасном режиме нажав клавишу F8 при загрузке компьютера.

В системе уже присутствует антивирус

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

Исправить такую ошибку совсем просто: удалите со своего компьютера все другие антивирусные, а также защитные программы, которые тоже любят вступать в конфликт с антивирусами. После этого можете запускать Касперского.

Компьютер не был перезагружен

Если Касперский не работает после установки , то, возможно, вы просто-напросто забыли перезагрузить комп. Это обязательно нужно делать не только после инсталляции программы, но и после очистки и работы утилиты по удалению антивируса. В этом случае решение совсем простое: нажмите на кнопку «Reset» на системнике или перезагрузите компьютерное устройство другим соответствующим способом.

Проблема в инсталляторе

Бывает, что в инсталляторе (файле-установщике) возникает ошибка, которая и приводит к отказу Касперского устанавливаться на ПК. Быть может, установщик был скачан с некорректного источника, а следовательно, неизвестно, является ли он рабочим. Вполне вероятно, что он подпорчен вирусами. Потому скачивайте антивирус только с официального сайта Касперского: http://www.kaspersky.ru/ - и проблем не будет.

Несовместимость антивируса с системой

Такая ошибка, как несовместимость антивируса с системой , появляется тогда, когда совсем новый Касперский устанавливается на совсем старую систему. Или же наоборот: совсем старая версия антивируса ставится на новую систему. Чтоб избежать такого конфликта, обязательно изучайте системные требования, предъявляемые установщиком.

Еще одно решение вопроса

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

1) создайте в ОС Windows еще одну учетную запись,

2) перезагрузите компьютер,

4) установите антивирусник Касперского.

Надо сказать, что это частенько помогает, и не только с антивирусным ПО, но и со многими другими программными продуктами.

Последнее решение проблемы

Вы честно старались следовать инструкциям и перепробовали все возможное для того, чтобы установить Касперского? Обидно и досадно, но пресловутый антивирус как будто специально издевается над вами и отказывается работать? Что ж, успокойтесь и прибегните к последнему решению этой проблемы: выберите другой антивирус! Удачи!

Касперский – один из лучших антивирусов в борьбе с вредоносными программами, однако иногда возникают проблемы, из-за которых Касперский не устанавливается на операционную систему Windows 7 или 8.

Основные причины, приводящие к невозможности установить Касперский на Windows 7/8, и способы их решения

1. Одна из таких причин — наличие уже установленной другой антивирусной программы. Следует понять, что все полноценные антивирусы, за исключением некоторых, конфликтуют друг с другом. Поэтому не пытайтесь установить две антивирусные программы на одну версию Windows. При удалении Лаборатории Касперского с помощью стандартных средств – Установка/Удаление программ) могут возникнуть проблемы, из-за которых антивирус удален или будет удален частично. Для полноценного удаления Лаборатории используйте утилиту kavremover. Ссылка на скачивание с официального сайта: http://support.kaspersky.com/downloads/utils/kavremover.exe
2. Вторая причина, относящаяся только к Windows 8.1, – невозможность установить Касперский с помощью старой версии инсталлятора. В таком случаи попробуйте скачать с официального сайта новую версию установщика с уже интегрированным патчем под вашу версию. Дело в том, что Windows 8.1. несколько отличается от предыдущих версий операционной системы, а для правильной установки Касперского требует патч.
3. И, пожалуй, самая распространенная и опасная причина, приводящая к невозможности установить антивирус, — контроль системы вирусом SalityNAU , который изменяет системный файл host. Бороться с ним достаточно трудно, так как он берет под контроль всю систему, блокируя установку любой антивирусной программы, а также запрещая доступ на официальные сайты. В некоторых случаях может заблокировать доступ к , командной строке и редактору реестра, запрещает доступ к соц-сетям, такие как «Вконтакте», «Одноклассники» и т.д., не разрешает скачивать файлы более 2мб, заражает exe файлы, что не дает им запуститься.

Способы борьбы с SalityNAU в 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 и доступное для встраивания в операционные системы других производителей, а также реализованное в защищенном гипервизоре.

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

INFO

Оранжевое небо, оранжевая книга

Тот пост из ЖЖ Касперского был фактически публичным представлением проекта «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

Помещенный в код сущности объектный код интерфейса обеспечивает формирование функций 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

Но каким образом 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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