L1D Eviction Sampling
https://cacheoutattack.com/
CVE-2020-0549 / INTEL-SA-00329
https://software.intel.com/security-software-guidance/software-guidance/l1d-eviction-sampling
Список процессоров, подверженных атаке:
https://software.intel.com/security-software-guidance/insights/processors-affected-l1d-eviction-sampling

#intel #cpu #vulnerability #tsx #taa #L1Deviction

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

В отчете рассматриваются пять ключевых областей, где академические исследования прямо противоречат распространенным заявлениям поставщиков инструментов:
1️⃣Манипуляции с бенчмарками и искусственные условия тестирования.
Используемые вендорами синтетические тестовые наборы не отражают сложность реальных приложений, что приводит к завышенным показателям обнаружения уязвимостей.
2️⃣Низкие реальные показатели обнаружения уязвимостей статическими анализаторами.
Статические анализаторы пропускают от 47% до 87% реальных уязвимостей, при этом коммерческие решения не демонстрируют значимых преимуществ перед открытым ПО.
3️⃣Высокий уровень ложных срабатываний.
Ложноположительные срабатывания достигают 25-80%, что приводит к усталости разработчиков и снижению эффективности использования инструментов.
4️⃣Ограничения покрытия при использовании методов черного ящика.
Фаззеры быстро достигают плато покрытия, пропуская сложные и зависящие от состояния уязвимости, что снижает их эффективность в реальных условиях.
5️⃣Сложности интеграции и настройки инструментов в CI/CD-средах.
Инструменты требуют значительной доработки, настройки и постоянного обслуживания, что зачастую недооценивается производителями.

Для выбора и оценки инструментов безопасности предлагается использовать следующие вопросы, основанные на академических данных и практическом опыте внедрения:
🟢Были ли тесты проведены на реальных, сложных приложениях, а не только на упрощённых тестовых кейсах?
🟢Проверялся ли инструмент на ранее неизвестных уязвимостях?
🟢Описана ли методология тестирования с указанием всех параметров и характеристик тестируемых приложений?
🟢Включают ли опубликованные метрики показатели ложноположительных и ложноотрицательных срабатываний, охват (coverage) и затраты на внедрение?
🟢Прошли ли результаты независимую верификацию третьими сторонами без участия или финансирования вендора?

Рекомендуемые критерии выбора и оценки инструментов:
🟠Эмпирическая обоснованность.
Отдавать приоритет инструментам, чья эффективность подтверждена независимыми, желательно академическими, исследованиями.
🟠Прозрачность покрытия.
Запрашивать детальные метрики покрытия и показатели обнаружения. Само количество найденных уязвимостей мало говорит о глубине и надёжности инструмента.
🟠Влияние на разработчиков.
Оценивать, как инструмент влияет на ежедневную работу: частота ложных срабатываний, задержки обратной связи, удобство в процессе локальной разработки.
🟠Интеграция и эксплуатация.
Анализировать инженерные затраты на внедрение, интеграцию и сопровождение инструмента, включая совместимость с CI/CD и инфраструктурные накладные
расходы.
🟠Комплементарность.
Не рассчитывать на универсальность одного решения — строить многоуровневую стратегию, комбинируя различные инструменты и подходы для покрытия известных пробелов.

#vulnerability #benchmark #testing #marketing #fuzzing #sast #dast #vm

_______
Источник | #alexredsec