Конституция построения систем

Версия: 0.1

Этот документ содержит универсальные требования SCF. Профиль продукта MAY делать требование строже, но MUST NOT ослаблять его без зарегистрированного исключения и оценки риска.

Нормативные слова: MUST / MUST NOT формулируют требование соответствия SCF; SHOULD / SHOULD NOT формулируют ожидаемое решение, отступление от которого требует обоснования доказательствами и зарегистрированного исключения; MAY формулирует допустимый выбор, подчинённый более сильным требованиям.

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

1. Продукт и управление — SCF-GOV

SCF-GOV-001. Определение продукта

Система MUST быть определена как продукт: с заявленным назначением, предполагаемым контекстом развёртывания, моделью угроз, сроком поддержки, политикой данных и ответственным лицом. Образ без этого — артефакт сборки, а не система, и MUST NOT представляться как выпущенная система.

SCF-GOV-002. Объявленные границы ответственности

Производитель MUST заявить, за какие компоненты он отвечает, какие берёт из вышестоящего проекта (upstream) и какие явно исключает. Заявление MUST быть доступно получателю до установки.

SCF-GOV-003. Модель угроз

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

SCF-GOV-004. Срок поддержки объявлен до приобретения

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

SCF-GOV-005. Безопасность по умолчанию, а не по настройке

Конфигурация по умолчанию MUST быть безопасной конфигурацией. Руководство по усилению защиты MUST NOT быть механизмом, за счёт которого система выполняет собственные заявления о безопасности.

SCF-GOV-006. Нет заявления без доказательства

Опубликованное заявление о безопасности, приватности, соответствии, воспроизводимости или сертификации MUST быть ограничено проверенными границами и подкреплено сохранёнными доказательствами. Маркетинговые формулировки MUST NOT выходить за пределы доказательств.

SCF-GOV-007. Исключения с ответственным

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

SCF-GOV-008. Юрисдикция и размещение данных

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

2. Спецификация — SCF-SPC

SCF-SPC-001. Декларативная спецификация

Система MUST описываться декларативной спецификацией, полноты которой достаточно для её построения. Полнота подтверждается требованием SCF-REP-001: если систему невозможно пересобрать из одной только её спецификации и фиксации входов (lock), спецификация неполна.

SCF-SPC-002. Каноническая форма и устойчивая идентичность

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

SCF-SPC-003. Нет скрытых входов

Всё, что способно изменить результат, MUST присутствовать в спецификации или в производной от неё фиксации входов (lock): источники, версии, архитектура, локаль, отметки времени, корни доверия и ключи проверки, наложения, обработчики и версии движка. Окружающее состояние хоста MUST NOT влиять на результат. Ключи подписи входами не являются и MUST NOT в ней присутствовать (SCF-CRY-003).

SCF-SPC-004. Слоистая композиция с видимым приоритетом

Если спецификация составляется из базы и переопределений, порядок приоритета MUST быть определён, а действующий результат MUST быть доступен для просмотра до начала сборки.

SCF-SPC-005. Проверенный ввод

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

SCF-SPC-006. Переносимость намерения

Спецификация SHOULD выражать намерение — «усиленный сервер с такими-то службами» — отдельно от платформенной механики. Если намерение невозможно выразить переносимо, платформозависимая часть MUST быть явно помечена.

SCF-SPC-007. Экспорт без привязки к поставщику

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

3. Источники и происхождение — SCF-SRC

SCF-SRC-001. Названный источник

Каждый вход MUST иметь названное происхождение, зафиксированное в lock: проект, архив, набор, компонент, версию и криптографический дайджест.

SCF-SRC-002. Аутентифицированное получение

Каждый вход MUST быть аутентифицирован подписью или дайджестом, привязанным к ключу, которому производитель доверился намеренно. Защита транспорта MUST NOT быть единственным механизмом целостности.

SCF-SRC-003. Явные корни доверия

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

SCF-SRC-004. Зафиксированное состояние архива

Сборка выпуска MUST разрешаться относительно зафиксированного состояния архива — среза архива, неизменяемого индекса, коммита или полного списка дайджестов, — чтобы тот же lock позднее давал те же входы. Если платформа не предоставляет службы архива, производитель MUST поддерживать собственный неизменяемый срез использованных входов.

SCF-SRC-005. Хранение в течение срока поддержки

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

SCF-SRC-006. Проверка сторонних компонентов и открытого кода

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

SCF-SRC-007. Обязанность передать исправление upstream

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

4. Выполнение сборки — SCF-BLD

SCF-BLD-001. Код, выполняемый во время сборки, недоверен

Сценарии сопровождающих, обработчики, системы сборки и ядро сборочной среды MUST рассматриваться как недоверенный код. Граница изоляции из SCF-BLD-002 MUST выдерживать проверку, при которой внутри неё выполняется произвольный код. Запуск средства сборки от имени непривилегированного пользователя MUST NOT приниматься за такую границу.

SCF-BLD-002. Граница изоляции

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

SCF-BLD-003. Нет общего состояния сборок

Сборка MUST NOT наследовать изменяемое состояние от предыдущей сборки или от другого арендатора. Кэши MAY быть общими только при адресации по содержимому и доступе к ним из сборки исключительно на чтение.

SCF-BLD-004. Контролируемая сеть

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

SCF-BLD-005. Безопасное извлечение артефактов

Результаты сборки MUST извлекаться способом, не требующим от хоста разбирать или монтировать файловую систему, созданную внутри сборки.

SCF-BLD-006. Ограниченные ресурсы

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

SCF-BLD-007. Минимальные привилегии внутри границы

Внутри границы изоляции стадии, не требующие привилегий, MUST NOT выполняться с ними. Если платформа допускает непривилегированное построение корневых файловых систем и образов, непривилегированный путь SHOULD быть предпочтительным.

SCF-BLD-008. Полный и атрибутируемый журнал

Каждая сборка MUST порождать журнал, в котором указаны lock, движок и его версия, каждый разрешённый вход, каждая стадия, её результат и её длительность. Журнал MUST сохраняться вместе с выпуском.

SCF-BLD-009. Платформа построения входит в границы

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

5. Воспроизводимость — SCF-REP

SCF-REP-001. Пересобираемость из lock

Каждый выпуск MUST быть пересобираемым из одного только lock, в чистой среде, не менее срока поддержки.

SCF-REP-002. Честное заявление о воспроизводимости

Заявление о побитовом совпадении MUST быть ограничено профилем, платформой и архитектурой, на которых оно подтверждено независимой пересборкой. Если входы невоспроизводимы, честным заявлением является «пересобираем из lock», и разницу MUST указывать.

SCF-REP-003. Средства обеспечения детерминизма

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

SCF-REP-004. Проверка пересборки в конвейере

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

6. Артефакты и аттестация — SCF-ART

SCF-ART-001. Манифест

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

SCF-ART-002. Машиночитаемый состав продукта

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

SCF-ART-003. Аттестация происхождения

Каждый выпуск MUST сопровождаться подписанной аттестацией происхождения, описывающей платформу сборки, lock и входы. Она MUST порождаться управляющим контуром по записи сборки, а не заявляться человеком, и MUST NOT порождаться внутри сборочной среды.

SCF-ART-004. Подписанные артефакты и дайджесты

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

SCF-ART-005. Неизменяемые выпуски

Выпуск MUST быть неизменяемым. Исправление — это новый выпуск. Каналы являются перемещаемыми указателями на выпуски; сами выпуски не перемещаются.

SCF-ART-006. Инструкция по проверке идёт вместе с артефактом

Инструкции по проверке подписи и дайджеста MUST публиковаться вместе с загрузкой, в форме, которой получатель может следовать, не обращаясь к производителю.

SCF-ART-007. Доступность исходного кода выпуска

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

7. Целостность загрузки — SCF-BOOT

SCF-BOOT-001. Объявленная модель доверия при загрузке

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

SCF-BOOT-002. Честный статус Secure Boot

Система MUST указывать, загружается ли она с включённой проверкой на уровне прошивки в конфигурации по умолчанию. Система, требующая от пользователя отключить проверку прошивки, MUST сообщать об этом до установки и MUST NOT называть себя совместимой с Secure Boot.

SCF-BOOT-003. Не разрывать унаследованную цепочку

Если система наследует подписанную цепочку загрузки от вышестоящего дистрибутива, она MUST NOT заменять или пересобирать компонент этой цепочки, не имея возможности подписать замену ключом, которому цепочка доверяет. Если компонент всё же заменён, система MUST объявить, что унаследованная цепочка более не действует.

SCF-BOOT-004. Актуальность отзывов

Компоненты загрузки MUST NOT поставляться в поколении, которое отвергается действующей политикой отзыва. Метаданные отзыва MUST проверяться автоматически перед каждым выпуском, и эта проверка MUST входить в контрольный этап выпуска.

SCF-BOOT-005. Зависимость от удостоверяющей стороны подписи — риск продукта

Зависимость от внешней удостоверяющей стороны подписи — срок действия её сертификата, её порядок проверки и её сроки — MUST фиксироваться как риск продукта с названным запасным планом. План продукта MUST NOT исходить из того, что запрос на подпись будет удовлетворён.

SCF-BOOT-006. Измерение там, где платформа его поддерживает

Если платформа предоставляет средство измерения, цепочка загрузки SHOULD измеряться, измеренные значения SHOULD документироваться, а всё, что запечатано под эти значения, MUST иметь документированный путь восстановления на случай их правомерного изменения.

SCF-BOOT-007. Проверяемый системный том для неизменяемых профилей

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

SCF-BOOT-008. Защита от отката

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

8. Криптография и ключи — SCF-CRY

SCF-CRY-001. Письменная политика алгоритмов

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

SCF-CRY-002. Устаревшие примитивы вне решений о доверии

Устаревшие примитивы хеширования и подписи MUST NOT использоваться ни в одном решении, предоставляющем доверие: подписи архивов, подписи артефактов, проверка обновлений, аутентификация.

SCF-CRY-003. Хранение ключей

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

SCF-CRY-004. Отдельные ключи для отдельных назначений

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

SCF-CRY-005. Смена и отзыв ключей спроектированы

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

SCF-CRY-006. Случайность при первой загрузке

Система MUST обеспечить корректно инициализированный источник случайности до порождения любого долгоживущего секрета. Секреты, которые должны быть уникальны для каждой установки, регулируются требованием SCF-IDN-001.

SCF-CRY-007. Криптографические заявления ограничены

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

9. Изоляция и поверхность атаки — SCF-ISO

SCF-ISO-001. Минимальная устанавливаемая поверхность

Система MUST устанавливать только то, что требуется её заявленному назначению. Компоненты, присутствующие «на случай, если понадобятся», — это поверхность атаки, и они MUST быть обоснованы в профиле.

SCF-ISO-002. Нет слушающих служб по умолчанию

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

SCF-ISO-003. Мандатное управление доступом работает принудительно

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

SCF-ISO-004. Ограничение прав служб

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

SCF-ISO-005. Базовый профиль усиления защиты ядра

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

SCF-ISO-006. Неподписанный код не попадает в ядро

Загружаемый код ядра MUST быть подписан ключом, которому доверяет работающее ядро. Если профиль допускает сторонние модули, процедура регистрации ключа MUST быть документирована, включая её ручные шаги и их последствия.

SCF-ISO-007. Перечисленные пути повышения привилегий

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

SCF-ISO-008. Умолчания изоляции не ослабляются ради удобства

Умолчание, отключающее средство изоляции платформы ради работоспособности приложения, MUST быть зарегистрировано как исключение по SCF-GOV-007 и MUST NOT применяться молча.

SCF-ISO-009. Умолчания хоста виртуализации

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

SCF-ISO-010. Умолчания среды выполнения контейнеров

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

10. Идентичность и учётные данные — SCF-IDN

SCF-IDN-001. Никаких поставляемых учётных данных

Образ MUST NOT содержать пароль по умолчанию, закрытый ключ по умолчанию, API-токен по умолчанию или любые иные заранее заданные учётные данные, общие для разных установок.

SCF-IDN-002. Качество учётных данных и блокировка

Конфигурация аутентификации по умолчанию MUST использовать современную схему хеширования паролей и MUST противостоять сетевому подбору за счёт ограничения частоты попыток или блокировки.

SCF-IDN-003. Автоматический вход — объявленное исключение

Автоматический вход и административный доступ без пароля MUST быть выключены по умолчанию. Если профиль их требует, они MUST быть объявлены, ограничены по области и дополнены компенсирующей мерой.

SCF-IDN-004. Строгая аутентификация поддерживается

Система SHOULD поддерживать аппаратные аутентификаторы для интерактивного входа и для повышения привилегий и MUST документировать порядок их включения.

SCF-IDN-005. Административные действия атрибутируемы

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

SCF-IDN-006. Объявленная сетевая и каталожная аутентификация

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

SCF-IDN-007. Изоляция локальных учётных записей

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

11. Защита данных — SCF-DAT

SCF-DAT-001. Реестр данных

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

SCF-DAT-002. Шифрование хранимых данных доступно и заметно

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

SCF-DAT-003. Разумные умолчания шифрования

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

SCF-DAT-004. Шифрование при передаче

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

SCF-DAT-005. Сообщение о нарушении целостности

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

SCF-DAT-006. Удаление данных и сброс

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

SCF-DAT-007. Согласованность и восстановление файловых систем

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

SCF-DAT-008. Резервное копирование и восстановление

Система MUST документировать, как хранимые ею данные можно скопировать в резервную копию и восстановить, включая то, чего восстановление не возвращает. Профиль MAY требовать, чтобы механизм поставлялся и был включён, а не только описан.

12. Приватность и телеметрия — SCF-PRV

SCF-PRV-001. Сетевая тишина по умолчанию

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

SCF-PRV-002. Телеметрия только по согласию

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

SCF-PRV-003. Нет устойчивого идентификатора устройства без необходимости

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

SCF-PRV-004. Минимизация

Данные, не необходимые для заявленного назначения, MUST NOT собираться, а собранные данные MUST храниться не дольше, чем требует это назначение.

SCF-PRV-005. Отчёты о сбоях и диагностике согласуются по каждому событию

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

SCF-PRV-006. Поведенческие журналы можно отключить

Если система наблюдает за поведенческой, пользовательской или диагностической активностью или ведёт её журнал, пользователь или оператор MUST иметь возможность это отключить, а последствия MUST быть указаны. Это не распространяется на записи, требуемые SCF-IDN-005, SCF-OPS-002 и SCF-OPS-006, которые профиль MAY сделать обязательными.

13. Сеть и время — SCF-NET

SCF-NET-001. Запрет входящего трафика по умолчанию

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

SCF-NET-002. Целостность разрешения имён

Конфигурация распознавателя имён по умолчанию MUST быть документирована, и система SHOULD защищать разрешение имён от пассивного наблюдения и подмены. Решение этого не делать MUST быть явным.

SCF-NET-003. Аутентифицированное время

Синхронизация времени SHOULD быть аутентифицированной. Если поставляемый клиент не умеет аутентифицировать источник, это MUST быть зафиксировано как известное ограничение, поскольку от времени зависят проверка сертификатов, актуальность обновлений и целостность журналов.

SCF-NET-004. Нет незапрошенного обнаружения

Протоколы обнаружения, объявления и сопряжения MUST быть выключены по умолчанию, если их не требует профиль.

SCF-NET-005. Приватность канального уровня

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

SCF-NET-006. Объявленная поддержка корпоративных сетей

Система MUST объявлять, какие механизмы управляемых сетей она поддерживает — аутентификацию на уровне порта, прокси, виртуальные частные сети и регистрацию сертификатов, — и ни один из них не может быть включён по умолчанию без настройки.

14. Обновление и откат — SCF-UPD

SCF-UPD-001. Механизм обновления существует и назван

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

SCF-UPD-002. Обновления безопасности применяются автоматически

Обновления безопасности MUST применяться автоматически в конфигурации по умолчанию. Пользователь или оператор MUST иметь возможность отложить их через ясно описанное средство управления, и последствия MUST быть указаны. Конфигурация, полностью отключающая обновления безопасности, MAY предлагаться; если профиль её допускает, она MUST быть зарегистрирована по SCF-GOV-007 и MUST NOT быть умолчанием.

SCF-UPD-003. Обновления безопасности отделимы

Исправления безопасности MUST быть поставляемы без принуждения к несвязанным функциональным изменениям.

SCF-UPD-004. Проверка до применения

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

SCF-UPD-005. Безопасность при прерывании

Прерванное обновление MUST оставлять систему загружаемой. Если платформа это допускает, обновления SHOULD быть атомарными с явным шагом активации.

SCF-UPD-006. Откат спроектирован и проверен

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

SCF-UPD-007. Доступность обновлений переживает выпуск

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

SCF-UPD-008. Офлайновые и ограниченные обновления

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

SCF-UPD-009. Ограниченное число попыток активации

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

15. Работа с уязвимостями — SCF-VUL

SCF-VUL-001. Опубликованный способ сообщить

Производитель MUST публиковать контакт для сообщений об уязвимостях и политику координированного раскрытия с указанием ожидаемых сроков ответа и порядка раскрытия.

SCF-VUL-002. Определённый процесс обработки

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

SCF-VUL-003. Известные эксплуатируемые уязвимости блокируют выпуск

Выпуск MUST NOT поставляться с уязвимостью, известной как эксплуатируемая в реальных атаках, в компоненте, который он доставляет, если только подверженность не устранена конфигурацией и это рассуждение не зафиксировано. Выпуск SHOULD NOT поставляться с известной уязвимостью, поддающейся эксплуатации; если это всё же происходит, остаточный риск MUST быть зафиксирован и, если получатель может на него повлиять, опубликован по SCF-VUL-004.

SCF-VUL-004. Заявления об эксплуатируемости машиночитаемы

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

SCF-VUL-005. Бюллетени безопасности сопровождают исправления

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

SCF-VUL-006. Обязанности по уведомлению переведены в процедуру

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

16. Наблюдаемость, диагностика и восстановление — SCF-OPS

SCF-OPS-001. Система объясняет собственное состояние

Администратор MUST иметь возможность определить по работающей системе её версию, её канал, состояние обновлений, состояние целостности загрузки и действующие политики безопасности.

SCF-OPS-002. Журналы полезны и ограничены

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

SCF-OPS-003. Путь восстановления существует и достижим

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

SCF-OPS-004. Отказ читаем

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

SCF-OPS-005. Диагностические и сервисные режимы

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

SCF-OPS-006. Журнал аудита защищён от незаметного изменения

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

SCF-OPS-007. Устойчивость к сбою питания

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

17. Оборудование и прошивки — SCF-HWE

SCF-HWE-001. Объявленная матрица оборудования

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

SCF-HWE-002. Несвободные прошивки объявлены

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

SCF-HWE-003. Вопрос обновления прошивок решён

Производитель MUST указывать, способна ли система доставлять обновления прошивок устройств, а если не способна — MUST прямо сообщать об этом.

SCF-HWE-004. Межархитектурные сборки проверяются на целевой архитектуре

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

SCF-HWE-005. Управление питанием, сон и гибернация

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

SCF-HWE-006. Часы и данные часовых поясов

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

18. Поверхности взаимодействия с человеком — SCF-HUM

SCF-HUM-001. HIF применяется в полном объёме

Каждая обращённая к человеку поверхность, порождаемая системой, — оболочка, программа установки, первый запуск, восстановление, средство обновления, диалоги согласия, сообщения об ошибках, документация и сама служба построения — подчиняется применимому профилю HIF. SCF MUST NOT использоваться для его ослабления.

SCF-HUM-002. Правдивая установка

Если продукт поставляет программу установки, она MUST до начала работы сообщать, что она сотрёт, какие диски затронет и что необратимо, и MUST соответствовать фактическому эффекту.

SCF-HUM-003. Уровень защищённости виден при первом использовании

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

SCF-HUM-004. Поверхности согласия честны

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

SCF-HUM-005. Автоматическая установка тоже подотчётна

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

SCF-HUM-006. Доступность до аутентификации

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

SCF-HUM-007. Документация поставляется, а не даётся ссылкой

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

SCF-HUM-008. Передача системы оператору

Если система передаётся оператору, который её не строил, выпуск MUST включать то, что этому оператору нужно для её эксплуатации: уровень защищённости, контракт обновлений, процедуру восстановления, контакт для сообщений и дату окончания поддержки.

SCF-HUM-009. Язык и ввод текста

Система MUST поддерживать объявленные языки и раскладки клавиатуры в каждой поверхности, способной заблокировать работу, включая аутентификацию. Ввод учётных данных MUST NOT зависеть от раскладки, которую пользователь не может выбрать в этот момент, а ввод текста MUST корректно обрабатывать нелатинские письменности объявленных языков.

19. Право, лицензии и товарные знаки — SCF-LGL

SCF-LGL-001. Реестр лицензий

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

SCF-LGL-002. Тексты лицензий идут вместе с продуктом

Обязательные уведомления, тексты лицензий и указания авторства MUST поставляться вместе с системой в месте, которое получатель найдёт без доступа к сети.

SCF-LGL-003. Обязательства copyleft исполняются в том же месте

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

SCF-LGL-004. Товарные знаки upstream уважаются

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

SCF-LGL-005. Происхождение раскрывается правдиво

Система MUST указывать, от какого upstream она произведена, и MUST NOT подразумевать несуществующие аффилированность, одобрение или сертификацию.

SCF-LGL-006. Регуляторные обязательства реализуются инженерно

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

SCF-LGL-007. Экспортные и дистрибутивные ограничения соблюдаются при выдаче

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

SCF-LGL-008. Права на элементы оформления подтверждены

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

20. Жизненный цикл — SCF-LCM

SCF-LCM-001. Версии содержательны

Идентичность версии MUST различать спецификацию, выпуск и канал и MUST позволять получателю определить, что изменилось.

SCF-LCM-002. У каналов есть правила

Каждый канал MUST иметь документированные критерии продвижения, ответственного, журнал аудита и определённый путь понижения или отката.

SCF-LCM-003. Актуальность отслеживается

Производитель MUST обнаруживать изменение входов выпущенной системы на стороне upstream и MUST быть способен указать для любого выпуска, насколько он отстаёт.

SCF-LCM-004. Об окончании поддержки объявляют, а не узнают случайно

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

SCF-LCM-005. Миграция обеспечена

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

21. Доказательства и выпуск — SCF-EVD

SCF-EVD-001. Проверка проектируется вместе с требованием

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

SCF-EVD-002. Автоматические проверки выполняются на каждой сборке

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

SCF-EVD-003. Проверки, зависящие от загрузки, идут на настоящей прошивке

Свойства, зависящие от прошивки, безопасной загрузки, измерения, шифрования носителя или оборудования, MUST проверяться в среде с этими средствами, а до выпуска общей доступности — на эталонном оборудовании.

SCF-EVD-004. Доказательства сохраняются вместе с выпуском

Запись о выпуске MUST содержать lock, манифест, состав продукта, журналы, результаты проверок, исключения и одобрения и MUST храниться в течение срока поддержки.

SCF-EVD-005. Названное одобрение выпуска

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