В чем различие между "уязвимостями инфраструктуры" и "уязвимостями приложений"? По мне так разница между "уязвимостями инфраструктуры" и "уязвимостями приложений" не техническая, а скорее в способе детектирования и исправления. Это условное разделение, чтобы понимать чем должен заниматься отдел Application Security, а чем отдел Infrastructure Security. Если уязвимость публично известная и у неё есть CVE/BDU, она детектируется сканерами уязвимостей и должна исправляться обновлением ПО/воркэраундом полученным от вендора, то это "уязвимость инфраструктуры". Если уязвимость публично неизвестная, была обнаружена с помощью SAST/DAST инструментов и должна исправляться изменением в коде самописного приложения, то это "уязвимость приложения". А технически и то, и другое может быть уязвимостью одного типа, например, Path Traversal. Технических типов уязвимостей можно выделить великое множество (см. CWE), но в рамках Vulristics я стараюсь всё раскладывать в несколько основных типов, отталкиваясь от уязвимостей, которые заводит MS.
Выпустил-таки блогопост и видяшечку по февральскому Microsoft Patch Tuesday до конца праздников. По сравнению с первоначальным вариантом добавились перспективные уязвимости Microsoft Edge, Microsoft Publisher и Word.
Борьба со "слепыми пятнами" в базе знаний 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 решений? 🤔 В прошлый раз показали, что VM решения могут детектировать не все уязвимости. Это данность. Что можно предложить VM-вендорам, чтобы эта ситуация начала меняться к лучшему.
1. Чтобы бороться, с проблемой нужно для начала её измерить. А для этого нужно понимать для каких продуктов VM-решение может детектировать уязвимости. Rapid7 поддерживает такой список. А как насчёт других VM-вендоров? Также было бы неплохо, чтобы во время аудита VM-решение подсвечивало продукты, которые были обнаружены, но детектов уязвимостей для них нет. Если это будет наглядно видно, клиент сможет выбирать как реагировать: пушить VM-вендора, чтобы добавляли поддержку; подобрать дополнительный специализированный сканер уязвимостей; отказаться от использования продуктов, для которых не работают детекты уязвимостей; принять риски.
2. Не можете детектировать сами, но хотите быть единственным решением для Vulnerability Management в организации? Тогда будьте любезны дать возможность заводить уязвимости в вашем решении, продетектированные, например, другим специализированным сканером уязвимостей. Технически это означает необходимость добавить возможность заводить уязвимости и редактировать списки активов, где они детектируются, через API.
3. Неплохо бы дать возможность пользователям управлять скриптами для кастомных детектов непосредственно внутри VM-решения. В какой-то степени это уже реализуется в некоторых VM-решениях через возможность добавления собственных детектов на специализированных языках (OVAL, NASL, Nmap scripting language). Но добавлять детекты с помощью более привычных, мощных и универсальных инструментов (Bash, Python) было бы гораздо предпочтительнее. Одну такую реализацию рассмотрим в следующий раз.
А ваше Vulnerability Management решение точно умеет все уязвимости детектировать? Естественно нет! 😀 Софтов и железок настолько много, настолько они разнообразные, что покрыть их все детектами уязвимостей невозможно. О некоторых IT продуктах VM-вендоры могут вообще не знать. Знают ли в Qualys или Tenable об 1С, Континент-АП, Astra Linux? В курсе ли в российских VM вендорах об IT-решениях используемых где-нибудь в Бразилии или ЮАР? Сомнительно. Даже если в курсе, то с каким приоритетом начнут пилить детекты уязвимостей для них? С нулевым или даже отрицательным. Важно же покрыть в первую очередь то, что у текущих и потенциальных клиентов используется.
Когда я разговаривал с представителями VM-вендоров об этом, мучил в основном сейлов/пресейлов, то получал обычно риторический прием "ну зачем же говорить про отдельные детекты, мы же Vulnerability Management процесс строим"! Ну типа главное, чтобы оно в целом работало, а частные недочёты значения не имеют. Но как оно может работать с такими "слепыми зонами" для меня так и осталось загадкой. 🤨 К сейлам и пресейлам претензий нет, у них задача с возражениями работать и сделки закрывать, а не с потенциальным клиентом по душам говорить. Но замалчивать принципиальную проблему это тоже такое себе.
Ещё раз, допустим есть продукт, софт или устройство, которое в компании используется, но VM-решение его не поддерживает, уязвимости детектить не может. А в продукте точно есть уязвимость критичная. Допустим нам вендор этого продукта сам о ней сообщил. Как теперь учесть эту уязвимость в этом навороченном VM-решении с дашбордиками, приоритизацей на нейронках и прочим? Да в общем случае никак. И к чему это приведет? Будет навороченная энтерпрайзная VM-красота и рядом с ней костыльный процесс. Этот костыльный процесс будет покрывать те уязвимости, с которыми дорогое VM-решение не справилось. Так и к чему тогда все эти размышления о том, чем "обычный сканер" отличается от продвинутого решения по управлению уязвимостями, если это решение может работать только с ограниченным набором уязвимостей, для которых есть готовые детекты у VM-вендора, а не со всеми, которые есть в компании-клиенте?
Есть, конечно, мысли как сделать лучше и есть примеры как некоторые VM-вендоры эту проблему решают, но об этом после.
Обновил Vulristics-отчет по февральскому Microsoft Patch Tuesday. Пофиксил детекты софтов и типов уязвимостей, добавил комментарии из обзоров Tenable, Qualys, Rapid7, ZDI, KrebsOnSecurity. Блогопостом и вядяшкой вероятнее всего займусь уже под конец праздников.
1. Раньше я о них не слышал. Из шведских VM-щиков я знал и общался только с Outpost24 . А тут оказывается есть ещё один шведский вендор, да ещё и существует с 2015 года. Круто! 2. Основная их фишка в том, что они совместили в одно решение Антифишинг и Управление Уязвимостями. 🤯 Очень необычно. Это меня особенно порадовало, т.к. на работе я как раз занимаюсь и Управлением Уязвимостями, и Антифишингом. 😅 Так сложилось. О нашей системе антифишинга был доклад на прошлом Offzone (презентацию готовил я, а докладывал Павел Жерелин). Так вот, мне всегда казалось, что Антифишинг это для меня непрофильная нагрузка. А оказалось, что в Holm Security всерьез позиционируют Антифишинг как часть VM-а. "Благодаря Next-Gen подходу [Vulnerability Management] платформа борется со всеми векторами атак, которым подвергается организация, включая защиту одного из самых важных активов — ваших сотрудников". Если сотрудники попадаются на фишинг, то это тоже своего рода уязвимость, которая исправляется обучением и другими мероприятиями. Согласитесь, довольно нестандартный подход. Так что теперь при случае могу говорить, что занимаюсь VM-ом не только для IT-инфраструктуры, но и для людей. 😁
Я, конечно, сомневаюсь, что в Holm Security действительно считают Антифишинг такой уж неотъемлемой частью процесса Управления Уязвимостями. Вероятнее, что у них были эти 2 решения в портфеле и их маркетологи решили, что они будут эффективнее продаваться в рамках одной платформы. Ну и подвели некоторую базу под это. Однако, если в эту тему поиграться, то действительно можно сделать некоторые занимательные выводы и для Антифишинга, и для Управления Уязвимостями.
Смотрим на Антифишинг с точки зрения Управления Уязвимостями: 1. Если актив уязвим (сотрудник попался), то должен быть ответственный за актив, который сделает фикс. А кто этот ответственный? Видимо это непосредственный руководитель сотрудника, который должен был проводить инструктаж. И спрашивать нужно в первую очередь с него, а не с попавшегося человека. 2. Если в VM мы стремимся к полному покрытию IT-активов, то Антифишинг не должен быть выборочным, а должен покрывать всех сотрудников. 3. Если в VM мы не проверяем активы только на одну уязвимость, а стараемся проводить проверки для всех возможных уязвимостей, то и Антифишинг должен касаться разнообразных техник и психологических манипуляций, с которыми может столкнуться сотрудник в реальной фишинговой атаке.
Смотрим на Управление Уязвимостями со стороны Антифишинга: 1. Если в Антифишинге мы предлагаем попавшемуся сотруднику пройти обучение по ИБ, почему бы не назначать курс по ИБ для владельца уязвимого актива? Пусть разбирается почему обновляться это важно. 2. Если в Антифишинге мы ограничиваем доступ к входящем письмам тем сотрудникам, которым обучение не помогает, то почему бы не ограничивать работу владельцам уязвимых активов, которые не справились с поддержанием их в безопасном (обновленном) состоянии? Показал, что не можешь полноценно владеть активом и обучение не помогло - теряешь доступ к этому активу, пусть более ответственные люди за него отвечают.
Т.е. возможно подводить Управление Уязвимостями и Антифишинг под некоторый общий базис это не такая бредовая идея, как может показаться на первый взгляд. 🙂
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.
