Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удобное положение вещей: выпущенное обновление искупает факт наличия уязвимости. Какая бы позорная она не была! Даже если она эксплуатировалась как 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)
🔹 пользователь может запустить задачу на сканирование, отслеживать её статус и получить по ней результаты

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

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся

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

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся. В январе 1999 года Дэвид Э. Манн и Стивен М. Кристи опубликовали статью "К единому перечислению уязвимостей" ("Towards a Common Enumeration of Vulnerabilities"), в которой предлагалось создать лист Common Vulnerability Enumeration, CVE (заметьте, в оригинале никаких "экспозиций" 😉), целью которого было бы:

🔻 нумеровать и различать все известные уязвимости
🔻 назначать стандартное уникальное имя каждой уязвимости
🔻 существовать независимо от множественных точек зрения на то, что такое уязвимость
🔻 являться публично "открытым", распространяемым без ограничений

В октябре 1999 года корпорация MITRE представила первый CVE лист, в котором была 321 запись. За 25 лет их количество перевалило за 250 000 идентификаторов (без Rejected). Количество новых CVE каждый год ставит рекорды, в этом году ожидается больше 35 000. В основном такой бешеный прирост обеспечивают организации со статусом CNA, которых уже 221. Они, получив заветный статус, могут заводить CVE на любую дичь. Хоть весь свой багтреккер пихать, как Linux Kernel. 😏

Во многом из-за такого прироста (ну и из-за приколов американской бюрократии) процесс по анализу уязвимостей в NIST NVD в 2024 году дал масштабный сбой, фактически остановился. Несмотря на все меры (включая финансовые), он так толком и не восстановился. NVD месяц от месяца анализирует значительно меньше CVE, чем получает от CVEorg. Бэклог на анализ растёт, и составляет 19 174 CVE. 🫣

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

Вот такой итог 25 лет. Вместо единой нейтральной базы пришли к стремительно растущему недоанализированному огороженному западному мусорному полигону. В котором приходится всем миром копаться, потому что ничего лучше всё равно нет. 🙄 Круто, чё. С юбилеем!

Отдельно разберу роадмап ScanFactory на 2025 год, озвученный на вебинаре

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

Отдельно разберу роадмап ScanFactory на 2025 год, озвученный на вебинаре

Отдельно разберу роадмап ScanFactory на 2025 год, озвученный на вебинаре.

Threat Intelligence фичи не относятся напрямую к VM-у: агрегатор утечек почт, мониторинг фишинговых доменов, поиск связанных доменов организации.

Из VM-ных фич:

🔹 Поддержка SSO. Важно для любого энтерпрайзного продукта.

🔹 Сканер с сертификатом ФСТЭК. Добавят в решение сканер от российского вендора. Для комплаенса и сканирования отечественных продуктов.

🔹 Сканирование изолированных (не связанных) сегментов сети в едином ЛК. Имеется ввиду сканирование внутренних сетей разных компаний (подразделений, тенантов) из единого ЛК.

🔹 Авто-тестирование безопасности внутренней сети. Будут автоматизировать действия внутреннего нарушителя: проверки безопасности служб AD (включая AD CS), анализ конфигураций ACL, атаки на сетевые протоколы, проверка стойкости паролей и т.д.

🔹 AI для рекомендации по устранению уязвимостей. Будут приоритизировать уязвимости и генерить человеко-читаемые рекомендации в оффлайн режиме.

Набор тем для программных проектов, связанных с Управлением Уязвимостями

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

Набор тем для программных проектов, связанных с Управлением Уязвимостями

Набор тем для программных проектов, связанных с Управлением Уязвимостями. Периодически меня просят порекомендовать VM-ную тему для курсовой, диплома, хакатона и т.п. Думаю будет полезно собрать эти рекомендации здесь в виде серии постов.

Имхо, чем больше студентов будут брать около-VMные темы для практических работ, тем лучше:

✅ Возможно кто-то превратит учебный проект в успешную опенсурсную и/или коммерческую историю.

✅ Возможно кто-то устроится работать в VM-вендора или в компанию-клиента уже с релевантным опытом и глубоким пониманием темы.

В любом случае VM-комьюнити в России получит дополнительное развитие. 👍

Буду постепенно накидывать темы, а коллег VM-щиков приглашаю присоединиться.

🔹 Web-интерфейс (лончер) сканера уязвимостей
🔹 Консольный сканер уязвимостей