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

Подбил итоги сентября для англоязычного канала и блога

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

Подбил итоги сентября для англоязычного канала и блога. Сентябрь получился отличный! 😊 Много разнообразных активностей удалось реализовать и разрулить. А с учётом непубличного так и вообще удивительно как всё в итоге удачно сложилось. 🙂 По Patch Tuesday: обратите внимание, что libwebp CVE-2023-4863 теперь идёт с уровнем Urgent, т.к. на гитхабе выложили эксплоит.

---

Hello everyone! On the last day of September, I decided to record another retrospective episode on how my Vulnerability Management month went.

Education
00:09 BMSTU online cyber security course
00:33 Positive Technologies online Vulnerability Management course
00:52 Bahasa Indonesia

Russian Podcasts
01:20 Прожектор по ИБ ("Information Security Spotlight") podcast
01:47 КиберДуршлаг ("Cyber Colander") by Positive Technologies

Main Job
01:57 Goodbye Tinkoff

Patch Tuesday
02:54 September Microsoft Patch Tuesday
03:11 Remote Code Execution – Microsoft Edge/libwebp (CVE-2023-4863), Memory Corruption – Microsoft Edge (CVE-2023-4352)
04:11 Remote Code Execution – Windows Themes (CVE-2023-38146) "ThemeBleed"
04:48 Information Disclosure (NTLM relay attack) – Microsoft Word (CVE-2023-36761)
05:19 Elevation of Privilege – Microsoft Streaming Service Proxy (CVE-2023-36802)
05:36 Remote Code Executions - Microsoft Exchange (CVE-2023-36744, CVE-2023-36745, CVE-2023-36756)

Other Vulnerabilities
06:54 Bitrix CMS RCE (BDU:2023-05857)
07:32 RHEL/CentOS 7 can’t be detected, can’t be fixed vulnerability (CVE-2022-1012)
08:09 Qualys TOP 20 vulnerabilities

Vulnerability Management Market
09:06 Forrester and GigaOm VM Market reports
09:49 R-Vision VM

🎞 Video
🎞 Video2 (for Russia)
📘 Blogpost

Руководство ФСТЭК по Управлению Уязвимостями

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

Руководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 2. Что определяет руководство?

Продолжаем увлекательное сравнение. Видим в Общих положениях новый пункт 1.2.

"Руководство определяет состав и содержание работ по анализу и устранению уязвимостей (далее – управление уязвимостями),"

Отмечаем: "управление уязвимостями" = "анализ и устранение уязвимостей" ❗️

"выявленных в

программных,
программно-аппаратных средствах"

Ага, вот куда ПО и ПАС из названия документа переехали. ПО и ПАС относящихся к чему?

"информационных систем,
информационно-телекоммуникационных сетей,
автоматизированных систем управления,
информационно-телекоммуникационных инфраструктурах [м.б. инфраструктур?] центров обработки данных, на базе которых функционируют эти системы и сети (далее – информационные системы)."

Т.е., если у вас есть ИС, ИТС, АСУ, центр обработки данных - будьте любезны внедрить VM для ПО и ПАС. 😉👍

Часть 1

Руководство ФСТЭК по Управлению Уязвимостями

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

Руководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 1. Общая структура.

Буду потихоньку делать сопоставление. Если смотреть только на релиз, ничего особенно в глаза не бросается, но изменений довольно много.

1. Скорректировали название. Было "Руководство по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)", стало "Руководство по организации процесса управления уязвимостями в органе (организации)". Новое название кажется более удачным. Тут и акцент именно на процесс, и вроде указывать уязвимости чего тоже смысла нет.
2. Общая структура документа не изменилась. Но добавили приложение с описанием BPMN элементов на схемах - полезная вещь.
3. Текстовая часть расширилась. Проект был на 29 страниц, релиз на 33 (включая одну страницу-приложение).

Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)"

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

Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)". Дождались, ура! 🙂 На первый взгляд не сильно отличается от исходного проекта, но нужно аккуратненько посравнивать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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