Главная » Инф-ая безопасность » OWASP Топ 10 – 2021

OWASP Топ 10 – 2021

OWASP Топ 10 – 2021
Инф-ая безопасность
03 октябрь 2021
0

Что изменилось в Топ-10 на 2021 год


В Топ-10 на 2021 год добавлены три новые категории, четыре категории с изменениями в названиях, а также с объединением некоторые категории. Мы изменили названия, когда это было необходимо, чтобы сосредоточиться на основной причине, а не на симптомах.

 

  • A01:2021- Нарушение контроля доступа (англ. Broken Access Control) переместился с пятой позиции в категорию с самым серьезным риском для безопасности веб-приложений; согласно внесенным данным, в среднем 3,81% протестированных приложений имели одно или несколько перечислений общих слабых мест (CWE), при этом в данной категории риска было обнаружено более 318 тыс. случаев CWE. 34 CWE, сопоставленные со сломанным контролем доступа, встречались в приложениях чаще, чем в любой другой категории.
  • A02:2021-Сбои в криптографии (англ. Cryptographic Failures) переместился на одну позицию выше и занял второе место, ранее известный как A3:2017- Утечка чувствительных данных (англ. Sensitive Data Exposure), который был скорее симптомом, чем главной причиной. Обновленное название фокусируется на сбоях, связанных с криптографией, как это подразумевалось ранее. Эта категория часто приводит к утечке конфиденциальных данных или к нарушению целостности системы.
  • A03:2021- Внедрение кода (англ. Injection) опускается на третью позицию. 94% приложений были протестированы на наличие той или иной формы инъекций с максимальным уровнем инцидентов 19%, средним уровнем инцидентов 3,37%, а 33 CWE, отнесенные к этой категории, занимают второе место по количеству инцидентов в приложениях - 274 тыс. инцидентов. Межсайтовый скриптинг (англ. Cross-site Scripting (XSS)) теперь является частью этой категории в данном выпуске.
  • A04:2021- Небезопасный дизайн (англ. Insecure Design) - это новая категория для 2021 года, в которой основное внимание уделяется рискам, связанным с недостатками проектирования. Если мы ходим двигаться в ином направлении, нам нужно больше моделирования угроз, моделей и принципов безопасного проектирования и эталонных архитектур. Небезопасный дизайн не может быть исправлен идеальной реализацией, поскольку по определению необходимые средства контроля безопасности никогда не создавались для защиты от конкретных атак.
  • A05:2021- Неправильная конфигурация (англ. Security Misconfiguration) безопасности поднялась с 6 на 5 место; 90% приложений были проверены на наличие той или иной формы неправильной конфигурации, со средним коэффициентом встречаемости 4,5%, и более 208 тысяч случаев CWE были отнесены к этой категории риска. Поскольку все большее число программ переходит на высококонфигурируемое программное обеспечение, неудивительно, что эта категория повысилась. Бывшая категория A4:2017- Внедрение внешних XML сущностей (англ. XML External Entities (XXE)) теперь является частью этой категории риска.
  • A06:2021-Уязвимые и устаревшие компоненты (англ. Vulnerable and Outdated Components) ранее называлась A09:2017 Использование компонентов с известными уязвимостями, она занимает второе место в Топ-10 по результатам опроса сообщества, но также имеет достаточно данных для попадания в Топ-10 по результатам наших анализов. Эта категория поднялась с № 9 в 2017 году и является известной проблемой, которую мы с трудом тестируем и оцениваем его риски. Это единственная категория, в которой нет общих уязвимостей (CVE), сопоставленных с включенными в нее CWE, поэтому в их оценках по умолчанию учитывается эксплойт и вес воздействия 5,0.
  • A07:2021- Ошибки идентификации и аутентификации (англ. Identification and Authentication Failures) ранее называлась A02:2017 Некорректная аутентификация (англ. Broken Authentication) и опустилась со второго места на седьмое место, теперь она включает в себя CWE, которые больше связаны с ошибками идентификации. Эта категория все еще является неотъемлемой частью Топ-10, но увеличение количества стандартизированных систем, похоже, способствует уменьшению некорректной аутентификации.
  • A08:2021- Нарушение целостности данных и программного обеспечения (англ. Software and Data Integrity Failures) - новая категория для 2021 года, посвященная принятию предположений, связанных с обновлениями программного обеспечения, критическими данными и CI/CD конвейерами без проверки на целостность. Одно из самых высоких по весу воздействий из данных Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) сопоставлено с 10 CWE в этой категории. A8:2017- Небезопасная десериализация (англ. Insecure Deserialization) теперь является частью этой более крупной категории.
  • A09:2021- Журнал безопасности и сбои мониторинга (англ. Security Logging and Monitoring Failures) ранее была A10:2017- Отсутствие журналирования и мониторинга (англ. Insufficient Logging & Monitoring) и добавлена из опроса сообщества Топ-10 (#3), поднявшись с десятого на девятое место. Эта категория расширена и включает больше типов сбоев, ее сложно тестировать, и она не очень хорошо представлена в данных CVE/CVSS. Однако сбои в этой категории могут напрямую влиять на видимость, оповещение об инцидентах и проведение экспертизы.
  • A10:2021- Подделка запросов со стороны сервера или же SSRF (англ. Server-Side Request Forgery) добавлена в Топ-10 опроса сообщества (#1). Данные показывают относительно низкий уровень инцидентов при охвате тестирования выше среднего, а также оценки выше среднего по потенциалу применения и воздействия. Эта категория представляет собой сценарий, в котором члены сообщества безопасности говорят нам, что это важно, хотя на данный момент это не показано в данных.

Методика


Этот выпуск Топ-10 как никогда опирается на полученные данные. Мы отобрали восемь из десяти категорий из предоставленных данных и две категории из опроса сообщества Топ-10. Мы сделали это по основной причине: просмотр предоставленных данных - это взгляд в прошлое. Исследователи AppSec тратят время на поиск новых уязвимостей и новых способов их проверки. Требуется время, чтобы добавить эти тесты в инструменты и процессы. К тому времени, когда мы сможем надежно протестировать слабое место, скорее всего, пройдут годы. Чтобы уравновесить это мнение, мы используем опрос сообщества, чтобы узнать у экспертов по безопасности и разработке приложений, работающих на передовой. Какие уязвимости, по их мнению, являются основными, по которым пока нет данных.

Есть несколько важных изменений, которые мы приняли для дальнейшего развития Топ-10.

Как структурированы категории


Несколько категорий изменились по сравнению с предыдущим выпуском OWASP Top 10. Ниже приводится краткое описание изменений в категориях.

Предыдущие усилия по сбору данных были сосредоточены на предписанном подмножестве 30 CWE, а в дальнейшем предлагалось получить дополнительные результаты. Мы узнали, что организации в основном фокусировались только на этих 30 CWE и редко добавляли дополнительные CWE, которые они видели. В этой версии мы открыли анкету и просто попросили предоставить данные, без ограничений по CWE. Мы попросили указать количество приложений, протестированных за определенный год (начиная с 2017 года), и количество приложений, в которых при тестировании был обнаружен хотя бы один экземпляр CWE. Такой формат позволил нам отследить, насколько распространен каждый CWE в популяции приложений. Мы игнорируем частоту для наших целей; хотя она может быть необходима в других ситуациях, она лишь скрывает фактическую распространенность в популяции приложений. Независимо от того, имеет ли приложение четыре экземпляра CWE или 4 000 экземпляров, это не является частью расчета для Топ-10. Мы перешли от примерно 30 CWE к почти 400 CWE для анализа в наборе данных. В будущем мы планируем провести дополнительный анализ данных в качестве дополнения. Столь значительное увеличение количества CWE потребовало внесения изменений в структуру категорий.

Мы потратили несколько месяцев на группировку и категоризацию CWE и могли бы продолжать еще несколько месяцев. В какой-то момент нам пришлось остановиться. Существуют типы CWE как по основной причине, так и по симптомам, где основная причина - это "криптографический сбой" и "неправильная конфигурация", а симптомы - "раскрытие конфиденциальных данных" и "отказ в обслуживании". Мы решили сосредоточиться на основной причине, когда это возможно, поскольку это более логично для предоставления рекомендаций по идентификации и устранению последствий. Сосредоточение внимания на основной причине, а не на симптоме, не является новой концепцией: в десятке лучших сочетаются симптомы и основные причины. CWE также представляют собой смесь симптомов и основных причин; мы просто более тщательно подходим к этому вопросу и указываем на них. В среднем 19,6 CWE на категорию в этом выпуске, с нижними границами от 1 CWE для A10:2021-Подделка запросов со стороны сервера  (SSRF) до 40 CWE в A04:2021-Небезопасный дизайн . Эта обновленная структура категорий дает дополнительные преимущества для обучения, поскольку компании могут сосредоточиться на CWE, которые имеют смысл для языка/фреймворка.

Как данные используются для выбора категорий


В 2017 году мы отобрали категории по уровню заболеваемости для определения вероятности, а затем проранжировали их путем обсуждения на основе десятилетнего опыта по Эксплуатационной способности, Обнаруживаемости (также вероятности) и Технического воздействия. В 2021 году мы хотим использовать данные по эксплуатационной пригодности и (техническому) воздействию, если это возможно.

Мы загрузили OWASP Dependency Check и извлекли оценки CVSS Эксплоит и Воздействие, сгруппированные по связанным CWE. Это потребовало довольно много исследований и усилий, поскольку все CVE имеют оценки CVSSv2, но в CVSSv2 есть недостатки, которые CVSSv3 должен устранить. После определенного момента времени всем CVE присваивается оценка по CVSSv3. Кроме того, диапазоны и формулы оценки были обновлены между CVSSv2 и CVSSv3.

В CVSSv2 оценки эксплойта и (технического) воздействия могли достигать 10.0, но формула снижала их до 60% для эксплойта и 40% для воздействия. В CVSSv3 теоретический максимум был ограничен 6.0 для Эксплойта и 4.0 для Воздействия. С учетом весовых коэффициентов, оценка воздействия сместилась выше, почти на полтора балла в среднем по CVSSv3, а эксплуатационная пригодность сместилась почти на полбалла ниже в среднем.

В Национальной базе данных уязвимостей (NVD), извлеченной из OWASP Dependency Check, имеется 125 тыс. записей о сопоставлении CVE с CWE, и 241 уникальный CWE сопоставлен с CVE. 62 тыс. карт CWE имеют оценку CVSSv3, что составляет примерно половину всей совокупности в наборе данных.

Для первой десятки 2021 мы рассчитали средние оценки эксплойтов и воздействия следующим образом. Мы сгруппировали все CVE с оценками CVSS по CWE и взвесили оценки эксплойтов и воздействия по проценту от общего числа CVSSv3 + оставшееся число CVSSv2 для получения общего среднего значения. Мы сопоставили эти средние значения с CWE в наборе данных, чтобы использовать их в качестве оценок эксплойтов и (технического) воздействия.

Почему не просто чистые статистические данные?


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

Поэтому мы выбираем только восемь из десяти категорий из данных, поскольку они неполные. Две другие категории взяты из опроса Топ-10 сообщества. Он позволяет специалистам, находящимся на передовой линии, проголосовать за то, что они считают самыми высокими рисками, которых может не быть в данных (и, возможно, никогда не будет выражено в данных).

Почему уровень заболеваемости, а не частота?


Существует три основных источника данных. Мы определили их как Human-assisted Tooling (HaT), Tool-assisted Human (TaH) и raw Tooling.

Инструментарий и HaT - это генераторы высокочастотных находок. Инструменты ищут конкретные уязвимости и неустанно пытаются найти каждый экземпляр этой уязвимости и генерируют большое количество находок для некоторых типов уязвимостей. Посмотрите на межсайтовый скриптинг, который обычно бывает двух видов: это либо незначительная, изолированная ошибка, либо системная проблема. Когда это системная проблема, количество находок может исчисляться тысячами для одного приложения. Такая высокая частота заглушает большинство других уязвимостей, обнаруженных в отчетах или данных.

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

Предположим, мы возьмем эти два разных набора данных и попытаемся объединить их по частоте. В этом случае данные Tooling и HaT будут топить более точные (но широкие) данные TaH, и это хорошая часть того, почему такие вещи, как межсайтовый скриптинг, занимают столь высокие позиции во многих списках, в то время как их влияние обычно низкое или умеренное. Это связано с огромным количеством находок. (Межсайтовый скриптинг также достаточно легко тестировать, поэтому и тестов на него гораздо больше).

В 2017 году мы ввели использование показателя заболеваемости вместо этого, чтобы по-новому взглянуть на данные и чисто объединить данные Tooling и HaT с данными TaH. Показатель заболеваемости определяет, какой процент приложений имеет хотя бы один экземпляр уязвимости того или иного типа. Нам не важно, была ли эта уязвимость единичной или системной. Для наших целей это не имеет значения; нам просто нужно знать, сколько приложений имели хотя бы один экземпляр, что помогает получить более четкое представление о результатах тестирования по нескольким видам тестирования, не загромождая данные высокочастотными результатами. Это соответствует представлению, связанному с риском, поскольку злоумышленнику достаточно одного экземпляра для успешной атаки на приложение через категорию.

Каков ваш процесс сбора и анализа данных?


Мы формализовали процесс сбора данных OWASP Top 10 на саммите Open Security Summit в 2017 году. Лидеры OWASP Top 10 и сообщество в течение двух дней занимались формализацией прозрачного процесса сбора данных. Издание 2021 года - это второй раз, когда мы используем эту методику.

Мы публикуем объявление о сборе данных через доступные нам каналы социальных сетей, как проекта, так и OWASP. На странице проекта OWASP мы перечисляем элементы и структуру данных, которые мы ищем, а также способы их предоставления. В проекте на GitHub у нас есть примеры файлов, которые служат шаблонами. При необходимости мы работаем с организациями, чтобы помочь разобраться со структурой и сопоставлением с CWE.

Мы получаем данные от организаций, которые по профессии являются поставщиками услуг по тестированию, поставщиками баг-баунти, а также от организаций, которые предоставляют данные о внутреннем тестировании. Получив данные, мы собираем их вместе и проводим тщательный анализ того, как CWE соотносятся с категориями риска. Некоторые CWE пересекаются, а другие очень тесно связаны между собой (например, криптографические уязвимости). Любые решения, связанные с представленными исходными данными, документируются и публикуются, чтобы быть открытыми и прозрачными в отношении того, как мы нормализовали данные.

Для включения в Топ-10 мы рассматриваем восемь категорий с самыми высокими показателями распространенности. Мы также смотрим на результаты опроса сообщества по Топ-10, чтобы увидеть, какие из них уже могут присутствовать в списке Топ-10. Две категории получившие больше всего голосов, которые еще не присутствуют в списке, будут отобраны в Топ-10. После того как все десять были отобраны, мы применили обобщенные коэффициенты эксплуатационной пригодности и воздействия, чтобы помочь ранжировать Топ-10 2021 в порядке, основанном на риске.

Факторы данных


Существуют факторы данных, перечисленные для каждой из 10 категорий, вот что они означают:

  • CWEs Mapped: Количество CWE, сопоставленных с категорией командой Топ-10.
  • Incidence Rate: Коэффициент инцидентности - это процент приложений, уязвимых к данному CWE, от общего числа приложений, протестированных данной командой за этот год.
  • (Testing) (Coverage): Процент приложений, протестированных всеми организациями на наличие данного CWE.
  • Weighted Exploit: Подшкала Exploit из оценок CVSSv2 и CVSSv3, присвоенных CVE, сопоставленных с CWE, нормализованных и расположенных по 10-бальной шкале.
  • Weighted Impact: Суб-оценка воздействия, полученная из оценок CVSSv2 и CVSSv3, присвоенных CVE, сопоставленным с CWE, нормализованная и расположенная по 10-бальной шкале.
  • Total Occurrences: Общее количество приложений, в которых обнаружены CWE, сопоставленные с категорией.
  • Total CVEs: Общее количество CVE в базе данных NVD, которые были сопоставлены с CWE, сопоставленными с категорией.


Об авторе
admin Пользователь не указал информацию о себе
Ctrl
Enter
Заметили ошЫбку
Выделите текст и нажмите Ctrl+Enter
14 083
0
+99
Комментарии (0)