Архив рубрики: Темы

В Штатах победил Трамп, но, имхо, для нашего дела это мало чего изменит

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

В Штатах победил Трамп, но, имхо, для нашего дела это мало чего изменит

В Штатах победил Трамп, но, имхо, для нашего дела это мало чего изменит. Будь там хоть Трамп, хоть Харрис, хоть Байден, хоть сам чёрт лысый. 😈

🔻 Как использовали США свой взращённый нерыночными методами бигтех как инструмент глобального доминирования, так и будут использовать. Как распространяли NSA-ные закладки под видом уязвимостей, так и продолжат распространять. Новые "оспенные одеяла" для нового времени. 🤷‍♂️

🔻 Наиболее негативным сценарием сейчас, как ни парадоксально, было бы снятие всех ограничений со стороны США и схлопывание импортозамещения у нас. Думаю, что это очень маловероятно. Памятуя о первой каденции Трампа, стоит ждать усиления санкционных ограничений в области экспорта IT-продуктов и сервисов. 🌚

🔻 Бардака в NVD, при Трампе, конечно, было куда меньше. Но и обещаний навести там порядок за 2 дня никто не озвучивал. 😅 Так что в части американской инфраструктуры для описания и оценки уязвимостей ничего кроме дальнейшей деградации я не жду.

Возможно ли использовать AI для детектирования уязвимостей?

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

Возможно ли использовать AI для детектирования уязвимостей?

Возможно ли использовать AI для детектирования уязвимостей? Думаю да, но тут нужно определиться, что мы под этим понимаем.

🔻 Если речь идёт об обнаружении ранее неизвестных уязвимостей, о ресёрче, то здесь AI инструменты работают уже сейчас. Буквально на днях, 1 ноября, исследователи из Google Project Zero обнаружили первую реальную эксплуатабельную уязвимость с помощью своего LLM проекта Big Sleep. Это была stack buffer underflow в SQLite. Очень круто и многообещающе. 👍

🔻 Если же речь идёт об известных (CVE) уязвимостях, то задача сводится к генерации чётких правил их детектирования в инфраструктуре. AI должен взять на вход имя продукта и вендора, обнаружить источник данных об уязвимостях, понять структуру данных и как можно из них сгенерировать формальные правила для детектирования (например, на языке OVAL), произвести генерацию и оценить корректность правил. Не выглядит как что-то невероятное, но практических реализаций этого я пока не встречал. 🤷‍♂️

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать

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

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать. И сейчас отечественные вендоры не любят сообщать об уязвимостях в своих продуктах, а так совсем ягнятки замолчат. 🤐

И тут я сформулирую предложение, без которого первое не работает. Если вендор знает об уязвимости в версии своего продукта, используемой у клиентов, и этот факт замалчивает, то это должно классифицироваться как КРАЙНЕ серьёзное нарушение. Если такая ситуация вскрывается, то

🔹 сертификат продукта должен отзываться, лицензия вендора анулироваться, назначаться крупный штраф

🔹 ответственный (гендир) должен лично нести за это уголовную ответственность

По какой статье? Имхо, стоит расширить 274.1, т.к. такое замалчивание создаёт риски для КИИ.

Следует сделать так, чтобы между публикацией информации об уязвимости (и последующим объяснением с регулятором) и замалчиванием вендору ВСЕГДА рационально было бы сделать выбор в пользу первого.

Как сделать так, чтобы вендоры отвечали за уязвимости в их продуктах?

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

Как сделать так, чтобы вендоры отвечали за уязвимости в их продуктах?

Как сделать так, чтобы вендоры отвечали за уязвимости в их продуктах? Как по мне, рыночные механизмы здесь не работают. 🤷‍♂️ Работают только регуляторные и только в контексте сертифицированных решений. Только отзыв сертификата существенно влияет на бизнес вендоров. 😏

"Если б я был султан", в случае обнаружения критичной уязвимости в сертифицированной версии ПО требовал бы, чтобы

🔻 вендор объяснил, как уязвимость туда попала, с учётом реализованных процессов безопасной разработки

🔻 испытательная лаборатория объяснила, почему уязвимость не была обнаружена в ходе работ по сертификации

А дальше пусть комиссия регулятора решает, что делать и с этим вендором, и с этой лабораторией. 😈

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

А почему компании-вендоры лепят продукты из кишащего уязвимостями недоверенного опенсурса и это их ничуть не напрягает? Просто их прибыль не зависит от уязвимостей примерно никак

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

А почему компании-вендоры лепят продукты из кишащего уязвимостями недоверенного опенсурса и это их ничуть не напрягает? Просто их прибыль не зависит от уязвимостей примерно никак

А почему компании-вендоры лепят продукты из кишащего уязвимостями недоверенного опенсурса и это их ничуть не напрягает? Просто их прибыль не зависит от уязвимостей примерно никак. Для них важно, чтобы фичи для решения бизнес-задач клиентов появлялись в продукте быстро и с минимальными затратами на ФОТ. А если это можно получить сразу, бесплатно и легально за счёт опенсурсного кода - это ж просто праздник какой-то! Практически деньги из воздуха! 💰🤑 А то, что в этом софте будут находить уязвимости или даже закладки, так и что с того? Надо будет - запатчат.

Быстро поднятое упавшим не считается!

Удобное положение вещей: выпущенное обновление искупает факт наличия уязвимости. Какая бы позорная она не была! Даже если она эксплуатировалась как 0day! Было и было. 🤷‍♂️

Ставьте обновления, господа клиенты. Хоть по 10 раз на дню. 😏 И не рефлексируйте.

Пока факт наличия уязвимости в продукте стоит вендорам примерно 0, ситуация не изменится. Издержки продолжат нести клиенты. 🤷‍♂️

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше?

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

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше?

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше? Даже Майкрософт с их образцовой системой выявления и исправления уязвимостей (без шуток, в этом они top-notch) и минимизацией использования чужого кода практически каждый месяц исправляет больше сотни уязвимостей в своих продуктах. Откуда-то ведь они берутся? Кто-то лепит эти баги, уходящие беспрепятственно в прод? Учитывая лаг в месяцы между тем как исследователь сообщает об уязвимости в Microsoft и, собственно, датой выхода фикса, известных незакрытых уязвимостей в бэклоге у MS должно быть очень и очень много.

Что уж говорить о компаниях попроще, продающих под видом своих продуктов сплошной суп из за… заимствованного опенсурсного кода. 🙂 Который зачастую разрабатывает полусумасшедший мейнтейнер-энтузиаст на пару с очередным фейковым Jia Tan-ом. 😈 Это они, должны требования по безопасной разработке выполнять, чтобы не допускать уязвимостей? Ну да, конечно, ждите-ждите. 😏

VM Dev Tasks: Разработка web-интерфейса для сканера уязвимостей

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

VM Dev Tasks: Разработка web-интерфейса для сканера уязвимостей

VM Dev Tasks: Разработка web-интерфейса для сканера уязвимостей. Может ли сканер уязвимости быть коммерчески успешным и при этом не иметь графического интерфейса (желательно web)? Теоретический - да, но практически я таких прецедентов не припомню. 😉 Отсюда и заинтересованность в специалистах с таким опытом разработки со стороны Vulnerability Management и EASM вендоров.

В рамках практического проекта предлагается реализовать веб-интерфейс для готового консольного сканера уязвимости, например Nmap+Vulners, Nuclei или Scanvus.

Классической является компановка веб-интерфейса сканера уязвимостей Tenable Nessus:

🔹 параметры сканирования задаются в профиле
🔹 задачу на сканирование определяет профиль и таргет (IP или fqdn)
🔹 пользователь может запустить задачу на сканирование, отслеживать её статус и получить по ней результаты

Желательно максимально упростить добавление в приложение поддержки новых консольных сканеров.