Оценка и соответствие

Версия: 0.1

1. Принцип

Система оценивается не по тому, загружается ли она, и не по количеству функций, которые в неё входят. Оценка отвечает на вопросы:

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

Зелёный конвейер доказывает, что конвейер отработал. Ничего из перечисленного он не доказывает.

2. Уровни доказательств

Свойство заявляется только на том уровне, на котором оно наблюдалось. Параметр ядра, присутствующий в файле конфигурации, — это доказательство уровня E2 о конфигурации, а не доказательство уровня E4 о работающей системе.

Требуемые минимальные уровни:

3. Корпус проверок

Каждый продукт ведёт корпус проверок. Каждая запись имеет вид:

CHECK-ID
требование           SCF-*
свойство             что должно быть истинно
метод                инструмент, команда или процедура
среда                офлайн | эмуляция | эталонное оборудование
ожидаемый результат
уровень доказательств
ответственный

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

Базовый корпус — это минимум, а не полное отображение Конституции. Если требованию здесь нет соответствующей записи, продукт MUST добавить её в собственный корпус до того, как заявит это требование выполненным; требование, заявленное без записи, остаётся декларацией уровня E0.

3.1 Спецификация и происхождение

3.2 Артефакты и аттестация

3.3 Целостность загрузки

3.4 Криптография и учётные данные

3.5 Изоляция и поверхность атаки

3.6 Данные и приватность

3.7 Обновления и уязвимости

3.8 Право и жизненный цикл

3.9 Поверхности взаимодействия с человеком

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

4. Severity

• S0 Blocker — системе нельзя доверять и нельзя её использовать: она не загружается, обновление выводит её из строя, данные теряются, секрет общий для всех установок, артефакт не подписан или не учтён, либо сообщение об активной эксплуатации невозможно обработать.
• S1 Critical — заявленное продуктом свойство безопасности или приватности не выполняется в поставляемой конфигурации.
• S2 Major — требуемое свойство выполняется только после ручной настройки, либо откат и восстановление работают лишь в части случаев.
• S3 Moderate — доказательства слабее требуемого уровня, либо документация противоречит поведению.
• S4 Minor — локальная несогласованность, не влияющая на заявленные свойства.
• Observation — гипотеза, не подтверждённый дефект.

Серьёзность определяется последствиями для людей и организаций, которые эксплуатируют систему, а не заметностью проблемы.

5. Уровни соответствия

SCF-Declared

• профили выбраны;
• матрица трассировки существует;
• известные исключения зарегистрированы.

Это означает начало процесса. Это не знак качества, и он MUST NOT представляться как знак качества.

SCF-Conformant

• выполнено каждое применимое MUST;
• каждое исключение из SHOULD обосновано и зарегистрировано;
• весь базовый корпус проверок выполнен на требуемом уровне доказательств, включая проверки на эталонном оборудовании;
• выпуск пересобираем из своего lock;
• состав продукта (SBOM), происхождение и подписи полны;
• срок поддержки, контракт обновлений и политика раскрытия опубликованы.

SCF-Validated

• выполнено SCF-Conformant, дополнительно:
• выпуск независимо пересобран и сличён;
• пути высокого риска — целостность загрузки, обновление, откат, восстановление, удаление данных — продемонстрированы на эталонном оборудовании;
• процесс работы с уязвимостями не только описан, но и отработан;
• эксплуатационный мониторинг на срок поддержки определён и обеспечен людьми.

Заявление о соответствии MUST называть версию SCF, профили, выпуск, архитектуры и эталонное оборудование, к которым оно относится. Заявление без этих границ недействительно.

6. Матрица трассировки

обязательство (право, модель угроз, требование заказчика)
→ требование SCF
→ требование продукта
→ поле спецификации, компонент или политика
→ реализация
→ автоматическая проверка
→ ручной или аппаратный сценарий
→ текущие доказательства и их уровень
→ исключения

Требование, у которого нет пути к доказательству, неполно и MUST NOT считаться выполненным.

7. Контрольный этап перед выпуском

Перед подписанием выпуска:

1. область изменения определена, затронутые профили перечислены;
2. lock полон, каждый вход аутентифицирован и зафиксирован;
3. сборка выполнена в соответствующем требованиям контуре, её журнал сохранён;
4. все офлайн-проверки пройдены, включая проверки лицензий, товарных знаков и уязвимостей;
5. состав продукта (SBOM), манифест и происхождение полны и валидны;
6. поколение цепочки загрузки актуально относительно политики отзыва;
7. динамическая проверка в эмуляции пройдена;
8. проверка на эталонном оборудовании пройдена для загрузки, обновления, отката, восстановления и шифрования накопителя;
9. проверки доступности, требуемые применимыми профилями HIF, пройдены;
10. срок поддержки, канал и дата окончания жизненного цикла установлены и опубликованы;
11. у каждого открытого исключения есть ответственный и не истёкшая дата пересмотра;
12. выпуск утверждает названный человек, утверждение фиксируется вместе с доказательствами.

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

8. Исключения

ID
версия и требование SCF
продукт и профиль
причина
затронутые пользователи, устройства и данные
риск и вероятность
компенсирующая мера
ответственный
срок действия или дата пересмотра
доказательства

Истёкшее исключение блокирует новое заявление о соответствии, пока не пересмотрено. Исключение MUST NOT использоваться для закрепления постоянного архитектурного решения; если требование неверно, предложите изменение стандарта.

9. После выпуска

Срок поддержки — часть продукта, поэтому оценка не заканчивается выпуском.

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

10. Изменение стандарта

Если продукт не может выполнить SCF:

1. проверить, не является ли проблема локальной архитектурой, а не требованием;
2. проверить альтернативы, включая другое семейство платформ;
3. зарегистрировать исключение с доказательствами;
4. собирать доказательства не менее одного цикла выпуска;
5. только затем предложить изменение стандарта.

Широко распространённая отраслевая практика не является доказательством того, что требование неверно. Отсутствие возможности в вышестоящем проекте — ограничение, которое фиксируется, а не основание для более слабого заявления.