Быстрое сравнение баз знаний Nessus и OpenVAS

Лично я считаю, что качество базы знаний является наиболее важной характеристикой Vulnerability Management (VM) продуктов. Возможно потому, что я сам довольно продолжительное время занимался разработкой security content-а для сканеров уязвимостей и это уже профессиональная деформация. =) Теперь, когда я сканеры в основном эксплуатирую, мне хотелось бы поделиться своими наблюдениями о качестве контента, который в них используется. В настоящее время на глобальном VM-рынке представлены десятки решений, которые имеют очень разные базы знаний и следовательно очень разные способности по обнаружению уязвимостей. Очень странно, что эта тема не обсуждается практически вообще. Такое ощущение, что качество сканирование никого не волнует. Рекомендую посмотреть на эту тем пост “Tenable doesn’t want to be Tenable anymore” и особенно комментарий к нему от HD Moore (основатель Metasploit и ex-CRO Rapid7).

Что VM-вендоры обычно рассказывают про базу знаний своего продукта? В лучшем случае количество реализованных проверок: 40000-80000 и примерный лист поддерживаемых систем. Чаще говорят, что умеют вообще всё. Но если все вендоры говорят, что умеют всё и не хотят соревноваться в качестве детекта с конкурентами, чем тогда остается очаровывать клиентов? Дашбордами, отчетами, SIEMоподобной функциональностью. По мне это всё, конечно, важно и круто, но все же не настолько важно как основная функциональность, за которую сканер уязвимостей и покупают. Чтобы показать, что разница в базах знаний действительно есть, я сделал простенькое сравнение Nessus и OpenVAS.

Я выбрал эти два продукта, главным образом потому, что информация о NASL-плагинах, которые в них используются доступна на Vulners.com . Как я писал ранее, как вы можете легко парсить архивы Vulners скриптами на python, так что результаты сравнения вы можете повторить самостоятельно при необходимости. Про сравнение баз знаний OpenVAS и Nessus я также рассказывал первые минут 10 на вебинаре Pentestit про Vulners, вот запись:

Почему я называю это сравнение быстрым и простеньким? Я не определяю структуру баз знаний для продуктов и не сопоставляю один NASL-плагин другому. Вполне вероятно, что я так и сделаю чуть позже. Вместо этого я смотрю только на CVE-ссылки. Если два сканера могут детектить одни и те же уязвимости у них и ссылки в плагинах будут на те же CVE проставлены, так ведь? На самом деле видим значительную разницу между продуктами и более половины из существующих CVE-шек нельзя обнаружить даже используя оба сканера.

CVE links from NASL plugins

Все CVEs: 80196
Ссылки на CVE в OpenVAS: 29240
Ссылки на CVE в Nessus: 35032
Пересечение OpenVAS и Nessus: 3787;25453;9579

Ну ок, в CVE-шках понятно, а сколько это в плагинах? Часть плагинов OpenVAS и Nessus используют одни и те же CVE-шки. На самом деле там сложная связь многие ко многим, нет смысла там особо разбираться сейчас. Но есть плагины OpenVAS и Nessus, которые ссылаются на какую-то CVE, а у конкурирующего решения плагинов, которые ссылкаются на эту CVE нет. И таких плагинов не 1-2, а тысячи.

NASL plugins

Все NASL-плагины:
OpenVAS: 49747
Nessus: 81349

Как-то мапящиеся друг на друга плагины: 38207 OpenVAS and 50896 Nessus
Не мапящиеся плагины OpenVAS: 2673
Не мапящиеся плагины Nessus: 6639

Последняя группа, которые “не мапятся”, это самое интересное и полезное. Они показывают слабые места решений. Можно смотреть списки этих плагинов и ходить потом к вендорам с неудобными вопросами: “а почему вы эту уязвимость не детектите? Есть же такая CVE и ваш конкурент её детектить умеет”. Что может на это ответить вендор? Ну во-первых это может быть ошибка. Проверка на самом деле есть, а CVE проставить забыли. Это недостаток подобного метода сравнения.

Другие причины:

Иными словами:

  • Сканер Уязвимостей это необходимость
  • Однако постарайтесь не зависеть от него слишком сильно
  • Если Сканер Уязвимостей что-то не находит — это ВАША проблема, а не вашего VM-вендора
  • Выбирайте VM-решение, которое вы можете контролировать
  • Используйте альтернативные источники информации об уязвимостях (vulners.com, vFeed)

И еще раз. Цель этого поста не в том, чтобы показать, что какой-то вендор хуже или лучше. И Openvas, и Nessus имеют свои сильные стороны. Однако, совершенно точно существуют пробелы в базах знаний продуктов для Анализа Защищенности и они весьма значительны. Я верю, что их можно исправить, но только в открытом диалоге между регуляторами, VM-вендорами, разработчиками Security Content-а и конечными пользователями продуктов.

Оригинал поста: http://avleonov.com/2016/11/27/fast-comparison-of-nessus-and-openvas-knowledge-bases/ (en)

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