Secure rollback prevention что это

Secure Rollback Prevention

Может ли кто-нибудь объяснить, что такое Secure Rollback Prevention, и зачем он нужен?

Поиском в Гугле смог узнать только, что это — фича биосов Lenovo, которую рекомендуют отключить.

Какое это имеет отношение к Линуксу? Самое прямое — мешает его ставить с флешек. Вроде.

question4 ★★★★★
20.12.13 18:55:27 MSK

Вангую, это фича, позволяющая не дать ревертнуть прошивку до настолько старой/новой версии, в которой осуществима нужная атака. Для этого ставится какая-нибудь RSA-подпись, позволяющая быстро отфильтровать левые прошивки, типа такой: http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto

stevejobs ★★★★☆
( 20.12.13 19:35:58 MSK )

а слово «Secure» там при том, чтобы маркетингово красиво выглядело рядом со словом «Secure Boot»

stevejobs ★★★★☆
( 20.12.13 19:47:03 MSK )
Ответ на: комментарий от stevejobs 20.12.13 19:35:58 MSK

это фича, позволяющая не дать ревертнуть прошивку

А почему загрузка с USB блокируется? Притом что с лазерных дисков всё грузится.

question4 ★★★★★
( 20.12.13 19:58:23 MSK ) автор топика
28 апреля 2014 г.

Secure Rollback Prevention оказалось ни при чём. Просто ряд ноутбуков Lenovo, включая мой B590, как оказалось не могут грузиться с флешки, на которой нет таблицы разделов. Если на флешку скопировать ISO при помощи dd, грузиться будет.

question4 ★★★★★
( 28.04.14 02:27:15 MSK ) автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.

Похожие темы

• Форум Fedora 18 secure boot not enable on Lenovo z570 (2013)
• Форум Отключение Secure Boot (2020)
• Форум asus pu500ca отключается ли secure boot? (2014)
• Форум Как перестать искать в инете bash: fgfglfjg: command not found. (2018)
• Форум Линукс и secure boot (2018)

• Форум О Secure Boot, LUKS и безопасности. (2017)
• Форум Linux не запускается после установки на Lenovo. (2013)
• Форум Установка Fedora на ноутбук Lenovo (2020)
• Форум Lenovo Z575 объявил войну с установкой! (2016)
• Форум Ошибка при установке Linux (2017)

Secure rollback prevention что это

Откатить последние обновления антивирусных баз. Это позволяет вернуться к использованию предыдущей версии баз и модулей приложения при необходимости, например, в том случае, если новая версия баз содержит некорректную сигнатуру, из-за которой Kaspersky Endpoint Security блокирует безопасное приложение.

Режим сохранения событий в файл отчета

Сохранять только критические события в файл отчета.

Сохранять все события в файл отчета.

avp.com ROLLBACK /RA:rollback.txt

Secured by Knox — механизмы мобильной безопасности Samsung

Если у вас телефон Samsung, то вы, возможно, замечали на экране загрузки фразу «Secured by Knox». Что это вообще значит? Под катом – описание платформы мобильной безопасности, предустановленной на большинстве смартфонов и планшетов Samsung. Это первый русскоязычный обзор того, какие механизмы вообще существуют в решении Knox.

Введение

В 2019 году компания Samsung Electronics отметила 50 лет, а еще этот год отмечен другой круглой датой – 10 лет с момента выпуска первого устройства линейки Galaxy — GT-I7500. Вот так выглядела эта модель:

По сегодняшним меркам телефон имел очень скромные характеристики: экран размером 3.2 дюйма и процессор с тактовой частотой всего в 528 МГц, работал под управлением одной из первых версий ОС Android. Собственно говоря, в 2009 году модель не была уникальной: на рынке были устройства на открытой ОС Android со схожими аппаратными характеристиками на платформе ARM. Было понятно, что для успеха нужна «изюминка», выделяющая компанию из общего ряда.

Несомненно, открытость операционной системы повлияла на успех ОС Android: по оценкам IDC на октябрь 2019 она установлена на 87% проданных смартфонах, и это число продолжает расти. Но и тогда, и сейчас, вопрос безопасности Android – одна из часто обсуждаемых тем.

Samsung представила платформу Knox, как ответ на вызовы в области информационной безопасности мобильных устройств. Первая редакция Knox (старое название «SAFE» или «Samsung for Enterprise») вышла в 2012 году вместе с Galaxy S3.

Последняя на сегодняшний день мажоритарная версия платформы (3.0) была выпущена вместе с Galaxy S9 в 2018. Актуальная версия на момент написания статьи — 3.4. Название Knox происходит от Форт-Нокса – одного из самых защищенных хранилищ золотых запасов в мире.

Что же такое Knox? Сейчас под этим названием (или уже правильнее брендом) понимается всё, что связано в Samsung с мобильной безопасностью. Сюда относят менеджер паролей Samsung Pass, Защищённая папка, платёжный сервис Samsung Pay, и целое семейство корпоративных решений, но в основе этого лежит платформа Knox.

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

Сюда включаются следующие принципы:

• Безопасность системы строится на аппаратном корне доверия (HW Root of Trust).
• Контроль безопасности устройства должен начинаться в момент загрузки.
• Мониторинг безопасности обязателен и регулярен во время работы устройства.
• В системе должен быть заложен механизм, позволяющий доказать свою целостность сторонним системам.
• Основная ценность устройства – данные пользователя. Их защита является приоритетом системы.

Платформа Knox решает и эту задачу:

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

Построение доверенной среды

Перед тем, как углубиться в рассмотрение отдельных механизмов, нужно пару слов сказать об основе всех аппаратных механизмов защиты платформы Knox – архитектуре TrustZone-based Integrity Measurement Architecture (TIMA). Она базируется на ARM TrustZone Framework.

В парадигме TrustZone существует 2 «мира» (области):

• Secure («Безопасный»)
• Normal или Non-secure («Обычный» или «Небезопасный» мир)

Источник: www.arm.com

Функционал телефона делится между этими двумя областями следующим образом:

• «Чувствительные» вычисления (например, шифрование).
• Защита критичной информации.
• Мониторинг состояния ядра ОС, запущенной в Normal World.
• Доступ к памяти и устройствам, помеченным как Secure (может быть осуществлён только из Secure World).

• Выполнение основной ОС и всех пользовательских приложений.
• Приложения, запущенные в Secure World, наиболее привилегированы, и могут получать доступ к ресурсам обеих сред (и Secure World, и Normal World). Приложения из Normal World ни при каких условиях не могут получить доступ к ресурсам Secure World напрямую.

Аппаратный корень доверия

Уже в момент производства на заводе, во время установки программного обеспечения (ПО), на мобильном устройстве создаются криптографические ключи. Рассмотрим 2 основных ключа:

• Device Unique Hardware Key (DUHK) или Уникальный аппаратный ключ устройства. Уникальный для каждого устройства симметричный ключ, который создается непосредственно на устройстве с использованием аппаратного генератора случайных чисел. Информация, зашифрованная этим ключом, может быть расшифрована только на том же самом устройстве. DUHK доступен только модулю аппаратного шифрования и не доступен никакому ПО на устройстве. С помощью DUHK шифруются остальные криптографические ключи на устройстве. Когда мы говорим, что какой-то компонент привязан к устройству, чаще всего подразумевается применение именно этого ключа.
• Device Root Key (DRK) или Корневой ключ устройства. Уникальная для каждого устройства пара ассиметричных ключей (RSA), подписанная корневым сертификатом (X.509) Samsung. DRK защищен с помощью DUHK и доступен только из Secure World. Он однозначно идентифицирует устройство и подтверждает, что оно произведено Samsung.

Производство устройств на фабрике Samsung Electronics, г. Гуми, Южная Корея

Загрузка устройства

Безопасная загрузка (Secure Boot)

Процесс загрузки устройства состоит из цепочки загрузчиков, каждый из которых проверяет подпись следующего компонента, после чего запускает его. Если проверка не проходит, процесс загрузки прерывается. Данный механизм называется Secure Boot, в своей работе он использует Samsung Secure Boot Key (SSBK) – асимметричную пару ключей в аппаратном хранилище.
Secure Boot гарантирует загрузку устройства только с помощью доверенных загрузчиков Samsung. Если один из загрузчиков скомпрометирован, то запуск устройства прерывается, предотвращая потенциальную компрометацию устройства.

Доверенная загрузка (Trusted Boot)

Secure Boot путем проверки подписи решает проблему сторонних загрузчиков, но не решает проблему старых, неактуальных версий, потенциально несущих в себе ряд известных уязвимостей. Поэтому разработан механизм доверенной загрузки Trusted Boot, работающий поверх Secure Boot. Он проверяет актуальность версии загрузчика. Результаты проверки записываются в защищённую память в TrustZone Secure World и могут быть использованы для будущих проверок.

Knox Verified Boot (KVB)

В момент начала загрузки ОС активируется ещё один механизм, называемый Knox Verified Boot. KVB – расширение механизма Android Verified Boot (AVB). Помимо стандартных метрик, контролируемых AVB, KVB также учитывает результаты, полученные Trusted Boot и Secure Boot (т.е. целостность загрузчиков и их актуальность). За счёт выполнения всех операций KVB в загрузчике, данная проверка является надёжной и безопасной (процедура осуществляется вне проверяемого объекта).

Компонент Knox Verified Boot является достаточно новым и поддерживается устройствами, начиная с Samsung S10, работающих под управлением операционной системы Android P или более поздних версий.

Графически процесс загрузки устройства, защищённого механизмами Knox можно представить следующим образом:

Аппаратный флаг Knox Warranty Bit

Knox Warranty Bit — функция безопасности, позволяющая зафиксировать факт установки неофициальной версии системного программного обеспечения на устройство. Устройства со сработавшим Warranty Bit не могут использовать некоторый функционал, например, Knox Workspace. Флаг не может быть возвращён в исходное состояние. Он гарантирует, что устройство Samsung ранее запускалось только с доверенной ОС.

Рис. Слева кастомная прошивка, KNOX WARRANTY VOID 0x1

Аппаратная блокировка возврата к старым версиям ПО (Rollback Prevention)

Старые версии загрузочных компонентов могут содержать уязвимости. Rollback prevention – функция, блокирующая возврат на более старую версию ОС. Минимальная версия загрузчика, возможная для прошивки, хранится в защищённой области. Минимальная возможная версия ядра ОС хранится в самом загрузчике. При штатном обновлении системы, минимально допустимые версии загрузчика и ОС повышаются. Вернуться на предыдущую или более раннюю версию невозможно.

Вернуться с Android P на Android O невозможно.

Контроль целостности доверенной среды

После запуска целостность системы нужно регулярно проверять. Для этого в Knox существует несколько механизмов.

Компонент Periodic Kernel Measurement (PKM)

PKM осуществляет периодический мониторинг ОС на предмет модификации её компонентов с момента загрузки. В рамках проверки отслеживаются контрольные суммы ядра и статус подсистемы SE for Android (о ней мы поговорим немного позже). PKM работает в Secure World. Таким образом, любая нештатная модификация ядра ОС будет детектирована.

Компонент Real-time Kernel Protection (RKP)

Trusted Boot защищает от загрузки измененного ядра, но ядро может быть подвергнуто атаке во время работы устройства. Необходим постоянный мониторинг целостности кода и критичных данных. RKP – это мониторинг безопасности, расположенный в изолированной среде – либо в ARM TrustZone Secure World, либо в «тонком» гипервизоре, защищенном аппаратными расширениями виртуализации.

RKP использует специальные методы, чтобы контролировать управление памятью в Normal World, перехватывать критичные запросы и оценить их влияние до того, как произойдёт их выполнение. Механизм защиты ядра в реальном времени дополняет периодические проверки целостности ядра (PKM).

Таким образом, Real-Time Kernel Protection – это гарантия защиты от выполнения вредоносного кода на уровне ядра ОС.

Проверка целостности доверенной среды

Мобильные устройства не работают изолированно, обычно они являются частью какой-то более масштабной системы, например, являются клиентами сервера, вычислительными узлами и пр. И чтобы система могла стабильно и безопасно работать, она должна быть уверена, что все её компоненты «здоровы» и являются теми, за кого себя выдают. Это достаточно непростая задача, в рамках платформы Knox она решается с помощью механизма удалённой аттестации.

Удалённая аттестация устройства (Knox Attestation)

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

• измерения, собранные в процессе доверенной загрузки Trusted Boot;
• логи нарушений безопасности от механизмов PKM и RKP с момента последней перезагрузки;
• состояние Knox Warranty Bit;
• различные идентификаторы устройства, такие как IMEI.

Аттестационное сообщение формируется в ARM TrustZone Secure World. Оно является корректным, даже если ОС в Normal World скомпрометирована.

Помимо проверки отдельных параметров, аттестация также оценивает состояние системы в целом. Только когда измерения, собранные Trusted Boot соответствуют эталонным значениям, и значение Knox Warranty Bit не изменено, аттестация считается пройденной.

Аттестационное сообщение не может быть подделано, так как оно подписано с использованием ключа аттестации Samsung Attestation Key (SAK), производного от корневого ключа Samsung. Удалённый сервер может проверить целостность сообщения, используя корневой ключ Samsung. Подпись содержит сгенерированную на серверной стороне криптографическую «добавку» (случайное число, используемое только один раз), чтобы не дать атакующему возможность использовать старое корректное аттестационное сообщение на уже скомпрометированном устройстве.

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

Защита данных

Данные являются основной ценностью мобильного устройства и требуют отдельных механизмов защиты.

Шифрование внутреннего хранилища

Полное шифрование внутренней памяти является обязательным требованием для всех устройств на базе ОС Android с версии 7. Knox развивает данную концепцию, храня ключ в защищённом аппаратном ключевом хранилище.

Система Security Enhancements (SE) for Android

Samsung Knox использует расширение безопасности для Android (Security Enhancement for Android, SE for Android), которое добавляет механизм принудительного (мандатного) контроля доступа Mandatory Access Control (MAC) в ОС.

SE для Android предоставляет два уровня защиты MAC:

1. Защита на уровне ядра
2. Защита на уровне промежуточного ПО Android

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

Контейнеризация Knox

Одним из частных случаев применения механизма SE for Android является контейнер Knox.
Контейнер разделяет приложения и данные на два независимых пространства: обычную и защищённую области. Данные защищённой области хранятся во внутренней памяти в зашифрованном виде. Ключи шифрования, в свою очередь, шифруются с помощью DUHK-ключа, т.е. они привязаны к конкретному устройству. В случае компрометации устройства (срабатывание Knox Warranty Bit, Trusted Boot и пр.) доступ к контейнеру блокируется.

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

Технология контейнеризации используется в нескольких продуктах Samsung, таких как Secure Folder и Knox Workspace.

Возможности для корпоративных пользователей

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

Дополнительные источники по теме:

• Knox Platform Whitepaper
• Trusted Boot and TrustZone Integrity Management explained
• Real-time Kernel Protection
• Knox Attestation

Автор: Владимир Карачаров,
Manager, B2B Pre/Post Sales
Business Development Team
Samsung R&D Institute Russia

• b2b
• корпоративное по
• android
• samsung knox
• мобильная безопасность
• trustzone

• Блог компании Samsung
• Смартфоны

Elastic Security overviewedit

Elastic Security combines SIEM threat detection features with endpoint prevention and response capabilities in one solution. These analytical and protection capabilities, leveraged by the speed and extensibility of Elasticsearch, enable analysts to defend their organization from threats before damage and loss occur.

Elastic Security provides the following security benefits and capabilities:

• A detection engine to identify attacks and system misconfigurations
• A workspace for event triage and investigations
• Interactive visualizations to investigate process relationships
• Inbuilt case management with automated actions
• Detection of signatureless attacks with prebuilt machine learning anomaly jobs and detection rules

Elastic Security components and workflowedit

The following diagram provides a comprehensive illustration of the Elastic Security workflow.

Here’s an overview of the flow and its components:

• Data is shipped from your hosts to Elasticsearch in the following ways:

• Elastic Defend: Elastic Agent integration that protects your hosts against malware and ships these data sets:

• Windows : Process, network, file, DNS, registry, DLL and driver loads, malware security detections
• Linux/macOS : Process, network, file

• Detection engine: Automatically searches for suspicious host and network activity via the following:

• Detection rules: Periodically search the data (Elasticsearch indices) sent from your hosts for suspicious events. When a suspicious event is discovered, an alert is generated. External systems, such as Slack and email, can be used to send notifications when alerts are generated. You can create your own rules and make use of our prebuilt ones.
• Exceptions: Reduce noise and the number of false positives. Exceptions are associated with rules and prevent alerts when an exception’s conditions are met. Value lists contain source event values that can be used as part of an exception’s conditions. When Elastic Defend is installed on your hosts, you can add malware exceptions directly to the endpoint from the Security app.
• Machine learning jobs: Automatic anomaly detection of host and network events. Anomaly scores are provided per host and can be used with detection rules.

For more background information, see:

• Elasticsearch: A real-time, distributed storage, search, and analytics engine. Elasticsearch excels at indexing streams of semi-structured data, such as logs or metrics.
• Kibana: An open-source analytics and visualization platform designed to work with Elasticsearch. You use Kibana to search, view, and interact with data stored in Elasticsearch indices. You can easily perform advanced data analysis and visualize your data in a variety of charts, tables, and maps.

Compatibility with cold tier nodesedit

Cold tier is a data tier that holds time series data that is accessed only occasionally. In Elastic Stack version >=7.11.0, Elastic Security supports cold tier data for the following Elasticsearch indices:

• Index patterns specified in securitySolution:defaultIndex
• Index patterns specified in the definitions of detection rules, except for indicator match rules
• Index patterns specified in the data sources selector on various Elastic Security app pages

Elastic Security does NOT support cold tier data for the following Elasticsearch indices:

• Index patterns controlled by Elastic Security, including signals and list indices
• Index patterns specified in indicator match rules

Using cold tier data for unsupported indices may result in detection rule timeouts and overall performance degradation.

Additional Elastic Defend informationedit

The Elastic Defend integration for Elastic Agent provides capabilities such as collecting events, detecting and preventing malicious activity, exceptions, and artifact delivery. The Fleet app is used to install and manage Elastic Agents and integrations on your hosts.

Elastic Endpoint self-protectionedit

Self-protection means that Elastic Endpoint has guards against users and attackers that may try to interfere with its functionality. This protection feature is consistently enhanced to prevent attackers who may attempt to use newer, more sophisticated tactics to interfere with the Elastic Endpoint. Self-protection is enabled by default when Elastic Endpoint installs on supported platforms, listed below.

Self-protection is enabled on the following 64-bit Windows versions:

• Windows 8.1
• Windows 10
• Windows 11
• Windows Server 2012 R2
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022

Self-protection is also enabled on the following macOS versions:

• macOS 10.15 (Catalina)
• macOS 11 (Big Sur)
• macOS 12 (Monterey)

Other Windows and macOS variants (and all Linux distributions) do not have self-protection.

For Elastic Stack version >= 7.11.0, self-protection defines the following permissions:

• Users — even Administrator/root — cannot delete Elastic Endpoint files (located at c:\Program Files\Elastic\Endpoint on Windows, and /Library/Elastic/Endpoint on macOS).
• Users cannot terminate the Elastic Endpoint program or service.
• Administrator/root users can read the Endpoint’s files. On Windows, the easiest way to read Endpoint files is to start an Administrator cmd.exe prompt. On macOS, an Administrator can use the sudo command.
• Administrator/root users can stop the Elastic Agent’s service. On Windows, run the sc stop «Elastic Agent» command. On macOS, run the sudo launchctl stop elastic-agent command.

Integration with other Elastic productsedit

You can use Elastic Security with other Elastic products and features to help you identify and investigate suspicious activity:

APM transaction data sourcesedit

By default, Elastic Security monitors APM apm-*-transaction* indices. To add additional APM indices, update the index patterns in the securitySolution:defaultIndex setting (Kibana → Stack Management → Advanced Settings → securitySolution:defaultIndex ).

ECS compliance data requirementsedit

The Elastic Common Schema (ECS) defines a common set of fields to be used for storing event data in Elasticsearch. ECS helps users normalize their event data to better analyze, visualize, and correlate the data represented in their events. Elastic Security supports events and indicator index data from any ECS-compliant data source.

Elastic Security requires ECS-compliant data. If you use third-party data collectors to ship data to Elasticsearch, the data must be mapped to ECS. Elastic Security ECS field reference lists ECS fields used in Elastic Security.