Архив метки: DevSecOps

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием

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

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием. Вместе с Дмитрием Беляевым и Рустамом Гусейновым обсудили Vulnerability Management и Exposure Management, CVSS/EPSS/KEV и приоритизацию уязвимостей, AI-агентов и нейросети в триаже, автоматизированный патчинг, моделирование атак, зашивание безопасности в разработку, проблемы взаимодействия с IT, работу с системами, которые нельзя патчить, будущее VM-специалистов и особенности управления уязвимостями в Linux, Kubernetes, контейнерах и облаках. Классно посидели, мне очень понравилось. Надо будет как-нибудь продолжить общение по теме. 😉

Таймстемпы:

00:00 Приветствие, медиа-партнёры
03:25 Справедливо ли мнение, что CVSS как основная метрика приоритизации - это уже "технология 2002 года"? Почему в 2026 году компании всё ещё живут в логике "сортируем по CVSS", хотя есть EPSS, KEV и трендовые метрики? Это лень, незнание или инерция?
07:49 Насколько вопросы триажа, ранжирования и приоритизации уязвимостей делаются лучше с помощью нейросетей? Будет ли в будущем происходить быстрое сопоставление по разным шкалам и интегральная оценка с учётом искажений, которые есть в тех или иных системах метрик?
10:09 Автономные AI-агенты и VM
12:00 System-hardening и патчинг уязвимостей агентами без участия человека - уже реальность?
15:33 Насколько справедливо утверждение, что Exposure Management - это не просто "VM 2.0", а действительно другой взгляд на управление риском? В твоём понимании это эволюция или всё-таки революция, но с новым ценником? (Я тут попутал "croûton" и "croissant" в известной кино-цитате - сорян 🤦‍♂️🤷‍♂️🙂)
20:32 Про зашивание безопасности в IT/разработку, почему так много Linux-уязвимостей, и нужна ли замена Linux Kernel
30:08 Если завтра появится "идеальный ИИ", который с точностью 99% предсказывает, что уязвимость будет эксплуатирована в течение 30 дней, - правда ли, что роль VM-специалиста всё равно не исчезнет? В чём тогда останется человеческая зона ответственности?
32:31 О реализуемости полного моделирования путей атаки и автоматизированном реагировании
37:46 Насколько справедливо утверждение, что IT-отделы часто фактически саботируют VM? Как это выглядит на практике: это злой умысел, защита своих интересов или просто боль от перегрузки?
42:43 Как выглядит VM-процесс для систем, которые нельзя патчить или даже активно сканировать?
45:51 Как превратить IT-шников в ответственных хозяев своих активов?
48:48 Насколько сильно отличается подход к детектированию и управлению уязвимостями в Linux, контейнерах, Kubernetes и облаках от классического сканирования Windows-хостов? Где сегодня самые большие слепые зоны?
51:30 Детектирование - это только начало, а вся драма начинается после? Какие этапы после детекции чаще всего "рассыпаются" в реальных компаниях?
54:26 Блиц-вопросы
56:11 Заключение

📺 Смотрите на платформах: VK Видео, RUTUBE, YouTube.
🎧 Слушайте на платформах: Яндекс Музыка, Звук, Spotify, Pocket Casts, Deezer, Podcast Addict, Mave.

SENSE опубликовали статистику по зарплатам IT- и ИБ-специалистов в России за Q1 2026

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

SENSE опубликовали статистику по зарплатам IT- и ИБ-специалистов в России за Q1 2026

SENSE опубликовали статистику по зарплатам IT- и ИБ-специалистов в России за Q1 2026. Там в аналитике основные моменты: количество вакансий сокращается, а искусственный интеллект начинает играть всё большую роль. Об этом можете подробнее у Евгения Баклушина почитать. У меня же в связи с этой публикацией основной вопрос другой: а где в этой статистике по ИБ-специалистам VM-щики? Ну или даже шире, где здесь инфраструктурная безопасность? Большая проблема в том, что нас (VM-щиков) не видно, незаметно. В отличие от пентестеров, AppSec, DevSecOps, SOС-оводов, архитекторов ИБ и методологов.

Нас вообще вроде как бы и нет. 🤷‍♂️ Нет отдельных дискуссионных площадок или специализированных конференций. Соответственно нет и понимания, что под VM должны быть выделенные роли в организации, а специалистам на этих ролях необходимо платить достойную зарплату. Даже VM-вендоры говорят, что VM-щик на part time - это норма (на самом деле не так 🙄).

Что делать с этим? 🤔 Имхо, кроме нас самих VM-ную тему в России никто качать не будет. Давайте как-то развивать нашу идентичность. Если вы в этой области трудитесь, неважно, на стороне клиента, вендора или интегратора, подумайте, как вы могли бы заявить о себе. Если у вас ещё нет канала или блога, заведите (и подсветите в avleonovchat). Делитесь в нём своими мыслями по профессиональным темам. Завязывайте дискуссии. Подайтесь с докладом на ближайшую ИБ-конференцию в вашем городе. Спросите у организаторов, будет ли там секция по VM. Предложите собрать круглый стол из знакомых VM-щиков.

Пока мы сами не начнём ощущать себя единой цеховой общностью, то так и будем оставаться где-то на задворках. И по заработной плате тоже. 🙄

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security

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

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security. А там мощный движ! 🔥🙂 Вообще у меня всегда было весьма скептическое отношение к Trivy. В первую очередь из-за качества детектирования уязвимостей. Каждый раз, когда я пытался использовать его для анализа докер-образов, я наталкивался на какие-то жуткие фолз-позитивы. Причём логику детектирования уязвимостей было отследить весьма непросто. Поэтому я Trivy использовал только в крайних случаях. Если образ можно было просканировать, детектируя чётко по бюллетеням безопасности через Vulners API, - делал так. Если нельзя из-за того, что образ был на основе какого-то дистрибутива, который Vulners на тот момент не поддерживал (например Alpine), то вынужденно использовал Trivy. Лучше, чем ничего. И тем более Trivy же БЕСПЛАТНЫЙ! 🙂 И если не задумываться о качестве детектирования, то бесплатный сканер - это ведь очевидный и лучший выбор, так ведь? 😅 Правда, я Trivy не пользовался уже года 3-4. Возможно, что с детектированием уязвимостей ситуация у них стала получше. Но вот с собственной безопасностью похоже стало хуже. Иначе как объяснить, что вместо бесплатного сканера с официального репозитория Trivy на GitHub распространяется малварь (и это уже во второй раз за два месяца!). 😱

В конце прошлой недели, 20 марта, исследователь безопасности Paul McCarty сообщил о крупной атаке на цепочку поставок, нацеленной на Trivy.

"Внимание! Trivy версии 0.69.4 скомпрометирована ⚠️ Контейнерные образы и GitHub-релизы версии 0.69.4 являются вредоносными, поэтому если вы используете Trivy в CI, стоит срочно обратить на это внимание. К счастью, версия через Homebrew не была скомпрометирована, как я сообщал ранее. Вредоносная нагрузка представляет собой бинарный файл, и мы пока не провели его анализ, но обновим информацию, как только узнаем больше. Огромное спасибо команде, которая оперативно отреагировала сегодня - вы спасли ОЧЕНЬ много людей от крайне неприятного дня."

Подробности по малвари на opensourcemalware.

Разработчики часто встраивают Trivy в свои CI/CD-пайплайны - и это делает его особенно привлекательным для злоумышленников, поскольку позволяет им похищать API-ключи, учетные данные облаков и баз данных, токены GitHub, а также множество других секретов и чувствительной информации.

За атакой стоит группа TeamPCP. Им удалось это сделать, потому что ещё в феврале та же группа воспользовалась ошибкой конфигурации в GitHub Action Trivy и похитила токен с привилегированным доступом. Эта проблема безопасности так и не была полностью устранена, и позже, в марте, злоумышленники использовали этот токен для создания поддельных коммитов в Trivy.

Исследователи из Socket и Wiz в выходные установили подробности атаки. Атака затронула несколько компонентов проекта Trivy: основной сканер, GitHub Action trivy-action и GitHub Action setup-trivy. Злоумышленники принудительно обновили 75 из 76 тегов trivy-action до вредоносных версий, что означает: любой, кто использовал Trivy в своем пайплайне разработки, запускал инфостилер-вредонос при обращении к сканеру.

Исследователи также обнаружили, что TeamPCP расширила свои операции, начав заражать экосистему npm с помощью ранее неизвестного червя под названием CanisterWorm, используя похищенные publish-токены из первоначального взлома Trivy.

В воскресенье Socket зафиксировали дополнительные вредоносные образы, опубликованные в Docker Hub, а Paul McCarty отметил высокий импакт атаки: "44 внутренних репозитория были взломаны, переименованы и сделаны публичными - включая исходный код Tracee, внутренние форки Trivy, CI/CD-пайплайны, Kubernetes-операторы и базы знаний команд (team knowledge bases)". Socket отмечают, что, хотя полный масштаб доступа остаётся неясным, наличие этих репозиториев указывает на более глубокий уровень контроля во время компрометации.

Charles Carmakal, директор Mandiant Consulting, на мероприятии Google заявил:

"Нам известно о более чем 1 000 затронутых SaaS-средах, которые прямо сейчас активно сталкиваются с этим конкретным злоумышленником. Количество этих жертв, вероятно, вырастет ещё на 500, ещё на 1 000, возможно, ещё на 10 000. И мы знаем, что эти акторы сейчас сотрудничают с рядом других групп".

В общем, излишнее доверие к сторонним бесплатным компонентам и излишняя автоматизация вышли компаниям боком. Снова. 😏🍿

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr

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

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.

00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании MongoDB
05:35 Декабрьский Linux Patch Wednesday
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23-01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р-ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rockstar Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало - Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024-м году
59:24 DevSecOps Maturity Model 2023
1:01:25 Прощание в стихах от Mr. X

Инструменты безопасности SDLC могут УВЕЛИЧИТЬ поверхность атаки

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

Инструменты безопасности SDLC могут УВЕЛИЧИТЬ поверхность атаки. Чего? А вот да! Мой коллега и товарищ Денис Макрушин, с которым мы вместе в PT работали, выложил сегодня доклад с мероприятия OWASP под говорящим названием "Dev Sec Oops". В нем он разбирает примеры как мисконфигурации статических анализаторов (SAST) и средств динамического анализа ПО (DAST) могут привести к утечке интеллектуальной собственности и компрометации процессов SDL.

SAST-ы (СДУК) и DAST-ы (СДУП) это всё части большого Vulnerability Management-а, поэтому это наша тема, надо слушать. 😉

И так как Денис ресерчер, то он ещё периодически находит интересные уязвимости в необычных технологиях и продуктах, вот например:

• Уязвимости умных городов - материалы исследования были опубликованы на DEFCON
• Уязвимости в системах подключенной медицины и медицинского оборудования

Обязательно переходите и подписывайтесь на канал Дениса Макрушина!

PS: Тут кто-то может сказать, а чего это вы вдруг друг про друга пишете, уж не интеграция ли это для обмена подписчиками? 🤔 Конечно! 😇 Но, во-первых, это первая за всё время, а во-вторых вы только посмотрите кого я вам рекомендую! ТОПовый контент!

PPS: Пользуясь случаем, поздравляю всех с Днем Космонавтики! Ура! 🚀🎉