Архивы автора: Александр Леонов

Об авторе Александр Леонов

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно и моих проектах можете прочитать здесь. Приглашаю подписаться на мой канал @avleonovrus "Управление Уязвимостями и прочее" в MAX или в Telegram. Вы можете обсудить мои посты или задать вопросы в группе ВКонтакте. And I invite all English-speaking people to another Telegram channel @avleonovcom.

Если вендор не предоставляет воркэраунд для исправления инфраструктурной уязвимости, возможно ли выработать его внутри организации? Если да, то кто должен за это отвечать? RedTeam? InfraSec? Совместно?

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

Если вендор не предоставляет воркэраунд для исправления инфраструктурной уязвимости, возможно ли выработать его внутри организации? Если да, то кто должен за это отвечать? RedTeam? InfraSec? Совместно?

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

1. В рамках этого исследования для начала нужно получить рабочий эксплоит, чтобы можно было оценить результативность workaround-а. Хорошо если эксплоит доступен публично и работоспособен. Или хотя бы есть подробное описание уязвимости. А если нет? В любом случае это скорее задача RedTeam. Без эксплоита рассуждения о workaround-ах становятся чисто теоретическими.

2. Когда есть рабочий инструмент для атаки, можно продумывать какой workaround можно применить. Заниматься этим вероятнее всего должны сотрудники InfraSec вместе с системными администраторами и владельцами уязвимых систем. Компенсирующие меры могут повлиять на функциональность систем, поэтому одни только безопасники этот вопрос решить не смогут.

3. На тестовом скоупе применяем workaround. Проверяем на хостах из этого скоупа, что эксплуатация уязвимости с помощью нашего эксплоита там больше невозможна. С помощью RedTeam подтверждаем, что легкого способа обойти это исправление нет. Принимаем решение о массовом применении workaround-а.

Всё это сложно, трудозатратно, очень плохо масштабируется и по определению является ненадежным временным решением. Посмотрите, например, сколько раз MS меняли рекомендуемый workaround для ProxyNotShell. А у них там лучшие эксперты работают и занимаются этим на фулл-тайм. Поэтому если есть возможность исправить уязвимость обновлением, лучше обновиться. Workaround-ы и компенсирующие меры лучше брать готовые от вендора или регулятора (для многих уязвимостей они есть прямо в БДУ!) и применять их только на время, пока обновление недоступно.

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

Финальная версия Карты российского рынка информационной безопасности 2023 от TAdviser

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

Финальная версия Карты российского рынка информационной безопасности 2023 от TAdviser. Посмотрел новую картинку. Наш любимый раздел "Системы анализа защищенности, Средства безопасной разработки (DevSecOps)". По сравнению с прошлой версией, добавили три компании, но сделали это как-то странновато.

Добавили Swordfish Security. Известный вендор в AppSec сегменте. Но теперь на схемке есть сам Swordfish Security и два их продукта: AppSec.Hub (DevSecOps платформа), Стингрей (анализ защищённости мобильных приложений; есть отдельное юрлицо, но значится как продукт на сайте Swordfish). Не многовато ли свордфишей? 😉

Добавили Webcontrol. Не очень понятно за что именно. На сайте в разделе "Решения" 11 пунктов. Но это в основном решения от сторонних компаний, и Webcontrol там выступает в роли дистрибьютора. Исключением является sPACE - система управления привилегированным доступом (PAM), которая является разработкой Webcontrol. Похоже добавили за услуги по DevSecOps, а не за продукты.

Про компьютерную игру Atomic Heart в контексте ИБ

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

Про компьютерную игру Atomic Heart в контексте ИБ. Посмотрел на выходных полное прохождение. Некоторые особенно крутые локации даже в нескольких прохождениях. Это, безусловно, веха в отечественном игростроении и большое культурное событие. Стартовая локация настоящее произведение искусства. Очень детализированная, щедро наполнена контентом. Из того, что особенно запомнилось это милая отсылка к Рэсси из Электроника и трогательная сцена с ветераном у вечного огня. Ну и основное это то, что все отсылки к нашему советскому/постсоветсткому культурному коду, поэтому выстреливают на все 100. Конечно, хотелось бы чтобы вся игра была про блуждание по городу из стартовой локации, но это невозможно. Слишком дорого. И по жанру это все-таки стрелялка с головоломками. Пишут, что это аналог BioShock, с которым я не знаком. Мне же напомнило Half-Life или Portal. Записки и аудиозаписи, на которые натыкается главный герой заставили вспомнить приколы из начала нулевых, типа Хроники лаборатории/диверсантов. Юмора в меру. 🙂 Матюков больше меры, но как уж есть.

То, что можно отнести к ИБ, но это СПОЙЛЕРЫ. Рекомендую прочитать после того как полностью зацените игру:

В общем, мне понравилось. Молодцы авторы, что умудрились все-таки не склепать агитку (которая напрашивалась). Долголетия франшизе. Старт мощный. Не удивлюсь, если по этой вселенной будут книги выходить, я их даже почитаю. 🙂

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

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

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