Презентация лекция №9

1.

ВОЕННО-КОСМИЧЕСКАЯ АКАДЕМИЯ ИМЕНИ А.Ф. МОЖАЙСКОГО
Лекция № 5
Анализ программных реализаций при отсутствии исходных
текстов программ

2.

2
Лекция №9
Анализ программных модулей UEFI систем
Цель: Изучить основные особенности и методы анализа реализаций UEFI модулей.
Учебные вопросы:
1.
2.
3.
Основные понятия UEFI
Доверенная загрузка в UEFI
Контроль UEFI - cредства доверенной загрузки

3.

3
Источники
1.
2.
3.
4.
Что такое UEFI, и чем он отличается от BIOS // Geektimes.
URL: https://geektimes.com/post/290009
Unified Extensible Firmware Interface Specification //URL:
http://www.uefi.org/.
О безопасности UEFI, части нулевая и …пятая // Хабр
URL: https://habr.com/post/266935/ .
Банк данных угроз безопасности информации //
Федеральная служба по техническому и экспортному
контролю ФСТЭК России, URL: https://bdu.fstec.ru/.

4. 1. Основные понятия UEFI

4
BIOS (basic input/output system) / UEFI (Unified Extensible Firmware Interface) –
интерфейс между операционной системой (ОС) и микропрограммами,
управляющими низкоуровневыми функциями оборудования ЭВМ (мобильных
устройств, сетевого оборудования)
Основное предназначение – корректная инициализация оборудования при
включении электропитания и передача управления загрузчику ОС (MS
Windows, Linux и др.).
UEFI предназначен для замены «устаревшей» BIOS.
Первоначально стандарт UEFI была выпущен компанией Intel в начале 2000-х
годов.

5. Структура UEFI как объекта защиты. Виды атак

Каждый производитель аппаратного
обеспечения ЭВМ реализует лишь
часть стандарта UEFI в зависимости
от
периферийных
устройств
материнских плат и конкретных
требований
к
ним.
Реализации
UEFI
разных
производителей
зачастую
НЕСОВМЕСТИМЫ друг с другом
UEFI Specification
Version 2.10. Август 2024.
2211 страниц описаний протоколов
http://www.uefi.org/specifications
5

6. Преимущества интерфейса UEFI по сравнению с традиционным Legacy BIOS

6
возможность работы UEFI в 32 и 64-битном режиме, что дает преимущество в скорости
загрузки ОС;
поддержка разделов устройств хранения данных емкостью более 2,2 Тб;
создание до 128 разделов на одном устройстве хранения данных;
дублирование таблицы разделов устройств хранения данных;
предоставляемый пользователю графический оконный интерфейс вместо текстового
псевдографического Legacy BIOS;
поддержку работы с манипулятором мышь и, как следствие, работу с групповыми
операциями (выделение и т.п.);
поддержка механизма доверенной загрузки ОС «Secure Boot», осуществляющего защиту
от попытки передачи управления загрузчику ОС, не имеющему соответствующей цифровой
подписи;
поддержка сетевых протоколов (HTTP, FTP, DHCP, TCP/IP) для осуществления
удаленной загрузки ОС;
возможность работы с бездисковыми ЭВМ;
поддержка технологии сетей беспроводного доступа Wi-Fi и Bluetooth;
поддержка работы с USB-устройствами;
наличие встроенной системной оболочки для выполнения команд UEFI Shell;
возможность получения доступа к параметрам UEFI из ОС Windows и Linux.

7. Преимущества интерфейса UEFI по сравнению с традиционным Legacy BIOS

7

8. UEFI В СОВРЕМЕННЫХ ОС

8
Преимущества стандартов UEFI и GPT привело к тому, что
большинство современных ОС устанавливается на системные разделы
устройств хранения данных, размеченные по стандарту GPT. Стандарт
GPT поддерживается в ОС семейства Windows, начиная с версии 7.
Начиная с ОС Windows 8.1 все OEM ЭВМ с предустановленной ОС
Windows устанавливаются в режиме UEFI и включенным механизмом
доверенной загрузки Secure Boot
ОС семейств Linux/Unix также поддерживают работу со стандартом
UEFI, при этом по умолчанию данный режим используется в
серверных и клиентских ОС компании Red Hat, ОС Ubuntu, ОС
семейства Debian и ОС семейства FreeBSD.

9. Основные объекты UEFI

системная таблица UEFI – основная структура данных, хранящая
таблицы с данными и функции интерфейса для взаимодействия с ПО аппаратной
платформы Application Programming Interface (API);
база данных описателей (дескрипторов) и протоколов – таблица,
хранящая доступные интерфейсы в системе, которые можно вызвать;
образы UEFI – файлы с кодом, которые можно запустить на ис-полнение;
события – это объекты, с помощью которых программное обес-печение
может быть уведомлено о какой-либо активности;
путь к устройству – структура данных, описывающая местоположение к
объектам устройств, таким как шина, раздел диска, имя UEFI образа на диске.
9

10. UEFI SYSTEM TABLE

Является самой важной структурой данных в UEFI. Указатель на UEFI System Table
передаётся каждому приложению или драйверу. Через эту структуру UEFI
приложения или драйвера могут получить доступ к информации о конфигурации
системы, а также большую коллекцию UEFI сервисов, которые включают в себя:
UEFI Boot Services
UEFI Runtime Services
Protocol Services
Boot Services и Runtime Services доступны через Boot Services Table и Runtime
Services Table, соответственно.
Protocol Services - это группа функций и полей данных, которые заданы с помощью 16
байтового уникального идентификатора( GUID), определенного в спецификации UEFI
Protocol Services используются для предоставления программному обеспечению
абстракции для устройств, таких как диски, сетевые интерфейсы. В спецификации
UEFI определены более 30 протоколов. UEFI приложения и драйвера могут
использовать свои протоколы для расширения своего функционала.
10

11. База данных обработчиков

Обработчик - это коллекция одного или нескольких протоколов и данных, которые
заданы с помощью GUID. Любой драйвер, приложение может добавлять в эту базу
данных свои протоколы, функции, данные или всё вместе. База является глобальной и
доступна для любого UEFI приложения или драйвера.
11

12. UEFI образы

UEFI ОБРАЗЫ
UEFI образы – это вид файлов, определённый спецификацией, которые содержат
исполняемый код.
В настоящее время существует три типа образов:
UEFI приложения;
UEFI boot сервисы;
UEFI runtime сервисы.
UEFI приложения – это образы, которые обладают памятью и состоянием, до вызова
функции выхода.
UEFI boot сервисы – это образы, которые обладают памятью и состоянием на
протяжении процесса подготовки к загрузке ОС. Эти сервисы владеют памятью до
вызова функции ExitBootServices(), вызываемой загрузчиком ОС.
UEFI runtime сервисы – это образы, которые продолжают храниться в памяти на
протяжении всего времени работы системы. Эти сервисы могут быть доступны UEFIсовместимой операционной системе.
12

13. UEFI образы

UEFI ОБРАЗЫ
Все UEFI образы содержат PE/COFF заголовок, который определяет формат
исполняемого кода. Код может быть написан для архитектуры IA-32, X64, Itanium,
ARM.
Загрузка образа с помощью Boot Service: gBS->LoadImage()
(Выделяется память под образ; создаётся новый обработчик в базе данных обработчиков, который устанавливает
экземпляр EFI_LOADER_IMAGER_PROTOCOL., содержащий информацию об UEFI образе,а доступна для всех
UEFI приложений.)
Запуск на выполнение gBS->StartImage().
Заголовок UEFI образа содержит адрес на входную точку. Входная точка всегда
принимает 2 параметра:
• Обработчик образа
• Указатель на UEFI System Table
Эти два параметра позволяют выполнять следующие операции:
Получать доступ ко всем UEFI сервисам, доступным на данной платформе;
Получать информацию о том, откуда был загружен образ и где в памяти он
13

14. ПРОТОКОЛЫ В UEFI

UEFI протокол это набор указателей на функции и данные, которые определены в
спецификации. Как минимум, спецификация должна определять GUID. Этот номер это настоящее название протокола. Boot сервис LocateProtocol использует GUID для
нахождения этого протокола в базе данных обработчиков. Протокол зачастую включает
в себя набор процедур и\или структур данных, называющихся структурой интерфейса
протокола. Пример определения протокола определяет одну функцию и три поля
данных.
#define EFI_DEVICE_PATH_PROTOCOL_GUID \
{0x09576e91,0x6d3f,0x11d2,0x8e,0x39,0x00,0xa0,0xc9,0x69,0x72,0x3b}
typedef struct _EFI_DEVICE_PATH_PROTOCOL {
EFI_DEVICE_PATH_GET_DRIVER_NAME GetDriverName;
UINT8 Type;
UINT8 SubType;
UINT8 Length[2];
} EFI_DEVICE_PATH_PROTOCOL;
14

15. УСТРОЙСТВО ПРОТОКОЛА В UEFI

Любой UEFI код может взаимодействовать с протоколами, однако после вызова функции ExitBootServices(), база
данных обработчиков больше не доступна.
15

16. СОБЫТИЯ:ТИПЫ СОБЫТИЙ, ПРИОРИТЕТЫ.

События являются еще одним типом объектов, которые доступны
через сервисы UEFI. Событие может быть создано и уничтожено, а
так же может находиться в активном состоянии или состоянии
ожидания. UEFI не поддерживает прерывания, необходимо
использовать события по таймеру, которые позволяют
периодически опрашивать оборудование.
Следующие элементы соответствуют всем типам событий:
Приоритет события
Вызываемая функция
Контекст
Вызываемая функция выполняется, когда событие переходит в
активное состояние, а контекст передаётся в вызываемую
функцию.
Определены следующие уровни приоритетов:
TPL_APPLICATION - уровень на котором выполняются UEFI
приложения;
TPL_CALLBACK - уровень для большинства вызываемых
функций;
TPL_NOTIFY - уровень для большинства устройства
ввода\вывода;
TPL_HIGH_LEVEL - уровень для одноразового таймера;
16

17. 2. Доверенная загрузка в UEFI - Secure Boot

SecureBoot — это программная технология, при
помощи которой UEFI-совместимая прошивка может
проверить подлинность исполняемых ей внешних
компонентов (загрузчиков, драйверов и UEFI
OptionROM'ов) В качестве алгоритма ЭЦП в данный
момент стандартом рекомендуется комбинация из
RSA2048 и SHA256
На вершине находится PK (Platform Key) — главный ключ, устанавливающий доверительные отношения
между пользователем платформы и ее прошивкой. хранится в NVRAM в виде self-signed (сертификат получается
из открытого ключа подписью своим же парным закрытым ключом) сертификата. PK может быть сгенерирован
следующим образом:
Собственный ключ для каждого отдельного ПК.
Общий ключ для каждой модели материнской. платы.
Общий ключ каждой линейки материнской плат.
Общий ключ для всех плат производителя. Наименее безопасное, но при этом чуть ли не самое популярное
решение.
17

18. Конфигурация базы ключей Secure Boot

Ключи по умолчанию
Пример содержимого базы ключей ASUS
PK -предоставляется производителем материнской
платы
PKDefault Variable Certificate (Platform Master Key):
KEK -сертификат Microsoft Corporation KEK CA
2011
ASUSTeK MotherBoard PK Certificate
KEKDefault Variable Certificates (Database Management):
db -обязательно присутствует сертификат Microsoft
Windows Production CA 2011, иногда к нему
добавляют сертификат Canonical Ltd. и сертификат
производителя платформы, которым подписаны
разного рода утилиты для обновления прошивки.
dbx на большинстве систем пустое.
ASUSTeK MotherBoard KEK Certificate
Конфигурация может быть разрушена удалением
стандартных ключей и добавлением собственных
из BIOS Setup или утилты Keytool.efi)
ASUSTeK MotherBoard SW Key Certificate
Получить содержимое базыпрограмма Insyde Software
Secure Boot Checkup Utility
Microsoft Corporation KEK CA 2011
Canonical Ltd. Master Certificate Authority
dbDefault Variable Certificates and Hashes (Allowed
Signers):
ASUSTeK Notebook SW Key Certificate
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Canonical Ltd. Master Certificate Authority
Ключом CA 2011- загрузчики Майкрософт. Ключом
Microsoft UEFI- компоненты третьих сторон (например,
загрузчик Shim). Сертификатом Canonical Ltd. Master
подписываются загрузчики efilinux/grub2
18

19. Интерфейс для настройки SecureBoot

.
Интерфейс настройки UEFI SecureBoot может сильно отличаться в
зависимости от производителя платформы. Общее-интерфейс в BIOS Setup
по удалению текущего PK (т.е. перевода SecureBoot в так называемый Setup
Mode).
1.Запустить любое EFI-приложение, способное вызвать UEFI-сервис gRS
–> SetVariable с предоставленными пользователем данными, в том числе
утилиту KeyTool.efi из пакета efitools, которая специально предназначена для
управления ключами.
2. Для генерации ключей целесообразно использовать дистрибутив
GNU/Linux, (запустить с LiveUSB). Для него существует целых два набора
утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign.
19

20. Инструменты для генерации новых ключей для SecureBoot

.
Инструменты efitools/sbsigntool:
Пакет openssl и одноименная утилита из него для генерирования
ключевых пар и преобразования сертификатов из DER в PEM.
1.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для
преобразования сертификатов в формат ESL и подписи файлов в этом
формате, и KeyTool.efi для управления ключами системы, находящейся в
Setup Mode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых
файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM'ов и
приложений для UEFI Shell) собственным ключом.
4. Пакет uuid-runtime, а точнее утилита uuidgen для генерации
случайных GUID.
20

21. Генерация собственных ключей для SecureBoot.

Ключей понадобится сгенерировать три: PK, KEK и ISK.
Генерация PK, с помощью OpenSSL требуется сгенерировать ключевую пару
RSA2048/SHA256 со сроком действия на один год, под названием Platform Key, с
выводом закрытого ключа в файл PK.key, а открытого — в файл PK.pem. Выполнить
команду:
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Platform
Key" -keyout PK.key -out PK.pem
после чего ввести и подтвердить пароль, который потом понадобится при попытке
подписи сгенерированным закрытым ключом. Аналогично генерируются ключевые
пары для KEK и ISK, пароли при этом лучше вводить разные:
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Key
Exchange Key" -keyout KEK.key -out KEK.pem
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Image
Signing Key" -keyout ISK.key -out ISK.pem
21

22. Конвертация открытых ключей в формат ESL

Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI
SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел
30.4.1 в текущей версии 2.6) и интересен тем, что файлы в нем можно соединять друг с
другом конкатенацией, и этот факт будет полезен позже.
cert-to-efi-sig-list -g "$(uuidgen)" PK.pem PK.esl
cert-to-efi-sig-list -g "$(uuidgen)" KEK.pem KEK.esl
cert-to-efi-sig-list -g "$(uuidgen)" ISK.pem ISK.esl
Ключ -g добавляет к сгенерированному ESL-файлу GUID, в данном случае —
случайный, полученный запуском утилиты uuidgen и использованием ее вывода. Если
этой утилиты нет, можно придумать GUIDы самостоятельно или оставить значение по
умолчанию.
22

23. Подпись ESL-файлов.

Для правильной работы SecureBoot необходимо:
PK должен быть подписан сам собой
KEK должен быть подписан PK
хранилища db и dbx — соответственно KEK.
При этом PK должен быть единственным.
Ключей KEK может быть несколько. В частности предустановленным ключом Microsoft
из KEK могут быть подписаны— db и dbx, т.е. если ключ Microsoft оттуда не удалить, то у
Microsoft будет возможность управлять содержимым db и dbx, т.е. добавлять любые новые
ключи или хеши в список доверенной загрузки и удалять из него существующие.
23

24. Добавление Microsoft в авторизованные пользователи платформы

Скачать сертификат Microsoft Corporation KEK CA 2011 в формате DER. Из него
нужно сначала получить PEM командой:
openssl x509 -in MicCorKEKCA2011_2011-06-24.crt -inform DER -out MsKEK.pem outform PEM
сконвертировать полученный PEM в ESL командой:
cert-to-efi-sig-list -g "$(uuidgen)" MsKEK.pem MsKEK.esl
добавить получившийся файл к файлу KEK.esl командой:
cat KEK.esl MsKEK.esl > NewKEK.esl
mv -f NewKEK.esl KEK.esl
24

25. Завершение формирования базы ключей SecureBoot

Для обеспечения возможности загрузки Windows и подписанных ключом Microsoft
исполняемых компонентов (GOP-драйверов внешних видеокарт и PXE-драйверов
внешних сетевых адаптеров), к сгенерированному ISK.esl надо добавить ключ
Microsoft Windows Production CA 2011, которым Microsoft подписывает собственные
загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются
компоненты третьих сторон ( загрузчик Shim, с помощью которого загружаются
разные дистрибутивы GNU/Linux, поддерживающие SecureBoot из коробки).
25

26. Завершение формирования базы ключей SecureBoot

Выполнить:
• конвертация из DER в PEM, затем из PEM в ESL
• добавление к db.esl и подписать любым ключом из KEK:
openssl x509 -in MicWinProPCA2011_2011-10-19.crt -inform DER -out MsWin.pem -outform PEM
openssl x509 -in MicCorUEFCA2011_2011-06-27.crt -inform DER -out UEFI.pem -outform PEM
cert-to-efi-sig-list -g "$(uuidgen)" MsWin.pem MsWin.esl
cert-to-efi-sig-list -g "$(uuidgen)" UEFI.pem UEFI.esl
cat ISK.esl MsWin.esl UEFI.esl > db.esl
Подпись PK самим собой:
sign-efi-sig-list -k PK.key -c PK.pem PK PK.esl PK.auth
Подпись KEK.esl ключом PK:
sign-efi-sig-list -k PK.key -c PK.pem KEK KEK.esl KEK.auth
Подпись db.esl ключом KEK:
sign-efi-sig-list -k KEK.key -c KEK.pem db db.esl db.auth
26

27. Подпись UEFI-загрузчика.

27
UEFI – загрузчики операционных систем
Windows хранит свои загрузчики в системных разделах EFI, по адресу
\EFI\BOOT\BOOTx64.efi и \EFI\Microsoft\Boot\bootmgfw.efi. По сути это два одинаковых
файла, с одинаковой подписью, но разными именами.
Ubuntu - \EFI\BOOT\BOOTx64.efi .
Проверка работы SecureBoot
1.Подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу
SecureBoot после добавления собственных ключей. Для примера, можно подписать
утилиту RU.efi.
2.Исполняемый файл
следующей командой:
подписывается
и
переименовывается
в
«bootx64.efi»
sbsign --key ISK.key --cert ISK.pem --output bootx64.efi RU.efi
В результате выполненных операций получилось три файла .auth, которые нужно
записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком
порядке, воспользовавшись утилитой KeyTool.efi или интерфейсом BIOS Setup.

28. 3. Контроль UEFI - cредства доверенной загрузки

Модель нарушителя и вектора атак
Вектора атак:
•SPI Flash
•TPM
•SMI Handlers
•NVRAM
•SMM
•DXE
•PCI-устройства
•Настройки BIOS/UEFI
•SecureBoot
28

29. Векторы атак на UEFI

SPI Flash – хранилище основной прошивки (в большинстве современных систем это 1-2 микросхемы
NOR-flash с интерфейсом SPI);
TPM (trusted platform module) – хранилище паролей и ключей шифрования;
SMI Handlers – обработчики прерываний SMM (режима системного управления);
DXE (driver execution environment) – среда исполнения драйверов;
хранилище прошивки PCI-устройств. Вредоносный код вставляется в прошивку какого-либо PCIустройства (Option ROM), к примеру, сетевой карты, UEFI выполняет этот код при инициализации
устройства;
настройки BIOS /UEFI (например, NVRAM);
SecureBoot – получение возможности загрузить любую операционную систему.
Способы установки и запуска вредоносного кода:
смена порядка загрузки ОС или невозможность загрузки ОС;
перехват данных (например, пароля BIOS);
манипуляция или порча переменных, процедур, регистров, областей памяти и т.п. в компонентах BIOS /
UEFI;
запрет подсистемы защиты или обход защищенной загрузки (secure boot);
кража криптографических ключей и сертификатов
29

30. Контроль за состоянием среды UEFI при помощи СДЗ уровня платы расширения

Основное назначение СДЗ:
реализация функции по предотвращению несанкционированного доступа к программным и
техническим ресурсам средств вычислительной техники на этапе до загрузки ОС
Основные функциональные возможности:
Исполнение PCI-E low profile,
60 x 80 мм
Исполнение M.2 key B/M,
22 x 30 мм
1. Блокировка загрузки пользователями нештатных копий ОС со съемных устройств.
2. Идентификация и аутентификация пользователей при помощи паролей и/или персональных
электронных идентификаторов.
3. Невозможность обхода процесса доверенной загрузки с помощью внешних органов
управления.
4. Контроль целостности загрузочных секторов устройств хранения данных, аппаратной и
программной конфигураций ЭВМ, реестра ОС семейства Microsoft Windows и файлов.
5. Регистрация в журнале происходящих событий в системе до доверенной загрузки ОС.
6. Диагностика аппаратных и программных средств на различных этапах его работы.
7. Генерирование паролей пользователей и PIN-кодов к персональным идентификаторам с
применением аппаратного или программного датчиков случайных чисел.
8. Аппаратный контроль за внешними устройствами хранения данных.
9. Наличие сторожевого таймера.
30

31. Пример интерфейса СДЗ уровня платы расширения

31

32. Средство доверенной загрузки уровня загрузочной записи

СДЗ предназначен для осуществления сокрытия сведений о структуре и размещении разделов жесткого диска путем
реализации следующих процессов:
1) получение управления до загрузки штатной операционной системы;
2) идентификация и аутентификация пользователя;
3) обеспечение доступности разделов жесткого диска (или другого соответствующего носителя) со штатной
операционной системой, данными пользователя и иной информацией в случае положительной аутентификации
пользователя с последующей загрузкой штатной операционной системы;
4) блокировка загрузки в случае превышения числа неудачных попыток аутентификации пользователя;
5) обеспечение недоступности штатными средствами операционной системы разделов жесткого диска (или другого
соответствующего носителя) со штатной операционной системой, данными пользователя и другой информацией в
случае загрузки нештатной операционной системы;
6) регистрация событий безопасности и запись аудита в выделенную область памяти в среде функционирования.
32

33. Алгоритм работы СДЗ уровня загрузочной записи

33

34. Структура разделов НЖМД при работе СДЗ УЗЗ

Структура НЖМД до преобразования:
Наименование
области
PMBR
Описание
GPT
Header
GPT
Array
Общие области диска
Примечание
Basic data partition
(recovery)
EFI system partition
Microsoft
reserved
partition
Basic data
partition
Раздел 1 –
восстановление OC
Windows
Раздел 2 –
загрузочный раздел EFI
Раздел 3 –
зарезервировано
ОС Windows
Раздел 4 –
основной OC
Windows
NTFS (1)
FAT32 (2)
(3)
NTFS (4)
GPT Array
GPT Header
Общие области диска
(копия)
Структура НЖМД после преобразования:
Наименование
области
PMBR
Описание
GPT
Header
GPT
Array
Общие области диска
(все разделы, кроме раздела
2,скрыты)
Примечание
1.
2.
3.
4.
5.
Basic data
partition
(recovery)
EFI system
partition
EFI system
partition (SDZ)
Microsoft
reserved
partition
Basic data
partition
Раздел 1 –
восстановление
OC Windows
Раздел 2 –
загрузочный
раздел EFI
Раздел 3 – ядро
СДЗ
Раздел 4 –
зарезервировано
ОС Windows
Раздел 5 –
основной OC
Windows
NTFS (1)
FAT32 (2)
FAT32 (5)
(3)
NTFS (4)
GPT Array
GPT Header
Общие области диска
(копия)
Файловая система – NTFS. Структура:
Recovery
WindowsRE
ReAgent.xml
Winre.wim
boot.sdi
Файловая система – FAT32. ESP или EFISYS раздел. С этого раздела UEFI запускает загрузчик и приложение UEFI
Раздел, который создается для резервирования части дискового пространства для возможного последующего использования
операционной системой Windows, установленной на отдельном разделе.
Файловая система – NTFS. Раздел с основными модулями ОС Windows10
Файловая система – FAT32. Раздел, содержащий модули СДЗ
34

35. Использование СДЗ в различных системах 1

№
35
Приказ № 17/31/235
Уровень защищенности
ГИС/АСУ ТП/КИИ
Класс защиты СДЗ
3
2
1
3 СДЗ уровня платы расширения 4 класса
+
+
4 СДЗ уровня BIOS 4 класса
+
+
1 СДЗ уровня загрузочной записи 6 класса
2 СДЗ уровня загрузочной записи 5 класса
№
+
Приказ № 21
Уровень защищенности ИСПДн
Класс защиты СДЗ
4
3
2
1
+
+
3 СДЗ уровня платы расширения 4 класса
+
+
4 СДЗ уровня BIOS 4 класса
+
+
1 СДЗ уровня загрузочной записи 6 класса
2 СДЗ уровня загрузочной записи 5 класса
Красным цветом отмечены обязательные требования по применению данных мер защиты. Для
АСУ ТП указанные меры являются дополнительными (компенсационными).

36. Использование СДЗ в различных системах 2

№
Класс защищенности АС
Класс защиты СДЗ
1Д
1Г
1 СДЗ уровня загрузочной записи 6 класса
+
2 СДЗ уровня загрузочной записи 5 класса
+
3 СДЗ уровня платы расширения 4 класса
+
+
4 СДЗ уровня BIOS 4 класса
+
+
№
Класс защиты СДЗ
Сведения, составляющие ГТ
1В (С)
1Б (СС)
1А (ОВ)
1 СДЗ уровня загрузочной записи 6 класса
2 СДЗ уровня загрузочной записи 5 класса
3 СДЗ уровня платы расширения 4 класса
4 СДЗ уровня BIOS 4 класса
5 СДЗ уровня платы расширения 3 класса
+
6 СДЗ уровня BIOS 3 класса
+
7 СДЗ уровня платы расширения 2 класса
+
8 СДЗ уровня BIOS 2 класса
+
9 СДЗ уровня платы расширения 1 класса
+
10 СДЗ уровня BIOS 1 класса
+
36

37.

Использование СДЗ в различных системах 2
№
Класс защищенности АС
Класс защиты СДЗ
1Д
1Г
1 СДЗ уровня загрузочной записи 6 класса
+
2 СДЗ уровня загрузочной записи 5 класса
+
3 СДЗ уровня платы расширения 4 класса
+
+
4 СДЗ уровня BIOS 4 класса
+
+
№
Класс защиты СДЗ
Сведения, составляющие ГТ
1В (С)
1Б (СС)
1А (ОВ)
1 СДЗ уровня загрузочной записи 6 класса
2 СДЗ уровня загрузочной записи 5 класса
3 СДЗ уровня платы расширения 4 класса
4 СДЗ уровня BIOS 4 класса
5 СДЗ уровня платы расширения 3 класса
+
6 СДЗ уровня BIOS 3 класса
+
7 СДЗ уровня платы расширения 2 класса
+
8 СДЗ уровня BIOS 2 класса
+
9 СДЗ уровня платы расширения 1 класса
+
10 СДЗ уровня BIOS 1 класса
+
37

38.

Обзор рынка СДЗ.
38