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

Что там у Greenbone и OpenVAS?

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

Что там у Greenbone и OpenVAS?

Что там у Greenbone и OpenVAS? Попался на глаза относительно свежий ролик Greenbone AG "Demystifying Greenbone" (вышел 3 месяца назад). Хороший такой ликбез по OpenVAS/GVM и куда ветер дует.

Что для себя отметил:

🔸 Greenbone корректно, но настойчиво отдаляются от бренда OpenVAS. Формула теперь такая: "Greenbone - это программное обеспечение с открытым исходным кодом и богатой историей". 😉

🔸 Greenbone Community Feed это для домашних продуктов "Home Application (only)", таких как Ubuntu Linux, AVM Fritzbox, MS Office. Если хотите комплаенса и "Enterprise grade" ПО, такого как MS Exchange, Palo Alto, Cisco IoT/OT, то нужен платный Greenbone Enterprise Feed. Был удивлён, что в бесплатном фиде есть немного комплаенса - German Policy IT-Grundschutz. Видимо для демки.

🔸 Методично отказываются от NASL-ового движка OpenVAS в пользу своего нового сканера Notus. В последнем стабильном релизе пишут, что Notus потенциально заменяет логику всех NASL-скриптов для локальных проверок: "Replaces the logic of potentially all NASL-based local security checks". Правда я что-то не нашёл в коде логику проверок для Windows, возможно имеются ввиду проверки только для Linux. 🤷‍♂️ Кстати, последней релиз был в июле 2022. В прошлом году стейбл так и не выпустили, но на GitHub новые пакеты выходят довольно часто.

В целом, прикольно, что до сих пор что-то движется и даже выкладывается в open source, но позывов бежать тестить это дело как не было, так и нет. Во-первых, с куцым контентом непонятен практический смысл, т.к. сканы будут заведомо недостоверными. Но даже не в контенте дело. Контент можно и собственный нагенерить, если прям очень хочется. Сама архитектура кажется переусложнённой и с кучей легаси. Одних репозиториев с какими-то либами и утилитами 62. 🫣 Вот уж действительно порождение "сумрачного германского гения". 🙂 Всё вроде так-то по уму, параллельно и перпендикулярно, но работать с этим решительно невозможно. 😣 Но будем наблюдать дальше. 😉

Что делать со "слепыми пятнами" в базах знаний Vulnerability Management решений?

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

Что делать со "слепыми пятнами" в базах знаний Vulnerability Management решений? 🤔 В прошлый раз показали, что VM решения могут детектировать не все уязвимости. Это данность. Что можно предложить VM-вендорам, чтобы эта ситуация начала меняться к лучшему.

1. Чтобы бороться, с проблемой нужно для начала её измерить. А для этого нужно понимать для каких продуктов VM-решение может детектировать уязвимости. Rapid7 поддерживает такой список. А как насчёт других VM-вендоров? Также было бы неплохо, чтобы во время аудита VM-решение подсвечивало продукты, которые были обнаружены, но детектов уязвимостей для них нет. Если это будет наглядно видно, клиент сможет выбирать как реагировать: пушить VM-вендора, чтобы добавляли поддержку; подобрать дополнительный специализированный сканер уязвимостей; отказаться от использования продуктов, для которых не работают детекты уязвимостей; принять риски.

2. Не можете детектировать сами, но хотите быть единственным решением для Vulnerability Management в организации? Тогда будьте любезны дать возможность заводить уязвимости в вашем решении, продетектированные, например, другим специализированным сканером уязвимостей. Технически это означает необходимость добавить возможность заводить уязвимости и редактировать списки активов, где они детектируются, через API.

3. Неплохо бы дать возможность пользователям управлять скриптами для кастомных детектов непосредственно внутри VM-решения. В какой-то степени это уже реализуется в некоторых VM-решениях через возможность добавления собственных детектов на специализированных языках (OVAL, NASL, Nmap scripting language). Но добавлять детекты с помощью более привычных, мощных и универсальных инструментов (Bash, Python) было бы гораздо предпочтительнее. Одну такую реализацию рассмотрим в следующий раз.