req_id

Обратная связь с рабочей группой

8.1.6

Было бы пересмотрено это Требование, чтобы оно было чем-то более действенным (например, резервные копии должны храниться только в течение X времени, резервные копии должны отслеживаться на предмет кражи/повреждения, резервные копии должны регулярно проверяться, чтобы подтвердить их возможность вернуться в производство). Нынешнее предположение является слишком широким и требует дополнительного определения.

5.1.4

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

7.3.3

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

1.2.2

удалить из-за покрытия в других требованиях, таких как 4.1.1

2.2.4

Удалите Req, поскольку он описан в 4.3.1.

(4.3.1 Убедитесь, что административные интерфейсы используют соответствующую многофакторную аутентификацию для

предотвратить несанкционированное использование.), который охватывает защиту от олицетворения против фишинга в интерфейсах администратора и других внутренних путях доступа.

2.2.5

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

2.4.3

Стандарт в том виде, в каком он написан, недостаточно конкретен, чтобы его можно было применять

2.4.5

Требование, удаленное в версии 5 ASVS, и рекомендуемые алгоритмы хеширования в версии 2.4.1 не могут удовлетворить это требование.

2.7.5

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

2.8.2

Требование относится только к пользовательским решениям MFA, также охватываемым 6.4.2 и 6.4.1.

2.8.5

Удалите требование, так как оно покрывается 2.7.6, кроме того, регистрация неудачных попыток покрывается требованием регистрации ASVS.

2.8.6

Физический OTP на уровне приложения не является распространенным вариантом использования, это требование необходимо для интерфейсов администратора. Однако требование 4.3.1 (Убедиться, что административные интерфейсы используют соответствующую многофакторную аутентификацию для предотвращения несанкционированного использования.) Покрывает MFA для интерфейсов администрирования и покрывает этот риск.

2.9.1

Это требование распространяется на физические устройства в соответствии с ASVS (Криптографические ключи безопасности — это смарт-карты или ключи FIDO, к которым пользователь должен подключить или связать

криптографическое устройство к компьютеру для завершения аутентификации. Верификаторы отправляют одноразовый номер вызова

криптографические устройства или программное обеспечение, и устройство или программное обеспечение вычисляет ответ на основе безопасного

сохраненный криптографический ключ.) делает это требование вне области действия CASA, поскольку риск аутентификации физических устройств покрывается 4.3.1 для целей MFA (физических или программных)

2.9.3

Это требование распространяется на физические устройства в соответствии с ASVS (Криптографические ключи безопасности — это смарт-карты или ключи FIDO, к которым пользователь должен подключить или связать

криптографическое устройство к компьютеру для завершения аутентификации. Верификаторы отправляют одноразовый номер вызова

криптографические устройства или программное обеспечение, и устройство или программное обеспечение вычисляет ответ на основе безопасного

сохраненный криптографический ключ.) делает это требование вне области действия CASA, поскольку риск аутентификации физических устройств покрывается 4.3.1 для целей MFA (физических или программных)

2.10.1

Требование противоречит 2.10.2

2.10.3

Покрывается 2.4.1 (убедитесь, что при хранении пароля пользователя для приложения используется одна из следующих функций хеширования пароля: argon2id, scrypt, bcrypt или PBKDF2), которая покрывает риск атак в автономном режиме и хранения паролей.

2.10.4

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

3.2.3

Покрывается 3.4.1, 3.4.2 и 3.4.3

3.5.1

Пользователь может отозвать токены через провайдера OAuth.

4.3.3

Req покрывается MFA для интерфейсов администратора и привилегированного доступа.

5.1.3

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

5.1.4

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

5.3.2

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

6.2.5

охвачено 6.2.4 и 6.2.3

6.2.6

охвачено 6.2.4 и 6.2.3

6.3.1

охвачено 6.2.4 и 6.2.3

6.3.3

покрываются другими требованиями к генерации случайных чисел.

7.1.2

подпадает под 7.1.1

7.1.3

подпадает под 7.1.1

7.3.1

подпадает под 7.1.1

7.3.3

подпадает под 7.1.1

8.1.3

Трудно описать, что является приемлемым или необходимым параметром. Не тестируемый случай. Что является необходимым? Как мы будем определять, действительно ли исключение? Считается выходящим за рамки CASA

8.3.3

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

8.3.6

Управление зависит от системы (вариант Windows/Linux) и зависит от устройства и в большинстве случаев не является управлением приложения.

8.3.8

охвачено 1.8.1, 1.8.2 и 1.1.4

9.2.5

охвачены 8.3.5 и обзоры политик ведения журналов приложения.

10.1.1

Покрывается обзором архитектуры и является рекомендуемой передовой практикой. Требование не подлежит проверке

10.2.3

Невозможно сделать в разумные сроки. Любой странный код должен быть задокументирован и проверен, однако постановка конкретной задачи по обеспечению отсутствия бэкдоров потребует подробного построчного анализа кода и не гарантирует отсутствие бэкдоров.

Трудно проверить на хорошо спроектированные вредоносные функции

10.2.4

Нет возможности проверить. Невозможно сделать в разумные сроки. Любой странный код должен быть задокументирован и проверен, однако постановка конкретной задачи по обеспечению отсутствия бэкдоров потребует подробного построчного анализа кода и не гарантирует отсутствие бэкдоров.

Трудно проверить на хорошо спроектированные вредоносные функции

10.2.5

Нет возможности проверить. Невозможно сделать в разумные сроки. Любой странный код должен быть задокументирован и проверен, однако постановка конкретной задачи по обеспечению отсутствия бэкдоров потребует подробного построчного анализа кода и не гарантирует отсутствие бэкдоров.

Трудно проверить на хорошо спроектированные вредоносные функции

13.1.1

Покрывается 5.2.6 и 5.3.9

12.3.1

риск обхода пути, охватываемый другими существующими требованиями главы 5 (Проверка, очистка и кодирование) ASVS и CASA

12.3.3

Покрывается 5.2.6 и 5.3.9

12.3.6

охвачено 10.3.2, 12.4.1 и 12.4.2

12.5.1

охвачено 10.3.2 и 12.4.2

12.5.2

охвачено 10.3.2, 12.4.1 и 12.4.2

13.1.5

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

13.2.2

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

13.2.3

Охвачено 4.2.2

13.2.5

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

13.3.1

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

14.4.1

подпадает под 5.3.1

14.4.2

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

14.4.3

охвачено 5.2.7 и 5.3.3

14.4.5

охвачено 6.2.1 и 9.2.1

14.4.7

подпадает под 12.4.1

14.5.3

подпадает под 14.5.2

2.1.5

охвачено 2.1.1

2.1.6

охвачено 2.1.1

2.2.3

Не относится к casa, поскольку риск покрывается другими средствами защиты от автоматизации.

2.5.6

покрыты другой защитой паролем

3.1.1

Низкий риск воздействия и покрытие другими средствами контроля ASVS

3.2.1

Низкий риск воздействия и покрытие другими средствами контроля ASVS

3.4.4

Низкий риск воздействия и покрытие другими средствами контроля ASVS

3.4.5

Низкий риск воздействия и покрытие другими средствами контроля ASVS

4.2.1

подпадает под 13.1.4

5.2.8

охвачены другими проверками входных данных и санитарными проверками

5.3.5

охвачены другими проверками входных данных и санитарными проверками

7.4.1

охвачены проверками журналирования

8.2.3

подпадает под 8.1.1

9.1.1

охвачено 6.2.1 и 9.2.1

1.2.3

охвачено 1.1.4, 1.8.4 и 1.8.2

1.4.4

охвачено 1.1.4, 1.8.4 и 1.8.2

1.5.2

охвачено 1.1.4, 1.8.4 и 1.8.2

1.5.3

охвачено 1.1.4, 1.8.4 и 1.8.2

1.5.4

охвачено 1.1.4, 1.8.4 и 1.8.2

1.9.1

охвачено 1.1.4, 1.8.4 и 1.8.2

1.11.3

охвачено 1.1.4, 1.8.4 и 1.8.2

1.14.1

охвачено 1.1.4, 1.8.4 и 1.8.2

1.14.2

охвачено 1.1.4, 1.8.4 и 1.8.2

1.14.3

охвачено 1.1.4, 1.8.4 и 1.8.2

1.14.4

охвачено 1.1.4, 1.8.4 и 1.8.2

1.14.5

охвачено 1.1.4, 1.8.4 и 1.8.2

1.14.6

охвачено 1.1.4, 1.8.4 и 1.8.2

6.1.2

Покрывается 6.1.1

6.1.3

Покрывается 6.1.1

2.10.2

Покрывается 2.5.4

2.2.1

Покрывается 11.1.4

2.7.3

Покрывается 2.7.2

2.7.4

Покрывается 2.7.2

5.1.2

Под защитой антиавтоматического контроля

6.2.2

одобренные криптографические алгоритмы не определены

8.2.1

Покрывается 8.1.1

9.1.2

Покрывается 9.2.1

9.1.3

Покрывается 9.2.1

5.5.1

Покрывается 1.8.2

14.2.1

Покрывается 1.14.6

3.3.4

Это неверно для приложений, использующих AuthN/Z без сохранения состояния. Согласен с рекомендацией NCC Group удалить. Это должно быть описано в 3.3.3.

req_id

Описание

1.1.4

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

1.8.1

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

1.8.2

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

применяется в архитектуре.

2.1.1

Убедитесь, что установленные пользователем пароли имеют длину не менее 12 символов.

2.5.4

Убедитесь, что общие учетные записи или учетные записи по умолчанию отсутствуют (например, «root»,

«админ» или «са»).

4.2.1

Убедитесь, что конфиденциальные данные и API защищены от атак с небезопасной прямой ссылкой на объект (IDOR), направленных на создание, чтение, обновление и удаление записей, например создание или обновление чужой записи, просмотр всех записей или удаление всех записей.

1.14.6

Убедитесь, что приложение не использует неподдерживаемые, небезопасные или устаревшие

клиентские технологии, такие как плагины NSAPI, Flash, Shockwave, ActiveX,

Silverlight, NACL или клиентские Java-апплеты.