Уровень доверия 4
Модель безопасности
Средство виртуализации 4 класса защиты обязано соответствовать 4 уровню доверия — это пункт 6 требований к средствам виртуализации, утверждённых приказом ФСТЭК России от 27 октября 2022 г. № 187. Сами уровни доверия задаёт приказ ФСТЭК России от 2 июня 2020 г. № 76 (с изменениями, внесёнными приказом от 18 апреля 2022 г. № 68). Разбор функций безопасности — в разделе Соответствие ФСТЭК; здесь разобраны требования приказа № 76.
Требования приказа № 76 адресованы не настройке платформы, а её разработке, испытаниям и сопровождению. Поэтому закрываются они тремя разными способами, и различать их важно:
- артефактами репозиториев — конвейер сборки, подпись раздачи, манифест целостности, набор тестов. Это проверяется чтением кода и конфигураций;
- документами изделия — технические условия, формуляр, функциональная спецификация, проектная документация, программа и методики испытаний. Они ведутся отдельно от этой документации, и страница на них только ссылается;
- процедурами заявителя — сроки реакции на недостатки, рассылка обновлений, информирование об окончании поддержки.
Таблица 1 приказа помечает три требования, которые предъявляются к четвёртому уровню доверия и не предъявляются к пятому и шестому. Это разработка модели безопасности средства (п. 8.2), анализ скрытых каналов (п. 20.2) и — по аппаратной платформе — часть требований к проектной документации (п. 12.3). Первые два и составляют содержательную дельту четвёртого уровня.
Соответствие
Требования к разработке и производству
Хостовая операционная система (п. 7).
Требование внешнее по отношению к платформе: хостовая ОС должна быть сертифицирована на 4 класс защиты и 4 уровень доверия по требованиям к операционным системам, утверждённым приказом ФСТЭК России от 19 августа 2016 г. № 119, и по приказу № 76. Функции безопасности узла — доверенная загрузка, контроль целостности, ограничение программной среды, защита памяти — реализованы в vStack OS, и сертифицируется она отдельно.
Модель безопасности средства (п. 8.2).
Требование предъявляется только к четвёртому уровню доверия. Модель должна описывать реализуемые политики управления доступом и реализуемые политики фильтрации информационных потоков, включать описание условий безопасности, выполнение которых указывает на реализацию политик, и доказательство выполнения этих условий формальным (математическим) способом. Язык описания должен быть математическим или машиночитаемым и допускать полную проверку корректности описания и доказательств независимо от разработчика модели.
Документ с таким названием в комплекте документов изделия есть. Требование при этом остаётся открытым, и различать здесь надо две вещи: наличие документа и выполнение пункта 8.2. Пункт требует формального доказательства, а не описания, и языка, допускающего проверку доказательств независимо от разработчика модели. Раздел Модель безопасности этой документации под пункт 8.2 не подходит тем более: он описывает границы доверия и политику разграничения доступа прозой и служит другой цели — объяснить устройство разграничения тому, кто настраивает платформу. См. «Границы подтверждения».
Архитектура безопасности средства (п. 9).
Архитектура должна обеспечивать невозможность обхода функций безопасности и защиту их от несанкционированного доступа, а описание — обосновывать безопасность инициализации, собственную защиту от несанкционированного доступа и невозможность обхода.
| Что требуется | Чем закрывается в платформе |
|---|---|
| Безопасность процесса инициализации | Загрузчик со встроенным доверенным якорем проверяет подпись манифеста целостности и передаёт ядру путь к манифесту и его SHA-256; ядро разбирает манифест на монтировании корня, и любая ошибка разбора останавливает загрузку узла. Сборочный профиль сертифицируемого контура этот путь запрашивает, но подписанный манифест загрузки пока не собирается, поэтому обоснование безопасности инициализации опирается на механизм, который в поставке не наполнен — см. «Границы подтверждения» |
| Невозможность обхода функций безопасности | Проверка целостности исполняемых файлов навешена не только на запуск, но и на открытие файла, на отображение в память и на изменение прав отображения. Без последних двух хуков ограничение обходилось в один вызов: файл вне манифеста нельзя запустить, но можно отобразить с правом исполнения и передать управление внутрь отображения |
| Собственная защита от несанкционированного доступа | Файлы, попавшие в манифест, защищены от записи и переименования отдельными тумблерами подсистемы контроля целостности. Подсистему переводят в состояние «включена, применяется, загрузка новых манифестов запрещена» — последний запрет снимается только перезагрузкой |
| Защита функций безопасности управляющего слоя | Авторизация каждого вызова API единой функцией; фиксированные роли неизменяемы через API; привилегии управления ролями кастомным ролям не выдаются |
Функциональная спецификация средства (п. 10.3).
Спецификация должна перечислять все функции средства, описывать назначение, способы использования и параметры каждого интерфейса функций безопасности, действия с каждым интерфейсом, сообщения об ошибках при выполнении функций безопасности и при вызове каждого интерфейса, а также перечислять интерфейсы, не влияющие на функции безопасности.
Интерфейс управляющего слоя описан в справочнике API: методы, параметры, коды ошибок и требуемые привилегии перечислены по методам, и раздел Справочник ведётся из канона API. Для требования этого недостаточно в одной части: спецификация должна разделять интерфейсы на влияющие и не влияющие на функции безопасности, а в справочнике такой разметки нет. Функциональная спецификация как документ изделия выпущена отдельно, и разметка интерфейсов — её предмет, а не предмет этого справочника. Ближе всего к такой разметке в репозиториях подошёл реестр интерфейсов форка базовой системы: он перечисляет параметры и вызовы, отданные наружу, с пометкой об обязательствах по стабильности каждого — но границу «влияет на функции безопасности» не проводит и покрывает только стык ядра с контроллером узла.
Проектирование средства и проектная документация (пп. 11, 12.3).
Требуется перечень подсистем с разделением на реализующие функции безопасности, поддерживающие их выполнение и не влияющие на него, проект на уровне подсистем и на уровне модулей, сопоставление функций и интерфейсов с подсистемами и модулями. Для пятого уровня и выше в документацию входят исходные тексты с контрольными суммами файлов, кроме заимствованного программного обеспечения, не реализующего функции безопасности.
| Что требуется | Чем закрывается |
|---|---|
| Перечень подсистем и модулей, описание взаимодействия | Репозитории компонентов ведут собственные описания подсистем, интерфейсов и реестр правок относительно апстрима; для форка базовой системы это отдельное дерево документов внутри репозитория |
| Исходные тексты с контрольными суммами | Раздача собирается по посчитанному замыканию списка пакетов; манифест целостности и ведомость состава считаются по одному и тому же набору файлов |
| Классификация заимствованных компонентов | Каждая внешняя зависимость размечена свойствами поверхности атаки и участия в функциях безопасности; разметка ведётся в репозитории компонента и попадает в ведомость состава |
| Сведения об аппаратной платформе | Требование адресовано программно-техническим средствам. Платформа поставляется программным средством, аппаратная платформа в её состав не входит |
Средства разработки (п. 13).
Требуется документация с описанием применяемых средств разработки и использованных опций. Версия набора инструментов сборки зафиксирована, инструменты анализа запечены в сборочный образ, профили сборки продукта заданы файлами конфигурации в репозитории — включая отдельный профиль сертифицируемого контура. Опции сборки тем самым лежат в репозитории в машиночитаемом виде.
Управление конфигурацией средства (п. 14.3).
Четвёртый уровень доверия добавляет к общим требованиям управление изменениями исходных текстов, применение автоматизированных мер контроля, обеспечивающих внесение только санкционированных изменений, и организацию процедур приёмки изменённых или вновь созданных элементов конфигурации.
| Что требуется | Чем закрывается |
|---|---|
| Управление изменениями исходных текстов | Изменение попадает в дерево только через merge request; прямой push в интеграционную и релизную ветки закрыт. Продвижение кода идёт по фиксированной цепочке «ветка задачи → интеграционная ветка → релизная» |
| Автоматизированные меры контроля санкционированности | Слияние запрещено при незелёном конвейере. Блокирующие проверки: анализатор кода, проверка зависимостей на известные уязвимости и на запрещённые пакеты, контроль подавлений — подавление находки без обоснования останавливает конвейер по всему дереву, а новое подавление требует согласования от выделенного списка специалистов по безопасности, причём автор изменения не может согласовать себя |
| Уникальная маркировка и список элементов конфигурации | Ведомость состава программного обеспечения в формате CycloneDX формируется в конвейере на релизных ветках: компоненты с идентификатором пакета и хешем Стрибог-256 на неизменяемый архив исходников. На ветках разработки генерация выключена, поэтому ведомость описывает именно то, что выпускается |
| Процедуры приёмки | Выпуск раздачи собирается по списку, посчитанному замыканием зависимостей, а не копированием готового каталога: набор файлов, манифест целостности и ведомость состава заведомо описывают одно и то же |
Документация по безопасной разработке (п. 15.3).
Требуется описание физических, процедурных и организационных мер защиты конфиденциальности и целостности проектной документации и реализации средства, а также мер, снижающих вероятность появления уязвимостей, с обоснованием. Меры безопасной разработки, работающие в конвейере, перечислены в разделе Соответствие ФСТЭК; документ об обеспечении безопасной разработки в комплекте изделия выпущен отдельно. Организационные и физические меры среды разработки в этой документации не описываются: они ведутся документами изделия.
Эксплуатационная документация (п. 16).
Требуется формуляр средства с контрольными суммами дистрибутива и исполняемых файлов, руководство пользователя и руководство администратора. Руководство пользователя должно описывать режимы работы, принципы безопасной работы, функции и интерфейсы, доступные каждой роли, параметры безопасности с их безопасными значениями, типы событий безопасности, связанных с доступными пользователю функциями, и действия после сбоев.
Комплект руководств и формуляр ведутся отдельными документами изделия, и все три документа выпущены. Публичная документация закрывает часть их содержания: типы событий безопасности — Журнал безопасности, функции и интерфейсы по ролям — справочник Роли и привилегии, параметры безопасности и их безопасные значения — раздел Харденинг. Контрольные суммы дистрибутива в публичную документацию не выносятся: они уточняются при каждом обновлении и живут в формуляре.
По параметрам безопасности между руководствами и этой документацией есть разрыв, и он в пользу этой. Требование называет среди обязательного содержания руководств параметры безопасности с их безопасными значениями и действия по безопасной настройке средства. Параметры узла, от которых зависит защита памяти и ограничение программной среды, в руководствах не описаны, хотя обе функции в них объявлены как обеспечиваемые. Единственное место, где порядок их включения записан, — раздел Харденинг этой документации. Это несоответствие требованию, и закрывать его надо в руководствах.
Требования к проведению испытаний
Тестирование средства (п. 18.3).
Тестовая документация четвёртого уровня доверия должна включать план тестирования со сценариями и зависимостями, сопоставление тестов с интерфейсами функций безопасности из функциональной спецификации, с подсистемами из эскизного проекта и с модулями из технического проекта — с демонстрацией полного покрытия функций безопасности тестами. При тестировании оценивается влияние на модули, реализующие функции безопасности, со стороны остальных модулей.
| Что требуется | Чем закрывается |
|---|---|
| Тесты функций безопасности | Подсистема контроля целостности закрыта отдельным набором сценариев: отображение в память и изменение прав отображения, подпись манифеста, конфигурация ядра, журналирование, классификация блокирующих событий, обход по привилегии, жёсткие ссылки. Набор лежит в репозитории базовой системы вместе с вспомогательными программами и аналитической запиской |
| Тесты механизма затирания при удалении | Восемнадцать сценариев на разных геометриях пула и свойствах набора данных: зеркало, RAIDZ, дедупликация, снимки и клоны, шифрование, несколько копий, gang-блоки, тома. План проверки и лог прогонов ведутся рядом с тестами |
| Тесты по дефектам | Каждый разобранный дефект базовой системы несёт в репозитории описание, воспроизведение и регрессионный тест |
| Тесты управляющего слоя | Модульные тесты идут в блокирующей стадии конвейера: непрошедший тест останавливает слияние |
| Сопоставление тестов с модулями и оценка влияния | Из репозиториев такое сопоставление не выводится: наборы тестов привязаны к подсистемам и дефектам, а не к модулям технического проекта. В комплекте документов изделия есть программа и методики испытаний и отдельный документ функционального тестирования; полноту покрытия функций безопасности и сопоставление с модулями эта документация не оценивает |
Выявление уязвимостей и недекларированных возможностей (п. 19.3).
Испытания программного обеспечения четвёртого уровня доверия проводятся по 4 уровню контроля. Это работа испытательной лаборатории, и её результат — не свойство продукта. Со стороны разработки под неё готовятся исходные тексты с контрольными суммами, ведомость состава и разметка зависимостей по участию в функциях безопасности. Приёмочные испытания по выявлению уязвимостей проводит изготовитель; постоянно действующая часть — блокирующая проверка зависимостей на известные уязвимости в конвейере и проверка по расширенной базе уязвимостей и поиск шаблонов небезопасного кода в предупреждающем режиме.
Анализ скрытых каналов (п. 20.2).
Требование предъявляется только к четвёртому уровню доверия. Требуются идентификация и анализ скрытых каналов по памяти, оценка их потенциальной пропускной способности формальными, техническими или модельными методами, требования к среде функционирования для ограничения или устранения найденных каналов и отдельная документация анализа — с описанием использованных процедур, сделанных предположений и наиболее опасного сценария по каждому каналу.
Один механизм, относящийся к остаточной информации в памяти, в базовой системе есть и снабжён измерительной обвязкой: при удалении виртуальной машины память гостя обходится и затирается, а до и после затирания выполняется поиск тестового образца в содержимом памяти. Это даёт измеримую проверку затирания, но задачи анализа скрытых каналов не решает: идентификации каналов, оценки пропускной способности и требований к среде функционирования здесь нет. Считать обвязку задельем под требование тоже не стоит: она отладочная, живёт только на текущей линии сборки и в следующей уже не переносится. Требование остаётся открытым.
Требования к поддержке безопасности
Устранение недостатков (п. 22.3).
Четвёртый уровень доверия сокращает срок доведения компенсирующих мер до потребителей до 48 часов с момента выявления недостатка и требует доводить сведения о недостатках и мерах до каждого потребителя сертифицированного средства — письмом на электронный адрес или компонентом средства, который делает это автоматически. Доработка средства или мер защиты — в срок не более 60 дней.
Сроки и адресная рассылка — процедуры заявителя, из репозиториев они не выводятся. Со стороны продукта под них есть контур публикации хотфиксов: отдельный конвейер выпускает исправление на релизной ветке с подписью, минуя цикл ветки разработки.
Обновление средства (п. 23.3).
Требуется информирование потребителей о выпуске обновлений, получение обновления способом, обеспечивающим целостность, получение обновлений по сети с информационного ресурса заявителя, подлинность и целостность обновлений за счёт электронной подписи и — для четвёртого уровня — доведение информации о выпуске до каждого потребителя.
| Что требуется | Чем закрывается |
|---|---|
| Подлинность и целостность обновления | Раздача пакетов подписана: тип подписи — открытый ключ, ключ раздачи выкладывается вместе с ней. Скрипт обновления публикуется с отсоединённой подписью, и конвейер проверяет её проверкой цифровой подписи по SHA-256 против того же открытого ключа; несовпадение останавливает публикацию |
| Целостность полученного набора | Ожидаемый отпечаток открытого ключа зашит в проверку конвейера, а его совпадение с ключом в раздаче сверяется отдельно |
| Обновление с ресурса заявителя | Обновление тянется с репозитория раздачи; сертифицируемый контур раздаётся из отдельного каталога |
| Информирование каждого потребителя | Процедура заявителя, средствами платформы не закрывается |
Документирование процедур устранения недостатков и обновления (п. 24).
Требуется включение процедур устранения недостатков в программную и конструкторскую документацию и регламент обновления средства потребителем с порядком получения, установки и контроля установки обновления. Из трёх частей публичная документация закрывает контроль установки: сверка версий пакетов по узлам описана в разделе Управление узлами. Порядок получения и установки как регламент ведётся документом изделия.
Информирование об окончании производства и поддержки (п. 25).
Потребители и ФСТЭК России должны быть проинформированы не позднее чем за год до окончания производства или поддержки безопасности средства. Процедура заявителя, средствами платформы не закрывается.
Границы подтверждения
Страница сопоставляет требования приказа № 76 с механизмами и артефактами, которые проверяются чтением репозиториев продукта. Она не подтверждает статус сертификации, не заменяет документы изделия и не свидетельствует о результатах испытаний.
Три требования приказа на момент сверки остаются открытыми, и вес у них одинаковый, а источник разный:
| Что требуется | Пункт | Состояние |
|---|---|---|
| Модель безопасности средства с формальным доказательством условий безопасности | 8.2 | Документ с таким названием в комплекте документов изделия есть. Соответствие требованию не подтверждено: пункт 8.2 требует не описания, а формального доказательства условий безопасности на математическом или машиночитаемом языке, допускающем независимую проверку. Прозаическое описание политики разграничения доступа этому не отвечает |
| Идентификация и анализ скрытых каналов по памяти | 20.2 | Не выполнены. Измерительная обвязка затирания памяти гостя есть, анализа каналов нет |
| Динамический анализ (фаззинг) | — | Мера безопасной разработки по ГОСТ Р 56939, в требования к уровню доверия входит через требования к процессу разработки. Вынесен отдельной задачей, не выполнен |
Пункты 8.2 и 20.2 к пятому и шестому уровням доверия не предъявляются вовсе, то есть именно ими четвёртый уровень от них и отличается. Пока они открыты, вывод о полном соответствии четвёртому уровню доверия преждевремен.
Основание для вывода по этим двум пунктам разное, и стоит сказать какое. В репозиториях продукта нет ни модели в машиночитаемом виде, ни документации анализа скрытых каналов. По анализу скрытых каналов документа нет и в комплекте документов изделия. По модели безопасности документ есть, но открытым пункт остаётся всё равно: требование выполняется формальным доказательством, а не наличием документа с таким названием, и оценка достаточности содержания в эту документацию не входит.
Отдельно стоит отметить требования, закрытые процедурами заявителя, а не свойствами продукта: сроки реакции на недостатки, адресная рассылка сведений о недостатках и обновлениях, информирование об окончании поддержки. Проверить их чтением репозиториев нельзя.
К обоснованию безопасности инициализации (п. 9) относится оговорка, которую стоит держать в виду при подготовке доказательной базы: проверка подписи манифеста загрузчиком в базовой системе реализована и сборочным профилем запрошена, но сам подписанный манифест загрузки в поставку не собирается — его сборка включается ключом подписи, а ключ в профилях не задан. Пока это так, контроль целостности на узле начинается после загрузки, с момента настройки подсистемы администратором.
Харденинг
Часть требований приказа держится на настройках, которые администратор обязан проверить после установки. Подсистема контроля целостности переходит в состояние «применяется и заперта» автоматически, когда загрузчик передал ядру манифест, — это штатный путь сертифицируемого контура. Запрет одновременной записи и исполнения включается файлом настроек, который приходит только с этим контуром. Затирание памяти гостя при удалении виртуальной машины и затирание блоков при удалении набора данных по умолчанию выключены и включаются администратором. Порядок — в разделе Харденинг.