Коллеги, доброго дня.

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

Ресурсы под эгидой Центра компетенций ФСТЭК России и ИСП РАН:

@sdl_inform - канал, не ставьте его в Mute, сообщения там появляются в среднем одно в неделю. Основные, наиболее значимые для сообщества оповещения о встречах и иных мероприятиях.

@sdl_static - чат, посвященный вопросам компиляторики и статического анализа (в первую очередь безопасный компилятор/Svace/Svacer, но не только).

@sdl_dynamic - чат, посвященный вопросам динамического анализа (в первую очередь Crusher/Sydr/Casr/Блесна/Natch, но не только).

@sdl_community - чат, посвященный вопросам объединения сил и средства сообщества в вопросах анализ ядра Линукс и критичных компонентов, доверенной загрузки и т. п., а также мероприятиям и некоторым (согласованным) новостям от регулятора.

[NEW] @sdl_arch - чат, посвященный вопросам качественной и безопасной разработки, не укладывающимся в темы указанных выше чатов. В частности здесь обсуждаются вопросы композиционного анализа и ППК, вопросы контейнеров и кубернетес, общий вопросы моделирования и архитектуры

[NEW - ранее flood] @sdl_holywar - чат, холивары на тему безопасной и качественно разработки. Сюда переносятся холивары по любым темам из остальных чатов, чтобы не засорять эфир и поддерживать низкий SNR (Signal-Noise Ratio).

Дружественные тематические ресурсы:

@sydr_fuzz - чат, поддержка пользователей фаззера Sydr.

@ispras_natch - чат, поддержка пользователей системы определения поверхности атаки Natch.

@sdl_for_upstream_ru и @sdl_for_upstream - чат и канал, оповещения о принятых апстримом багах и уязвимостях, найденных участниками сообщества.

@ispras_friends - чат неформального общения друзей и единомышленников РБПО-сообщества ФСТЭК России и ИСП РАН.

@SDL_Community_SPb - чат, локальный чат Питерской ветки нашего сообщества, созданный в мае с целью координировать локальные встречи в СПб (ближайшая будет 12го августа, 27го июля объявим подробности).

Некоторые правила ресурсов "под эгидой":

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

2. Чаты не предназначены для обсуждения особенностях трактовки регуляторных документов (Положения, Требования, Методики и т. п.) и их правоприменительной практики, за исключением особых случаев, как правило непосредственно инспирированных регулятором, например: https://t.me/sdl_community/2218.

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

[NEW] 3.1. Некоторое исключение делается для значимых и кросс-верифицированных участников нашего сообщества (вы и так знаете о ком речь, если в сообщества давно. Модератор знает их точно, и авторитаризм никто не отменял) в случае ответов на вопросы в чате. Но в любом случае злоупотребление данной возможностью будет пресекаться вне зависимости от любой дружбы.

4. Избегайте флуда, в том числе личных эмоциональных позиций, флейма, глубокомысленных комментариев по вопросам, в которых вы слабо разбираетесь и т. п. Все люди взрослые, банхаммер не дремлет :) Исключение - чат друзей @ispras_friends.

Прогрев двигателей 😎

3, 2, 1 ...

Методическая рекомендация № 2025-04-001

Область: Определение поверхности атаки (ПА)

Тип недостатка: Некорректное определение ПА на системные компоненты. Фаззинг кода, не составляющего ПА в типовых сценариях эксплуатации СЗИ.

Описание: Фаззинг-тестирование стандартных консольных утилит как правило не является приоритетным с точки зрения анализа поверхности СЗИ. На рис. 1 представлен список компонентов, определенных в качестве ПА на СЗИ типа А - "Операционная система общего пользования". На рис. 2-3 представлена консоль фаззера afl++, с помощью которого в ходе испытаний выполнялось фаззинг-тестирование в отношении утилит base64 и cat.

Утилиты base64 и cat из состава пакета coreutils как правило запускаются пользователем или администратором системы, который уже имеет доступ к терминалу, либо используются в служебных скриптах. Данные утилиты не обладают какими либо повышенными привилегиями (права rwx, suid-бит, capabilities и т. п.) в данном СЗИ после выполнения инструкции по безопасной установке и настройке. В случае обнаружения программной ошибки в данных утилитах, вероятность использования данной ошибки в качестве уязвимости как правило мала, поскольку утилиты не обладают повышенными привилегиями, не реализуют механизмы управления доступом или иные функции безопасности. Потенциальный нарушитель в первую очередь будет стремиться воздействовать на компоненты ОС, обладающие повышенными привилегиями, либо взаимодействующие с недоверенными источниками - в первую очередь сетевые службы в составе ОС.

Рекомендации:

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

- при отнесении к поверхности атаки компонентов, очевидно не обладающих указанными выше свойствами, приводить описание реалистичных и вероятных сценариев использования СЗИ, обосновывающих очевидное присутствие данных компонентов на поверхности атаки

Дополнительные информационные материалы:

- определение ПА в ГОСТ 56939-2024
- слайды 4, 6, 9 по ссылке
- слайды 16, 18

Методическая рекомендация № 2025-04-002

Область: Определение поверхности атаки (ПА)

Тип недостатка: Некорректное определение ПА на системные компоненты. Необоснованная приоритизация исследования компонентов ПА.

Описание 1: На рис. 1 представлен список компонентов, определенных в качестве ПА на СЗИ типа А - "Операционная система общего пользования". Эксперт определил, что компонент openssh находится на ПА, что, как правило, является верным определением. Данный открытый компонент содержит исходные коды и правила сборки для нескольких исполняемых модулей, к которым относятся приложения сервера (сервис, служба, демон) sshd и клиента ssh. В качестве единственного модуля, подлежащего исследованиям, эксперт выбрал (рис. 2) именно модуль ssh.

Выбор ssh в качестве единственной цели для исследования из состава компонента openssh в рамках исследований указанного СЗИ (и - как правило, всегда, за исключением подлежащих обоснованию частных случаев в т. ч. запуска ssh с повышенными привилегиями в ОС) является некорректным по причине низкого приоритета. ssh является клиентским приложением, запускаемым пользователем из терминала каждый раз при желании установить соединение с сервером. Дополнительных привилегий (SUID, capabilities и т. п.) для его запуска не требуется - повышение привилегий пользователя за счет эксплуатации дефектов кода в данном модуле, как правило, является маловероятным.

Значительно более перспективной целью является исследование компонента sshd, также входящего в состав компонента openssh и реализующего функционал ssh-сервера. Именно ssh-сервер, как правило, составляет сетевую ПА в составе типовых СЗИ типа ОС.

Рекомендации:

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

- при исследовании СЗИ, основанных на дистрибутивах ОС (Линукс и иных), рекомендуется в приоритетном порядке исследовать модули сетевых сервисов, доступные потенциальным нарушителям по сети (в первую очередь сервисы, постоянно держащие открытые LISTEN-сокеты)

Дополнительные информационные материалы:

- список типовых Линукс-утилит с установленным битом suid (повышенные привилегии)
- список типовых сетевых сервисов для ОС Линукс
- определение ПА в ГОСТ 56939-2024
- слайды 4, 6, 9 по ссылке
- слайды 16, 18

Методическая рекомендация № 2025-04-003

Область: Определение поверхности атаки (ПА) / Фаззинг-тестирование

Тип недостатка: Некорректное определение составляющего ПА кода компонентов. Необоснованный фаззинг аргументов командой строки консольных приложений.

Описание: На рис. 1 представлено описание проведения фаззинг-тестирования утилиты ssh через аргументы командной строки с использованием заголовочного файла argv-fuzz-inl.h, для СЗИ типа А - "Операционная система общего пользования". На рис. 2 представлена консоль фаззера afl++, с помощью которого в ходе испытаний выполнялось фаззинг-тестирование в отношении утилиты ssh.

Фаззинг-тестирование параметров запуска (аргументов командной строки) консольных приложений как правило не представляет значительной ценности с точки зрения исследования ПА. Если злоумышленник уже получил доступ к терминалу (закрепился в системе), его действия будут направлены на задачи повышения собственных привилегий, воздействие на критичные компоненты системы, такие как ядро, сетевые сервисы или права доступа. Эксплуатация потенциальных ошибок в обработке аргументов запуска консольных приложений, как правило, не позволит пользователю нанести системе больший ущерб, чем уже достигнутая возможность запускать данное приложение с различными штатными параметрами. Например для утилиты ssh указанные некорректно имя пользователя или адрес удаленного хоста приведут к завершению приложения с сообщением об ошибке, без влияния на безопасность приложения (объекта оценки) в целом.

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

Рекомендации:

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

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

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

Дополнительные информационные материалы:

- пример исследования кода сетевого сервиса sshd
- определение ПА в ГОСТ 56939-2024
- слайды 4, 6, 9 по ссылке
- слайды 16, 18

Методическая рекомендация № 2025-04-004

Область: Определение поверхности атаки (ПА) / Фаззинг-тестирование

Тип недостатка: Некорректное определение ПА. Необоснованное фаззинг-тестирование интерпретаторов за счет подачи скриптов на вход.

Описание: На рис. 1-3 представлены примеры фаззинг-тестирования сред выполнения программного кода на языках программирования OpenJDK, Bash, Python (далее — интерпретатор), путем перебора скриптов, поданных на вход.

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

Например:
Мутация вида print("Hello world") → print("llHeo world") сохраняет семантику исходного кода, не влияя на работу интерпретатора.
Мутация вида print("Hello world") → ntpri("llHeo world") приводит к синтаксической ошибке, после которой интерпретатор прекращает выполнение скрипта.

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

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

Рекомендации:

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

- рекомендуется взаимодействие с Центром исследований безопасности системного программного обеспечения для организации фаззинг-тестирования интерпретаторов, поскольку Центр обладает значительным опытом в их анализе и выявлении потенциальных уязвимостей

Дополнительные информационные материалы:

- презентация Центра
- слайды 8, 9 по ссылке
- определение ПА в ГОСТ 56939-2024
- слайды 16, 18

Уважаемые коллеги!

Сегодня, 16:15 (мск) на канале Общественного телевидения России выйдет передача серии "Очевидно.Вероятно", посвященная математике - "Математика вокруг нас".

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

Ведущий программы – Арутюн Аветисян, академик РАН, директор Института системного программирования им. В.П. Иванникова РАН.

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

Сегодня гость в студии – Николай Андреев, заведующий лабораторией популяризации и пропаганды математики Математического института им. В.А. Стеклова РАН.

Ссылка на прямой эфир ОТР: https://otr-online.ru/online/

https://otr-online.ru/programmy/ochevidno-veroyatno/anons-matematika-vokrug-nas-88285.html

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

Шкала «Критичность» разделяет все рекомендации на три основных уровня, каждый из которых отражает степень влияния ошибки на процесс и результаты испытаний:

- 3 (Недостаток высокого уровня критичности)
Прямое нарушение требований Методики ВУ и НДВ. Невыполнение требований, игнорирование ключевых процедур.

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

- 1 (Недостаток низкого уровня критичности)
Неэффективное выполнение испытаний, проведение испытаний с отклонениями от лучших практик РБПО.

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