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

Методические документы регуляторов, связанные с Управлением Уязвимостями

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

Методические документы регуляторов, связанные с Управлением Уязвимостями. В презентации, которую я сейчас готовлю к ISCRA Talks, будет слайд про документы регуляторов связанные с VM-ом, выпущенные за последние 1,5 года. Если я что-то важное пропустил, напишите мне, пожалуйста, в личку или комментом в пост в ВК.

1. НКЦКИ "Критерии для принятия решения по обновлению критичного ПО, не относящегося к open-source". Рекомендательный алгоритм, помогающий принять решение: установить обновление с риском привнести НДВ (недекларированные возможности)/блокировку функциональности или не обновлять с риском получить эксплуатацию уязвимости. Этого алгоритма я касался в выступлении на PHDays 11 и писал скрипты автоматизации проверок по нему в рамках опенсурсного проекта Monreal.

2. ФСТЭК "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств". Описывает каким образом можно получить общую оценку критичности уязвимости и выставить требования по оперативности исправления. Я писал комментарии по этой методике.

3. ФСТЭК "Методика тестирования обновлений безопасности программных, программно-аппаратных средств". Описывает какими способами искать НДВ в обновлениях безопасности. Мои комментарии к этой методике: Часть 1, Часть 2, Часть 3.

4. ФСТЭК "Рекомендации по безопасной настройке операционных систем Linux". Рекомендации распространяются на настройку НЕсертифицированных ОС (Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Я разбирал эти рекомендации.

5. ФСТЭК "Руководство по организации процесса управления уязвимостями в органе (организации)". Подробное описание этапов процесса, участников процесса и выполняемых ими операций. Я написал комментарии к проекту руководства "процесс не для человеков" и "место автоматического детектирования уязвимостей".

Заметил, что проект руководства по управлению уязвимостями, который был публично доступен на сайте ФСТЭК с 31 марта по 17 апреля для сбора отзывов, с сайта убрали

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

Заметил, что проект руководства по управлению уязвимостями, который был публично доступен на сайте ФСТЭК с 31 марта по 17 апреля для сбора отзывов, с сайта убрали. Видимо теперь уже до доработанного официального релиза. Поэтому ту публичную версию от 31 марта заливаю сюда. Чтобы было понятно к чему относятся мои комментарии про "процесс не для человеков" и "место автоматического детектирования уязвимостей". Кроме того, после официального релиза будет интересно посмотреть, что изменилось по сравнению с проектом.

Насчёт количества CVEшек в NVD и БДУ ФСТЭК

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

Насчёт количества CVEшек в NVD и БДУ ФСТЭК. Годы летят и обычно не задумываешься насколько быстро растет реестр NVD CVE. А ведь там действительно 212793 идентификаторов на текущий на текущий момент. 😱 Я вполне помню момент, когда их было 50к. 🙂

Что, реально так много? Не ошибка? Нет, похоже всё правильно: 


$ for i in `seq 2002 2023`; do wget https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-$i.json.zip; done
$ zcat nvdcve-1.1-*  | grep '"ID" : "CVE-[0-9]*-[0-9]*"' | sort | uniq | wc -l
212793

Для интереса посмотрел, а сколько ссылок на CVE есть в БДУ ФСТЭК: 


$ wget --no-check-certificate https://bdu.fstec.ru/files/documents/vulxml.zip
$ unzip vulxml.zip
$ cat export/export.xml | egrep -o "CVE-[0-9]*-[0-9]*" | sed 's/\/identifier>//g' | sort | uniq | wc -l
37757

Можем видеть, что сильно меньше. О причинах судить не берусь, но точно можно сказать, что воспринимать БДУ просто как downstream NVD неправильно. Туда попадает, мягко говоря, не всё, что есть в NVD. В прочем, в NVD тоже есть не всё, что есть в БДУ.

О месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостями

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

О месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостямиО месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостями

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

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

• Принятие решений на получение дополнительной информации
• Постановка задачи на сканирование объектов
• Сканирование объектов

Этап контроля устранения уязвимостей

• Принятие решения о способе контроля
• Проверка объектов на наличие уязвимостей

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

1. Нет требований, что все активы в организации должны быть покрыты средствами анализа защищенности.
2. Нет требований, что в любой момент времени необходимо иметь актуальные данные о состоянии инфраструктуры с точки зрения имеющихся уязвимостей.
3. Нет требований к средствам анализа защищённости, как они должны работать и какие возможности по детектированию уязвимостей должны иметь.
4. Не предусмотрено процедуры оценки полноты и качества детектирования уязвимостей.

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

И, говоря об оценке качества детектирования, раз уж есть ScanOVAL (для российских Linux-ов и Windows), то почему бы не зафиксировать его статус в качестве эталонного средства анализа защищенности и не обязать периодически проводить сверку результатов детектирования ScanOVAL c результатами полученными от средств анализа защищенности, используемых в организации? Как минимум это привлечет внимание к проблеме качества детектирования уязвимостей (как соответствию эталону, так и улучшению эталона), которая сейчас, к сожалению практически не обсуждается.

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

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

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

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 от Сбера. Местами неплохо генерит. 🙂