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

Cyber Media выпустили аналитическое сравнение российских продуктов по Управлению Уязвимостями

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

Cyber Media выпустили аналитическое сравнение российских продуктов по Управлению Уязвимостями

Cyber Media выпустили аналитическое сравнение российских продуктов по Управлению Уязвимостями. В сравнение попали 8 on-prem продуктов:

🔹 MaxPatrol 8
🔹 MaxPatrol VM
🔹 R-Vision VM
🔹 RedCheck
🔹 ScanFactory VM
🔹 ScanOVAL
🔹 Security Vision VM
🔹 Сканер-ВС 7 (непубличная бета)

Подготовка таких сравнений дело трудоёмкое, неблагодарное, я бы даже сказал рискованное. Обязательно найдутся недовольные. Особенно, если сравнение предполагает какое-то ранжирование. 🥇🥈🥉 В документе в явном виде оценки решений не приводятся, но порядок перечисления решений в выводах наводит на некоторые предпочтения авторов. 😏 По самим выводам могу сказать только то, что я обращал бы внимание на другие моменты. Вот не думаю, что сканирование портов nmap-ом (или не nmap-ом) является чем-то определяющим для VM-решения. 🙂

Основная часть документа это 2 сравнительные таблицы по "Основным критериям" и "Расширенным критериям". Основные критерии авторы сформировали сами, расширенные - с учётом предложений от участников. Заполнение таблицы делалось путём общения с вендорами, клиентами, интеграторами, экспертами-консультантами. Если что, меня к этому ни в каком виде не привлекали. 😅

Определение критериев сравнения - суперсубъективная вещь. Какие критерии выберешь, такие результаты и получишь. 😏 Как по мне, это сравнение очень слабо отражает возможности решений по непосредственному детектированию уязвимостей, буквально только одним пунктом "5.18. Список поддерживаемых для сканирования систем/решений" (плюс пара пунктов про Docker). Здесь я хотел бы видеть гораздо большую детализацию, хотя и понимаю, что это весьма трудоёмко.

В целом, документ очень интересный, объёмный и, я уверен, полезный для российского VM-сообщества. И для клиентов, и для вендоров. Как минимум как основа для собственных сравнений. 😉 Рекомендую ознакомиться.

Про Endpoint Vulnerability Detection

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

Про Endpoint Vulnerability Detection

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

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

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

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

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

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

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

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

/etc/docker/daemon.json

{
  "max-concurrent-downloads" : 1
}

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

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

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

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

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

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

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

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

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

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

Разбираю ответы на мои вопросы с эфира 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 решений?" 🤦🏻‍♂️

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

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

Часть 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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