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

Борьба со "слепыми пятнами" в базе знаний 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-вендорам есть смысл присмотреться. Из минусов, пока это касается только хостов с установленными агентами. Про сетевые устройства, например, никто не говорит. Хотя теоретически тоже можно было бы добавить возможность выполнения кастомных скриптов активным сканером.

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

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

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

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

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

А ваше Vulnerability Management решение точно умеет все уязвимости детектировать?

А ваше Vulnerability Management решение точно умеет все уязвимости детектировать? Естественно нет! 😀 Софтов и железок настолько много, настолько они разнообразные, что покрыть их все детектами уязвимостей невозможно. О некоторых IT продуктах VM-вендоры могут вообще не знать. Знают ли в Qualys или Tenable об 1С, Континент-АП, Astra Linux? В курсе ли в российских VM вендорах об IT-решениях используемых где-нибудь в Бразилии или ЮАР? Сомнительно. Даже если в курсе, то с каким приоритетом начнут пилить детекты уязвимостей для них? С нулевым или даже отрицательным. Важно же покрыть в первую очередь то, что у текущих и потенциальных клиентов используется.

Когда я разговаривал с представителями VM-вендоров об этом, мучил в основном сейлов/пресейлов, то получал обычно риторический прием "ну зачем же говорить про отдельные детекты, мы же Vulnerability Management процесс строим"! Ну типа главное, чтобы оно в целом работало, а частные недочёты значения не имеют. Но как оно может работать с такими "слепыми зонами" для меня так и осталось загадкой. 🤨 К сейлам и пресейлам претензий нет, у них задача с возражениями работать и сделки закрывать, а не с потенциальным клиентом по душам говорить. Но замалчивать принципиальную проблему это тоже такое себе.

Ещё раз, допустим есть продукт, софт или устройство, которое в компании используется, но VM-решение его не поддерживает, уязвимости детектить не может. А в продукте точно есть уязвимость критичная. Допустим нам вендор этого продукта сам о ней сообщил. Как теперь учесть эту уязвимость в этом навороченном VM-решении с дашбордиками, приоритизацей на нейронках и прочим? Да в общем случае никак. И к чему это приведет? Будет навороченная энтерпрайзная VM-красота и рядом с ней костыльный процесс. Этот костыльный процесс будет покрывать те уязвимости, с которыми дорогое VM-решение не справилось. Так и к чему тогда все эти размышления о том, чем "обычный сканер" отличается от продвинутого решения по управлению уязвимостями, если это решение может работать только с ограниченным набором уязвимостей, для которых есть готовые детекты у VM-вендора, а не со всеми, которые есть в компании-клиенте?

Есть, конечно, мысли как сделать лучше и есть примеры как некоторые VM-вендоры эту проблему решают, но об этом после.

февральскому Microsoft Patch Tuesday

Обновил Vulristics-отчет по февральскому Microsoft Patch Tuesday. Пофиксил детекты софтов и типов уязвимостей, добавил комментарии из обзоров Tenable, Qualys, Rapid7, ZDI, KrebsOnSecurity. Блогопостом и вядяшкой вероятнее всего займусь уже под конец праздников.

С днём защитника Отечества всех!

Про карту рынка Импортозамещение 2023 от CNews

Про карту рынка Импортозамещение 2023 от CNewsПро карту рынка Импортозамещение 2023 от CNews

Про карту рынка Импортозамещение 2023 от CNews. Это что-то феерическое. "Производители самых известных российских аппаратных и программных ИТ-продуктов, предлагаемых для замены зарубежных решений в наиболее важных сегментах." Интерес у меня был прежде всего к разделу "Корпоративное программное обеспечение -> Информационная безопасность".

То, что Vulnerability Management-у, и даже в целом анализу защищенности, место не нашлось это ещё ладно. Допустим место нашей темы где-то в аналитике. Но то, что Positive Technologies вообще нигде не упомянули, включая раздел SIEM, это просто смешно. 😀 Получается ИскраУралТЕЛ (без негатива, просто как пример) входит в список самых известных российских ИБ вендоров, а PT нет. 😅

Один очень популярный западный мессенджер заблокировал возможность делать голосовые вызовы

Один очень популярный западный мессенджер заблокировал возможность делать голосовые вызовы
Один очень популярный западный мессенджер заблокировал возможность делать голосовые вызовы

Один очень популярный западный мессенджер заблокировал возможность делать голосовые вызовы. Пишет, что ему нужно выдать дополнительные права, чтобы совершать телефонные звонки и управлять ими. 🤨 А с чего бы это вдруг? И нафига?

Ну вот вы знаете, вдруг вы будете по телефону говорить, а мы вас голосовым звонком из мессенджера побеспокоим в этот момент, не хорошо же будет, да? Что? Вам пофиг и пусть себе беспокоит? Нет-нет, это не опционально и не обсуждается. Права нужно выдать обязательно, без этого мы больше не разрешаем делать голосовые вызовы. Эти права нужны нам исключительно для того, чтобы мы могли сделать вам удобнее, верьте нам!

Про Perplexity AI

Про Perplexity AIПро Perplexity AI

Про Perplexity AI. По поводу ChatGPT моё мнение не поменялось. Это малополезный бредогенератор. Однако это не значит, что я против ИИ чатботов вообще. Приемлемая альтернатива, с которой я теперь частенько играюсь, это Perplexity AI. Сервис также использует модель GPT-3, но в отличие от ChatGPT имеет ряд важных преимуществ:

- можно использовать бесплатно и без регистрации
- работает с актуальными данными (например знает о MS Patch Tuesday на прошлой неделе)
- показывает пруфлинки, можно залезть и проверить на основании чего был нагенерен текст
- позволяет исключать нерелевантные ссылки и перегенерировать текст (например в запросе об "Alexander V. Leonov" можно убрать инфу подтянутую из биографии тезки-океанолога)

В общем, вполне удобная штука, если нужно быстро узнать мнение по какому-то вопросу, а самому искать, ходить по ссылкам и вычитывать странички не хочется. 🙂 На скриншотах сбор ссылок с обзорами MS Patch Tuesday и сбор громких кейсов по фишинговым атакам.