State of Exploitation - A Peek into the Last Decade of Vulnerability Exploitation

Я думаю, что ни для кого не секрет, что число уязвимостей с каждым годом только растет. VulnCheck выпустил неутешительную статистику по данному тренду с 2014 по 2024 год:

- Число CVE с известной эксплуатацией увеличивается на 19,7% в год.
- Число раскрытых CVE растет на 14,1% в год.
- Число CVE с публично доступными Proof-of-Concept (PoC) эксплойтами растет на 11,8% в год.

При этом:

31% уязвимостей имеют PoC, но только 1% уязвимостей эксплуатируется в "живой природе".

В данном канале мы также не освещали существующие проблемы NIST и их неспособность обрабатывать очередь из необработанных CVE для добавления в NVD. К февралю таких уязвимостей насчитывалось 11 000, на фоне сокращения бюджета и ухода текущего ключевого подрядчика CISA. К счастью, если вы еще не слышали, месяц назад NIST объявили, что к сентябрю этого года проблема будет решена, так как найден новый подрядчик. История с NVD с самого начала вызвала сильный резонанс. Были даже слышны упоминания о потенциальном "конце света" в мире управления уязвимостями.

На фоне этого хочется поделиться статьей "Dirty Little Secrets of Vulnerability Management". Автор освещает общепринятые мифы управления уязвимостями. В частности, он напоминает, что NVD не является единственным источником CVE. Существует 383 партнёра программы CVE, поддерживающих приём и регистрацию CVE (так называемые CVE Numbering Authority). Среди них есть не только вендоры, такие как Apple, но и независимые исследователи, open source и bug bounty площадки. И даже если вам это не подходит, существуют китайские аналоги CNNVD, число уязвимостей которых превышает NVD, и российская БДУ ФСТЭК🙈. Кстати, про проблему NVD и особенности БДУ подробно осветил Александр Леонов в своём докладе phd2.

#vm #cve

Contextual Vulnerability Management With Security Risk As Debt

Я думаю, каждый, кто занимался построением программы управления уязвимостями или хотя бы раз пытался добиться от ИТ-команд их устранения, знает, насколько сложно обеспечить соблюдение установленных SLA. Зачастую SLA берутся «с потолка» и, как правило, далеки от реальных возможностей организации по быстрому устранению выявленных уязвимостей. В результате в организации возникает общая фрустрация, где все сталкиваются с удручающими отчетами. А CISO за "кружкой пива" мрачно заявляет, что "у него в бэклоге 3 миллиона уязвимостей" и "он/она не знает, что с ними делать!". И хотя из общих соображений понятно, что здесь придется обращаться к приоритезации и мудрости в духе общества анонимных алкоголиков:

Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого.

Всегда интересно понять, а как конкретно можно реализовать эффективный vulnerabilty management? Сегодня мы предлагаем вам ознакомиться с опытом DigitalOcean по внедрению методики «технического долга». Суть такова:

1) При выявлении новой уязвимости ей присваивается определенный уровень критичности.

2) В зависимости от уровня критичности уязвимости определяется рекомендуемое время для ее устранения. Это время известно как «Accepted Insecure Time» — период, в течение которого уязвимость должна быть устранена, чтобы не накапливать долг.

3) Если уязвимость не устранена в течение рекомендованного времени, начинает накапливаться долг по безопасности. Долг рассчитывается ежедневно: за каждый день, в течение которого уязвимость остается нерешенной после истечения срока, к общему долгу добавляется определенная величина, зависящая от критичности уязвимости. Чем выше критичность, тем быстрее накапливается долг.

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

5) Для каждой команды или бизнес-подразделения устанавливается определенный порог долга — максимально допустимая сумма накопленного долга по безопасности. Если долг превышает этот порог, это сигнализирует о необходимости устранить уязвимости, чтобы вернуть показатели в допустимые рамки.

6) Для всех бизнес-подразделений рассчитывается показатель соответствия порогу долга по безопасности (Security Debt Adherence), то есть процент команд, у которых долг по безопасности соответствует ожидаемому уровню (или, иначе говоря, установленному уровню обслуживания (SLO)). Вначале DigitalOcean достигали 75% и постепенно продвигались к цели в 95%. Этот порог является согласованным компромиссом между бизнес-подразделением и командой безопасности относительно того, насколько гибким может быть график выполнения работ по безопасности. Если ускорение разработки продукта, критическая инициатива, инцидент безопасности или другой фактор изменяет верхнеуровневую оценку этой гибкости, DigitalOcean может повысить или снизить порог долга для соответствующей части организации.

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

Очень красивая success story. И что характерно очень соответствующая ситуационным моделям управления ИБ, которые мы упоминали во вчерашнем посте. А как выстраиваете свой VM вы, и что используете в качестве "центральной шины"?

#vm #experience