Это первая статья из серии переводов стандарта 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 Требования к жизненному циклу безопасной разработки программного обеспечения
№ | Описание | У1 | У2 | У3 | CWE |
1.1.1 | Безопасность внедрена во все этапы жизненного цикла разработки безопасного ПО. |
| + | + |
|
1.1.2 | Моделирования угроз для каждого изменения дизайна или планирование спринта для выявления угроз, планирование контрмер, содействие надлежащему реагированию на риски и проведение тестирования безопасности. |
| + | + | 1053 |
1.1.3 | Все пользовательские истории и функции содержат ограничения функциональной безопасности, такие как «Как пользователь, я должен иметь возможность просматривать и редактировать свой профиль. Я не должен иметь возможность просматривать или редактировать чужой профиль». |
| + | + | 1110 |
1.1.4 | Проверка документации и обоснование всех границ доверия приложения, компонентов и значительных потоков данных. |
| + | + | 1059 |
1.1.5 | Анализ безопасности высокоуровневой архитектуры приложения и всех подключённых удалённых служб. |
| + | + | 1059 |
1.1.6 | Реализации централизованных, простых, проверенных, безопасных и переиспользуемых средств контроля безопасности, чтобы избежать дублирования, отсутствия, неэффективности или небезопасности средств контроля. |
| + | + | 637 |
1.1.7 | Доступность контрольного списка безопасного программирования, требований безопасности, рекомендаций или политики для всех разработчиков и тестировщиков. |
| + | + | 637 |
V1.2 Требования к архитектуре аутентификации
При разработке аутентификации не имеет значения, есть ли у вас мощная аппаратная многофакторная аутентификация, если злоумышленник может сбросить учётную запись, позвонив в центр обработки вызовов и ответив на широко известные вопросы. При проверке личности все пути аутентификации должны иметь одинаковую силу.
Таблица 2 – V1.2 Требования к архитектуре аутентификации
№ | Описание | У1 | У2 | У3 | CWE |
1.2.1 | Для всех компонентов приложений, служб и серверов используются уникальные или специальные учётные записи операционной системы с низким уровнем привилегий. |
| + | + | 250 |
1.2.2 | Связь между компонентами приложения, включая API-интерфейсы, промежуточное ПО и уровни данных, аутентифицирована. Компоненты должны иметь минимально необходимые привилегии. |
| + | + | 306 |
1.2.3 | Приложение использует единый проверенный механизм аутентификации, который заведомо безопасен, может быть расширен за счёт включения строгой аутентификации и имеет достаточное журналирование и мониторинг для обнаружения злоупотребления аккаунтом или взлома. |
| + | + | 306 |
1.2.4 | Все пути аутентификации и API-интерфейсы управления идентификацией реализуют согласованную силу контроля безопасности аутентификации, таким образом, что нет более слабых альтернатив в зависимости от риска приложения. |
| + | + | 306 |
V1.3 Требования к архитектуре управления сеансами
Требования к архитектуре управления сеансами появятся в будущих версиях.
V1.4 Требования к архитектуре контроля доступа
Таблица 3 – V1.4 Требования к архитектуре контроля доступа
№ | Описание | У1 | У2 | У3 | CWE |
1.4.1 | Доверенные точки принудительного применения, такие как шлюзы управления доступом, серверы и бессерверные функции, обеспечивают контроль доступа. Никогда не применяйте контроль доступа на клиенте. |
| + | + | 602 |
1.4.2 | Убедитесь, что выбранное решение для контроля доступа достаточно гибкое, чтобы соответствовать потребностям приложения. |
| + | + | 284 |
1.4.3 | Проверьте соблюдение принципа наименьших привилегий в функциях, файлах данных, URL-адресах, контроллерах, службах и других ресурсах. Это подразумевает защиту от спуфинга и повышения привилегий. |
| + | + | 272 |
1.4.4 | Приложение использует единый и проверенный механизм контроля доступа для доступа к защищённым данным и ресурсам. Все запросы должны проходить через этот единый механизм, чтобы избежать копирования и вставки или небезопасных альтернативных путей. |
| + | + | 284 |
1.4.5 | Используется управление доступом на основе атрибутов или функций, при котором код проверяет авторизацию пользователя для функции/элемента данных, а не только его роль. Разрешения по-прежнему следует распределять с помощью ролей. |
| + | + | 275 |
V1.5 Требования к архитектуре ввода и вывода
В версии 4.0 больше нет термина «серверная сторона» в качестве термина для определения границ доверия. Граница доверия по-прежнему актуальна – принятие решений о ненадёжных браузерах или клиентских устройствах можно обойти. Однако сейчас точка зрения на обеспечение доверия резко изменилась. Поэтому, когда в ASVS используется термин «уровень доверенного сервиса», имеется в виду любая надёжная точка принудительного применения, независимо от местоположения, такая как микросервис, бессерверный API, серверная сторона, доверенный API на клиентском устройстве с безопасной загрузкой, партнёрские или внешние API и т. д.
Таблица 4 – V1.5 Требования к архитектуре ввода и вывода
№ | Описание | У1 | У2 | У3 | CWE |
1.5.1 | Требования по вводу и выводу чётко определяют, как обрабатывать данные в зависимости от типа, содержания, а также применимых законов, нормативных актов и соответствия другим политикам. |
| + | + | 1029 |
1.5.2 | Убедитесь, что сериализация не используется при взаимодействии с ненадёжными клиентами. Если это невозможно, убедитесь, что применяются соответствующие меры контроля целостности (возможно, шифрование при отправке конфиденциальных данных), чтобы предотвратить атаки десериализации, включая внедрение объекта. |
| + | + | 502 |
1.5.3 | Проверка ввода выполняется на уровне доверенных служб. |
| + | + | 602 |
1.5.4 | Кодировка выходных данных происходит рядом с интерпретатором, для которого оно предназначено или им самим. |
| + | + | 116 |
V1.6 Требования к архитектуре криптографической защиты
Приложения должны разрабатываться с использованием надёжной криптографической архитектуры для защиты активов данных в соответствии с их классификацией. Шифрование всех данных ресурсозатратно, отсутствие шифрования – халатность с юридической точки зрения. Разработка архитектуры криптографической защиты в процессе разработки или её перед неизбежно будут стоить гораздо дороже для безопасной реализации, чем её установка с самого начала.
Таблица 5 – V1.6 Требования к архитектуре криптографической защиты
№ | Описание | У1 | У2 | У3 | CWE |
1.6.1 | Существует явная политика для управления криптографическими ключами и что жизненный цикл криптографического ключа соответствует стандарту управления ключами, например, NIST SP 800-57. |
| + | + | 320 |
1.6.2 | Убедитесь, что потребители криптографических услуг защищают ключевой материал и другие секреты, используя хранилища ключей или альтернативы на основе API. |
| + | + | 320 |
1.6.3 | Все ключи и пароли заменимы и являются частью чётко определённого процесса повторного шифрования конфиденциальных данных. |
| + | + | 320 |
1.6.4 | Убедитесь, что симметричные ключи, пароли или секреты API, сгенерированные клиентами или совместно используемые с ними, используются только для защиты секретов с низким уровнем риска, таких как шифрование локального хранилища, или временного использования, такого как обфускация параметров. Обмен секретами с клиентами эквивалентен открытому тексту и с архитектурной точки зрения должен рассматриваться как таковой. |
| + | + | 320 |
V1.7 Ошибки, ведение журнала и требования к архитектуре аудита
Таблица 6 – V1.7 Ошибки, ведение журнала и требования к архитектуре аудита
№ | Описание | У1 | У2 | У3 | CWE |
1.7.1 | В системе должен использоваться общий формат и подход к ведению журнала. |
| + | + | 1009 |
1.7.2 | Журналы безопасно передаются в систему (желательно удалённую) для анализа, обнаружения аномалий, оповещения и эскалации. |
| + | + |
|
V1.8 Требования к архитектуре защиты данных и конфиденциальности
Таблица 7 – V1.8 Требования к архитектуре защиты данных и конфиденциальности
№ | Описание | У1 | У2 | У3 | CWE |
1.8.1 | Все конфиденциальные данные идентифицированы и классифицированы по уровням защиты. |
| + | + |
|
1.8.2 | Все уровни защиты имеют связанный набор требований защиты, таких как требования к шифрованию, требования целостности, хранения, конфиденциальности и другие требования, и они применяются в архитектуре. |
| + | + |
|
V1.9 Требования к архитектуре связи
Таблица 8 – V1.9 Требования к архитектуре связи
№ | Описание | У1 | У2 | У3 | CWE |
1.9.1 | Приложение шифрует обмен данными между компонентами, особенно когда эти компоненты находятся в разных контейнерах, системах, сайтах или облачных провайдерах. |
| + | + | 319 |
1.9.2 | Компоненты приложения проверяют подлинность каждой стороны канала связи, чтобы предотвратить атаки типа «человек в середине». Например, компоненты приложения должны проверять сертификаты и цепочки TLS. |
| + | + | 295 |
V1.10 Требования к архитектуре вредоносного ПО
Таблица 9 – V1.10 Требования к архитектуре вредоносного ПО
№ | Описание | У1 | У2 | У3 | CWE |
1.10.1 | Используется система контроля исходного кода, с процедурами, гарантирующая, что проверки сопровождаются отчётами о неисправностях или заявками на изменение. Система управления исходным кодом должна иметь контроль доступа и опознаваемых пользователей, чтобы можно было отслеживать любые изменения. |
| + | + | 284 |
V1.11 Требования к архитектуре бизнес-логики
Таблица 10 – V1.11 Требования к архитектуре бизнес-логики
№ | Описание | У1 | У2 | У3 | CWE |
1.11.1 | Проверьте определение и документирование всех компонентов приложения с точки зрения бизнес-функций или функций безопасности, которые они предоставляют. |
| + | + | 1059 |
1.11.2 | Все важные потоки бизнес-логики, включая аутентификацию, управление сеансами и контроль доступа, не разделяют несинхронизированное состояние. |
| + | + | 362 |
1.11.3 | Все важные потоки бизнес-логики, включая аутентификацию, управление сеансами и контроль доступа, являются потокобезопасными и устойчивы к Time-of-check to time-of-use ошибкам. |
|
| + | 367 |
V1.12 Требования к архитектуре безопасной загрузки файлов
Таблица 11 – V1.12 Требования к архитектуре безопасной загрузки файлов
№ | Описание | У1 | У2 | У3 | CWE |
1.12.1 | Загруженные пользователем файлы хранятся вне корневых файлов проекта. |
| + | + | 552 |
1.12.2 | Убедитесь, что загруженные пользователем файлы - если их необходимо отображать или загружать из приложения – обслуживаются либо с помощью octet-stream загрузки, либо из несвязанного домена, например, из облачного хранилища. Реализуйте подходящую политику безопасности контента, чтобы снизить риск XSS-векторов или других атак из загруженного файла. |
| + | + | 646 |
V1.13 Требования к архитектуре API
Требования к архитектуре API появятся в будущих версиях.
V1.14 Требования к архитектуре конфигурации
Таблица 12 – V1.14 Требования к архитектуре конфигурации
№ | Описание | У1 | У2 | У3 | CWE |
1.14.1 | Компоненты с разными уровнями доверия разделены с помощью чётко определённых средств управления безопасностью, правил брандмауэра, шлюзов API, обратных прокси-серверов, облачных групп безопасности (cloud-based security groups) или аналогичных механизмов. |
| + | + | 923 |
1.14.2 | При запуске двоичных файлов на ненадёжных устройствах используются двоичные подписи, доверенные соединения и проверенные конечные точки. |
| + | + | 494 |
1.14.3 | При сборке пайплайн (build pipeline) предупреждает об устаревших или небезопасных компонентах и принимает соответствующие меры. |
| + | + | 1104 |
1.14.4 | Пайплайн (build pipeline) содержит этап для автоматической сборки и проверки безопасного развёртывания приложения, особенно если инфраструктура приложения определяется программным обеспечением, например, скрипты запуска в облачной среде. |
| + | + |
|
1.14.5 | Убедитесь, что развёртывание приложений помещено в песочницу, контейнеризировано и/или изолированно на сетевом уровне, чтобы не допустить атаки на другие приложения, особенно когда они выполняют конфиденциальные или опасные действия, такие как десериализация. |
| + | + | 256 |
1.14.6 | Приложение не использует неподдерживаемые, небезопасные или устаревшие клиентские технологии, такие как плагины NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL или клиентские Java-апплеты. |
| + | + | 477 |
Ссылки
Для получения дополнительной информации см. также:
- OWASP Threat Modeling Cheat Sheet;
- OWASP Attack Surface Analysis Cheat Sheet;