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

Про Endpoint Vulnerability Detection

Про Endpoint Vulnerability Detection

Про End­point Vul­ner­a­bil­i­ty Detec­tion. Поделюсь некоторыми соображениями, болями и хотелками по поводу отечественных средств детектирования уязвимостей инфраструктуры.

1. Если брать только ОС‑и, то основная боль детектирования уязвимостей это Win­dows и macOS. Особенно Win­dows: и по KBшкам, и для Third-Par­ty. Я верю, что в какой-то перспективе от этого в российском энтерпрайзе откажутся, но пока оно есть и требует поддержки. С Lin­ux, особенно в той части детектов, которые обычно реализуют VM-вендоры, детект только по бюллетеням безопасности и версиям пакетов, можно сказать, терпимо.
2. Архитектура и интерфейсы управления отечественных VM решений (я намеренно не буду никого конкретного называть, считайте, что это в среднем по больнице) это просто беда. Трудно развертывать, трудно эксплуатировать, трудно дебажить. Лучше бы этого переусложненного безобразия не было вовсе. 😔
3. Функциональности по детектированию уязвимостей, которая есть в бесплатном ScanOVAL ФСТЭК в принципе было бы достаточно, если бы он не был специально ограничен с точки зрения автоматизации работы. Понятно почему ограничен — забесплатно и так очень круто, тут вопросов нет. Но если бы был, допустим, сканер аналогичный ScanOVAL, но позволяющий запускаться в неинтерактивном режиме с возможностью подложить ему OVAL-контент (или в другом формате — не важно) и получить результаты детектирования — это был бы отличный продукт, за который можно было бы платить вменяемые деньги. Поддержание работы движка и наполнение контента это тяжёлая, важная и трудоемкая работа, это должно финансироваться, тут тоже без вопросов. Я бы топил за такое. Назовем такой класс продуктов, например, Local Vul­ner­a­bil­i­ty Scan­ner.
4. Допустим у нас есть консольная сканилка из предыдущего пункта. Как должно выглядеть вменяемое взаимодействие агента и сервера? Максимально просто и прозрачно для конечного пользователя (№*?@%#$🤬💪)!!! Агент на устройстве должен периодически брать адрес сервера (обычного web-сервера, REST API) из текстового конфига, спросить у сервера "есть у тебя новый контент?", если есть, то скачать его, запустить детект и залить результаты детекта на сервер. Всё! Это тривиально запиливается на скриптах за неделю. И агентная часть, и серверная. И дебажится в случае непоняток ручным выполнением тех же самых запросов с таргет-хоста. И агентная обвязка, и сервер это вообще может быть опенсурс. Вменяемому клиенту все эти интерфейсные красивости, на которые VM-вендоры палят столько ресурсов либо вообще не нужны, либо абсолютно второстепенны.

Сомневаюсь я, конечно, что кто-то из VM-вендоров прислушается и выпустит базовое решение для детекта уязвимостей а‑ля ScanOVAL, но с возможностями для автоматизации. Или, что возможности автоматизации добавят непосредственно в ScanOVAL. Или, что агентное сканирование сделают по-человечески, нормально и прозрачно. Но высказываться в эту сторону, имхо, нужно. А то так и продолжим терпеть с улыбочкой всю эту лютую дичь. 😬

Как я тестил VulnsIO on-prem

Как я тестил VulnsIO on-prem

Как я тестил VulnsIO on-prem. Установка простая. Нужна Lin­ux-овая виртуалка, на неё ставим dock­er и dock­er-com­pose. Затем скачиваем с официального сайта консольную утилиту vio-installer. Отвечаем на вопросы в текстовом интерфейсе и через минут 5 получаем развернутое VM-решение с web-интерфейсом. 👍

Из подводных камней можно отметить то, что инсталлеру нужен доступ не только до vulns.io, но и до некоторых других внешних reg­istry для скачивания образов. Не все требуемые доступы сейчас описаны в руководстве. Пришлось несколько раз запускать инсталлер и дозаказывать доступы от виртуалки наружу. Также были проблемы со скачиванием некоторых образов. Видимо проблемы были на стороне окружения, всё решилось ограничением количества одновременных потоков на уровне dock­er-демона:

/etc/docker/daemon.json

{
  "max-con­cur­rent-down­loads" : 1
}

Но это всё мелочи.

Помимо безагентного сканирования, VulnsIO поддерживает также честное агентное сканирование. Т.е. на таргет-хосты можно поставить агенты, которые будут сами подключаться к on-prem серверу VulnsIO по 443 порту и периодически скидывать туда данные для расчета уязвимостей (можно и принудительно обновить данные через задачу на аудит). Подход +- как у Qualys с легковесными агентами. Агенты обновляются сами. Аутентификации агента на доменные учётки не завязана. В общем, тут всё удобно и работает так, как ожидается.

При сравнении со ScanOVAL для тестового Win­dows Serv­er хоста и тот, и другой надетектировал около 2000 CVE. При этом пересечение получилось 68%. Есть по ~ 300–400 CVE, которые детектируются одним из средств, а другим нет. 🤷‍♂️ С чем связаны расхождения это вполне себе повод для дальнейшего ресерча и общения с вендором, но то, что совпадает сильно больше половины, это уже неплохо. 😉

Результаты сканирования RedCheck и ScanOVAL для Windows хостов

Результаты сканирования RedCheck и ScanOVAL для Windows хостов

Результаты сканирования Red­Check и ScanOVAL для Win­dows хостов. Есть коммерческий VM-продукт Red­Check от АЛТЭКС-СОФТ и бесплатный локальный сканер уязвимостей ScanOVAL от ФСТЭК, который также использует контент от АЛТЭКС-СОФТ. Было интересно посмотреть, а есть ли какая-то разница в результатах сканирования. Возможно какая-нибудь разница в контенте или в работе движка. Сравнение отчетов по CVE-шкам для нескольких тестовых Win­dows хостов с разной конфигурацией подтвердило: разницы в результатах сканирования нет, совпадение по 100% CVE. Так что, если считать ScanOVAL эталонным сканером, то Red­Check будет полностью соответствовать этому эталону. Уточнение: при сканировании Red­Check-ом использовался транспорт Win­RM.

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management‑у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vul­ner­a­bil­i­ty Management‑у. Часть 2/3. Эталонный сканер.

Вопрос был такой:  

> 2. Вы согласны, что бесплатный сканер ScanOVAL ФСТЭК может рассматриваться как эталонное средство детектирования уязвимостей для хостов под управлением Win­dows и отечественных Lin­ux-ов?

Зачем я задал этот вопрос? Давайте начнем с того, что такое эталонный сканер уязвимостей.

Начнем просто с эталона. Возьмем, для примера, эталон единицы измерения массы. "Международный прототип (эталон) килограмма хранится в Международном бюро мер и весов (расположено в Севре близ Парижа) и представляет собой цилиндр диаметром и высотой 39,17 мм из платино-иридиевого сплава (90 % платины, 10 % иридия)." Вряд ли вы будете использовать этот цилиндр для того, чтобы отвесить себе килограмм помидоров. Скорее всего вы просто положите свои помидоры на электронные весы. А вот для того, чтобы проверить, что эти весы работают корректно, некоторый эталон очень даже пригодится.

Теперь по поводу сканеров уязвимостей. Не секрет, что если вы просканируете один и тот же хост различными сканерами уязвимостей, то вы получите различные же результаты. Иногда практически не пересекающиеся по CVE идентификаторам. Тут дело не в том, что различные VM-вендоры поддерживают различные наборы Third-par­ty софтов, это ещё простительно. Но даже если мы ограничимся только детектированием уязвимостей ОС, по KB-шкам Win­dows или бюллетеням безопасности Lin­ux, всё равно разница будет, потому что каждый VM-вендор реализует свои собственные алгоритмы детектирования. А уязвимость на хосте либо есть, либо нет. Это вещь объективная. И если результаты различаются, значит как минимум одно из средств детектирования работает неправильно.

Есть ли у нас такой сканер уязвимостей, результаты детектирования которого мы могли бы принять за эталон? Есть один претендент — ScanOVAL. Он общедоступный, бесплатный и самое главное выпущен ФСТЭК. С ним вполне удобно сравнивать результаты детектирования уязвимостей для Win­dows и российских Lin­ux-ов.

Так готовы ли VM-вендоры признать ScanOVAL за эталон качества детектирования уязвимостей?

Каверзность вопроса в том, что если ответить "да", то все различия при сравнении со ScanOVAL будут автоматически являться ошибками. А если ответить "нет", то получается сканер уязвимостей регулятора некорректно уязвимости детектирует? Давайте-ка с этого момента поподробнее. 😏

Любой ответ представителя VM-вендора, сулит проблемы для него. А для клиентов наоборот — любой ответ выгоден, т.к. подсвечивает проблемы детектирования уязвимостей и улучшает либо возможности продукта VM-вендора, либо ScanOVAL. Ну или хотя бы дискуссию провоцирует о качестве детектирования, и то неплохо.

В итоге вопрос про ScanOVAL задали в 2:22:01 в таком виде:

"А у нас ещё такой провокационный немного вопрос в сторону присутствующих здесь вендоров. А что если просто взять ScanOVAL и с помощью умелых рук организовать весь процесс, чем это будет слабее Enter­prise решений?" 🤦🏻‍♂️

Как видите, вопрос не про эталон, не про качество сканирования, а из серии можно ли выкопать котлован малой сапёрной лопаткой. Ну и ответы соответствующие. 🤷‍♂️

В общем, жаль, что обсуждение этой темы не получилось, но попробуем пропедалировать её в следующий раз. 😉

Часть 1

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

Уточнение по предоставлению доступа к базе детектов уязвимостей от АЛТЭКС-СОФТ (Red­Check)

Компания дает возможность выгрузки ОVAL feed-ов, используемых для детекта уязвимостей в Red­Check, на следующих условиях:

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

При этом фиды АЛТЭКС-СОФТ, которые поддерживаются в рамках проекта ScanOVAL ФСТЭК полностью открыты и фактически доступны для изучения.

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

Если кто-то ещё из представителей VM-вендоров хочет добавить уточнения по своей позиции — пишите в личку, всегда выкладываю без проблем. 🙂

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

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

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

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

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

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

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

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

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

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

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

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

Погонял, по случаю, ScanOVAL — бесплатный сканер уязвимостей от ФСТЭК. На этот раз версию не под Lin­ux, а под Win­dows (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 Sys­tem Char­ac­ter­is­tics, и привычный OVAL HTML отчет, знакомый, например, по результатам Open­SCAP.

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