Новости ИСП РАН

Информационное сообщение о проведении круглого стола на тему «Методики оценки степени защищенности операционных систем»

Круглый стол состоялся в Институте системного программирования им. В.П. Иванникова РАН 9 июня 2026 года.

В нем приняли участие представители ИСП РАН, Лаборитории Касперского, ГосНИИАС, «Базальт СПО», «Группа Астра», «Открытая мобильная платформа», «Positive Technologies» и «Фобос-НТ».

Участники:

• Ведущий - А.К. Петренко (ИСП РАН)
• Виктор Кулямин (ИСП РАН)
• Александр Попов (Positive Technologies)
• Денис Ефремов (ИСП РАН)
• Евгений Басков (ИСП РАН)
• Алексей Хорошилов (ИСП РАН)
• Дмитрий Пономарев (ФОБОС-НТ)
• Анна Мелехова (Лаборатория Касперского)
• Александр Аршинов (Лаборатория Касперского)
• Юрий Солоделов (ГосНИИАС)
• Сергей Рогачев (Лаборатория Касперского)
• Сергей Аносов (Открытая мобильная платформа)
• Валерий Кащеев (Открытая мобильная платформа)
• Владимир Тележников (Astra Linux)
• Денис Медведев (Базальт СПО)

Сокращенная стенограмма круглого стола

1. Ведущий:

Коллеги, добрый день! Цель нашей встречи — обсудить подходы к сравнению и оценке степени защищенности программных систем. Изначально мы рассматривали широкие ПО, но сузили фокус до операционных систем (ОС), так как сравнивать разнородные системы (веб-интерфейсы, магазины приложений) сложнее, чем ядра ОС, в которых мы разбираемся лучше.

Наша задача — найти подходы к сопоставлению защищенности. Мы не ожидаем универсального решения, но хотим понять полноту картины. Сегодня выступят три докладчика:
1. Виктор Кулямин представит общий обзор проблемы и существующие методики.
2. Денис Ефремов расскажет о своей метрике инженерного сопровождения безопасности ядер ОС.
3. Евгений Басков предложит альтернативный подход, оценивая защищенность подсистем (на примере драйверов).

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

2. Доклад Виктора Кулямина: Обзор исследовательских работ

Виктор Кулямин:

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

Существует два основных подхода:
1. Функциональные требования (Checklists): Берутся списки требований безопасности (например, профили Common Criteria). ОС проверяется на соответствие этому списку «фич».
2. Деревья атак-защит: Рассматриваются возможные атаки и меры защиты от них. Часто строится дерево, где атакующий пытается обойти защиту, а защитник — предотвратить атаку.

Проблемы существующих подходов:

• Отсутствие полноты: Невозможно доказать, что в список включены все аспекты или что дерево атак полно. Аргументация часто субъективна.
• Произвольность метрик: При сведении оценок к числам возникает произвол в выборе шкал и весов. Иногда пытаются использовать байесовские оценки или нечеткие системы, но суть остается прежней.
• Сложность использования: Фреймворки без четкой методологии трудно применять на практике.

Наши выводы:

Мы составили собственный перечень характеристик (зонтик). Он достаточно полный для среднего уровня, но требует дополнительной аргументации, чтобы убедить сторонних экспертов.

• Оценка по этим ячейкам возможна, но опирается на интуицию и опыт эксперта.
• Методика рассчитана на заинтересованных экспертов, а не на ИИ или новичков.
• На данный момент мы имеем каркас, но не «болото».

Александр Попов (комментарий):
Когда я создавал карту средств защиты ядра Linux, я столкнулся с проблемой гранулярности. Если классы слишком мелкие — схема перегружена, если крупные — теряется суть. Я выбрал степень, при которой в каждый элемент входит 3-4 связи.
Для оценки полноты я использовал эмпирический подход: 10 лет следил за безопасностью ядра Linux. Если новая атака или уязвимость появлялась, я добавлял ее в карту. Карта оказалась полной.
Я также сверял свою карту с материалами Microsoft Security Response Center (для ядра Windows). Разногласий не обнаружилось, за исключением некоторых особенностей C++ в Windows. Это подтвердило правильность моего пути.

3. Доклад Дениса Ефремова: Метрика инженерного сопровождения безопасности

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

Определение Hardening:

Набор архитектурных решений, приемов реализации, параметров сборки и настроек, которые:

1. Сокращают поверхность атаки.
2. Затрудняют использование ошибок ядра.
3. Защищают целостность кода и данных.
4. Регулируют расширяемость привилегированным кодом.

Важно: Идеально, если это работает автоматически и с приемлемыми потерями производительности.

История развития:

До 2014-2015 годов защиты внедрялись энтузиастами. После атаки Hardlit, появления непрерывного фаззинга и уязвимостей спекулятивного исполнения (Spectre/Meltdown), защита стала обязательной. С 2022 года эти меры проникают в стандарты и предписания.

Критерии оценки:

Я выделил 7 классов защиты и 76 механизмов. Для оценки каждого механизма использовались следующие критерии (шкалы 0-3):

1. Наличие механизма: Есть ли он в ОС?
2. Режим по умолчанию: Включен ли по умолчанию? (Чем дольше работает по умолчанию, тем выше ценность).
3. Сила реализации: Насколько сильно реализован механизм (например, канарейка стека: случайное число, зааскоренное, уникальное для потока).
4. Глубина интеграции: Включен ли в основную ветвь ядра или это сторонний модуль/форк?
5. Зрелость: Как давно механизм добавлен и как активно поддерживается?

Формула и результаты:

Итоговый индекс — взвешенная сумма оценок.

• 0–1: Базовая забота о безопасности отсутствует или минимальна.
• 1–1.5: Есть базовые защиты.
• >1.5: Централизованная, профессиональная работа над безопасностью.

* Примечание: Формула не учитывает разрыв в сложности реализации защиты (например, более сложная реализация ASLR в OpenBSD дает тот же балл, что и простая в других ОС). Также метрика отражает *процесс* и *культуру разработки*, а не абсолютную неуязвимость.

Обсуждение метрики:

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

Денис Ефремов: Это не метрика безопасности *как таковой*, а метрика инженерной практики. Если поверхность атаки отсутствует (доказано формально), механизм просто не оценивается.

• Вопрос про Windows: Исключена из-за закрытости исходного кода.
• Вопрос про российские ОС (Астра, РЕД ОС): Внешние патчи и надстройки могут снижать оценку по критерию «глубины интеграции», если они не вмержены в ядро. Это справедливо, так как мы оцениваем качество самого ядра.

4. Доклад Евгения Баскова: Оценка подсистем (на примере драйверов)

Евгений Басков:
Предлагаю расширить подход на другие подсистемы, например, драйверы.

Угрозы для драйверов:

1. Со стороны оборудования: Штормы прерываний, некорректная конфигурация.
2. DMA-атаки: Интеграция IOMMU/AMD-Vi. Уровни защиты от линейного отображения до изоляции каждого запроса.
3. ПО и уязвимости: Баги драйверов, небезопасные интерфейсы.
4. Спекулятивные атаки: Новые классы угроз.
5. Изоляция: Выполнение драйверов в режиме ядра (монолит) или пользователя (микроядро/драйверы в userspace).
6. Цепочка поставки: Подпись драйверов, защита от откатов, недоверенное ПО.

Метрика:

Можно построить аналогичную оценку для драйверов, учитывая контекст применения (ПК, сервер, встроенные системы, мобильные устройства). В мобильных устройствах выше требования к подписи, во встроенных — может отсутствовать MMU.

5. Дискуссия: Для кого нужна методика?

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

1. Роль регуляторов и сертификационных лабораторий (Дмитрий Пономарев):

• Лаборатории работают по нормативам (СТК). Если регулятор не установит требования, методика бесполезна.
• На практике лаборатория не может заставить клиента сменить ОС (например, с Linux на OpenBSD) из-за низкого балла. Максимум — порекомендовать хардинги.
• Методика полезна как *рекомендательный инструмент* для клиентов, но не как строгое требование без нормативной базы.
• Если регулятор введет пороги (например, «ниже 2 баллов — недопустимо»), лаборатория будет следовать этому.

2. Роль заказчика и продукта (Владимир Тележников):

• Заказчик выбирает ОС по цене и удобству, пока нет регуляторного давления.
• Методика полезна для обоснования инвестиций в безопасность. Она показывает, где система уязвима до появления реальных атак.
• Например, анализ атак на Mali GPU показал, что проблема была в гранулярности доступа. Методика позволила бы выявить эту слабость заранее.
• Для вендора важно понимать, какие хардинги приоритетны, чтобы не тратить ресурсы на малозначимые.

3. Роль разработчика и культура производства (Юрий Солоделов, Александр Попов):

Александр Попов: Безопасность нельзя мерить одной цифрой. Она зависит от аппаратной части (чип, TrustZone). Метрика Дениса хороша тем, что измеряет *инженерную культуру*, а не мнимую «неуязвимость». Бакбаунты (деньги за уязвимости) — плохая метрика, так как зависят от бюджета компании, а не от реального уровня защиты.

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

Дмитрий Пономарев: Метрика отражает *культуру разработки*. Культура важнее разовой находки эксплоита.

4. Проблема модели угроз (Сергей Аносов, Валерий Кащеев):

Сергей Аносов: Нельзя оценивать безопасность абстрактной ОС. Нужна модель атакующего. Угрозы зависят от контекста: телефон на руках у директора vs телефон в защищенном контуре с «двухсантиметровым зазором».

Валерий Кащеев: Нужно разделять *управление уязвимостями* (культура разработки, патчи) и *средства защиты* (хардинги против неизвестных уязвимостей).

Идея: Создать общий каталог угроз. Для каждого класса ОС (мобильная, серверная, embedded) вырезать применимые угрозы и оценивать защиту именно против них. Ядро Linux — это «наибольший общий делитель» для всех моделей угроз.

6. Итоги и дальнейшие шаги

Основные тезисы:

1. Методика нужна, но необходимо четко определить целевую аудиторию и сценарии использования.
2. Это не метрика абсолютной безопасности, а метрика зрелости процессов, инженерной культуры и качества реализации защитных механизмов.
3. Сравнение ОС возможно только в рамках одного класса и с учетом применимых угроз. Сравнение Android и серверной ОС некорректно.
4. Бакбаунты и деньги — некорректная метрика безопасности.
5. Регуляторика — ключевой драйвер внедрения. Без требований регуляторов методика останется академическим интересом.

Планы:

• Лаборатория Касперского начнет применять методологию на своих продуктах.
• Планируется проведение круглого стола в конце года (октябрь) для обсуждения результатов.
• Будет подготовлен краткий тезисный документ и стенограмма.

Ведущий:
Спасибо всем за продуктивную дискуссию. Мы поняли, что «идеальной метрики» не существует, но есть полезный инструмент для анализа процессов и выявления слабых мест. Продолжим работу над уточнением критериев и интеграцией с моделями угроз.

7. Резюме по итогам круглого стола (Анна Мелехова)

Методики оценки уровня защищенности – кто является заинтересованными стороны ИТ-индустрии, какова их мотивация?

Появление методики оценки уровня защищенности/безопасности было поддержано всеми участниками.

Такая методика помогла бы компаниям сделать выбор между ОС1 и ОС2 при проектировании своих решений или построении своей информационной системы, то есть она была бы востребована CISO организации и solution architect-орам. Без наличия такой технической метрики выбор между ОС отдается непрофессионалам. Наличие такой технической метрики - это зрелость индустрии.

Метрика помогла бы компаниям-разработчикам ОС более планомерно развиваться в сторону безопасности и поможет сфокусировать усилия. Она могла бы использоваться как аттестация зрелости программного решения с точки зрения ИБ, как способ аналитически оценить, насколько механизмы безопасности справляются с угрозами.

Насколько широк может быть класс сопоставимых систем?

Общее мнение заключается в том, что сопоставлять нужно системы в рамках одного класса. Под классом мы понимаем ФСТЭК-деление на системы общего назначения, встроенные системы и системы реального времени. При этом класс может делиться на подклассы по принципу наличия функциональности и релевантности угроз. Так, мобильные ОС, относящиеся к системам общего назначения, обрабатывают биометрию, и потому угрозы от хранения и обработки биометрии актуальны и для Android, и для iOS, и для Аврора, но не актуальны для серверных систем. При этом на наш взгляд задача выделение подклассов связано с выделением подмножества угроз, но не влияет на жизнеспособность методики.

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

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