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 не поддерживается большинством поставщиков криптосистем; кроме того, большинство разработчиков, протестированных для CASA, будут использовать аутентификацию на основе пароля.

2.4.3

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

2.4.5

Требование удалено в V5 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

Физические одноразовые пароли на уровне приложения используются нечасто, это требование необходимо для административных интерфейсов. Однако требование 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

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

5.1.3

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

5.1.4

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

5.3.2

Часть этого требования, указывающая на допустимость каждого символа Unicode, может усложнить тестирование. Не каждое приложение будет включать текстовую форму, достаточно большую, чтобы вместить в неё все символы Unicode. Кроме того, из-за отсутствия поддержки некоторых операционных систем и хакерских инструментов для всего пространства 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 защищены от атак типа Insecure Direct Object Reference (IDOR), направленных на создание, чтение, обновление и удаление записей, например, создание или обновление чужой записи, просмотр записей всех пользователей или удаление всех записей.

1.14.6

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

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

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