«Тонкий клиент» — дословный перевод англоязычного термина thin client. Часто под этим подразумевается маломощный компьютер под управлением функционально ограниченной ОС, работающий в сетевой терминальной или клиент-серверной архитектуре. Существует несколько целей применения тонкого клиента вместо полноценного компьютера на рабочем месте, среди них — повышение уровня информационной безопасности.
Kaspersky Thin Client (KTC) — тонкий клиент «Лаборатории Касперского» — создан в соответствии с кибериммунной методологией, и цель этой статьи — ответить на вопрос, как именно реализуется кибериммунитет KTC, за счет чего обеспечивается его защита как от известных, так и от неизвестных угроз.
Чтобы ответить на вопрос «Как достигается кибериммунность Kaspersky Thin Client?» и оценить преимущества, которыми она обладает, необходимо понимание того, что такое кибериммунитет и зачем он нужен. В этом разделе мы лишь тезисно коснемся этих вопросов, а более подробно они освещаются в многосерийной статье про кибериммунный подход к проектированию.
Современный кибермир характеризуется взаимным проникновением (конвергенцией) всех видов операционных (OT) и информационных (IT) технологий. «Умными» стали не только автомобили, самолеты, системы транспорта, промышленности и управления, но и дома людей. Для конвергентных решений характерны сложность, гетерогенность компонентов, высокая связность, глобальная доступность, высокая скорость и большие объемы передачи данных, а также большой объем программного кода, в том числе заимствованного.
В таких условиях становится недостаточным использование только наложенных мер для защиты изначально небезопасных киберсистем. Альтернативный подход — создание конструктивно безопасных (Secure by Design) систем — еще не стал повсеместным по двум основным причинам. Во-первых, разработка конструктивно безопасной, в отличие от «просто работающей» системы, требует компетенций в области кибербезопасности, а подходящие специалисты дороги и немногочисленны. Во-вторых, подход Secure by Design пока еще слабо поддержан методически.
Кибериммунный подход предлагает методологию разработки конструктивно безопасной киберсистемы, объединяющую описание процесса ее разработки и архитектурные требования к ней. Целью кибериммунного подхода является создание кибериммунного программного продукта, заявленные ценности которого остаются в безопасности даже под атакой. В целом, кибериммунный подход помогает формулировать задание на безопасность и строить соответствующую архитектуру с использованием архитектурных шаблонов безопасности, что обеспечивает доказуемо высокое качество свойств безопасности киберсистемы.
В этом разделе мы описываем верхнеуровневую архитектуру и базовые функции KTC, как достигается его кибериммунитет, какой вклад в это вносит операционная система KasperskyOS.
На следующем рисунке приведена схема взаимодействия Kaspersky Thin Client с платформами виртуализации:
Типовая схема работы Kaspersky Thin Client (см. рис ниже) такова:
Практический смысл кибериммунного продукта состоит в том, чтобы при любых обстоятельствах обеспечить сохранность прикладных ценностей, которые так или иначе связанны с этим продуктом. Поэтому мы описали ценности KTC, а также нежелательные события в их отношении:
На основе этого описания ценностей с точки зрения потребителя, в соответствии с положениями кибериммунной методологии, техническая команда выработала следующие цели безопасности, фактически являющиеся формализованным «контрактом на безопасность» KTC:
Были определены также ограничения на предпринимаемые меры защиты (априори принимаемые предположения безопасности), которые также являются частью «контракта на безопасность»:
Какова стратегия технического обеспечения достижения сформированных целей безопасности для KTC с учетом заданных ограничений? Для ее определения обобщим верхнеуровневую архитектуру тонкого клиента, чтобы визуализировать ее проблемные места с точки зрения сформулированных целей безопасности.
Сопоставив эту схему с целями безопасности КТС, мы видим компоненты, которые напрямую влияют на них:
Про библиотеку, имплементирующую протокол RDP, необходимо сделать несколько замечаний. Ее влияние на цели безопасности является прямым — в частности, уязвимости в ней могут быть эксплуатированы как для нарушения целостности и конфиденциальности принимаемых и передаваемых данных, так и для несанкционированного доступа к локальному хранилищу данных, в котором, среди прочего, хранится чувствительная ключевая информация — атрибуты доступа, сертификаты публичных ключей и т. д. С другой стороны, собственная «безопасная» реализация стандартной библиотеки нецелесообразна с любой точки зрения: коммерческой, сопровождения и поддержки, а также совместимости.
В соответствии с традиционным подходом можно было бы взять все известные уязвимости библиотеки RDP (на сегодняшний день их несколько десятков) и выработать ответные меры, предотвращающие угрозы. Однако кибериммунный подход нацелен не столько на защиту активов системы, уже попавших в опасное состояние, сколько на исключение возможности попадания активов в такие состояния. Это существенно, поскольку, с одной стороны, стандартная библиотека постоянно обновляется и в будущем в ней появятся новые уязвимости, а с другой — нет никаких гарантий, что даже в какой-то «замороженной» ее версии выявлены все уязвимости. Это очень большой объем нетривиального кода, и глубокая его верификация коммерчески нецелесообразна. В соответствии с кибериммунным подходом, потенциально опасный компонент должен быть изолирован от защищаемых ценностей. Именно так мы и сделали, «заслонив» стандартную библиотеку RDP собственным стандартным доверенным компонентом с достаточно простой функциональностью — TLS-терминатором, и ограничив политиками безопасности все взаимодействия между компонентами. Все сказанное про библиотеку реализации RDP справедливо и для библиотеки потокового аудио. Впрочем, как и для любой другой сторонней библиотеки, реализующей какой-либо типовой функционал.
Что касается локального хранения данных, подход к решению этой задачи сходен: во-первых, вместо одного общего хранилища используется несколько изолированных партиций, во-вторых, доступ к этим изолированным хранилищам разрешен только ограниченному набору специализированных доверенных компонентов, все коммуникации с которыми регулируются политиками безопасности.
Таким образом, техническая стратегия достижения целей безопасности выглядит следующим образом:
Достижение Цели 1
Цель: в рабочем режиме устройства обеспечена конфиденциальность и целостность данных, передаваемых между устройством и удалённым рабочим столом; между устройством и брокером соединений с удаленными рабочими столами; между устройством и KSC-сервером; между устройством и сервером логирования.
Стратегия: конфиденциальность и целостность данных обеспечиваются протоколом TLS, который имплементируется шаблонным доверенным компонентом. При работе в доверенном режиме к удаленным рабочим столам, брокерам подключений, серверу KSC и серверам логирования подключение возможно только с применением сертификатов публичных ключей, установленных Админом KSC.
Достижение Цели 2
Цель: обеспечение целостности хранимых на устройстве данных, полученных от пользователя, непосредственно работающего с устройством (сертификатов, реквизитов для подключения) и от KSC-сервера (конфигураций, сертификатов, лицензий, реквизитов для отключения от сервера KSC).
Стратегия: сертификаты публичных ключей, реквизиты для подключения к рабочим столам и серверу KSC, файлы конфигурации, лицензии принимаются только от доверенных компонентов и хранятся в отдельных изолированных хранилищах, доступ к каждому из которых есть только у специализированных доверенных компонентов.
Достижение Цели 3
Цель: обновление программного обеспечения тонкого клиента выполняется, только если подтверждена аутентичность и целостность обновления.
Стратегия: образ обновления подписывается цифровой подписью доверенной системой сборки поставщика, которая проверяется дважды — при загрузке на доверенный KSC-сервер и непосредственно перед применением на локальном устройстве, специализированным доверенным компонентом. Для локальной проверки подписи образа обновления перед его применением используется шаблон безопасности «Безопасное обновление», реализуемый с участием монитора безопасности KasperskyOS.
В итоге после модификации исходной верхнеуровневой архитектуры в соответствии с технической стратегией достижения целей безопасности, мы получили следующий ее вариант:
Следует напомнить, что все взаимодействия между системными процессами продукта под KasperskyOS определяются политикой архитектуры продукта, все остальные взаимодействия запрещены и в силу изоляции невозможны. Изоляцию процессов и контролируемые взаимодействия между ними по разрешенным IPC-каналам обеспечивает микроядро KasperskyOS. Во время взаимодействия проверяются политики безопасности процессов, которые контролирует выделенный доверенный сервис KasperskyOS — монитор безопасности, Kaspersky Security Module (KSM). Монитор обеспечивает проверку используемых методов, интерфейсов, параметров, состояний системы, моделей безопасности в контексте каждого участвующего процесса.
Анализ известных уязвимостей по доступным базам данных уязвимостей и техническое моделирование угроз показали, что разработанная архитектура отвечает установленным целям безопасности, при условии выполнения заданных предположений безопасности.
Прикладные доверенные компоненты КТС являются небольшими специализированными модулями с простыми интерфейсами и параметризацией. В целом доверенные компоненты отвечают за реализацию безопасных (TLS) соединений и гарантию их аутентичности, целостности, и ограничение доступа к специализированным изолированным хранилищам (сертификатов подписей, данных аутентификации и т.п). Это соответствует стратегии достижения целей безопасности. Доверенные компоненты прошли тщательную верификацию: статический анализ кода, динамический анализ кода с анализом тестового покрытия, харденинг кода, внешнее независимое фаззинг-тестирование, конечный продукт был подвержен независимому тестированию на проникновение.
Кибериммунный подход является концептуальным, то есть не привязанным к какой-либо конкретной ОС или платформе — в частности, он не синонимичен использованию KasperskyOS. Однако KasperskyOS изначально разрабатывалась в идеологии кибериммунности и на сегодняшний день является одним из наиболее подходящих инструментом для создания кибериммунных программных продуктов. Архитектурные требования кибериммунного подхода имплементируются в KasperskyOS на уровне ее собственной архитектуры, что значительно облегчает задачу создания кибериммунного продукта.
KasperskyOS — микроядерная ОС, реализующая принципы глубокой изоляции процессов и содержащая среди доверенных системных сервисов монитор безопасности (Kaspersky Security Module, KSM), контролирующий взаимодействие изолированных системных процессов на основе политик безопасности. Для каждого отдельного процесса создается политика, описывающая правила взаимодействия с ним, а общая политика безопасности продукта формируется как совокупность этих частных политик, собранных в единую согласованную структуру общей политикой архитектуры. Политики безопасности являются формализованными, для этого используется специальный язык PSL, то есть фактически политики являются кодом, который подвергается тестированию и верификации.
Ядро KasperskyOS действительно является микроядром с относительно небольшим количеством кода (порядка 100 тыс. строк) и очень небольшим набором функций. Главная задача микроядра — организация изолированных доменов безопасности (процессов) и исполнение вердиктов безопасности, ответственность за вычисление которых возложено на выделенный из ядра монитор безопасности, KSM.
Практические исследования специалистов по кибербезопасности «Лаборатории Касперского» показали, что KasperskyOS за счет своей архитектурных особенностей, что называется «из коробки» предотвращает подавляющее большинство широко распространенных угроз. Например, процессы KasperskyОС не ассоциируются ни с каким пользователем, поэтому угрозы, связанные с нелегитимным повышением привилегий исполняемого кода, принципиально не актуальны.
Кибериммунная специфика КТС достигнута не за счет разработки какой-то специальной функциональной архитектуры, а путем модификации одной из таких типовых функциональных архитектур в соответствии со стратегиями достижения установленных целей безопасности. Иначе говоря, KTC — это полнофункциональный тонкий клиент со множеством вариантов его непосредственного подключения к удаленным рабочим столам по протоколу RDP, при помощи брокеров подключений СКАЛА-Р, подключения к Citrix-инфраструктуре. В том числе, KTC поддерживает безопасное использование аудиоконференций.
Для обеспечения высокого уровня безопасности и мониторинга состояния пула развернутых в организации КТС используется Kaspersky Security Center (KSC), который управляет их конфигурациями и обновлениями. KSC имеет модуль расширения Kaspersky Security Management Suite для организации централизованного администрирования тонких клиентов через единую консоль управления KSC.
«Тонкий клиент» — дословный перевод англоязычного термина thin client. Часто под этим подразумевается маломощный компьютер под управлением функционально ограниченной ОС, работающий в сетевой терминальной или клиент-серверной архитектуре. Существует несколько целей применения тонкого клиента вместо полноценного компьютера на рабочем месте, среди них — повышение уровня информационной безопасности.
Kaspersky Thin Client (KTC) — тонкий клиент «Лаборатории Касперского» — создан в соответствии с кибериммунной методологией, и цель этой статьи — ответить на вопрос, как именно реализуется кибериммунитет KTC, за счет чего обеспечивается его защита как от известных, так и от неизвестных угроз.
Чтобы ответить на вопрос «Как достигается кибериммунность Kaspersky Thin Client?» и оценить преимущества, которыми она обладает, необходимо понимание того, что такое кибериммунитет и зачем он нужен. В этом разделе мы лишь тезисно коснемся этих вопросов, а более подробно они освещаются в многосерийной статье про кибериммунный подход к проектированию.
Современный кибермир характеризуется взаимным проникновением (конвергенцией) всех видов операционных (OT) и информационных (IT) технологий. «Умными» стали не только автомобили, самолеты, системы транспорта, промышленности и управления, но и дома людей. Для конвергентных решений характерны сложность, гетерогенность компонентов, высокая связность, глобальная доступность, высокая скорость и большие объемы передачи данных, а также большой объем программного кода, в том числе заимствованного.
В таких условиях становится недостаточным использование только наложенных мер для защиты изначально небезопасных киберсистем. Альтернативный подход — создание конструктивно безопасных (Secure by Design) систем — еще не стал повсеместным по двум основным причинам. Во-первых, разработка конструктивно безопасной, в отличие от «просто работающей» системы, требует компетенций в области кибербезопасности, а подходящие специалисты дороги и немногочисленны. Во-вторых, подход Secure by Design пока еще слабо поддержан методически.
Кибериммунный подход предлагает методологию разработки конструктивно безопасной киберсистемы, объединяющую описание процесса ее разработки и архитектурные требования к ней. Целью кибериммунного подхода является создание кибериммунного программного продукта, заявленные ценности которого остаются в безопасности даже под атакой. В целом, кибериммунный подход помогает формулировать задание на безопасность и строить соответствующую архитектуру с использованием архитектурных шаблонов безопасности, что обеспечивает доказуемо высокое качество свойств безопасности киберсистемы.
В этом разделе мы описываем верхнеуровневую архитектуру и базовые функции KTC, как достигается его кибериммунитет, какой вклад в это вносит операционная система KasperskyOS.
На следующем рисунке приведена схема взаимодействия Kaspersky Thin Client с платформами виртуализации:
Типовая схема работы Kaspersky Thin Client (см. рис ниже) такова:
Практический смысл кибериммунного продукта состоит в том, чтобы при любых обстоятельствах обеспечить сохранность прикладных ценностей, которые так или иначе связанны с этим продуктом. Поэтому мы описали ценности KTC, а также нежелательные события в их отношении:
На основе этого описания ценностей с точки зрения потребителя, в соответствии с положениями кибериммунной методологии, техническая команда выработала следующие цели безопасности, фактически являющиеся формализованным «контрактом на безопасность» KTC:
Были определены также ограничения на предпринимаемые меры защиты (априори принимаемые предположения безопасности), которые также являются частью «контракта на безопасность»:
Какова стратегия технического обеспечения достижения сформированных целей безопасности для KTC с учетом заданных ограничений? Для ее определения обобщим верхнеуровневую архитектуру тонкого клиента, чтобы визуализировать ее проблемные места с точки зрения сформулированных целей безопасности.
Сопоставив эту схему с целями безопасности КТС, мы видим компоненты, которые напрямую влияют на них:
Про библиотеку, имплементирующую протокол RDP, необходимо сделать несколько замечаний. Ее влияние на цели безопасности является прямым — в частности, уязвимости в ней могут быть эксплуатированы как для нарушения целостности и конфиденциальности принимаемых и передаваемых данных, так и для несанкционированного доступа к локальному хранилищу данных, в котором, среди прочего, хранится чувствительная ключевая информация — атрибуты доступа, сертификаты публичных ключей и т. д. С другой стороны, собственная «безопасная» реализация стандартной библиотеки нецелесообразна с любой точки зрения: коммерческой, сопровождения и поддержки, а также совместимости.
В соответствии с традиционным подходом можно было бы взять все известные уязвимости библиотеки RDP (на сегодняшний день их несколько десятков) и выработать ответные меры, предотвращающие угрозы. Однако кибериммунный подход нацелен не столько на защиту активов системы, уже попавших в опасное состояние, сколько на исключение возможности попадания активов в такие состояния. Это существенно, поскольку, с одной стороны, стандартная библиотека постоянно обновляется и в будущем в ней появятся новые уязвимости, а с другой — нет никаких гарантий, что даже в какой-то «замороженной» ее версии выявлены все уязвимости. Это очень большой объем нетривиального кода, и глубокая его верификация коммерчески нецелесообразна. В соответствии с кибериммунным подходом, потенциально опасный компонент должен быть изолирован от защищаемых ценностей. Именно так мы и сделали, «заслонив» стандартную библиотеку RDP собственным стандартным доверенным компонентом с достаточно простой функциональностью — TLS-терминатором, и ограничив политиками безопасности все взаимодействия между компонентами. Все сказанное про библиотеку реализации RDP справедливо и для библиотеки потокового аудио. Впрочем, как и для любой другой сторонней библиотеки, реализующей какой-либо типовой функционал.
Что касается локального хранения данных, подход к решению этой задачи сходен: во-первых, вместо одного общего хранилища используется несколько изолированных партиций, во-вторых, доступ к этим изолированным хранилищам разрешен только ограниченному набору специализированных доверенных компонентов, все коммуникации с которыми регулируются политиками безопасности.
Таким образом, техническая стратегия достижения целей безопасности выглядит следующим образом:
Достижение Цели 1
Цель: в рабочем режиме устройства обеспечена конфиденциальность и целостность данных, передаваемых между устройством и удалённым рабочим столом; между устройством и брокером соединений с удаленными рабочими столами; между устройством и KSC-сервером; между устройством и сервером логирования.
Стратегия: конфиденциальность и целостность данных обеспечиваются протоколом TLS, который имплементируется шаблонным доверенным компонентом. При работе в доверенном режиме к удаленным рабочим столам, брокерам подключений, серверу KSC и серверам логирования подключение возможно только с применением сертификатов публичных ключей, установленных Админом KSC.
Достижение Цели 2
Цель: обеспечение целостности хранимых на устройстве данных, полученных от пользователя, непосредственно работающего с устройством (сертификатов, реквизитов для подключения) и от KSC-сервера (конфигураций, сертификатов, лицензий, реквизитов для отключения от сервера KSC).
Стратегия: сертификаты публичных ключей, реквизиты для подключения к рабочим столам и серверу KSC, файлы конфигурации, лицензии принимаются только от доверенных компонентов и хранятся в отдельных изолированных хранилищах, доступ к каждому из которых есть только у специализированных доверенных компонентов.
Достижение Цели 3
Цель: обновление программного обеспечения тонкого клиента выполняется, только если подтверждена аутентичность и целостность обновления.
Стратегия: образ обновления подписывается цифровой подписью доверенной системой сборки поставщика, которая проверяется дважды — при загрузке на доверенный KSC-сервер и непосредственно перед применением на локальном устройстве, специализированным доверенным компонентом. Для локальной проверки подписи образа обновления перед его применением используется шаблон безопасности «Безопасное обновление», реализуемый с участием монитора безопасности KasperskyOS.
В итоге после модификации исходной верхнеуровневой архитектуры в соответствии с технической стратегией достижения целей безопасности, мы получили следующий ее вариант:
Следует напомнить, что все взаимодействия между системными процессами продукта под KasperskyOS определяются политикой архитектуры продукта, все остальные взаимодействия запрещены и в силу изоляции невозможны. Изоляцию процессов и контролируемые взаимодействия между ними по разрешенным IPC-каналам обеспечивает микроядро KasperskyOS. Во время взаимодействия проверяются политики безопасности процессов, которые контролирует выделенный доверенный сервис KasperskyOS — монитор безопасности, Kaspersky Security Module (KSM). Монитор обеспечивает проверку используемых методов, интерфейсов, параметров, состояний системы, моделей безопасности в контексте каждого участвующего процесса.
Анализ известных уязвимостей по доступным базам данных уязвимостей и техническое моделирование угроз показали, что разработанная архитектура отвечает установленным целям безопасности, при условии выполнения заданных предположений безопасности.
Прикладные доверенные компоненты КТС являются небольшими специализированными модулями с простыми интерфейсами и параметризацией. В целом доверенные компоненты отвечают за реализацию безопасных (TLS) соединений и гарантию их аутентичности, целостности, и ограничение доступа к специализированным изолированным хранилищам (сертификатов подписей, данных аутентификации и т.п). Это соответствует стратегии достижения целей безопасности. Доверенные компоненты прошли тщательную верификацию: статический анализ кода, динамический анализ кода с анализом тестового покрытия, харденинг кода, внешнее независимое фаззинг-тестирование, конечный продукт был подвержен независимому тестированию на проникновение.
Кибериммунный подход является концептуальным, то есть не привязанным к какой-либо конкретной ОС или платформе — в частности, он не синонимичен использованию KasperskyOS. Однако KasperskyOS изначально разрабатывалась в идеологии кибериммунности и на сегодняшний день является одним из наиболее подходящих инструментом для создания кибериммунных программных продуктов. Архитектурные требования кибериммунного подхода имплементируются в KasperskyOS на уровне ее собственной архитектуры, что значительно облегчает задачу создания кибериммунного продукта.
KasperskyOS — микроядерная ОС, реализующая принципы глубокой изоляции процессов и содержащая среди доверенных системных сервисов монитор безопасности (Kaspersky Security Module, KSM), контролирующий взаимодействие изолированных системных процессов на основе политик безопасности. Для каждого отдельного процесса создается политика, описывающая правила взаимодействия с ним, а общая политика безопасности продукта формируется как совокупность этих частных политик, собранных в единую согласованную структуру общей политикой архитектуры. Политики безопасности являются формализованными, для этого используется специальный язык PSL, то есть фактически политики являются кодом, который подвергается тестированию и верификации.
Ядро KasperskyOS действительно является микроядром с относительно небольшим количеством кода (порядка 100 тыс. строк) и очень небольшим набором функций. Главная задача микроядра — организация изолированных доменов безопасности (процессов) и исполнение вердиктов безопасности, ответственность за вычисление которых возложено на выделенный из ядра монитор безопасности, KSM.
Практические исследования специалистов по кибербезопасности «Лаборатории Касперского» показали, что KasperskyOS за счет своей архитектурных особенностей, что называется «из коробки» предотвращает подавляющее большинство широко распространенных угроз. Например, процессы KasperskyОС не ассоциируются ни с каким пользователем, поэтому угрозы, связанные с нелегитимным повышением привилегий исполняемого кода, принципиально не актуальны.
Кибериммунная специфика КТС достигнута не за счет разработки какой-то специальной функциональной архитектуры, а путем модификации одной из таких типовых функциональных архитектур в соответствии со стратегиями достижения установленных целей безопасности. Иначе говоря, KTC — это полнофункциональный тонкий клиент со множеством вариантов его непосредственного подключения к удаленным рабочим столам по протоколу RDP, при помощи брокеров подключений СКАЛА-Р, подключения к Citrix-инфраструктуре. В том числе, KTC поддерживает безопасное использование аудиоконференций.
Для обеспечения высокого уровня безопасности и мониторинга состояния пула развернутых в организации КТС используется Kaspersky Security Center (KSC), который управляет их конфигурациями и обновлениями. KSC имеет модуль расширения Kaspersky Security Management Suite для организации централизованного администрирования тонких клиентов через единую консоль управления KSC.
