Это первая статья из серии переводов стандарта Application Security Verification Standard 4.0, который был разработан OWASP в 2019 году. Стандарт состоит из 14 групп требований для программного обеспечения. Первая группа (V1) содержит в себе требования к архитектуре и моделированию угроз для основных функций ПО, таких как, аутентификация, управления сеансами, контроль доступа и др. Последующие группы расширяют список требований для каждой из функций.

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

Стандарт проверки безопасности приложений (Application Security Verification Standard – ASVS 4.0)

1. О стандарте

ASVS – это список требований или тестов для проверки безопасности приложений, которым могут воспользоваться архитекторы, разработчики, тестировщики, специалисты по безопасности, поставщики ПО и заказчики для проверки, создания, тестирования и проверки безопасности приложений.

1.1 Использование ASVS

ASVS преследует две основные цели:

- помочь организациям разрабатывать и поддерживать безопасные приложения;

- позволить заказчикам и поставщикам средств и услуг в области информационной безопасности согласовывать свои требования и предложения.

1.2 Уровни проверки безопасности приложений

Стандарт проверки безопасности приложений определяет три уровня проверки безопасности, каждый из которых дополняет требования предыдущего уровня.

- Уровень 1 предназначен для низкого уровня доверия и может быть полностью протестирован только с помощью тестов на проникновение.

- Уровень 2 предназначен для приложений, содержащих конфиденциальные данные, которые требуют защиты и является рекомендуемым уровнем для большинства приложений.

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

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

Уровень 1 – единственный уровень, который может полностью тестироваться на проникновение в ручном режиме. Все остальные требуют доступа к документации, исходному коду, конфигурации и взаимодействия с людьми, участвующими в процессе разработки. Уровень 1 позволяет проводить тестирование методом «чёрного ящика» (без документации и исходного кода), однако такой способ не является надёжным, поэтому лучше от него отказаться. Защищаемой стороне необходимо встраивать меры безопасности, находить и устранять все слабые места, а также обнаруживать попытки взлома и реагировать на них в разумные сроки. У злоумышленников практически неограниченные ресурсы, а для достижения успеха требуется всего лишь одна брешь в защите, одна слабость или отсутствие обнаружения. Тестирование «чёрного ящика», которое часто наскоро проводится в конце разработки, либо не выполняется вообще, не может справиться с такой асимметрией.

За последние 30 с лишним лет тестирование методом «чёрного ящика» снова и снова доказывало, что упускает из виду критические проблемы безопасности, которые напрямую вели к более серьёзным последствиям. Авторы стандарта настоятельно рекомендуют использовать весь спектр средств обеспечения и проверки безопасности, включая замену тестов на проникновение методом «чёрного ящика» полным доступом к коду, документации и разработчикам на протяжении всего процесса создания. Например, финансовые регулирующие органы не допускают внешний финансовый аудит без доступа к бухгалтерским книгам, образцам операций или людям, осуществляющим контроль. Промышленность и правительства должны требовать одинаковых стандартов прозрачности в области разработки программного обеспечения.

Авторы стандарта настоятельно рекомендуют использовать инструменты безопасности в самом процессе разработки, такие как инструменты DAST (Dynamic Application Security Testing) и SAST (Static Application Security Testing), которые должны непрерывно использоваться при сборке приложений, чтобы легко находить типовые проблемы безопасности.

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

1.3 Как пользоваться стандартом

Один из лучших способов использования стандарта – применять его в качестве образца для создания чек-листов безопасного программирования для вашего приложения, платформы или организации. Адаптация ASVS к вашим вариантам использования позволит сосредоточить внимание на требованиях безопасности, которые наиболее важны для ваших проектов и сред.

Уровень 1 - Начальный, автоматизированный или полный профиль (First steps, automated, or whole of portfolio view)

Приложение достигает Уровня 1 ASVS, если оно адекватно защищено от уязвимостей, которые легко обнаружить и которые включены в OWASP Top 10 или другие чек-листы, например, списки самых распространённых CVE (Common Vulnerabilities and Exposures) или CWE (Common Weakness Enumeration).

Уровень 1 – это минимум, к которому должны стремиться все приложения. На Уровень 1 также полезно ориентироваться при проведении первых этапов работ по созданию приложений или, когда приложения не хранят и не обрабатывают конфиденциальные данные, следовательно, не нуждаются в более строгих элементах контроля Уровней 2 или 3. Элементы управления Уровня 1 могут быть проверены либо автоматически с помощью инструментов, либо просто вручную без доступа к исходному коду. Авторы считают Уровень 1 минимальным уровнем, необходимым для всех приложений.

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

Уровень 2 – Большинство приложений

Приложение достигает Уровня 2 ASVS, если оно адекватно защищено от большинства актуальных рисков, связанных с программным обеспечением.

Уровень 2 гарантирует, что в приложении используются эффективные меры безопасности. Уровень 2 обычно подходит для приложений, которые обрабатывают важные B2B-транзакции, обрабатывают медицинскую информацию, реализуют критически важные для бизнеса функции или обрабатывают другие конфиденциальные активы. Также он подходит для отраслей, где целостность является критическим аспектом для защиты их бизнеса, например, в игровой индустрии, чтобы противостоять читерам и взломам игр.

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

Уровень 3 - Большая ценность, высокая надёжность или высокий уровень безопасности

Уровень 3 – это самый высокий уровень проверки в рамках ASVS. Этот уровень обычно предназначается для приложений, требующих значительного уровня проверки безопасности, например, тех, которые могут быть использованы в областях вооружённых сил, здравоохранения и безопасности, критической инфраструктуры и т.д.

Организациям может потребоваться Уровень 3 для приложений, выполняющих критически важные функции, отказ которых может существенно повлиять на работу организации и даже на существование организации в целом. Приложение достигает 3-го уровня ASVS, если оно адекватно защищает от расширенного списка уязвимостей, а также демонстрирует принципы хорошего проектирования с точки зрения безопасности.

Приложение на Уровне 3 ASVS требует более глубокого анализа или более продуманной архитектуры, кодирования и тестирования, чем все остальные уровни. Безопасное приложение имеет конструктивную модульную структуру (для обеспечения отказоустойчивости, масштабируемости и, прежде всего, уровней безопасности), и каждый модуль (разделённый сетевым подключением и/или находящийся на другом физическом экземпляре) выполняет свои собственные обязанности по безопасности, которые необходимо надлежащим образом задокументировать. Обязанности по обеспечению безопасности включают в себя средства управления для обеспечения конфиденциальности (например, шифрование), целостности (например, транзакции, проверка ввода), доступности (например, корректная обработка нагрузки), аутентификации (в том числе между системами), неотказуемости, авторизации и аудита (журналирование).

1.4 Применение ASVS на практике

В некоторых отраслях есть уникальные информационные и технологические активы, а также нормативные требования для конкретных областей. Организациям настоятельно рекомендуется внимательно изучить свои уникальные характеристики риска в зависимости от характера их бизнеса и на основе этого риска и бизнес-требований определить соответствующий уровень ASVS.

2. Оценка и сертификация

2.1 Позиция OWASP в отношении сертификации ASVS и знаков доверия

OWASP, как некоммерческая организация, не зависящая от поставщиков, в настоящее время не сертифицирует поставщиков, верификаторов или программное обеспечение.

Все заверения, знаки доверия или сертификаты не проходят официальную проверку, регистрацию или сертификацию OWASP. Поэтому необходимо с осторожностью относиться к доверию, оказываемому какой-либо третьей стороне или знаку доверия, заявляющему о сертификации ASVS.

Это не должно препятствовать организациям предлагать такие услуги по обеспечению гарантий до тех пор, пока они не заявляют об официальной сертификации OWASP.

2.2 Руководство для сертифицирующих организаций

Стандарт проверки безопасности приложений может использоваться в качестве инструкции для проверки приложения, включая полный и неограниченный доступ к ключевым ресурсам, таким как архитекторы и разработчики, проектная документация, исходный код, аутентифицированный доступ к тестовым системам (включая доступ к одной или нескольким учётным записям каждой роли), особенно для проверок Уровня 2 и 3.

Исторически сложилось так, что при тестировании на проникновение и анализа безопасности кода в окончательном отчёте указывались только тесты, которые были провалены. Сертифицирующая организация должна включать в любой отчёт объем проверки (особенно, если ключевой компонент выходит за рамки, например, SSOauthentication), сводку результатов проверки, включая удавшиеся и неудавшиеся тесты, с чёткими указаниями о том, как устранить причины провала теста.

Некоторые требования проверки могут быть неприменимы к тестируемому приложению. Например, если вы предоставляете своим клиентам API-сервис без сохранения состояния и без реализации клиента, многие требования по управлению сессиями (V3 Session Management) не применимы напрямую. В таких случаях сертифицирующая организация может по-прежнему требовать полного соответствия ASVS, но должна чётко указать в отчёте причину неприменимости исключённых требований.

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

2.3 Метод тестирования

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

Роль автоматизированных средств тестирования безопасности

Рекомендуется использовать автоматизированные инструменты тестирования на проникновение для обеспечения максимально возможного покрытия. Невозможно полностью завершить проверку ASVS с использованием только автоматизированных инструментов тестирования на проникновение. Хотя подавляющее большинство требований Уровня 1 можно выполнить с помощью автоматических тестов, в целом большинство требований не проверяются автоматическим тестированием на проникновение. Обратите внимание, что границы между автоматическим и ручным тестированием стираются по мере развития индустрии безопасности. Автоматизированные инструменты часто настраиваются вручную экспертами, и при ручном тестировании часто используется широкий спектр автоматизированных инструментов.

Роль тестирования на проникновение

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

При выполнении оценки Уровня 2 или 3 требуется взаимодействие с разработчиками, доступ к документации, коду и тестовому приложение с не конфиденциальными данными. Тестирование на проникновение, проводимое на этих уровнях, требует такого уровня доступа, который обычно называется «гибридные проверки» или «гибридные тесты на проникновение».

3. Другое использование ASVS

Помимо использования для оценки безопасности приложения, существует ряд других потенциальных применений ASVS.

Как подробное руководство по архитектуре безопасности

Одно из наиболее распространённых применений стандарта проверки безопасности приложений - это ресурс для архитекторов безопасности. В Sherwood Applied Business Security Architecture (SABSA) отсутствует большой пласт инструкций, необходимый для проведения тщательного анализа архитектуры безопасности приложений. ASVS можно использовать для заполнения этих пробелов, позволяя специалистам выбирать лучшие средства мониторинга распространённых проблем, таких как шаблоны защиты данных и стратегии проверки ввода.

В качестве замены готовых контрольных списков безопасного программирования

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

В качестве руководства для автоматизированных модульных и интеграционных тестов

ASVS разработан для обеспечения высокого качества тестирования. Создавая модульные и интеграционные тесты, которые проверяют конкретные и релевантные случаи неувязок и завышенных полномочий, разработчики делают приложение почти самопроверяющимся при каждой сборке. Например, для набора тестирования входа в систему могут быть созданы дополнительные модули, проверяющие имя пользователя на предмет совпадения со списками распространённых имён по умолчанию, нумерации аккаунтов, брутфорс, внедрение XSS, LDAP- и SQL-инъекций. Точно так же проверка параметров пароля должна включать словарные пароли, длину пароля, инъекцию нулевого байта, удаление параметра, XSS и многое другое.

Для обучения безопасной разработке

ASVS также можно использовать для определения характеристик защищённого программного обеспечения. Многие курсы «безопасной разработки» - это просто курсы этичного хакинга с небольшим количеством советов по программированию. Нет гарантии, что такие курсы помогут разработчикам писать более безопасный код. Вместо этого можно использовать ASVS, уделяя особое внимание проактивным элементам защиты, а не Топ-10 самых распространённых ошибок.

Как основа для Agile-методов разработки приложений

ASVS можно использовать в процессе Agile разработки в качестве базы для определения конкретных задач, которые должны быть реализованы командой, чтобы получить безопасный продукт. Один из подходов может быть следующим: начиная с уровня 1, проверьте конкретное приложение или систему в соответствии с требованиями ASVS для указанного уровня, найдите, какие элементы отсутствуют, и создайте определённые задачи в следующий спринт. Это помогает расставить приоритеты для конкретных задач и делает безопасность видимой в Agile-процессе. Это также можно использовать для ранжирования задач аудита и проверки в организации, где конкретное требование ASVS может быть основой для проверки, рефакторинга или аудита для конкретного члена команды и отображаться как «задолженность», которую необходимо в конечном итоге выполнить.

Как основа для руководства закупкой безопасного ПО

ASVS - отличный фреймворк, помогающий обеспечить безопасность закупок программного обеспечения или заказных услуг по разработке. Заказчик может просто установить требование о том, что программное обеспечение, которое он хочет приобрести, должно соответствовать Уровню X ASVS, и запросить у продавца подтверждение этого. Это хорошо работает в сочетании с OWASP Приложением к контракту на обеспечение безопасности.

Далее следует содержательная часть стандарта. В этой части статьи будет приведена только первая группа требований.

4. V1: Требования к архитектуре, дизайну и моделированию угроз

Сфера безопасности приложений должна догнать и принять гибкие принципы безопасности, вновь знакомя специалистов-практиков с ведущими принципами безопасной архитектур. Архитектура - это не реализация, а способ размышления о проблеме, на которую может быть много разных ответов, и нет единственного «правильного». Слишком часто безопасность рассматривается как негибкая и требующая от разработчиков исправления кода определённым образом, тогда как разработчики могут знать намного лучший способ решения проблемы. Не существует единого простого решения для архитектуры, и неправильно делать вид, что это не так.

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

Если бы разработчики вложили средства в единую безопасную модель поставщика учётных записей, такую как SAML, поставщик мог бы быть обновлён с учётом новых требований, таких как соответствие NIST 800-63, без изменения интерфейсов исходного приложения. Если многие приложения используют одну и ту же архитектуру безопасности и, следовательно, один и тот же компонент, все они получают выгоду от этого обновления. Однако SAML не всегда будет лучшим или наиболее подходящим решением для аутентификации – его, возможно, придётся заменить другими решениями по мере изменения требований. Подобные изменения либо сложны и настолько дороги, что потребуют полного переписывания кода, либо вообще не будут возможны без внедрения безопасной архитектуры.

В этой главе ASVS охватывает основные аспекты любой надёжной архитектуры безопасности: доступность, конфиденциальность, целостность обработки, невозможность отказа от авторства и конфиденциальность. Каждый из этих принципов безопасности должен быть встроен во все приложения. Очень важно проводить Shift-left тестирование, начиная с предоставления разработчикам контрольных списков безопасного кодирования, наставничества и обучения, программирования и тестирования, построения, развёртывания и конфигурирования, заканчивая последующим независимым тестированием, чтобы гарантировать, что все меры безопасности присутствуют и функционируют. Раньше индустрия тестирования занималась только последним шагом, но этого уже недостаточно, когда разработчики публикуют код в production десятки или сотни раз в день. Специалисты по безопасности приложений должны не отставать от Agile-методов, что означает внедрение инструментов разработчика, обучение программированию и работу с разработчиками, а не критику проекта через несколько месяцев после того, как все остальные ушли.

Требования к жизненному циклу безопасной разработки программного обеспечения

Таблица 1 – V1.1 Требования к жизненному циклу безопасной разработки программного обеспечения

V1.2 Требования к архитектуре аутентификации

При разработке аутентификации не имеет значения, есть ли у вас мощная аппаратная многофакторная аутентификация, если злоумышленник может сбросить учётную запись, позвонив в центр обработки вызовов и ответив на широко известные вопросы. При проверке личности все пути аутентификации должны иметь одинаковую силу.

Таблица 2 – V1.2 Требования к архитектуре аутентификации

V1.3 Требования к архитектуре управления сеансами

Требования к архитектуре управления сеансами появятся в будущих версиях.

V1.4 Требования к архитектуре контроля доступа

Таблица 3 – V1.4 Требования к архитектуре контроля доступа

V1.5 Требования к архитектуре ввода и вывода

В версии 4.0 больше нет термина «серверная сторона» в качестве термина для определения границ доверия. Граница доверия по-прежнему актуальна – принятие решений о ненадёжных браузерах или клиентских устройствах можно обойти. Однако сейчас точка зрения на обеспечение доверия резко изменилась. Поэтому, когда в ASVS используется термин «уровень доверенного сервиса», имеется в виду любая надёжная точка принудительного применения, независимо от местоположения, такая как микросервис, бессерверный API, серверная сторона, доверенный API на клиентском устройстве с безопасной загрузкой, партнёрские или внешние API и т. д.

Таблица 4 – V1.5 Требования к архитектуре ввода и вывода

V1.6 Требования к архитектуре криптографической защиты

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

Таблица 5 – V1.6 Требования к архитектуре криптографической защиты

V1.7 Ошибки, ведение журнала и требования к архитектуре аудита

Таблица 6 – V1.7 Ошибки, ведение журнала и требования к архитектуре аудита

V1.8 Требования к архитектуре защиты данных и конфиденциальности

Таблица 7 – V1.8 Требования к архитектуре защиты данных и конфиденциальности

V1.9 Требования к архитектуре связи

Таблица 8 – V1.9 Требования к архитектуре связи

V1.10 Требования к архитектуре вредоносного ПО

Таблица 9 – V1.10 Требования к архитектуре вредоносного ПО

V1.11 Требования к архитектуре бизнес-логики

Таблица 10 – V1.11 Требования к архитектуре бизнес-логики

V1.12 Требования к архитектуре безопасной загрузки файлов

Таблица 11 – V1.12 Требования к архитектуре безопасной загрузки файлов

V1.13 Требования к архитектуре API

Требования к архитектуре API появятся в будущих версиях.

V1.14 Требования к архитектуре конфигурации

Таблица 12 – V1.14 Требования к архитектуре конфигурации

Ссылки

Для получения дополнительной информации см. также:

-     OWASP Threat Modeling Cheat Sheet;

-     OWASP Attack Surface Analysis Cheat Sheet;

-     OWASP Threat modeling;

-     OWASP Secure SDLC Cheat Sheet;

-     Microsoft SDL;

-     NIST SP 800-57.