Архив метки: FSTEC

В комментах в ВК (а туда всё дублируется и вы можете там комментить) мне написали, что в последнем посте слишком много аббревиатур и непонятно даже в чём весь цимес

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

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

1. Есть уязвимость в архиваторе WinRAR, для которой Positive Technologies предварительно получили CVE идентификатор.

2. После того как уязвимость была исправлена, Mitre Corporation (они держат реестр CVE идентификаторов и являются апстримом для National Vulnerability Database) по какой-то причине начали использовать этот ранее выданный CVE идентификатор для какой-то другой уязвимости, которая к WinRAR никак не относится.

3. Можно подумать, что случилась какая-то ошибка и Mitre завели эту уязвимость WinRAR под другим CVE идентификатором. Но нет, других уязвимостей WinRAR с похожим описанием за 2021 год и позже не наблюдается. Просто забили.

Почему так вышло? Кто его знает, Mitre нам не расскажут. Можно предположить такую логику Mitre: "вы, Positive Technologies, под санкциями, мы от вас больше уязвимости принимать не будем". В итоге сложилась ситуация, когда один и тот же CVE идентификатор CVE-2021-35052 используется для ссылки на две совершенно разные уязвимости. Коллизия. 🤷‍♂️

Разумеется, это очень странное и контрпродуктивное поведение со стороны Mitre. Но дело не только в них. Было несколько похожих эпизодов с западными IT-вендорами, когда PT на сообщение об уязвимости либо не отвечали, либо в acknowledgement не ставили. А, например, в случае с Citrix сначала добавили acknowledgement, потом тихонько убрали, а после публичного обсуждения вернули назад. Насколько я понимаю, такое было не только с PT, но и с Digital Security, и с другими исследовательскими компаниями под американскими санкциями.

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

Читая проект руководства по Vulnerability Management от ФСТЭК

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

Читая проект руководства по Vulnerability Management от ФСТЭК

Читая проект руководства по Vulnerability Management от ФСТЭК. Процесс не для человеков. Если брать совсем упрощенно, то в руководстве описан процесс, где на входе мы имеем общий поток уязвимостей (не только от сканеров, а вообще всех известных BDU/CVE уязвимостей!), который мы пропускаем по хитрому многоступенчатому процессу, несколько напоминающему Gartner Vulnerability Management Сycle. В рамках этого процесса мы делаем вывод о релевантности уязвимости и если уязвимость релевантна, устраняем её срочно, устраняем планово или применяем компенсирующие меры.

Главное, что вызывает озабоченность это кажущаяся окончательность принятия решения по уязвимости. Приняли решение, что уязвимость нерелевантная и забыли о ней. Приняли решение, что она не особо критичная и может быть устранена планово, закинули в неприоритетную задачку на IT и забыли об этой уязвимости (как минимум на время фикса).

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

Рассмотрим примеры:

1. Мы на этапе мониторинга уязвимостей и оценки их применимости пришли к выводу, что уязвимость нерелевантная. На следующей день изменились входные данные по уязвимости (уточнили тип, был EoP, стал RCE) или составу инфраструктуры (думали нет таких софтов у нас, а они появились) и она уже становится релевантной. А мы её уже убрали из рассмотрения и пропустили поэтому супер-критичную уязвимость.

2. Возьмем "этап оценки уязвимостей". Там есть "Определение уровня опасности уязвимости" - Расчет базовой, контекстной и временной метрик CVSS. Как минимум временная метрика требует постоянной актуализации. Там есть Exploit Code Maturity (E). Сегодня эксплоита для уязвимости нет, а завтра он появится.

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

- ранее нерелевантные уязвимости пускать в исправление (и наоборот)
- плановое исправление заменять на срочное (и наоборот)
- планировали патчить, а теперь решили компенсировать (и наоборот).

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

В рамках руководства весь этот момент можно снять одним уточнением в разделе "2. ПРОЦЕСС УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ", что все уязвимости должны постоянно и непрерывно пропускаться по всему процессу и при изменении их статуса (релевантность, тип исправления) должны корректироваться фактические способы устранения уязвимостей. Причем не только уязвимости, которые детектируются в инфраструктуре сканерами, но и вообще все. Даже если уязвимости уже ранее устранялись. Безусловно, это сразу поменяет характер документа, по сути он превратится в ТЗ для разработки автоматизированной системы, но по-другому здесь вряд ли получится.

А вы уже прочитали проект руководства по Управлению Уязвимостями от ФСТЭК? Дали фидбек?

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

А вы уже прочитали проект руководства по Управлению Уязвимостями от ФСТЭК? Дали фидбек?

А вы уже прочитали проект руководства по Управлению Уязвимостями от ФСТЭК? Дали фидбек? 😏

Поигрался немножко с новой версией @kandinsky21_bot от Сбера. Местами неплохо генерит. 🙂

Проект руководства по Vulnerability Management от ФСТЭК

8 комментариев

Проект руководства по Vulnerability Management от ФСТЭК

Проект руководства по Vulnerability Management от ФСТЭК. Уже в паблике. 26 страниц. (upd. после окончания сбора отзывов первоначальная ссылка перестала работать)

Что вас ждет внутри:

1. Общая схема VM-процесса и его связи с другими ИБ процессами организации
2. Перечень участников процесса и выполняемых ими операций
3. Подробное описание 5 этапов процесса, их схемы, описания операций:
3.1. Мониторинг уязвимостей и оценка их применимости
3.2. Оценка уязвимостей
3.3. Определение методов и приоритетов устранения
3.4. Устранение уязвимостей
3.5. Контроль устранения уязвимостей

Вещь абсолютно монументальная. Без шуток. Ничего более детализированного на тему VM-а я ещё не видел.

А вот будет ли это работать на практике? Зависит от нас и от наших правок:

"ФСТЭК России предлагает специалистам в области защиты информации заинтересованных государственных органов власти, организаций, субъектов критической информационной инфраструктуры рассмотреть проект методического документа и направить предложения по доработке указанного документа в соответствии с прилагаемой формой на адрес электронной почты otd22@fstec.ru.

Предложения и замечания по проекту методического документа принимаются до 17 апреля 2023 г."

Давайте все ознакомимся и дадим полезную обратную связь. Нам потом с этим жить и свои VM-процессы в соответствии с этими рекомендациями выстраивать.

upd. Мои посты-комментарии:

1. Читая проект руководства по Vulnerability Management от ФСТЭК. Процесс не для человеков.
2. О месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостями.

Погонял, по случаю, ScanOVAL - бесплатный сканер уязвимостей от ФСТЭК

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

Погонял, по случаю, ScanOVAL - бесплатный сканер уязвимостей от ФСТЭК. На этот раз версию не под Linux, а под Windows (1.4.1). Делюсь впечатлениями.

1. Полезная штука, если качество детекта основного вашего СДУИ вызывает вопросы. Ставишь локально на тестовый хост ScanOVAL и качаешь OVAL-контент к нему, запускаешь, получаешь результаты, приводишь к листу CVE/БДУ идентификаторов, сравниваешься. Всё быстро, просто и бесплатно. Причем если зайти в VM-вендора с претензией "а вот решение X детектирует набор CVE совершенно отличный от того, что ваше решение детектирует для того же тестового хоста" можно получить отписку, что спрашивайте у вендора решения X, а у нас все правильно. В случае сканера от ФСТЭК так отмахнуться будет сложнее. 😏 Таким образом ScanOVAL можно рассматривать как эталонный сканер (не исключая, конечно, что проблемы могут быть и в нем).

2. Результаты работа сканера можно сохранить только в формате HTML. Довольно неожиданно. Но с другой стороны все парсабельно и жить можно. Основной идентификатор, по которому строится отчет, это БДУ. Но в отчете также приводятся ссылки на CVE, так что получить CVE-лист можно одним несложным grep-ом. Правда имейте в виду, что вам нужны именно строчки вида "CVE‑2023‑21716 (CVE)", если грепать просто регуляркой по CVE можно зацепить и описания вида "Уязвимость отлична от список CVE через запятую>".

3. В HTML отчете и GUI подтверждение почему уязвимость была продетектирована доступно в формате "путь до бинаря> (версия>)". В общем случае, конечно, дерево критериев OVAL в такую строчку не сворачивается. Но конкретно для OVAL-контента от АЛТЭКС-СОФТ возможно это и норм. Стандартные результаты в XML (OVAL Results) на самом деле тоже доступны. Лежат в C:\ProgramData\ScanOVAL, а именно в папке Temp. Там же есть и файл OVAL System Characteristics, и привычный OVAL HTML отчет, знакомый, например, по результатам OpenSCAP.

4. Нашел проблемку в руководстве по ScanOVAL. Декларируется, что программа может использоваться для "разработки и отладки описаний (определений) на языке OVAL". По факту сканер запускает только OVAL-контент подписанный ФСТЭКом. Если убрать из XML-контента тег с подписью и попытаться скормить контент ScanOVAL, то он его откажется запускать. Так что разрабатывать и отлаживать свой контент с помощью ScanOVAL не получится. Хотелось бы, чтобы либо описание поменяли, либо ограничение на запуск контента убрали (второе, безусловно, было бы гораздо предпочтительнее). 🙂

Управление уязвимостями в новых реалиях

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

Управление уязвимостями в новых реалиях. Крутой доклад по VM-ной теме с недавно прошедшего Инфофорума. Представлял доклад Андрей Никонов, старший инженер-программист из Фродекс (Vulns.io). Видео в паблике не нашел, но есть даже лучше - слайды с текстом выступления.

Выписал тезисно:

1. Зарубежные VM-вендоры ушли - нет детектов, IT-вендоры ушли - нет обновлений.
2. Атаки на российские компаний множатся, утечки ПД и оборотные штрафы.
3. Рост отечественного ПО -> рост проблемы анализа защищенности этого ПО -> "VM-решения должны уметь работать с операционными системами и программами российского происхождения".
4. В достаточной степени отечественные VM-решения поддерживают отечественное ПО? Непонятно. "Никто открыто не публикует списки поддерживаемых ПО и не дает внятных ответов по степени покрытия российского софта".
5. Необходимы данные об уязвимостях отечественного ПО.
5.1. Западные компании "публикуют уязвимости, найденные в своих продуктах, причем эти данные являются общедоступными, несмотря на то, что большая часть ПО является коммерческим".
5.2. "Данные NVD также являются общедоступными, содержат огромное количество уязвимостей, но для проведения точного аудита годятся мало. В основном из-за того, что они используют собственный формат данных, и в них не указаны правила, по которым можно определить, является ПО уязвимым или нет". -> Ага, детект по CPE-шкам это зло.
5.3. Все ли вендоры одинаково описывают свои уязвимости? Далеко не все. OVAL стал довольно популярным. Но этого недостаточно.
5.4. У нас хорошие источники это БДУ ФСТЭК и OVAL RedOS. "Остальные вендоры, если и публикуют свои данные, то в намного более расслабленном режиме – обычно это выглядит как лента новостей или запись в блоге. Это очень сильно усложняет их обработку. Более того, не все вендоры публикуют данные открыто, хотя некоторые из них готовы предоставить данные по запросу или в случае приобретения сертификата на техническую поддержку."
5.5. Для прикладного ПО из 65 вендоров в базе ФСТЭК 3 публикуют данные об уязвимостях. А в реестре российского ПО 16000 программных продуктов!
5.6. Одной БДУ ФСТЭК недостаточно, т.к. "не указываются правила применимости той или иной уязвимости, для сканирования использовать эти данные проблематично". Данные в БДУ могут добавляться с запаздыванием, данные не всегда актуальны. Напрямую от вендора было бы быстрее.
6. Итог: "обратить внимание разработчиков российского ПО на важность поиска уязвимостей в своих продуктах, и выпуска обновлений безопасности".
Просьбы к регулятору:
"- принять единый стандарт описания уязвимостей или разработать собственный
- обязать разработчиков ОС и ПО вести базы данных уязвимостей в соответствии с принятым стандартом
- оказывать содействие компаниям при организации мероприятий Bug Bounty при условии публикаций найденных уязвимостей в базу ФСТЭК"

В целом, огонь! 🔥 Как раз такие доклады от VM-вендора и хочется видеть. Конкретно про детект уязвимостей и как делать его лучше. Очень сильно перекликается с моими собственными мыслями по этому поводу. Хочется надеяться, что регулятор прислушается.

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском

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

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.