Архив рубрики: ФСТЭК

На сайте Anti-Malware 25 мая вышел аналитический отчёт "Сканеры уязвимостей: обзор российского рынка и отечественных решений"

Добавить комментарий

На сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решений
На сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решений

На сайте Anti-Malware 25 мая вышел аналитический отчёт "Сканеры уязвимостей: обзор российского рынка и отечественных решений". В обзоре были рассмотрены следующие сканеры уязвимостей:

🔻 BITsignal
🔻 Hscan
🔻 Security Vision VS
🔻 ScanOVAL
🔻 RedCheck
🔻 XSpider PRO
🔻 METASCAN
🔻 Ревизор Сети
🔻 Сканер-ВС

Для каждого решения приводятся характеристики, иллюстрации (для всех, кроме Security Vision VS, это скриншот), возможности сканера, информация о нахождении в реестрах и наличии сертификатов, а также ссылки на дополнительную информацию.

Сделал выжимку из отчёта:

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

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

🌍 Как развивается мировой рынок сканеров уязвимостей. Мировой рынок сканеров уязвимостей продолжает уверенно расти как в сегменте сервисов сканирования (Vulnerability Scanning Service), так и в сегменте программных продуктов (Vulnerability Scanner Software). По оценкам аналитиков, к 2033 году объём этих рынков увеличится в несколько раз благодаря распространению облачных и гибридных инфраструктур, внедрению практик DevSecOps, развитию контейнерной безопасности и автоматизации, а также использованию технологий искусственного интеллекта и машинного обучения. Среди наиболее известных решений этого класса можно выделить Nessus и Tenable.io (актуальное название - Tenable One Vulnerability Management), Qualys, Nexpose, Acunetix и Burp Suite.

🇷🇺 Как развивается российский рынок сканеров уязвимостей. Уход зарубежных сканеров уязвимостей, таких как Qualys, Nexpose и Nessus, не привёл к образованию пустоты на российском ИБ-рынке: отечественные вендоры и новые игроки VS-сегмента активно включились в процессы импортозамещения, усилив конкуренцию и расширив выбор решений для заказчиков - от классических сетевых сканеров до платформ с функциями комплаенса и поддержкой требований российских регуляторов. При этом, несмотря на развитие рынка, в отраслевых исследованиях фиксируются сохраняющиеся проблемы отечественных решений. Дополнительно аналитические материалы указывают на постепенное размывание границы между сканерами уязвимостей и системами Vulnerability Management, при этом классические сканеры остаются базовым инструментом VM-экосистем.

🧩 Альтернативные решения на рынке. Решения для управления уязвимостями (Vulnerability Management, VM) представляют собой отдельный класс систем, однако сканирование уязвимостей является их неотъемлемой частью, поэтому такие продукты часто рассматриваются вместе со сканерами уязвимостей; к ним относятся MaxPatrol VM, Security Vision VM, R-Vision VM, ScanFactory VM и Vulns.io VM. Наряду с коммерческими решениями существует большое количество сканеров с открытым исходным кодом, которые требуют высокой экспертизы и используются либо как вспомогательные инструменты, либо как источник данных в комплексных системах. Среди наиболее известных open source решений можно выделить Nikto, Nmap, Nuclei и OpenVAS, а также специализированные инструменты для контейнеров, веб-приложений, кода и баз данных. Дополнительно для задач выявления уязвимостей могут использоваться смежные классы систем, включая платформы управления поверхностью атаки (EASM) и решения для симуляции кибератак (BAS).

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

Материал интересный. Единственное: список решений довольно неоднородный. В основном там инфраструктурные сканеры уязвимостей, но есть и периметровые сканеры (BITsignal, METASCAN), и даже бесплатный локальный хостовый сканер от ФСТЭК ScanOVAL. Не уверен, что собирать их все в одну группу "сканеров" - это правильный подход, слишком уж разные решения. Свою, на мой взгляд, более удачную классификацию я представлял в рамках проекта карты отечественных VM-вендоров.

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (3.0)

Добавить комментарий

Инфосистемы Джет выложили Результаты тестирования решений для управления уязвимостями по новой версии методики (3.0)

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (3.0). Тестировали следующие продукты:

🔸 MaxPatrol VM v. 2.8 (27.6)
🔸 SecurityVision VM v. 5.0.1773849508
🔸 ScanFactory v. 7.21.9
🔸 R-Vision VM v. 6.2
🔸 AlphaSense v. 4.57.08.04

В отличие от тестирования по второй версии методики, здесь отсутствуют RedCheck и Vulns io VM. Возможно их добавят позже.

Оценка проводилась по 12 группам требований:

⚙️ Нефункциональные требования. Автоматическое и оффлайн обновление базы уязвимостей, открытый доступ к базе, централизованное управление, агентское сканирование и работа с хостами, поддержка изолированных сегментов и распределенной установки компонентов, мультиязычность, мультитенантность, а также соответствие требованиям ФСТЭК и включение в реестр отечественного ПО.

📱 Мобильный сканер. Наличие портативного (мобильного) сканера с возможностью переноса результатов в основную инсталляцию и формирования отчетов.

🗺️ Управление активами. Интерактивная карта сети, управление активами (динамические группы, поиск, карточки), скоринг и дедупликация активов, тегирование, хранение истории изменений, патч-менеджмент и выполнение административных команд на активах.

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

📊 Функционал визуализации и отчетности. Визуализация данных через настраиваемые виджеты и дашборды, создание и планирование отчетов, расширенная кастомизация интерфейса и объектов.

💻 Поддерживаемые типы активов для сканирования. Поддержка сканирования операционных систем (Windows, Linux и отечественных ОС), сетевого и серверного оборудования, СУБД и серверного ПО, а также поддержка периферийных устройств, промышленных систем (ICS/SCADA) и контейнеров.

🔗 Возможности интеграции. Документированный API с управлением доступом через ключи, встроенный мониторинг работоспособности (health-check) и интеграции с внешними системами мониторинга, поддержка доменной аутентификации, интеграции с Service Desk/ITSM и с SIEM, получение данных об активах из смежных систем и отправка оповещений.

🛡️ Управление сканированием и уязвимостями. Кастомизация карточки и тегирование уязвимостей, планирование и управление сканированиями (расписания, профили, ретроскан, исключения, технологические окна, пауза, клонирование), настройка правил и параметров сканирования, проверка доступности и учетных записей, в том числе брутфорс с пользовательскими словарями и несколькими типами учетных записей, управление исключениями, прогресс в реальном времени, расширенная работа с уязвимостями (CVE/CWE/БДУ, CVSS v2–v4 и кастомные метрики, скоринг, дедупликация, эксплуатируемость, вероятность использования, наличие эксплойтов, путь атаки, трендовость), а также рекомендации, внешние ссылки и методики ФСТЭК и НКЦКИ, плюс оповещения о событиях системы.

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

🌐 Сканирование веб-ресурсов. Аутентификация в веб-приложениях, сканирование веб-ресурсов (поиск поддоменов, скрытых файлов и директорий), режимы имитации и активной атаки, а также обнаружение широкого спектра уязвимостей (инъекции, CSRF, загрузка файлов и доступ к ФС, клиентские атаки, редиректы, слабая криптография, небезопасные security headers, утечки информации, cookie и сессионные уязвимости, memory corruption).

🔐 Безопасность. Настраиваемая ролевая модель, управление парольной политикой (сложность, история, минимальная длина, срок действия), блокировка учетных записей после неудачных попыток входа, шифрование критичных данных с поддержкой пользовательских ключей и создание/восстановление из резервных копий.

⚡ Производительность и эффективность. Скорость обновления базы уязвимостей (от появления в публичных источниках до добавления в сканер), настройка интенсивности сканирования через веб-интерфейс, поддержка геораспределенных филиалов и мультитенантности, а также возможность выбора нескольких модулей сканирования в одной задаче.

Возможные значения для каждого требования: ✅ Да, ❌ Нет, Частично. За исключением "Производительность и эффективность" → "Скорость добавления новых уязвимостей в базу уязвимостей решения…", где указывается значение в часах. По некоторым требованиям доступны 💬 комментарии вендоров.

Работа была проделана, вне всяких сомнений, большая и основательная. 🔥 Но, как и в случае тестирования по первой версии методики, мне не хватает оценки качества детектирования. Большая часть этой функциональности скрывается за пунктом "Поддержка сканирования ОС: Windows Server, Windows, AlmaLinux, Ubuntu, Debian" с галочкой у всех вендоров и без каких-либо комментариев. А ведь там самое интересное, ради чего, собственно, пользователи и покупают САЗы. Очень хотелось бы гораздо большей детализации поддерживаемых типов активов и подробного сравнения результатов детектирования на стендах с детализацией до конкретных CVE-шек, чтобы была видна разница в реализованной логике детектирования. Возможно, когда-нибудь и это сделают. 🙂

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки.

Добавить комментарий

Закончу разбирать основной VM-ный пункт 3.3. Управление уязвимостями (КУ) из недавно опубликованного методического документа Мероприятия и меры по защите информации, содержащейся в информационных системах, и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки.

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки. В прошлый раз я расписал Цели и Требования к реализации, сегодня рассмотрю Требования к документированию и Требования к усилению.

ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

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

👥 Подразделения / работники

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

Получается, что подразделения (работники) делятся на:

🔹 ответственных за организацию и контроль управления уязвимостями;
🔹 участвующих в реализации процессов управления уязвимостями.

Для каждого подразделения (работника) необходимо расписать:

🔹 обязанности (функции);
🔹 права (полномочия).

Напрашивается таблица следующей структуры:

Подразделение (работник); За что отвечает; В реализации каких процессов участвует; Обязанности (функции); Права;

📋 Операции

Требования по документированию операций имеют идентичную структуру:

"описание операций, осуществляемых при {название этапа (подпроцесса)}, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при {название этапа (подпроцесса)}"

Буквально вот так:

"описание операций, осуществляемых при мониторинге уязвимостей и оценке их применимости, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при мониторинге уязвимостей и оценке их применимости;
описание операций, осуществляемых при оценке уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при оценке уязвимостей;
описание операций, осуществляемых при определении методов и приоритетов устранения уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при определении методов и приоритетов устранения уязвимостей;
описание операций, осуществляемых при устранении уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при устранении уязвимостей;
описание операций, осуществляемых при контроле устранения уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при контроле устранения уязвимостей;"

Напрашивается таблица следующей структуры:

Этап (подпроцесс); Наименование операции; Описание операции; Перечень исполнителей; Продолжительность реализации; Входные данные; Выходные данные;

Типовые операции и их описания можно взять из Таблиц 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2 "Руководства по организации процесса управления уязвимостями в органе (организации)" от 17 мая 2023 г. (далее для краткости буду обозначать документ как РУУ23).

🗺️ Схемы

"схемы взаимодействия подразделений (работников) при реализации операций по управлению уязвимостями."

Интересно, что здесь требуются схемы взаимодействия при реализации операций. А операция, в терминах РУУ23, - это что-то более-менее атомарное, чем занимается один исполнитель. Например, "Анализ информации об уязвимости" или "Корректировка механизмов мониторинга". Это не тот уровень, где подразумевается взаимодействие. Есть подозрение, что авторы здесь имели в виду не конкретные операции, а этапы (подпроцессы). По аналогии с тем, как этапы разрисованы в РУУ23 на Рисунках 2.2, 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2. Здесь требуется разъяснение регулятора, какие именно схемы должны быть приведены в регламенте. Текущая формулировка неоднозначна.

📜 Какие различия с драфтом?

В релизе убрали требование "перечень информационных систем, для которых осуществляется управление уязвимостями;". Скорее всего, этот пункт убрали, чтобы не привязывать регламент к статическому перечню информационных систем, который быстро устаревает и дублирует данные из CMDB или реестра активов, а также чтобы закрыть лазейку формального комплаенса, когда систему можно просто не включить в список и не управлять её уязвимостями; в результате область применения становится неявно шире и распространяется на все релевантные ИС, что делает подход более процессным и универсальным.

Остальные правки касались только орфографии.

К сожалению, требования к документированию не затрагивают, как именно описываются уязвимости и как ставятся задачи для IT на их устранение. 😔 А ведь именно от качества описаний и постановки задач зависит, будут ли уязвимости корректно поняты и устранены в требуемый срок. Без этого процесс управления уязвимостями рискует остаться формальным.

ТРЕБОВАНИЯ К УСИЛЕНИЮ

Насколько вообще обязательны требования из этого раздела? Читаем в сноске в пункте 3.1:

"Усиления мероприятий (процессов) по защите информации, приведенные в подразделах «требования к усилению» раздела 3, применяются по решению оператора (обладателя информации) для повышения эффективности реализации мероприятий по защите информации и повышения уровня защищенности информационных систем и содержащейся в них информации, а также для снижения возможности нарушителей по реализации угроз безопасности информации.

⚙️ Автоматизация

1) для управления уязвимостями используются автоматизированные системы управления уязвимостями;

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

👾 Анализ угроз

2) для мониторинга уязвимостей применяются средства анализа угроз, в том числе TI-платформы;

Фактически это требование означает, что управление уязвимостями должно стать частью CTEM (Continuous Threat Exposure Management) и учитывать данные о реальной эксплуатации уязвимостей: какие из них уже используются атакующими, какие техники применяются и в каких сценариях. В связке с анализом путей атаки это позволяет понимать, как уязвимости используются злоумышленниками для проникновения к целевым активам, и соответственно приоритизировать их устранение.

🗃️ CMDB

3) для оценки применимости уязвимостей используются данные, содержащиеся в автоматизированных системах сбора и хранения данных об объектах инвентаризации и их конфигурациях (СMDB-системы); (в документе в "СMDB" кириллическая С 🤷‍♂️)

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

🤝 Смежные процессы

4) для контроля устранения уязвимостей используются результаты мониторинга информационной безопасности или управления обновлениями, или управления конфигурациями.

Это требование означает, что контроль устранения уязвимостей должен опираться на перекрёстные проверки из уже существующих процессов - мониторинга ИБ, управления обновлениями и управления конфигурациями. Такой подход снижает риск ошибок, когда устранение уязвимости подтверждается только средством анализа защищённости (САЗ), но фактически проблема в системе сохраняется. Использование нескольких независимых источников позволяет подтвердить факт устранения с разных сторон и повысить достоверность контроля.

📜 Какие различия с драфтом?

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

Очень жаль, что убрали этот пункт, потому что результаты пентестов и независимого анализа защищённости часто выявляют уязвимости, которые по каким-то причинам не обнаруживаются штатными САЗ, используемыми в процессе управления уязвимостями. Такие находки являются индикатором проблем в процессе: недостаточного покрытия активов, низкого качества детектирования или несоблюдения сроков устранения. Они позволяют объективно оценить эффективность VM-процесса и улучшить его.

Остальные исправления касаются опечаток и косметических изменений.

---

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

Начну разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки

1 комментарий

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

Начну разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки. Также сделаю предположения, откуда были взяты формулировки. Номер и название пункта остались теми же "3.3. Управление уязвимостями", но добавился двухбуквенный маркер "КУ", который, по всей видимости, означает "Контроль Уязвимостей".

Формулировка цели. "Цель: Своевременное выявление уязвимостей информационных систем, оценка их критичности, определение методов и приоритетов устранения уязвимостей, а также контроль за устранением уязвимостей". Она полностью совпадает с тем, что было в драфте. Фактически это перечисление этапов (или подпроцессов) VM-процесса. Имхо, цель должна отвечать на вопрос не "что делаем", а "какого результата достигаем": снижение уровня риска информационной безопасности, уменьшение количества эксплуатабельных уязвимостей или повышение защищенности информационных систем. Но сформулировано как сформулировано. 🤷‍♂️

Требования к реализации. Раздел начинается с перечисления того, что управление уязвимостями должно предусматривать. Это также перечисление этапов (подпроцессов), но несколько по-другому сформулированных. Они совпадают с этапами из "Руководства по организации процесса управления уязвимостями в органе (организации)" от 17 мая 2023 г. (далее для краткости буду обозначать документ как РУУ23).

Распишу маппинг формулировок из требований к реализации / РУУ23 и целей управления уязвимостями:

🔹 мониторинг уязвимостей и оценка их применимости → выявление уязвимостей информационных систем
🔹 оценка уязвимостей → оценка критичности уязвимостей
🔹 определение методов и приоритетов устранения уязвимостей → определение методов и приоритетов устранения уязвимостей ✅
🔹 устранение уязвимостей → ❓
🔹 контроль устранения уязвимостей → контроль за устранением уязвимостей

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

Далее по каждому этапу (подпроцессу) перечисляются требования к реализации.

🔎 Мониторинг уязвимостей и оценка их применимости

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

Очевидно, эта формулировка частично взята из описания соответствующего этапа в РУУ23: "На этапе мониторинга уязвимостей и оценки их применимости осуществляется выявление уязвимостей на основании данных, получаемых из внешних и внутренних источников, и принятие решений по их последующей обработке". Были только добавлены примеры внутренних и внешних источников данных.

В этом пункте регулятор предписывает выстроить полноценную работу по выявлению уязвимостей, в которой автоматизированные средства анализа защищенности (САЗ) являются лишь одним из источников данных. Если детектирование уязвимостей для какого-то класса систем или технологий не поддерживается имеющимися САЗ, это не означает, что детектирование и устранение уязвимостей в них можно вовсе не осуществлять. Для каждой уязвимости, актуальной для инфраструктуры, необходимо понимать, как и чем она будет детектироваться. В случае отсутствия готовых САЗ может потребоваться разработка собственных средств автоматизации либо проведение анализа на наличие уязвимостей вручную. Поэтому использование САЗ с наилучшим качеством детектирования уязвимостей становится в том числе способом снизить объем in-house разработки и ручной работы.

⚖️ Оценка уязвимостей

"В ходе оценки уязвимостей определяется уровень критичности уязвимостей применительно к информационным системам органа (организации)."

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе оценки уязвимостей определяется уровень критичности уязвимостей применительно к информационным системам органа (организации)". При этом в драфте было: "В ходе оценки уязвимостей определяется уровень критичности уязвимостей применительно к информационным системам органа (организации) в соответствии с Методикой оценки уровня критичности уязвимостей программных, программно-аппаратных средств, утвержденной ФСТЭК России." В драфте оценка критичности уязвимостей была возможна исключительно по методике ФСТЭК. То есть процесс был жестко регламентирован. В релизе это требование убрано, и осталась только общая обязанность определять уровень критичности уязвимостей.

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

Можно возразить: сроки устранения устанавливаются напрямую 117 приказом. Да, но эти сроки зависят от критичности уязвимости, которая будет определяться непонятно как. 🤷‍♂️ В целом, на мой взгляд, в драфте было сформулировано лучше. Хочется надеяться, что я ошибаюсь и необходимость использовать методику ФСТЭК по оценке уровня критичности уязвимостей всё-таки закрепляется где-то в другом месте. Здесь нужны разъяснения регулятора.

🧭 Определение методов и приоритетов устранения уязвимостей

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

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе определения методов и приоритетов устранения уязвимостей определяется приоритетность устранения уязвимостей и выбираются методы их устранения: обновление программного обеспечения и (или) применение компенсирующих мер защиты информации". Различий с драфтом нет. Фактически здесь фиксируются только методы устранения уязвимостей: обновление программного обеспечения или применение компенсирующих мер. Про приоритизацию ничего не пишут, но, видимо, предполагается, что она будет выполняться в соответствии с оценкой критичности уязвимости из предыдущего пункта. Добавить несколько слов о приоритизации было бы неплохо. Например, что приоритизация должна проводиться с учетом уровня критичности уязвимостей, их реальной эксплуатабельности и использования в потенциальных путях атаки. При этом приоритет устранения уязвимостей должен определяться с акцентом на разрыв критических путей атаки и предотвращение компрометации ключевых активов.

⚙️ Устранение уязвимостей

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

Очевидно, первое предложение взято из описания соответствующего этапа в РУУ23: "На этапе устранения уязвимостей принимаются меры, направленные на устранение или исключение возможности использования (эксплуатации) выявленных уязвимостей." Добавлено только слово "нарушителем". Второе предложение - отсылка к требованиям по срокам устранения из 117 приказа. Различий с драфтом в формулировке нет. Этот абзац вызывает вопросы тем, что вводится некое "исключение возможности использования (эксплуатации) нарушителем выявленных уязвимостей", которое формально отличается от "устранения уязвимостей". Хотя по сути речь идет об устранении уязвимостей методом применения компенсирующих мер (см. предыдущий пункт). В результате становится непонятно, определяются ли требования по SLA на "исключение возможности эксплуатации" исходя из уровня критичности уязвимости (непонятно как определяемого 🙄) в соответствии с 117 приказом или нет. Зачем вводить дополнительные сущности и создавать неоднозначности - непонятно. 🤷‍♂️ При этом здесь никак не регламентируется, как должен быть выстроен процесс взаимодействия между VM и IT. Допустимо ли передавать в IT (прямо в почту CTO 😅) огромные отчеты без конкретных рекомендаций по устранению? Формально, исходя из этого пункта, так делать можно. Но насколько это будет эффективно - большой вопрос. 😏

🔭 Контроль устранения уязвимостей

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

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе контроля устранения уязвимостей осуществляется сбор и обработка данных о процессе управления уязвимостями и его результатах, а также принятие решений по улучшению данного процесса". В релизе исправлена грамматика: "осуществляется сбор и обработка данных" заменено на "осуществляются сбор и обработка данных". В текущем виде пункт не про контроль устранения уязвимостей и соблюдение SLA как таковых. Он смещён в сторону более высокого уровня и описывает сбор и анализ данных о том, как в целом работает процесс управления уязвимостями, оценку его результатов и принятие решений по его улучшению. То есть речь идёт не об операционном контроле закрытия конкретных уязвимостей, а о мониторинге и повышении эффективности всего VM-процесса. Улучшение процесса - это важно, но хотелось бы, чтобы пункт "контроль устранения уязвимостей" был прежде всего про контроль устранения конкретных уязвимостей, раз уж он так называется.

Итого, что же можно сказать об описании требований к реализации этапов (подпроцессов). Очевидно, авторы хотели описать их так, чтобы РУУ23 им полностью соответствовал, поэтому формулировки были взяты оттуда с небольшими изменениями. Но проблема в том, что для РУУ23 раздел 2.1 - это лишь самое общее описание, а полноценно и подробно требования раскрываются в соответствующих разделах РУУ23. Поэтому неполнота и неточность формулировок в 2.1 РУУ23 вполне простительны, а при перенесении в рассматриваемый документ вызывают вопросы и недоумение. Имхо, правильно было бы формулировки требований переработать и расширить (имея ориентиром всё тот же РУУ23). Ну или прямо предписать использование РУУ23. 😉

🔄 Завершается раздел требованиями по актуализации сведений об уязвимостях:

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

По сравнению с драфтом изменили только орфографическую ошибку. Очевидно, формулировка взята из 2.2 РУУ23: "Процесс управления уязвимостями организуется для всех информационных систем органа (организации) и должен предусматривать постоянную и непрерывную актуализацию сведений об уязвимостях и объектах информационной системы. При изменении статуса уязвимостей (применимость к информационным системам, наличие исправлений, критичность) должны корректироваться способы их устранения". Разница: в релизе "информационные системы оператора", а не "системы органа (организации)". Если это критично, тогда странно, почему в требованиях выше остались "органы (организации)"? 🤔 "Объекты информационной системы" расписаны как "состав программных и программно-аппаратных средств информационных систем", что, наверное, действительно лучше. Изменение "критичность" на "уровень критичности" тоже можно приветствовать.

По сути, если уязвимость была запланирована в задаче на патчинг через месяц, но для неё появились эксплоиты и признаки эксплуатации вживую, её нужно исключить из этой задачи и перепланировать устранение в рамках срочного патчинга. 👍 Единственное, что в отрыве от РУУ23 "корректировка способов устранения уязвимостей" может пониматься по-разному. Было бы лучше, если бы было конкретизировано, что речь о том, что если уязвимость стала объективно более критичной, то это изменение нужно отследить и устранить уязвимость в более сжатые сроки.

❌ И закончить этот пост хотелось бы двумя требованиями к реализации, которые были в драфте, но из релиза были исключены:

🔹 "Процесс управления уязвимостями должен быть взаимоувязан с другими процессами и процедурами деятельности органа (организации) в области защиты информации и информационных технологий."

Это фактически пункт 2.3 РУУ23: "Процесс управления уязвимостями связан с другими процессами и процедурами деятельности органа (организации)". Речь там идёт о процессах мониторинга информационной безопасности, оценки защищенности, оценки угроз безопасности информации, управления конфигурацией, управления обновлениями, применения компенсирующих мер защиты информации. В целом, идея правильная, но, возможно, этому пункту в данном документе действительно не место.

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

Это фактически сокращённый пункт 2.4 РУУ23: "Участниками процесса управления уязвимостями являются…". Также не вижу большого вреда от отсутствия этого пункта в документе, так как перечень участников процесса и выполняемых ими операций будет сильно зависеть от конкретной организации.

На этом пост заканчиваю, "Требования к документированию" и "Требования к усилению" рассмотрю в следующей части.

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей

Добавить комментарий

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что у них лапки, и они будут обогащать ещё меньше уязвимостей

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей. Хотя, казалось бы куда уж меньше. 😏 Суть обращения, опубликованного NIST 15 апреля, в том, что из-за резкого роста числа CVE они меняют подход к ведению National Vulnerability Database: вместо анализа всех уязвимостей база переходит на риск-ориентированную модель. Полноценно обогащаться будут только приоритетные уязвимости:

🔥 уже эксплуатируемые (из каталога CISA KEV) - обещают обрабатывать за сутки
🏛️ относящиеся к ПО, используемому в госсекторе США (федеральным правительством)
🛠️ относящиеся к критическому ПО, определённому в Executive Order 14028

Остальные CVE останутся в базе, но получат низкий приоритет и будут долго оставаться без детального анализа. При этом NVD отказываются от дублирования CVSS-оценок (если CVSS пришёл от CNA, ему будут доверять, а свой CVSS рассчитывать не будут), будут реже перерабатывать записи, по которым изменилась ситуация, и фактически законсервируют накопившийся бэклог, чтобы сосредоточиться на наиболее опасных уязвимостях ценой снижения полноты и единообразия данных по остальным.

В целом, у меня такие новости вызывают сплошные фейспалмы. 🤦‍♂️ От NIST, которые, по-видимому, разогнали всех адекватных IT/ИБ-специалистов и превратились в синекуру для бюрократов, тратящих огромное финансирование непонятно на что. От CISA, которые не могут навести порядок в базовом ИБ-сервисе, критичном и для США, и для мира в целом. От американской администрации, которая тратит совершенно астрономические суммы на дикие геополитические прожекты, но совершенно не заботится о том, что происходит (разваливается) у них дома. MAGA? Лол, что? 😅

Ну а в практическом плане это означает, что если вы полагаетесь ТОЛЬКО на бесплатную NVD, то совершаете фатальную ошибку. Адекватность этой базы год от года стремительно снижается. Учитывайте альтернативные источники: Vulners, DBugs, VulnCheck, GCVE, БДУ ФСТЭК и прочие. Единственной мировой базы уязвимостей больше нет.

Ниже привожу полный перевод сообщения NIST.
Читать далее →

Ну раз КУ, значит КУ (3 раза)

1 комментарий

Ну раз КУ, значит КУ (3 раза)

Ну раз КУ, значит КУ (3 раза!). Извините, не удержался. 😅

"Владимир Николаевич, у тебя на периметре дыра, админ - бездельник, AD-шка не пропатчена, а ты тут мозги пудришь. Плохо кончится, родной…"

"- Ну вот у вас в организации, как вы определяете - кто уязвимости фиксить должен и в какой срок?
- Ну, это на глаз…
- Дикари!"

"- У меня такое предложение, родной. Ты нам сервак сейчас запатчишь, а мы тебе потом VM-ный мерч привезём, идёт?"

"- Стой! Стой, я говорю! Ты кто? Я спрашиваю: ты кто?
- Lead DevOps Engineer.
- Нет. Ты ITшник. А ты кто?
- Я ведущий разработчик.
- Не-ет, ты тоже ITшник. Ты ITшник, ты ITшник и он ITшник. А я VM-щик, и они VM-щики! Так что ты репорт открой и уязвимости фикси, ясно?"

На сайте ФСТЭК 12 апреля выложили методический документ "Мероприятия и меры по защите информации, содержащейся в информационных системах"

3 комментария

На сайте ФСТЭК 12 апреля выложили методический документ Мероприятия и меры по защите информации, содержащейся в информационных системах

На сайте ФСТЭК 12 апреля выложили методический документ "Мероприятия и меры по защите информации, содержащейся в информационных системах". Проект этого документа выкладывали в феврале.

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

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

Фактически это детализация 117-го приказа ФСТЭК и замена методического документа ФСТЭК России от 11 февраля 2014 года "Меры защиты информации в государственных информационных системах".

Документ объёмный, 255 страниц (по файлу в формате ods). Я посмотрел, в каких разделах встречается слово "уязвимости" в различных формах (звёздочками условно отметил частоту упоминания):

✳️✳️✳️✳️✳️ 3.3. Управление уязвимостями (КУ)
✳️✳️✳️✳️✳️ ЗКО.8 Выявление и устранение уязвимостей в контейнерной среде
✳️✳️✳️✳️ II. ФАКТОРЫ, ВЛИЯЮЩИЕ НА СОСТОЯНИЕ ЗАЩИТЫ ИНФОРМАЦИИ, СОДЕРЖАЩЕЙСЯ В ИНФОРМАЦИОННЫХ СИСТЕМАХ
✳️✳️✳️ 3.18. Обеспечение защиты информации при использовании искусственного интеллекта (ИИ)
✳️✳️ 3.4. Управление обновлениями (КО)
✳️✳️ 3.12. Обеспечение разработки безопасного программного обеспечения (БР)
✳️✳️ ЗИВ.4 Контроль целостности
✳️ 3.1. Выявление и оценка угроз безопасности информации (ВУ)
✳️ 3.19. Проведение периодического контроля уровня защищенности информации, содержащейся в информационных системах (ПК)
✳️ РСБ.2 Анализ событий безопасности и реагирование на них
✳️ ЗСВ.1 Доверенная загрузка средств виртуализации и виртуальных машин
✳️ ЗКО.2 Регистрация событий безопасности в контейнерных средах
✳️ ЗБД.3 Защита пользовательских данных
✳️ ЗБД.4 Контроль целостности

Ниже привожу полную структуру документа.
Читать далее →