Общий обзор классификаций угроз безопасности: OWASP, CWE, CAPEC, WASC

Мировой опыт

Прежде всего необходимо пояснить важное отличие реестра или перечня от классификации. К классификации предъявляются достаточно строгие требования:

• классы не должны пересекаться;
• объединение всех классов должно быть полным, т. е. покрывать все классифицируемые объекты;
• процедура классификации должна быть понятной, повторяемой и непротиворечивой, то есть вне зависимости от того, кто пытается вычислить класс объекта, результат всегда будет один и тот же;
• классификация должна быть полезной: к примеру, легко разбить множество объектов на две группы по какому-либо признаку, что формально будет являться классификацией, однако такой подход вряд ли будет востребован;
• наконец, классификация должна стать принятой в сообществе; данный критерий является следствием предыдущих – без выполнения какого-либо из перечисленных выше пунктов у классификации мало шансов быть адаптированной специалистами.

В данной статье будут рассматриваться следующие перечни и классификации:

• OWASP – перечень наиболее опасных рисков информационной безопасности для веб-приложений по мнению экспертного сообщества;
• CWE – классификация уязвимостей и недостатков программного обеспечения (не обязательно в веб-приложениях);
• CAPEC – классификация шаблонов компьютерных атак;
• WASC – классификация угроз безопасности веб-приложений.

OWASP Top 10

OWASP (Open Web Application Security Project) – это некоммерческая организация, целью которой является повышение осведомленности всех специалистов отрасли информационной безопасности в вопросах разработки, эксплуатации и защиты веб-приложений. OWASP Top 10 является одним из наиболее известных проектов организации. OWASP Top 10 — это рейтинг из десяти наиболее опасных рисков информационной безопасности для веб-приложений, составленный сообществом экспертов отрасли. Для каждого пункта рейтинга риск посчитан экспертами на основе методики OWASP Risk Rating Methodology и включает оценку по следующим критериям: распространенности соответствующих уязвимостей в приложениях (Weakness Prevalence), сложности их обнаружения (Weakness Detectability) и эксплуатации (Exploitability), а также критичности последствий их эксплуатации (Technical Impacts). По понятным причинам в расчетах критичности рисков не учитываются бизнес-последствия от их реализации. Там, где это возможно, названия рисков в рейтинге соотносятся с названиями соответствующих уязвимостей в классификации CWE (Common Weakness Enumeration). Следует отметить, что в отличие от классификаций, проект OWASP Top 10 не претендует на охват всех имеющихся рисков, а лишь представляет самые актуальные из них на момент выпуска рейтинга.

Первая версия рейтинга OWASP Top 10 появилась в 2004 году, и с тех пор документ обновляется каждые три-четыре года. Обновленные версии публиковались в 2007, 2010, 2013 и 2017 годах.

Последняя версия рейтинга, опубликованная в 2017 году, содержит следующие риски:

• A1 – Внедрение кода (Injection).
• A2 – Некорректная аутентификация (Broken Authentication).
• A3 – Утечка чувствительных данных (Sensitive Data Exposure).
• A4 – Внедрение внешних XML-сущностей (XXE – XML External Entities).
• A5 – Нарушение контроля доступа (Broken Access Control).
• A6 – Небезопасная конфигурация (Security Misconfiguration).
• A7 – Межсайтовый скриптинг (XSS – Cross-Site Scripting).
• A8 – Небезопасная десериализация (Insecure Deserialization).
• A9 – Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities).
• A10 – Отсутствие журналирования и мониторинга (Insufficient Logging & Monitoring).

На схеме отражены отличия текущей версии от предыдущей:

Для каждого пункта в OWASP Top 10 представлена общая информация, описание, рекомендации по предотвращению, примеры соответствующих атак и полезные ссылки.

Рейтинг OWASP Top 10 составляется на основе данных, предоставляемых сообществом экспертов отрасли информационной безопасности. В 2017 году рейтинг был обновлен на основе данных, собранных из отчетов 23 компаний, специализирующихся в сфере безопасности веб-приложений, в которых было проанализировано свыше 114 тысяч веб-приложений. В предоставленных данных присутствовали результаты как автоматического, так и ручного анализа, однако автоматический преобладал. При этом данные по 68% от общего числа приложений были предоставлены компанией Veracode, занимающейся автоматическим анализом (статическим и динамическим).

Для оценки рисков использовались две группы факторов: факторы, влияющие на возможности атакующего по обнаружению и эксплуатации уязвимостей, а также факторы, влияющие на критичность последствий эксплуатации уязвимостей. В первую группу входят распространенность (prevalence), сложность обнаружения (detectability) и простота эксплуатации (ease of exploit). Ко второй группе относятся последствия эксплуатации уязвимости (technical impact). Некоторые важные факторы, например, такие как последствия эксплуатации уязвимости для бизнеса (business impact), модели злоумышленников, технические особенности невозможно проанализировать для всех веб-приложений в целом без учета специфики конкретного веб-приложения, поэтому они не рассматривались. Вероятностные характеристики выявлялись на основе предоставленных данных, а возможные последствия оценивались сообществом экспертов. Каждый фактор для конкретной уязвимости получал оценку от 1 до 3, и для получения общей оценки риска среднее арифметическое первой группы факторов умножалось на среднее арифметической второй группы факторов.

Надо отметить, что данный подход к формированию рейтинга и тот факт, что OWASP – компания некоммерческая, все-таки не исключают возможность вмешательства коммерческих интересов. Например, выход в свет OWASP Top 10 2017 RC (предварительная версия рейтинга 2017 года) сопровождался волной возмущения по поводу нового пункта A7 – Недостаточная защита от атак (Insufficient Attack Protection). Спорный пункт был предложен компанией Contrast Security. Один из руководителей этой компании был активным участником проекта OWASP Top 10, что, вероятно, сыграло основную роль в появлении этого «риска» в рейтинге. Даже не дожидаясь выхода окончательной версии рейтинга, Contrast Security начала ссылаться на пункт A7 у себя на сайте, рекламируя свою программу для защиты веб-приложений. В итоговом рейтинге этот пункт был исключен.

OWASP Top 10 используется в Microsoft, PCI DSS (Payment Card Industry Data Security Standard), MITRE (некоммерческая организация, занимающаяся разработками и исследованиями в области системной инженерии при поддержке органов государственной власти США) и множестве других организаций, связанных с безопасностью веб-приложений. Некоторые позиционируют OWASP Top 10 как «лучшую практику защиты веб-приложений», однако такая позиция не совсем верна. Во-первых, рейтинг не покрывает все возможные уязвимости и поэтому не является достаточным источником для полной защиты веб-приложения. Даже в самом документе OWASP, описывающем Top 10, есть призыв: «Не останавливайтесь на 10». Во-вторых, нужно помнить про его ограничения и недостатки: довольно большой период между обновлениями, неуточненная предметная область (для тех приложений, которые используют только новые фреймворки, большая часть рейтинга может быть неактуальна), неполные исходные данные (в основном — полученные компаниями на основе автоматических тестирований).

В настоящее время упоминание OWASP Top 10 часто является скорее маркетинговым ходом, чем реальной гарантией качественной защиты веб-приложений. С другой стороны, этот рейтинг хорош для отсылок благодаря своей широкой известности, может использоваться как стартовая точка и для привлечения внимания к обеспечению безопасности веб-приложений.

С 2011 года OWASP выпускает рейтинг Top 10 Mobile Risks, который обновлялся в 2014 и 2016 годах. В него входят следующие риски:

• M1 – Обход ограничений безопасности платформы (Improper Platform Usage).
• M2 – Небезопасное хранение данных (Insecure Data Storage).
• M3 – Небезопасная передача данных (Insecure Communication).
• M4 – Небезопасная аутентификация (Insecure Authentication).
• M5 – Слабая криптостойкость (Insufficient Cryptography).
• M6 – Небезопасная авторизация (Insecure Authorization).
• M7 – Низкое качество кода в клиентской части приложения (Poor Code Quality).
• M8 – Модификация кода (Code Tampering).
• M9 – Анализ исходного кода (Reverse Engineering).
• M10 – Скрытый функционал (Extraneous Functionality).

Некоторые формулировки в этом списке вызывают недоумение своей неконкретностью. Например, M8 и M9. Почти любое мобильное приложение может быть с тем или иным успехом подвергнуто анализу исходного хода (reverse engineering); почти любое мобильное приложение запускается в окружении, которое автор приложения не контролирует, и поэтому потенциально подвержено модификации кода (code tampering). Эти пункты сложно соотнести с конкретными уязвимостями, а как риски они теряют свою ценность, не будучи проанализированы для конкретного приложения с его спецификой и бизнес-логикой.

Несколько лет назад на стадии разработки находился еще один проект - OWASP Cloud Top 10 Security Risks, однако последняя активность в рамках этого проекта наблюдалась в 2012 году, и в настоящее время он переведен в статус неактивных проектов.

Классификация недостатков CWE

CWE (Common Weakness Enumeration) - общий перечень уязвимостей и недостатков безопасности программного обеспечения (ПО), представляет собой иерархический словарь, предназначенный для разработчиков и специалистов по обеспечению безопасности ПО. CWE поддерживается MITRE по заказу Министерства внутренней безопасности США и развивается при широкой поддержке сообщества экспертов. По словам разработчиков, CWE — это общий язык для описания недостатков безопасности ПО, который необходим для стандартизации методик оценки программных продуктов с точки зрения информационной безопасности.

Ошибки в программном обеспечении, которые могут быть непосредственно использованы злоумышленником для реализации угроз безопасности называют уязвимостями. Ошибки, которые могут привести к возникновению уязвимостей – недостатками безопасности. Примером, иллюстрирующим разницу между этими двумя понятиями, является уязвимость – СVE-2010-2245 (внедрение внешних XML-сущностей в веб-сервисе Apache версии ниже 1.1.1) и недостаток безопасности СWE-611 (неверное ограничение XML-ссылок на внешние объекты), послуживший причиной этой уязвимости. Главное отличие принципов, на которых строятся классификации недостатков от принципов классификации уязвимостей, состоит в том, что особенно важно сохранить связь между недостатками, ведь ошибки ведут к новым ошибкам, например, ошибки проектирования ведут к ошибкам в реализации. Такая связь в CWE воплощена через разные уровни абстракций и обширные иерархические представления, которые будут рассмотрены ниже.

Первая версия CWE 0.1 вышла в 2005 году и стала результатом продолжения работы MITRE над CVE. В настоящее время актуальна версия  3.0. В обновлении перечня участвует большое количество компаний и научных организаций. Обновление происходит посредством широкого обсуждения на официальном форуме и через почтовую рассылку. Важной особенностью CWE является строгая структурированность. Любое изменение – результат объемной работы сообщества, поэтому перечень обновляется относительно редко.

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

1. Концепции разработки – в этом представлении CWE недостатки безопасности классифицируются с использованием принципов и понятий, которые часто встречаются при разработке ПО; представление предназначено в первую очередь для разработчиков и специалистов по оценке качества ПО.
2. Концепции архитектуры – для анализа качества архитектурных решений на этапе проектирования.
3. Концепции исследований – представление, предназначенное для упрощения академических исследований. Отличается от первых двух высоким уровнем абстракций. Основное внимание в этом представлении уделено формальным понятиям поведения программного обеспечения, конкретные же примеры по возможности опускаются.

На схеме ниже приведен граф связей CWE-611 (XXE) в разных представлениях. Полные графы для всех представлений, можно увидеть на официальном сайте проекта (http://cwe.mitre.org/data/pdfs.html).

Кроме основных представлений поддерживается большое количество вспомогательных, например «Разработка на С++» или «Недостатки разработки мобильных приложений». Поскольку CWE претендует на то, чтобы быть наиболее общим перечнем недостатков безопасности, большое внимание при разработке словаря обращается на сопоставление записей CWE с записями других классификаций, перечней, рейтингов. Результатом этого сопоставления являются представления внешних отображений, например, SANS Top 25, OWASP Top 10, Seven Pernicious Kingdoms и т. д. Эти представления переносят структуру других рейтингов и классификаций на CWE для того, чтобы упростить их сравнение и работу с ними.

Запись о недостатке строго структурирована и содержит в себе следующую информацию:

• Название.
• Описание.
• Другие названия.
• Описание поведения.
• Описание и вероятность возможной эксплуатации.
• Описание возможных последствий эксплуатации.
• Способы предотвращения.
• Информация о связях с другими элементами CWE.
• Источники.
• Примеры кода для языков/архитектур.
• Ссылки на актуальные CVE.

CWE 445	Double free (повторное освобождение памяти)
Описание	ПО вызывает free() дважды на одном адресе памяти, что потенциально может привести к непредсказуемому изменению структур, управляющих памятью.
Вероятность эксплуатации	От низкой до средней.
Общие последствия	Контроль доступа: двойное освобождение памяти может привести к условию write-what-where, позволяя злоумышленнику выполнить произвольный код.
Способы предотвращения	Архитектура и дизайн: рекомендуется выбрать язык, обеспечивающий автоматическое управление памятью.
Способы предотвращения	Архитектура и дизайн: рекомендуется выбрать язык, обеспечивающий автоматическое управление памятью. Реализация: рекомендуется убедиться, что каждое выделение памяти освобождается только один раз. После освобождения блока рекомендуется присвоить указателю значение NULL, чтобы обеспечить невозможность повторного освобождения указателя. Если язык является объектно-ориентированным, рекомендуется убедиться, что деструкторы объектов удаляют каждый фрагмент памяти только один раз. Реализация: рекомендуется использовать инструмент статического анализа для поиска двойных освобождений памяти.
Примеры	Пример кода на языке С++: char* ptr = (char*)malloc (SIZE); ... if (abrt) { free(ptr); } ... free(ptr);
Ссылки на актуальные CVE	CVE-2002-0059 CVE-2003-0545 CVE-2003-1048 CVE-2004-0642 CVE-2004-0772 CVE-2005-1689
Информация о связях с другими элементами CWE	Предшествующие: CWE-666, СWE-675 в представлении CWE-1000 CWE-339 в представлении CWE-699 CWE-398 в представлении CWE-700 CWE-633 в представлении CWE-631 CWE-742 в представлении CWE-734 Связанные: CWE-364, CWE- 416, CWE-123
Подверженные платформы	C/C++
Источники	PLOVER - DFREE - Double-Free Vulnerability7 Pernicious Kingdoms - Double Free CLASP - Doubly freeing memory CERT C Secure Coding - MEM00-C - Allocate and free memory in the same module, at the same level of abstraction CERT C Secure Coding - MEM01-C - Store a new value in pointers immediately after free() CERT C Secure Coding - MEM31-C - Free dynamically allocated memory exactly once CERT C Secure Coding - MEM00-C - Allocate and free memory in the same module, at the same level of abstraction CERT C Secure Coding - MEM01-C - Store a new value in pointers immediately after free() CERT C Secure Coding - MEM31-C - Free dynamically allocated memory exactly once

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

1. Возможность поиска и группировки срабатываний средства по идентификаторам CWE.
2. Срабатывания средства включают или позволяют получить соответствующие им элементы CWE.
3. Срабатывания средства однозначно отображаются на элементы CWE.
4. В документации средства и в описании срабатываний используются описания из CWE.
5. В документации средства и в описании срабатываний явным образом перечислены идентификаторы из CWE.
6. Результаты тестирования размещены на сайте CWE.

Если продукт соответствует всем шести требованиям он считается CWE-совместимым.

Классификация шаблонов компьютерных атак CAPEC

В ходе развития CWE, появилась еще одна классификация, схожая с CWE по структуре – CAPEC (Common Attack Pattern Enumeration and Classification). Объектом систематизации в ней являются шаблоны атак, то есть, описания общих элементов и методов, используемых при атаках на уязвимые компоненты. Расширение перечня происходит аналогично CWE через обсуждение на официальном форуме и почтовую рассылку.

В CAPEC используется сходный с CWE иерархический подход. Разработано два основных представления (механизмы атак и объекты атак) и несколько вспомогательных. В представлении «механизмы атак» шаблоны иерархически упорядочены в соответствии с механизмами, которые часто используются при эксплуатации уязвимостей. Категории, например «внедрение непредвиденных элементов», в этом представлении отражают различные методы, используемые для атаки на систему, но не отображают целей и последствий. В представлении «объекты атак» категории содержат описание компонентов, на которые производится атака, например «передача данных».

На схеме ниже приведен граф связей CAPEC-112 в разных представлениях.

Запись о шаблоне атак в CAPEC включает описание механизмов эксплуатации уязвимости, возможные последствия и методы противодействия. Кроме того, запись ссылается на используемые в шаблоне уязвимости в CVE и на приводящие к ним недостатки из CWE.

CAPEC-34	HTTP Response Splitting
Название	Разделение HTTP-ответов.
Критичность	Высокая.
Описание	Разделение HTTP-ответов приводит к тому, что уязвимый веб-сервер отвечает на вредоносный запрос, отправляя клиенту HTTP-ответ таким образом, что он интерпретируется в браузере как два отдельных ответа вместо одного. Это возможно, когда контролируемый пользователем ввод используется в составе заголовков ответов. Злоумышленник может заставить жертву интерпретировать введенный Заголовок как ответ на второй фиктивный запрос, в результате чего созданное содержимое будет отображаться клиентом и, возможно, кэшироваться на промежуточных прокси-серверах или самом клиенте. Чтобы добиться разделения HTTP-ответа на уязвимом веб-сервере, злоумышленник: Находит такие данные для ввода, которые приводят к произвольному внедрению HTTP-заголовка. Производит вредоносный ввод, состоящий из данных, необходимых для того, чтобы завершить исходный ответ (например, \r\n\r\n) и начать второй ответ с заголовками, контролируемыми злоумышленником. Вынуждает жертву отправить на уязвимый сервер два HTTP-запроса. Первый запрос состоит из вредоносного ввода, который будет использоваться как часть заголовков HTTP-ответов, а второй является фиктивным запросом, чтобы жертва интерпретировала вторую часть разделенного ответа как принадлежащую второму HTTP-запросу.
Необходимые предпосылки атаки	Пользователь может контролировать входные данные, которые могут использоваться как часть HTTP-заголовка. Возможность злоумышленника внедрять произвольные строки в HTTP-заголовок. Недостаточные проверки входных данных.
Вероятность эксплуатации	Средняя.
Метод атаки	Внедрение, манипуляция протоколом.
Примеры сценария	Уязвимость CVE-2006-0207.
Компетенции злоумышленника	Высокие, злоумышленник должен иметь глубокое понимание протокола HTTP.
Необходимые злоумышленнику ресурсы	Нет.
Признаки атаки	Единственный признак – несколько ответов на один запрос в логах, однако это сложно заметить без анализатора журнала.
Способ предотвращения	Чтобы избежать разделения HTTP-ответов, приложение не должно доверять вводу пользователя при формировании выходного потока ответов (заголовков или тела). Разделение ответов происходит за счет внедрения последовательностей CR-LF и дополнительных заголовков. Все данные, поступающие от пользователя и используемые в качестве части заголовков HTTP-ответов, должны подвергаться строгой проверке (валидации).
Цель и последствия	Исполнение несанкционированного кода или команд. Вытекающие последствия – повышение привилегий.
Описание контекста	Атаки разделения HTTP-ответа происходят там, где сценарий сервера внедряет управляемые пользователем данные в заголовки HTTP-ответа. Обычно это происходит, когда скрипт встраивает такие данные в URL-адрес перенаправления в ответ перенаправления (код статуса HTTP 3хх), или когда сценарий включает такие данные в cookie ответа.
Вектор атаки	Управляемый пользователем ввод, который является частью выходных заголовков HTTP-ответов.
Атакующая строка	Закодированный HTTP-заголовок и данные, разделенные соответствующими последовательностями CR-LF. Вводимые данные должны состоять из корректных HTTP-заголовков, а также скрипта (обычно JavaScript), который будет включен в текст HTML.
Зона активации	Вызовы API в приложении, которые формируют выходные заголовки HTTP-ответов.
Связанные недостатки	CWE-113, CWE-74, CWE-697, CWE-707, CWE-713.

Проекты CWE и CAPEC представляют собой иерархические классификации и используются в первую очередь именно в таком качестве. Они предоставляют способ формального описания явлений информационной безопасности для использования в качестве общепринятого языка. Основной акцент сделан на общеупотребимость, поэтому MITRE привлекает к разработке специалистов как из научной среды, так и из промышленности. Эти проекты служат важным инструментом для конструктивного взаимодействия в области информационной безопасности.

Классификация угроз WASC Threat Classification

Рассматривая классификации угроз безопасности, нельзя не упомянуть проект WASC Threat Classification. WASC (The Web Application Security Consortium) — это некоммерческая организация, которая ранее активно занималась разработкой и продвижением стандартов безопасности приложений. В настоящий момент организация не проявляет активности. Некоторые члены WASC участвовали также и в разработке проектов OWASP.

В WASC Threat Classification (далее – TC) описываются недостатки и классы атак, которые могут привести к компрометации веб-приложения, его данных или пользователей. Первая версия классификации появилась в 2004 году, вторая — в 2010-м, и на данный момент она остается последней. Атаки и недостатки в проекте сформированы в два представления: первое — это обычное перечисление, а второе — это распределение по трем фазам разработки (проектирование, реализация, внедрение). Всего в перечнях описано 34 типа атаки и 15 типов недостатков. Для каждой сущности приводится описание, примеры и полезные ссылки.

Классификация разрабатывалась большой группой экспертов по веб-безопасности на добровольной основе: в разработке второй версии приняло участие более 50 экспертов. Обсуждение содержания проекта, все предложения и замечания обсуждались посредством почтовой рассылки. Так, каждый раздел составлялся и обсуждался неделями, обеспечивая итоговый консенсус среди участников проекта. Неясно как с методической точки зрения участниками обеспечивалась полнота и непротиворечивость разрабатываемой классификации, кроме как умозрительное экспертное согласие с разработанными документами. Архив email-переписки доступен на сайте по адресу http://lists.webappsec.org/mailman/listinfo/wasc-threat_lists.webappsec.org.

Интересная деталь: в материалах второй версии WASC TC упоминалось, что авторы предполагают отдохнуть несколько месяцев и продолжить работать над проектом в том же 2010 году. На сайте проекта даже существует раздел с планами на будущее, где среди прочего есть недостающие пункты, которые предлагается добавить в классификацию. К сожалению, по необнародованным причинам раздел после этого не обновлялся, а следующая версия классификации так и не вышла. Таким образом, данный проект не рассматривается как завершенный самими авторами.

В первую очередь WASC TC предлагается использовать как справочное руководство. Ссылки на эту классификацию встречаются в книгах, презентациях, отчетах, описаниях уязвимостей и т. п. Проект можно использовать в процессе оценки безопасности веб-приложения как контрольный список или план тестирования, а также как систему для сбора метрик обнаруживаемых в приложении недостатков и уязвимостей. Однако стоит учитывать, что область безопасности веб-приложений активно развивается, а WASC Threat Classification не обновлялся с 2010 года.

При сравнении WASC TC с CWE и CAPEC, другими известными перечнями недостатков и атак, можно отметить несколько основных отличий. Во-первых, CWE/CAPEC — это более общие и фундаментальные проекты, которые больше подходят для академических целей и формализации, в то время как WASC TC удобнее и проще для «повседневного» использования. Во-вторых, CWE/CAPEC охватывают не только веб-приложения. Наконец, эти проекты продолжают развиваться и обновляться, а WASC TC так и остался незавершенным.

Авторы:
Николай Калинин, разработчик систем безопасности, ООО "СолидСофт",
Валерия Шерварлы, разработчик систем безопасности, ООО "СолидСофт",
Андрей Петухов, м.н.с. кафедры информационной безопасности ВМК МГУ.