Архив за месяц: Февраль 2023

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

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

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

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

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

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

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

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

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

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

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

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

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

В чем различие между "уязвимостями инфраструктуры" и "уязвимостями приложений"? По мне так разница между "уязвимостями инфраструктуры" и "уязвимостями приложений" не техническая, а скорее в способе детектирования и исправления. Это условное разделение, чтобы понимать чем должен заниматься отдел Appli­ca­tion Secu­ri­ty, а чем отдел Infra­struc­ture Secu­ri­ty. Если уязвимость публично известная и у неё есть CVE/BDU, она детектируется сканерами уязвимостей и должна исправляться обновлением ПО/воркэраундом полученным от вендора, то это "уязвимость инфраструктуры". Если уязвимость публично неизвестная, была обнаружена с помощью SAST/DAST инструментов и должна исправляться изменением в коде самописного приложения, то это "уязвимость приложения". А технически и то, и другое может быть уязвимостью одного типа, например, Path Tra­ver­sal. Технических типов уязвимостей можно выделить великое множество (см. CWE), но в рамках Vul­ris­tics я стараюсь всё раскладывать в несколько основных типов, отталкиваясь от уязвимостей, которые заводит MS.

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

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

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

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

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

Борьба со "слепыми пятнами" в базе знаний VM-решения от Qualys. Это и будет примером для п.3 из прошлого поста. Модуль называется Qualys Cus­tom Assess­ment and Reme­di­a­tion (CAR). Идея следующая. Для детектирования уязвимостей Qualys использует в первую очередь легковесные "облачные агенты". Почему бы не дать возможность выполнять пользовательские скрипты на хостах посредством этих агентов? И эти скрипты связывать с идентификаторами уязвимостей и мисконфигураций (QIDs, CIDs), так чтобы с результатами этого кастомного детектирования можно было работать в рамках общего VM/CM процесса. Это в Qualys и сделали.

Причем это позиционируется не как компенсация для дырявой базы знаний Qualys, а как решение отдельной задачи "tac­ti­cal secu­ri­ty work­flow". Т.е. это когда вам нужно добавить детект по-быстрому, а не ждать, когда он появится в VM-решении. А ещё для всяких самописных приложений ("cus­tom in-house appli­ca­tions"), для которых иначе детектов вообще не было бы. В общем, трансформируют компенсацию недостатков в конструктив и позитив — мудро.

Скрипты можно писать на Pow­er­Shell, Python, Lua, Perl и Shell. Есть встроенная Script Test­ing Sand­box для тестирования перед запуском на хостах. Есть ролевая модель доступа к скриптам. Планируют интеграцию со сторонними репозиториями, включая Github, для упрощения разработки. Можно автоматизировать работу через API.

Скрипты можно использовать не только для детектирования уязвимостей и мисконфигураций, но и для исправления проблем: изменять конфигурации, закрывать порты, удалять файлы, завершать процессы, удалять нежелательное ПО и т.д.

В целом, прикольная штука и кажется всем VM-вендорам есть смысл присмотреться. Из минусов, пока это касается только хостов с установленными агентами. Про сетевые устройства, например, никто не говорит. Хотя теоретически тоже можно было бы добавить возможность выполнения кастомных скриптов активным сканером.

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

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

Что делать со "слепыми пятнами" в базах знаний Vul­ner­a­bil­i­ty Man­age­ment решений? 🤔 В прошлый раз показали, что VM решения могут детектировать не все уязвимости. Это данность. Что можно предложить VM-вендорам, чтобы эта ситуация начала меняться к лучшему.

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

2. Не можете детектировать сами, но хотите быть единственным решением для Vul­ner­a­bil­i­ty Man­age­ment в организации? Тогда будьте любезны дать возможность заводить уязвимости в вашем решении, продетектированные, например, другим специализированным сканером уязвимостей. Технически это означает необходимость добавить возможность заводить уязвимости и редактировать списки активов, где они детектируются, через API.

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

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

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

А ваше Vul­ner­a­bil­i­ty Man­age­ment решение точно умеет все уязвимости детектировать? Естественно нет! 😀 Софтов и железок настолько много, настолько они разнообразные, что покрыть их все детектами уязвимостей невозможно. О некоторых IT продуктах VM-вендоры могут вообще не знать. Знают ли в Qualys или Ten­able об 1С, Континент-АП, Astra Lin­ux? В курсе ли в российских VM вендорах об IT-решениях используемых где-нибудь в Бразилии или ЮАР? Сомнительно. Даже если в курсе, то с каким приоритетом начнут пилить детекты уязвимостей для них? С нулевым или даже отрицательным. Важно же покрыть в первую очередь то, что у текущих и потенциальных клиентов используется.

Когда я разговаривал с представителями VM-вендоров об этом, мучил в основном сейлов/пресейлов, то получал обычно риторический прием "ну зачем же говорить про отдельные детекты, мы же Vul­ner­a­bil­i­ty Man­age­ment процесс строим"! Ну типа главное, чтобы оно в целом работало, а частные недочёты значения не имеют. Но как оно может работать с такими "слепыми зонами" для меня так и осталось загадкой. 🤨 К сейлам и пресейлам претензий нет, у них задача с возражениями работать и сделки закрывать, а не с потенциальным клиентом по душам говорить. Но замалчивать принципиальную проблему это тоже такое себе.

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

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