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

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

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

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

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

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