Итоговое тестирование «М БРПО-01» — ответы и пояснения

ОС управляет процессором, памятью, устройствами ввода-вывода, файловой системой и процессами, предоставляя приложениям унифицированный интерфейс к аппаратуре. Компиляция — задача компилятора, а не ОС; антивирус — отдельный класс ПО.

NTFS поддерживает разрешения NTFS (ACL/DACL), аудит, шифрование (EFS), журналирование. FAT32/exFAT прав доступа не хранят, поэтому для защищаемых данных они не подходят. Это важно при настройке защищённой среды функционирования ПО.

Capabilities дробят всемогущество root на отдельные привилегии и выдаются точечно — это прямая реализация принципа минимальных привилегий. SUID, наоборот, запускает программу с правами владельца (часто root); chmod 777 ослабляет защиту; запуск от root даёт максимум прав.

SUID — мощный, но опасный механизм: уязвимость в SUID-root программе ведёт к эскалации до root, поэтому количество SUID-файлов минимизируют, а на разделах с данными монтируют nosuid/nodev/noexec. Массовая установка SUID, напротив, расширяет поверхность атаки.

ASLR (Address Space Layout Randomization) случайно размещает в памяти стек, кучу и библиотеки, из-за чего эксплойтам труднее предсказать адреса. Это одна из защитных опций сборки/ОС наряду со stack protector, FORTIFY_SOURCE, DEP/NX.

Привилегированный режим (ring 0) отведён ядру; прикладной код выполняется в непривилегированном режиме и обращается к ресурсам только через системные вызовы. Это базовый механизм изоляции и контроля доступа в ОС.

Неверно лишь утверждение про «единый общий формат исполняемых файлов»: у Windows это PE (.exe/.dll), у Linux — ELF. Утверждения о многозадачности и многопользовательском режиме, о правах rwx в Linux и о реестре Windows — верны. Понимание различий важно при настройке безопасной среды и кросс-платформенной разработке.

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

Модель OSI содержит 7 уровней: физический, канальный, сетевой, транспортный, сеансовый, представления, прикладной. Модель TCP/IP — 4 уровня.

IP отвечает за логическую адресацию и маршрутизацию пакетов между сетями — это сетевой (3-й) уровень OSI. На транспортном уровне работают TCP и UDP.

TCP и UDP — протоколы транспортного (4-го) уровня. TCP обеспечивает надёжную доставку с установлением соединения, UDP — быструю передачу без гарантий.

HTTP, FTP, SMTP — протоколы прикладного уровня. ARP (разрешение адресов) и Ethernet относятся к канальному уровню / уровню сетевого доступа. Путаница уровней — частая ошибка, поэтому модель полезно держать в голове.

TCP — надёжный протокол с установлением соединения (хендшейк), контролем доставки, порядка и потока. UDP — без соединения, быстрый, но без гарантий. Ни тот, ни другой сам по себе не шифрует данные; оба используют порты.

Модель TCP/IP содержит 4 уровня: сетевого доступа (канальный), межсетевой, транспортный и прикладной. Уровню сетевого доступа TCP/IP соответствуют физический и канальный уровни OSI.

Нельзя защитить то, о существовании чего не знаешь. Инвентаризация активов даёт карту сети, перечень хостов, сервисов и установленного ПО — это отправная точка для оценки и устранения уязвимостей.

«Сканер-ВС 6» — система комплексного анализа защищённости: инвентаризация, поиск уязвимостей по базам (БДУ ФСТЭК, NVD и базам ОС), подбор паролей, тестирование на проникновение, контроль конфигураций. Само устранение уязвимостей выполняет администратор/разработчик — сканер их находит.

Межсетевой экран контролирует трафик между сетями/узлами по правилам (адреса, порты, протоколы, состояние соединений), разграничивая сетевые потоки. Это базовый рубеж сетевой защиты.

Разделение сети на сегменты с контролем доступа между ними локализует инцидент: скомпрометировав один сегмент, злоумышленник не получает свободный доступ ко всей сети. Это реализация эшелонированной защиты и ограничения «радиуса поражения».

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

Уровень сетевого доступа TCP/IP объединяет физический и канальный уровни OSI (передача кадров в физической среде). Межсетевой уровень TCP/IP соответствует сетевому уровню OSI.

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

Классическая триада — конфиденциальность, целостность, доступность (К-Ц-Д / CIA). В АСУ ТП и КИИ приоритет нередко смещён к доступности и целостности.

БДУ ФСТЭК (bdu.fstec.ru) содержит описания угроз (УБИ) и уязвимостей и используется при моделировании угроз. Каждая запись содержит идентификатор, наименование, объекты воздействия, источник и последствия.

С 2021 года модели угроз строят по «Методике оценки угроз безопасности информации» ФСТЭК (от 05.02.2021), которая пришла на смену методическим документам 2008 года. ГОСТ Р 56939 — про процессы разработки ПО; приказ № 76 — про уровни доверия.

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

Потенциал нарушителя ранжируют от низкого до высокого. Наивысший потенциал приписывают спецслужбам иностранных государств: собственные исследования, эксплойты «нулевого дня», аппаратные закладки, неограниченные ресурсы. Для значимых объектов КИИ такой нарушитель часто считается актуальным.

№ 149-ФЗ — рамочный закон об информации и её защите. № 152-ФЗ регулирует персональные данные, № 187-ФЗ — КИИ, № 99-ФЗ — лицензирование. Каждый закрывает свою область.

Соответствия «152-ФЗ — персональные данные», «187-ФЗ — КИИ» и «149-ФЗ — информация и её защита» верны. А вот ГОСТ Р 56939-2024 — это национальный стандарт (ГОСТ Р), а не федеральный закон. Путать уровни нормативных актов (ФЗ, постановления, приказы, ГОСТы) нельзя.

Угроза — это потенциальная или реальная опасность нарушения К-Ц-Д. Её не следует смешивать с уязвимостью (недостаток, который может быть использован) и с атакой (действие по реализации угрозы).

SDL означает, что безопасность учитывается на каждом этапе — от требований и проектирования до выпуска и реагирования на инциденты, а не «прикручивается» в конце. Идеология SDL лежит в основе процессного подхода ГОСТ Р 56939.

Defense in depth — многослойная защита: если злоумышленник преодолел один рубеж, его встречает следующий. Опора на единственное средство или только на периметр — антипаттерн.

Минимум прав ограничивает ущерб при компрометации компонента или учётной записи. Реализуется через capabilities, RBAC, разделение сервисов, запуск под непривилегированными пользователями.

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

Чем позже найден дефект, тем дороже его исправление — это известное эмпирическое наблюдение (Боэм/IBM). Важно: конкретное соотношение «1:100» — это наблюдение из практики, а не норма ГОСТ. Поэтому моделирование угроз и проектирование безопасности выполняют на ранних этапах.

Ручное управление памятью (C/C++) — источник целого класса уязвимостей; нативные расширения возвращают эти риски и в «безопасные» языки. Управляемые языки снижают класс ошибок памяти, но не исключают уязвимости (инъекции, логические ошибки, небезопасная десериализация, JNI/unsafe).

Поверхность атаки — это входные точки (аргументы, файлы, сеть, API, IPC, переменные окружения), через которые поступают потенциально недоверенные данные. Её описание и сокращение — часть процесса 5.7 ГОСТ Р 56939.

Парсеры недоверенных данных — типовая цель атак, поэтому их выносят в изолированный процесс с минимальными привилегиями, ограничивая «радиус поражения» при эксплуатации уязвимости. Это сочетание изоляции и least privilege.

ЖЦ ПО включает требования, проектирование, реализацию, тестирование, выпуск, сопровождение и вывод из эксплуатации. Выпуск первой версии — не конец, а начало этапа сопровождения, где безопасность тоже важна (обновления, реагирование на уязвимости).

Моделирование угроз даёт максимальный эффект на проектировании: оно влияет на архитектурные решения и описание поверхности атаки. Модель угроз затем поддерживают в актуальном состоянии в течение всего ЖЦ.

Дробление на сервисы повышает изолируемость, но множит интерфейсы (сеть, API), которые нужно защищать аутентификацией и авторизацией. Контроль доступа не исчезает — он становится распределённым и даже более важным.

НДВ — скрытая функциональность, не отражённая в документации и потенциально нарушающая безопасность (закладки, скрытые каналы). Выявление НДВ — часть испытаний при сертификации и анализа безопасности.

«Безопасно по умолчанию» — система из коробки находится в защищённом состоянии (минимум открытого, доступ по принципу запрета). Учётные данные по умолчанию, наоборот, — классическая уязвимость (см. угрозу использования учётных данных по умолчанию в БДУ).

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

Динамический анализ наблюдает реальное исполнение: работу с памятью, исключения, таймауты, взаимодействие с окружением. Он дополняет статический анализ, выявляя дефекты, проявляющиеся только при выполнении (переполнения, use-after-free, гонки).

SCA (в ГОСТ — композиционный анализ, процесс 5.16) инвентаризирует сторонние компоненты и сверяет их с базами известных уязвимостей (CVE, БДУ ФСТЭК), а также проверяет лицензионную чистоту. Большая часть уязвимостей нередко скрыта именно в транзитивных зависимостях.

Фаззинг — частный (и важный) способ динамического анализа; SAST не запускает код; SCA смотрит на зависимости. IAST (интерактивный анализ), напротив, работает во время выполнения с инструментацией приложения, а не «только при компиляции».

Фаззер автоматически и системно «забрасывает» объект необычными входами, провоцируя падения, зависания, утечки памяти и иные срабатывания. Современный покрытийный фаззер сохраняет интересные входы и мутирует корпус, расширяя исследованную область.

Фаззинг — лишь один из методов динамического анализа. По способу формирования входных данных его делят на случайный, мутационный и генерационный; по наличию обратной связи (по покрытию) — на coverage-guided/grey-box и blackbox; по доступу к коду — black/grey/white box. Никакой объём фаззинга не доказывает отсутствие уязвимостей — он лишь повышает шанс их найти.

RASP встраивается в приложение и в реальном времени отслеживает и блокирует подозрительные действия (в отличие от внешних средств вроде WAF). Это один из инструментов в арсенале безопасной разработки наряду с SAST/DAST/SCA/IAST/MAST.

SAST, DAST, MAST — это виды тестирования защищённости. SLA (Service Level Agreement) — соглашение об уровне услуг, к анализу кода отношения не имеет. Аббревиатуры важно не путать.

ГОСТ Р ИСО/МЭК 15408 («Общие критерии», Common Criteria) задаёт критерии оценки безопасности ИТ: функциональные требования и требования доверия, конструкции ПЗ и ЗБ. Процессы разработки — это уже ГОСТ Р 56939.

Профиль защиты (ПЗ) формулирует требования к классу/типу изделий независимо от конкретной реализации (его пишут потребители/регулятор). Требования к конкретному изделию — это задание по безопасности (ЗБ).

ЗБ описывает требования безопасности применительно к конкретному ОО (изделию), часто на основе одного или нескольких ПЗ. ЗБ — основа для оценки и сертификации именно этого продукта.

ОО (Target of Evaluation) — то, что оценивается: продукт или система ИТ вместе с документацией. Вокруг ОО строятся ПЗ/ЗБ, функциональные требования и требования доверия.

ПЗ, ЗБ и ОУД — ключевые конструкции «Общих критериев». Фаззинг-корпус — это термин из динамического анализа (фаззинга), к 15408 он не относится.

«Общие критерии» делят требования на функциональные (что система делает для безопасности) и доверия (насколько можно верить, что она это делает), изложенные через ПЗ/ЗБ. Бизнес-функциональность как таковая — вне предмета 15408.

Часть 1 — введение и общая модель; часть 2 — функциональные компоненты безопасности; часть 3 — компоненты доверия к безопасности. Это разделение полезно помнить при работе с ПЗ/ЗБ.

Часть 3 описывает классы и компоненты доверия (например, ALC — поддержка жизненного цикла, ADV — разработка, ATE — тестирование, AVA — оценка уязвимостей). Именно с ними соотносятся меры РБПО и требования доверия приказа ФСТЭК № 76.

Процессы РБПО (56939) дают свидетельства доверия, которые перекликаются с требованиями доверия 15408-3 и требованиями уровней доверия приказа № 76. Но это разные документы: 56939 — про процессы разработки, 15408 — про критерии оценки.

ОУД (EAL) — предопределённые наборы требований доверия, образующие шкалу от ОУД1 (минимум) до ОУД7. Не путать с классами защищённости ГИС/ИСПДн и категориями КИИ — это разные шкалы.

Определения уязвимости, поверхности атаки и безопасного ПО соответствуют нормативной базе. А вот ложноположительное срабатывание (FP) — это, наоборот, предупреждение о конструкции, не содержащей реальной ошибки; именно поэтому предупреждения анализатора подлежат разметке (истинное / ложное).

Корректные нормативные ссылки 56939-2024 — ГОСТ Р ИСО/МЭК 12207 (процессы ЖЦ ПО), ГОСТ Р 50922 (термины), ГОСТ Р 58412 (угрозы при разработке ПО). Часто встречающееся в авто-пересказах упоминание ГОСТ Р 51904 (это авионика!) и ISO 27001/15408 в нормссылках 56939 — ошибка.

Критическая ошибка — та, что способна привести к нарушению безопасности обрабатываемой информации (например, переполнение буфера, разыменование нулевого указателя, ошибки работы с памятью). Именно такие ошибки в приоритете при статическом анализе.

Приказ № 76 ввёл требования по безопасности информации, устанавливающие уровни доверия (УД) к средствам ТЗИ. Они применяются при сертификации СрЗИ и фактически требуют от разработчика выстроенных процессов безопасной разработки.

Установлено 6 уровней доверия: 6-й — низший, 1-й — высший. УД6 применяется, например, на объектах КИИ 3 категории, в ГИС 3 класса; чем критичнее объект, тем выше требуемый УД (меньше номер).

Приказ № 240 ввёл новый вид сертификации — сертификацию не продукта, а процессов безопасной разработки ПО средств защиты информации, на соответствие ГОСТ Р 56939. Зарегистрирован в Минюсте 16.04.2024, действует с 01.06.2024 (изменён приказом ФСТЭК России № 230 от 30.06.2025; изменения вступили в силу 30.09.2025).

Сертификация процессов РБПО подтверждает зрелость процессов разработки изготовителя СрЗИ на соответствие ГОСТ Р 56939. Сертификацию проводят в рамках системы ФСТЭК (аккредитованные органы), а не произвольные организации.

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

Лицензируются ТЗКИ (ПП РФ № 79, орган — ФСТЭК), разработка и производство СЗИ, а также деятельность по выявлению электронных устройств для негласного получения информации (последняя — с оговоркой: лицензируется, если ведётся в интересах третьих лиц; для собственных нужд юридического лица это исключение). А вот применение сертифицированных СЗИ оператором для собственных нужд лицензии не требует — лицензируется оказание услуг и производство, а не использование. Криптографические средства лицензирует ФСБ России.

Лицензирование ТЗКИ (по ПП РФ № 79) осуществляет ФСТЭК России. ФСБ лицензирует деятельность, связанную с шифровальными (криптографическими) средствами; Роскомнадзор — оператор реестра операторов ПДн.

В требованиях к уровням доверия (приказ № 76) есть требования к безопасной разработке и производству средства и к соответствующей документации. Выполнить их без выстроенных процессов РБПО (ГОСТ Р 56939) практически невозможно — поэтому РБПО стало необходимым условием сертификации.

В разделе 5 ГОСТ Р 56939-2024 описаны 25 процессов (5.1–5.25) — от планирования и обучения до вывода ПО из эксплуатации. Это существенное расширение и переработка по сравнению с редакцией 2016 года.

Действует ГОСТ Р 56939-2024, введённый 20.12.2024 взамен 56939-2016. ГОСТ Р 71207-2024 — отдельный стандарт о статическом анализе, применяется совместно с 56939, но не заменяет его.

Каждый процесс описан единообразно: цели, требования к реализации и артефакты (документы, отчёты, журналы, конфигурации), подтверждающие выполнение. Именно артефакты проверяются при аудите и сертификации процессов.

Моделирование угроз (5.7), статический анализ (5.10), композиционный анализ (5.16) — процессы стандарта. При этом ГОСТ не предписывает конкретный продукт: организация сама выбирает инструменты, обосновывая выбор.

Реализация процессов РБПО оформляется Руководством по разработке безопасного ПО и сопутствующими регламентами. Его разработка — отдельное практическое занятие программы (Тема № 8).

Композиционный анализ (КАПО) инвентаризирует сторонние компоненты, сверяет их с базами уязвимостей и проверяет лицензии. Результат фиксируется в перечне программных компонентов (ППК / SBOM).

Артефакты — это регламенты, отчёты инструментов, модели угроз, ППК, журналы и т. п., доказывающие, что процесс действительно выполняется. Коммерческое предложение поставщика к артефактам РБПО не относится.

Атаки на цепочку поставок внедряют вредоносный код через сторонние пакеты, репозитории или процесс сборки. Контрмеры — внутренний доверенный репозиторий, фиксация версий (а не «latest»), сверка ППК с базами уязвимостей, контроль поставщиков.

ППК — это «ведомость состава ПО», аналог SBOM: перечень всех компонентов с версиями, хэшами, лицензиями и связями (в т.ч. транзитивными). По материалам лекции, в качестве формата ППК прорабатывается CycloneDX — это практика и позиция рабочих материалов ФСТЭК и ИСП РАН, а не дословная норма ГОСТ.

РБПО — это управляемый и непрерывный процесс: внедрение поэтапное, артефакты обязательны для аудита, модели и перечни регулярно актуализируются. «Настроил и забыл» противоречит идее жизненного цикла.

Управление уязвимостями пронизывает весь ЖЦ: от анализа в разработке до поиска уязвимостей при эксплуатации (процессы 5.23, 5.24). Откладывать поиск «на потом» нельзя — это удорожает исправление и повышает риск.

Прямые зависимости тянут за собой множество транзитивных, о составе которых разработчики часто не знают. Поэтому первый запуск генератора ППК/SBOM нередко становится «открытием» реального состава продукта.

Процесс 5.10 — «Статический анализ исходного кода» (детализируется ГОСТ Р 71207-2024). 5.11 — динамический анализ, 5.7 — моделирование угроз, 5.2 — обучение сотрудников.

Планирование задаёт, какие процессы и в каком объёме применяются, кто отвечает, какие ресурсы и инструменты нужны, как процессы будут улучшаться. Это «нулевой» процесс, с которого начинают внедрение РБПО.

ГОСТ Р ИСО/МЭК 12207 — базовый стандарт процессов жизненного цикла ПО, на который опирается 56939. ГОСТ Р 50922 — термины ИБ; ГОСТ 34.602 — ТЗ на АС.

План РБПО фиксирует состав процессов, роли, ресурсы, инструменты и критерии. Маркетинговая стратегия к процессам безопасной разработки не относится — это другая область управления.

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

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

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

Требования безопасности задают рано (они влияют на архитектуру) и периодически пересматривают по мере изменения угроз, НПА и самого продукта. Их учёт и актуализация — часть управляемого процесса.

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

Процесс 5.2 — «Обучение сотрудников». Он стоит одним из первых не случайно: без подготовленных людей остальные процессы РБПО работают формально.

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

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

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

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

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

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

РБПО — организационная задача: без поддержки руководства (ресурсы, приоритеты, контроль) процессы не приживаются. Именно поэтому программа курса адресована руководителям и ответственным сотрудникам.