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

Про историю Vulnerability Management-а

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

Про историю Vulnerability Management-а. Иногда люди говорят публично что-то странное, но делают это настолько уверенно, что сам начинаешь в себе сомневаться. Вдруг они лучше знают? Ну или может ты их не так понял? Вот, например, посмотрел ролик "Traditional Vulnerability Management is Dead!" с Stefan Thelberg, CEO Holm Security. Это те ребята, которые считают, что без встроенного Антифишинга VM уже не VM.

В начале Stefan Thelberg заявляет про историю Vulnerability Assessment-а (Vulnerability Management-а) буквально следующее:

1. Оригинальная идея Vulnerability Assessment-а появилась в гайдлайнах NIST-а.
2. Прошло 20 лет и появились первые Vulnerability Assessment продукты.
3. Большая часть Vulnerability Assessment продуктов родились из опенсурсного проекта OpenVAS.
4. Один из наиболее распространенных продуктов на рынке, Nessus, это коммерческий форк OpenVAS.
5. Прошло ещё несколько лет и около 2000-го появилось несколько больших компаний: Rapid7, Tenable, Qualys.

То, что VA/VM родился из каких-то публикаций NIST-а не проверишь особо, организация в 1901 году основана, вполне вероятно что-то и было в 80х. Но заявление, что сначала был OpenVAS, а потом Nessus это очень странно. Первая версия The Nessus Project вышла в 1998 как GPL проект. Первая версия XSpider (тогда Spider) также появилась в 1998, а в 2000 он стал публично доступным. Компания Qualys была основана в 1999, Rapid7 в 2000, Tenable в 2002, Positive Technologies в 2002. Проект OpenVAS (GNessUs) появился не раньше 2005-го как форк последней опенсурсной версии Nessus-а, т.к. сам Nessus с 2005 года стал проприетарным продуктом Tenable.

Вот и думай теперь, то ли Stefan Thelberg говорит о том, о чем понятия не имеет. То ли он как-то странно называет OpenVAS-ом оригинальный Nessus 1998-го года. Но даже говорить, что другие VM продукты родились из Nessus-а или OpenVAS-а более чем странно, как минимум потому что другие продукты (Qualys, Rapid7 Nexpose, XSpider/MaxPatrol) не используют и не использовали NASL-скрипты, которые составляют основу Nessus. Может, конечно, у самих Holm Security движок это OpenVAS и они всех по себе меряют, не знаю. 😏

Немного про остальной ролик. Само обоснование почему традиционный VM уже не живой это отличный пример борьбы с "соломенным чучелом". Определяют "традиционный VM" так, как удобно. Что он, дескать, не поддерживает новые технологии (облака, IoT, SCADA). Добавляют свой спорный тезис, что обучение пользователей через Антифишинг это тоже обязательная часть VM. И дальше получившееся удобное "соломенное чучело" атакуют. Хотя чего бы "традиционному VM-у" не поддерживать все типы активов, которые в организации есть - непонятно. Да и какой-то проблемы прикрутить к VM-у Антифишинг, если так уж хочется, тоже нет.

Год с великого исхода западных вендоров: судьба специалиста

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

Год с великого исхода западных вендоров: судьба специалиста. С трудом уже верится, но раньше в РФ было возможно строить IT/ИБ системы, используя западные решения. 🙂 Более того, это был абсолютный мейнстрим. Как следствие, сотрудники российских компаний естественным образом развивались в крутых специалистов по продуктам Microsoft, Oracle, CISCO, PaloAlto, AWS, Tenable/Qualys/Rapid7 и т.д. 😉 Собирали комплекты вендорских сертификатов, выстраивали красивые CV-шки.

Безусловно, в этом была своя прелесть. Ты используешь те же решения, что и крупные компании во всем развитом мире, твои скилы также востребованы в общемировом масштабе. А значит релокация туда, где лучше, выглядит как вполне себе план Б (а у кого-то и как план А). Минусом шла привязка к западным вендорам и их судьбе в России. Но что с ними сделается-то? 😏

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

- продолжать делать то, что делали, а значит релоцироваться туда, где можно продолжать строить системы на западных решениях;
- остаться и строить системы на тех решениях, которые остались/появились в РФ;
- остаться, перестать строить системы и принять участие в копировании западных решений.

Релокация это всегда мероприятие на любителя. Тем более сейчас, когда "жить на 2 страны" стало совсем не так просто и комфортно. Переезд на запад теперь выглядит скорее как дорога в один конец.

Остаться и развиваться в чем-то другом это и потеря конкурентных преимуществ, и необходимость быстро учиться новому, и переход в новый локальный контекст. Опыт с Яндекс Клауд и Астра Линукс безусловно менее универсален, чем с AWS и RHEL. 🙂 Это нужно осознать и принять.

Никого не осуждаю, у всех свои ситуации. Но милей мне, безусловно, оставшиеся. Мы в одной лодке, выгребем. 🛶 🙂

Доли мирового (Device) Vulnerability Management рынка на 2021 год по версии IDC

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

Доли мирового (Device) Vulnerability Management рынка на 2021 год по версии IDC

Доли мирового (Device) Vulnerability Management рынка на 2021 год по версии IDC. Сам отчет "Worldwide Device Vulnerability Management Market Shares, 2021: The Stakes Are High" (Ставки высоки!) вышел в декабре 2022 года и вы могли насладиться этими чарующими 13 страницами уже тогда за какие-то жалкие $4,500.00. 😏 Однако Tenable начали хвастаться своим первым местом в нем только сегодня. Видимо потому, что им только сегодня разрешили выложить бесплатный отрывок, включающий разделы: резюме, доля рынка, кто повлиял на год, контекст рынка, приложение и дополнительная информация. Почитаем, порефлексируем, прокомментируем. Пока же можно констатировать то, что большая тройка не поменялась, это всё ещё: Tenable, Qualys и Rapid7. В принципе и по ощущениям оно как-то так же.

Борьба со "слепыми пятнами" в базе знаний VM-решения от Qualys

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

Борьба со "слепыми пятнами" в базе знаний VM-решения от Qualys. Это и будет примером для п.3 из прошлого поста. Модуль называется Qualys Custom Assessment and Remediation (CAR). Идея следующая. Для детектирования уязвимостей Qualys использует в первую очередь легковесные "облачные агенты". Почему бы не дать возможность выполнять пользовательские скрипты на хостах посредством этих агентов? И эти скрипты связывать с идентификаторами уязвимостей и мисконфигураций (QIDs, CIDs), так чтобы с результатами этого кастомного детектирования можно было работать в рамках общего VM/CM процесса. Это в Qualys и сделали.

Причем это позиционируется не как компенсация для дырявой базы знаний Qualys, а как решение отдельной задачи "tactical security workflow". Т.е. это когда вам нужно добавить детект по-быстрому, а не ждать, когда он появится в VM-решении. А ещё для всяких самописных приложений ("custom in-house applications"), для которых иначе детектов вообще не было бы. В общем, трансформируют компенсацию недостатков в конструктив и позитив - мудро.

Скрипты можно писать на PowerShell, Python, Lua, Perl и Shell. Есть встроенная Script Testing Sandbox для тестирования перед запуском на хостах. Есть ролевая модель доступа к скриптам. Планируют интеграцию со сторонними репозиториями, включая Github, для упрощения разработки. Можно автоматизировать работу через API.

Скрипты можно использовать не только для детектирования уязвимостей и мисконфигураций, но и для исправления проблем: изменять конфигурации, закрывать порты, удалять файлы, завершать процессы, удалять нежелательное ПО и т.д.

В целом, прикольная штука и кажется всем VM-вендорам есть смысл присмотреться. Из минусов, пока это касается только хостов с установленными агентами. Про сетевые устройства, например, никто не говорит. Хотя теоретически тоже можно было бы добавить возможность выполнения кастомных скриптов активным сканером.

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском

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

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.

Хах, ситуация вокруг отчета Qualys на November Microsoft Patch Tuesday стала даже смешнее

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

Хах, ситуация вокруг отчета Qualys на November Microsoft Patch Tuesday стала даже смешнее
Хах, ситуация вокруг отчета Qualys на November Microsoft Patch Tuesday стала даже смешнее

Хах, ситуация вокруг отчета Qualys на November Microsoft Patch Tuesday стала даже смешнее. Авторка этого отчета DEBRA M. FEZZA REED 🧡🌻 (She/Her) обиделась на меня, потому что я указал на ее ошибки публично, а не в личном сообщении в одной американской соцсеточке для профессионального общения. ¯\_(ツ)_/¯

> почему вы сочли необходимым пойти сразу на публичное осмеяние, а не обратиться ко мне напрямую, в профессиональной манере, чтобы исправить эту ошибку?

Честно говоря, у меня не было мотивации делать это после того, как Qualys ушла с российского рынка и оборвала все связи. Я даже не посмотрел, кто автор этого поста. И чего так серьезно-то? Это была просто невинная шутка с моей стороны, потому что описание получилось забавное.

> Я очень много работала, чтобы создать профессиональную репутацию, основанную на добросовестности, прозрачности, ответственности и подотчетности. Восприятие — это все, и действия имеют последствия. Вопреки вашему намерению, я не интерпретирую ваш пост как "невинную шутку".

Хорошо, продолжайте обвинять меня в своей ошибке. Видимо я помешал вам перечитать пост перед его публикацией. Видимо это моя вина, что с 8 ноября 2022 года больше никто не читал этот пост (ни в Qualys, ни во вне) и не указал вам на эти ошибки. Во всем виноват рандомный парень из России, который не написал вам в личку. Как непрофессионально с моей стороны. 🙂

PS: на QSC меня теперь вряд ли когда-нибудь пригласят. 😅

Интересный пост вышел вчера в блоге Qualys

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

Интересный пост вышел вчера в блоге Qualys. Про устаревшие активы. Суть в следующем. В ходе эксплуатации Vulnerability Management системы в неё добавляются активы. В основном сетевые хосты, но в случае Qualys не только. На них каким-то образом, агентно или безагентно детектируются уязвимости. И вот по какой-то причине данные по некоторому активу перестают обновляться. Как правило, это связано с тем что актива больше нет. Сервер выключили, виртуалку удалили, десктоп перезалили и т.п. А в интерфейсе Qualys актив продолжает отображаться, для него показываются уязвимости, он в лицензии учитывается. Непорядок.

И какую же функциональность предлагает Qualys для решения этой проблемы? Во-первых отображают активы в дашборде, с разбивкой по дате последнего обновления данных. Уже неплохо. Как минимум можно поресерчить что с этими активами случилось. Во-вторых можно настроить правила, которые будут активы неактивные больше N дней удалять. Это конечно не самое хорошее решение, десятки дней терпеть в VM-е зомби-хосты и неисправляемые уязвимости на них. Но зато просто. И эти правила не работают для "IP/DNS/NetBIOS tracked scanned assets (no Cloud Agent)", для них там ручной метод предлагается.

Но, имхо, самое лучшее решение, о котором в посте не пишут это забирать актуальные статусы активов непосредственно из IT-систем через которые они управляются, залезать в VM решение по API и оперативно подчищать неживое. Благо у Qualys API мощный и такие штуки можно делать без проблем. Кастомная автоматизация рулит! 🙂