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

Впечатления от моих вчерашних выступлений на PHDays 2

Впечатления от моих вчерашних выступлений на PHDays 2Впечатления от моих вчерашних выступлений на PHDays 2Впечатления от моих вчерашних выступлений на PHDays 2Впечатления от моих вчерашних выступлений на PHDays 2Впечатления от моих вчерашних выступлений на PHDays 2

Впечатления от моих вчерашних выступлений на PHDays 2. Было круто, мне понравилось. 🙂 Причём эмоций от первой модерации дискуссии даже больше, чем от собственного доклада. 😅

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

Здесь огромная благодарность всем участникам! Особенно, конечно, Виталию Сергеевичу Лютикову, за терпение к высказанным критическим моментам и интересные комментарии.

Также отдельно хотелось бы поблагодарить Алексея Викторовича Лукацкого за идею проведения дискуссии, большую помощь в организации и возможность попробовать себя в новой роли модератора.

Запись трансляции ищется на Youtube по "Государство 24 мая Positive Hack Days Fest 2". Чуть позже перезалью ролики на свой канал и перемонтирую выступление, чтобы слайды было лучше видно.

Выступать будем здесь

Выступать будем здесь

Выступать будем здесь. Можно будет с чистой совестью говорить, что "выступал в Лужниках" (непосредственно). А с учётом того, что сцена частично на игровом поле, то получается "выступал на поле Лужников". 😅⚽

Время начала моего выступления и дискуссии по базам уязвимостей на PHDays сместилось на 35 минут: теперь стартуем 24 мая (пятница) в 16:25 в локации Галактика

Время начала моего выступления и дискуссии по базам уязвимостей на PHDays сместилось на 35 минут: теперь стартуем 24 мая (пятница) в 16:25 в локации Галактика

Время начала моего выступления и дискуссии по базам уязвимостей на PHDays сместилось на 35 минут: теперь стартуем 24 мая (пятница) в 16:25 в локации Галактика. Надеюсь, что больше изменений не будет, но если что, отпишу в канал. 🙂 Также можете уточнять в интерактивной программе мероприятия (выделил фильтрами день и трек "Государство").

Уточнил у автора статьи откуда именно были цитаты Tanya Brewer из NIST

Уточнил у автора статьи откуда именно были цитаты Tanya Brewer из NIST

Уточнил у автора статьи откуда именно были цитаты Tanya Brewer из NIST. Она это говорила в сессии "NVD Symposium". Эта сессия есть в программе, но её запись в канал VulnCon 2024 НЕ выложили, несмотря на "TLP:CLEAR". Такие дела. 😏

Записи c VulnCon 2024 доступны на Youtube

Записи c VulnCon 2024 доступны на Youtube

Записи c VulnCon 2024 доступны на Youtube. Я об этой конфе уже писал ранее, она прошла в конце марта.

Там много интересного контента связанного с уязвимостями: их описание, приоритизация, ответственное разглашение, разнообразные связанные стандарты. 🤩 Кейсы про управление уязвимостями в организациях тоже есть. В России такого контента пока маловато. У нас если и говорят об уязвимостях, то скорее обсуждают конкретные ресерчи или атаки, а не то, как работать с уязвимостями более-менее массово и систематически. 😔

Описание докладов также доступно в программе конференции. Там удобно подыскивать интересное, а потом уже смотреть запись в Youtube канале.

Есть там и панельная дискуссия с Tanya Brewer из NIST. Но что-то откровений про кризис NVD, которые ей приписывали в статье по итогам VulnCon ("story behind it, it is long, convoluted and very administrivia" и т.п.) я не нашёл. Искал по автоматическим субтитрам. Ну, может это было сказано не на панельке, а где-то ещё. 🤷‍♂️

Мой доклад на PHDays "Кризис NVD и светлое БуДУщее" пройдёт 24 мая (Пятница) в 16:25–17:10 в локации Галактика

Мой доклад на PHDays Кризис NVD и светлое БуДУщее пройдёт 24 мая (Пятница) в 16:25–17:10 в локации Галактика

Мой доклад на PHDays "Кризис NVD и светлое БуДУщее" пройдёт 24 мая (Пятница) в 16:25–17:10 в локации Галактика. На сайте PHDays уже доступно расписание.

В рамках доклада рассмотрим:

🔹 Как ретроспективно развивался кризис NVD, реакцию на него со стороны сообщества безопасников и текущее состояние.
🔹 Какие меры предлагались сообществом для уменьшения зависимости от NVD, чтобы такая ситуация в будущем не могла повториться.
🔹 Оценку текущего состояния NVD и БДУ ФСТЭК: возможно ли для российских организаций использовать только БДУ?
🔹 Уязвимости, которые присутствуют только в БДУ ФСТЭК: общее количество, распределение по годам, типы уязвимостей, уязвимые продукты.

Сразу после доклада в 17:20–18:20 в той же локации будет дискуссия "Источники данных об уязвимости в современных реалиях" с моим участием (и модерированием).

upd. 22.05 Обновил время начала

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме Пентест): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе. Что достаточно расставить агенты по хостам. А те хосты, куда агенты установить нельзя, например сетевые устройства, достаточно сканировать с аутентификацией. Дескать сканы без аутентификации всегда менее достоверны, чем сканы с аутентификацией, и нужны они только для сканирования периметра или первичной инвентаризации сети. На мой взгляд, это не совсем правильно. Сканировать без аутентификации на наличие известных уязвимостей, обязательно нужно, особенно в случае хостов с веб-приложениями.

И связано это именно с особенностями детектирования уязвимостей при сканировании с аутентификацией. Возьмём Linux-хосты. Как правило, VM-вендоры при сканировании Linux-хостов с аутентификацией ограничиваются детектированием уязвимостей в пакетах из официального репозитория Linux-вендора. 🤷‍♂️ Просто потому, что эти уязвимости описываются в общедоступных бюллетенях безопасности или даже в виде формализованного OVAL-контента. Удобно. Научился работать с этим контентом и можно ставить галочку, что Linux-дистриб поддерживается VM-решением. А как насчёт уязвимостей софта, который отсутствует в официальном репозитории Linux-вендора? Вот тут всё сложнее.

Такой софт может быть установлен:

🔹 Из подключенного стороннего репозитория
🔹 Из пакета (вендорского или самосборного) стандартной пакетной системы дистрибутива (deb, rpm), который принесли на хост ручками
🔹 Из альтернативных пакетов для распространения софта (snap, flatpak, appimage и т.д.)
🔹 Из средств распространения модулей (pip, conda, npm и т.д.)
🔹 Из образа контейнера (docker, podman и т.д.)
🔹 Из исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесён в виде бинарных файлов

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

В итоге мы получаем ситуацию: допустим, у нас есть какой-то коммерческий или опенсурсный софт на Linux-хосте (Zabbix, GitLab, Confluence, Jira). Рыская по хосту по SSH этот софт не так-то просто надёжно найти. А при взгляде на хост извне, он ищется тривиально: сканируем порты, находим web-GUI, зачастую на главной странице находим версию и по ней детектируем уязвимости. При этом мы вообще не зависим от конкретного способа установки и запуска софта на хосте. Главное, что мы сам веб-интерфейс приложения видим. 🤩

Такие "внешние" правила детектирования уязвимостей и самим гораздо проще разрабатывать, и открытой экспертизой можно воспользоваться. Фингерпринтинг для получения CPE в сочетании с поиском в NVD по CPE это, конечно, грязный способ. Зато массовый. 😏 И если грамотно подтачивать и фингепринтилку, и правила детектирования по CPE, то и количество фолзов можно уменьшить до приемлемого уровня. А если ещё и добавить валидацию с помощью проверок с попыткой эксплуатации уязвимости (подтянуть nuclei тот же), то значительный набор уязвимостей можно будет детектировать более чем надежно. 😉

В общем, "пентест"-сканирование для определения известных уязвимостей - must have и для внутрянки тоже, особенно для веб-приложений.