Архив рубрики: Темы

Аналитика от VM-вендоров: Tenable, Rapid7, Positive Technologies

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

Аналитика от VM-вендоров: Tenable, Rapid7, Positive Technologies. Выпустили практически одновременно.

1. Tenable "2022 Threat Landscape Report". 66 страниц. 16 упоминаний слова "Russia" (терпимо). Есть раздел с ТОПовыми уязвимостями за год "A Closer Look at the Key Vulnerabilities of 2022".

2. Rapid7 "The Annual Vulnerability Intelligence Report: 2022 Edition". 51 страница. Одно упоминание слова "Russia" (да ладно! 🙂). Есть несколько подборок уязвимостей по категориям. Глаз зацепился за странное в глоссарии: RCE у них это не тип уязвимости, а одна из "Attacker Utilities". А тип уязвимости это, например, "injection". Подозреваю тут отголоски холивара что есть атака, а что уязвимость. Но допустим.

3. Positive Technologies "Актуальные киберугрозы для промышленных организаций: итоги 2022 года". Здесь без CVE, только статистика по атакам. "Статистика основана на многочисленных расследованиях и открытых данных как российских, так и зарубежных авторитетных источников". Есть небольшая подборка громких кейсов.

В чем различие между "уязвимостями инфраструктуры" и "уязвимостями приложений"?

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

В чем различие между "уязвимостями инфраструктуры" и "уязвимостями приложений"? По мне так разница между "уязвимостями инфраструктуры" и "уязвимостями приложений" не техническая, а скорее в способе детектирования и исправления. Это условное разделение, чтобы понимать чем должен заниматься отдел Application Security, а чем отдел Infrastructure Security. Если уязвимость публично известная и у неё есть CVE/BDU, она детектируется сканерами уязвимостей и должна исправляться обновлением ПО/воркэраундом полученным от вендора, то это "уязвимость инфраструктуры". Если уязвимость публично неизвестная, была обнаружена с помощью SAST/DAST инструментов и должна исправляться изменением в коде самописного приложения, то это "уязвимость приложения". А технически и то, и другое может быть уязвимостью одного типа, например, Path Traversal. Технических типов уязвимостей можно выделить великое множество (см. CWE), но в рамках Vulristics я стараюсь всё раскладывать в несколько основных типов, отталкиваясь от уязвимостей, которые заводит MS.

Выпустил-таки блогопост и видяшечку по февральскому Microsoft Patch Tuesday до конца праздников

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

Выпустил-таки блогопост и видяшечку по февральскому Microsoft Patch Tuesday до конца праздников. По сравнению с первоначальным вариантом добавились перспективные уязвимости Microsoft Edge, Microsoft Publisher и Word.

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

Что делать со "слепыми пятнами" в базах знаний 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) было бы гораздо предпочтительнее. Одну такую реализацию рассмотрим в следующий раз.

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

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

А ваше 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. Блогопостом и вядяшкой вероятнее всего займусь уже под конец праздников.

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