Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)". Дождались, ура! 🙂 На первый взгляд не сильно отличается от исходного проекта, но нужно аккуратненько посравнивать.
Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 2/3. Эталонный сканер.
Вопрос был такой:
> 2. Вы согласны, что бесплатный сканер ScanOVAL ФСТЭК может рассматриваться как эталонное средство детектирования уязвимостей для хостов под управлением Windows и отечественных Linux-ов?
Зачем я задал этот вопрос? Давайте начнем с того, что такое эталонный сканер уязвимостей.
Начнем просто с эталона. Возьмем, для примера, эталон единицы измерения массы. "Международный прототип (эталон) килограмма хранится в Международном бюро мер и весов (расположено в Севре близ Парижа) и представляет собой цилиндр диаметром и высотой 39,17 мм из платино-иридиевого сплава (90 % платины, 10 % иридия)." Вряд ли вы будете использовать этот цилиндр для того, чтобы отвесить себе килограмм помидоров. Скорее всего вы просто положите свои помидоры на электронные весы. А вот для того, чтобы проверить, что эти весы работают корректно, некоторый эталон очень даже пригодится.
Теперь по поводу сканеров уязвимостей. Не секрет, что если вы просканируете один и тот же хост различными сканерами уязвимостей, то вы получите различные же результаты. Иногда практически не пересекающиеся по CVE идентификаторам. Тут дело не в том, что различные VM-вендоры поддерживают различные наборы Third-party софтов, это ещё простительно. Но даже если мы ограничимся только детектированием уязвимостей ОС, по KB-шкам Windows или бюллетеням безопасности Linux, всё равно разница будет, потому что каждый VM-вендор реализует свои собственные алгоритмы детектирования. А уязвимость на хосте либо есть, либо нет. Это вещь объективная. И если результаты различаются, значит как минимум одно из средств детектирования работает неправильно.
Есть ли у нас такой сканер уязвимостей, результаты детектирования которого мы могли бы принять за эталон? Есть один претендент - ScanOVAL. Он общедоступный, бесплатный и самое главное выпущен ФСТЭК. С ним вполне удобно сравнивать результаты детектирования уязвимостей для Windows и российских Linux-ов.
Так готовы ли VM-вендоры признать ScanOVAL за эталон качества детектирования уязвимостей?
Каверзность вопроса в том, что если ответить "да", то все различия при сравнении со ScanOVAL будут автоматически являться ошибками. А если ответить "нет", то получается сканер уязвимостей регулятора некорректно уязвимости детектирует? Давайте-ка с этого момента поподробнее. 😏
Любой ответ представителя VM-вендора, сулит проблемы для него. А для клиентов наоборот - любой ответ выгоден, т.к. подсвечивает проблемы детектирования уязвимостей и улучшает либо возможности продукта VM-вендора, либо ScanOVAL. Ну или хотя бы дискуссию провоцирует о качестве детектирования, и то неплохо.
В итоге вопрос про ScanOVAL задали в 2:22:01 в таком виде:
"А у нас ещё такой провокационный немного вопрос в сторону присутствующих здесь вендоров. А что если просто взять ScanOVAL и с помощью умелых рук организовать весь процесс, чем это будет слабее Enterprise решений?" 🤦🏻♂️
Как видите, вопрос не про эталон, не про качество сканирования, а из серии можно ли выкопать котлован малой сапёрной лопаткой. Ну и ответы соответствующие. 🤷♂️
В общем, жаль, что обсуждение этой темы не получилось, но попробуем пропедалировать её в следующий раз. 😉
Все, о чем вы хотели, но боялись спросить регулятора
Виталий Лютиков, ФСТЭК России. Ответ про уязвимости в контексте использования зарубежных NGFW:
"Сам факт использования зарубежного сетевого экрана, особенно в КИИ, не столько критичен, сколько использование уязвимого зарубежного межсетевого экрана. Поэтому я всем рекомендую, у кого на периметре стоят такие средства, озадачиться вопросом анализа уязвимоcтей (которые сейчас по некоторым классам продуктов всё чаще и чаще появляются, и критичные, в том числе эксплуатируемые удаленно) и формированием компенсирующих мер, выработкой сигнатур, постановке на мониторинг, анализом событий и т.д. Для того, чтобы эти риски компенсировать. Вот это более критично чем факт использования зарубежного сетевого экрана, по крайней мере до 25го года."
"Если отсутствие технической поддержки привело к наличию уязвимости, которое не компенсируется другими способами или средствами, то тогда данное нарушение мы рассматриваем с соответствующими санкциями. Если [компенсирующие меры] выработаны, тогда рекомендация по переходу к соответствующему сроку, но санкции не применяются."
Владимир Бенгин, Минцифры России. Рассказал про положительный опыт багбаунти Госуслуг. Нашли десятки уязвимостей, хотя ожидалось, что после всех пентестов ничего не найдут. Опыт будут масштабировать и будут продвигать. Завтра будут подробности.
Ещё было пара реплик, что "Руководство по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК могут на днях зарелизить. Видимо об этом было на предыдущих секциях. Ждем. 🙂
Завтра открывается фестиваль PHDays 12! Непосредственно про Vulnerability Management я выступлений в программе не нашел. Но есть разборы конкретных уязвимостей и выступления на смежные темы, которые я себе наметил. Возможно кому-то тоже будет интересно. Первый день буду слушать фоном в онлайне, а в субботу планирую быть на площадке в Парке Горького.
Обязательно загляну на стенд Positive Technologies с MaxPatrol VM, вчера на AM Live обещали показать реализацию оценки критичности уязвимостей по методике ФСТЭК! 🔥Очень интересно откуда они временные и контекстные метрики CVSS берут, а также тип уязвимого актива. 🙂
19 мая
🔸12:00–13:00 Кто, как и зачем атакует Linux-инфраструктуры. DEFENSE
Олег Скулкин. BIZONE
🔸13:45–14:45 Все, о чем вы хотели, но боялись спросить регулятора. БИЗНЕС ТРЕК 1
Виталий Лютиков, ФСТЭК России
Владимир Бенгин, Минцифры России
Алексей Лукацкий, Positive Technologies
🔸15:00–16:00 Интернет-картография в 2023 году. Чего не может Shodan. OFFENSE
Сергей Гордейчик, CyberOK
Александр Гурин, CyberOK
🔸15:00–16:00 SCAзка о SCAнерах. DEVELOPMENT
Виктор Бобыльков, Райффайзенбанк
Дмитрий Евдокимов, Luntry
🔸17:00–18:00 Опыт тестирования и верификации ядра Linux. DEVELOPMENT
Алексей Хорошилов, ИСП РАН
🔸17:15–18:30 Киберсуверенитет: вклад открытого кода. БИЗНЕС ТРЕК 1
Сергей Гордейчик, CyberOK
Кирилл Севергин, АЛРОСА
Сергей Золотарев, Arenadata
Александр Гутин, ГК «Астра»
Иван Панченко, Postgres Professional
-------------------------
20 мая
🔹11:00–11:40 People as code: сотрудник как актив и объект защиты. БИЗНЕС ТРЕК 2
Сергей Волдохин, «Антифишинг»
🔹13:00–14:00 Внедрение кода в процессы из контекста ядра Linux. OFFENSE
Илья Матвейчиков
🔹13:00–14:00 Как обезопасить от санкций ваш открытый проект на GitHub. DEVELOPMENT
Александр Попов, Positive Technologies
🔹14:00–15:00 История одной уязвимости. DEVELOPMENT
Андрей Наенко, Kaspersky
🔹14:00–15:00 Топ-10 артефактов Linux для расследования инцидентов. DEFENSE
Лада Антипова, Angara Security
🔹15:10–15:40 Отечественные ОС сегодня: вызовы, задачи, перспективы. ЭФИРНАЯ СТУДИЯ
Александр Попов, Positive Technologies
Алексей Хорошилов, ИСП РАН
Владимир Тележников, «РусБИТех»
🔹16:00–17:00 Антология способов программного мониторинга и защиты Linux в пользовательском пространстве. OFFENSE
Тимур Черных, F.A.С.С.T.
🔹17:00–18:00 Positive Awards. ЭФИРНАЯ СТУДИЯ
Методические документы регуляторов, связанные с Управлением Уязвимостями. В презентации, которую я сейчас готовлю к 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 апреля для сбора отзывов, с сайта убрали. Видимо теперь уже до доработанного официального релиза. Поэтому ту публичную версию от 31 марта заливаю сюда. Чтобы было понятно к чему относятся мои комментарии про "процесс не для человеков" и "место автоматического детектирования уязвимостей". Кроме того, после официального релиза будет интересно посмотреть, что изменилось по сравнению с проектом.
Насчёт количества 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 тоже есть не всё, что есть в БДУ.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.