req_id

Feedback do grupo de trabalho

8.1.6

Reconsidere esse requisito para que ele seja mais prático (por exemplo, os backups devem ser retidos apenas por X tempo, os backups devem ser monitorados em busca de roubo/corrupção, e os backups devem ser auditados regularmente para confirmar a capacidade deles de voltar para a produção). A suposição atual é muito ampla e precisaria de mais definição.

5.1.4

Cópia de outros casos de teste. Esse é um caso de teste de alto valor e alto esforço. Recomendamos remover.

7.3.3

Cópia de outros casos de teste. Esse é um caso de teste de alto valor e alto esforço. Recomendamos remover.

1.2.2

remover devido à cobertura em outro requisito, como 4.1.1

2.2.4

Remoção da solicitação obrigatória 4.3.1.

(4.3.1 Verificar se as interfaces administrativas usam a autenticação multifator apropriada para

impedir o uso não autorizado, que abrange a resistência à falsificação de identidade contra phishing em interfaces de administrador e outros caminhos de acesso interno.

2.2.5

A remoção como mTLS não é compatível com a maioria dos CSPs. Além disso, a maioria dos desenvolvedores testados para CASA usará a autenticação baseada em senha

2.4.3

O padrão conforme escrito não é específico o suficiente para ser aplicado

2.4.5

Requisito removido na V5 do ASVS e os algoritmos de hash recomendados na versão 2.4.1 não atendem a esse requisito.

2.7.5

O teste é inviável, já que pode exigir uma análise de provedores de OOB de terceiros. O risco aqui é baixo, porque o código de autenticação é de curta duração.

2.8.2

requisito só é relevante para soluções de MFA personalizadas, também cobertas pelas versões 6.4.2 e 6.4.1.

2.8.5

Remoção da exigência de 2,7,6.Além disso, a geração de registros de tentativas com falha é coberta pelo requisito de geração de registros do ASVS.

2,8,6

A OTP física no nível do aplicativo não é um caso de uso comum. Essa exigência é necessária para interfaces de administrador. No entanto, o requisito 4.3.1 (verificar se as interfaces administrativas usam a autenticação multifator apropriada para evitar o uso não autorizado) abrange a MFA para interfaces de administrador e cobrirá esse risco.

2.9.1

Esse requisito abrange dispositivos físicos de acordo com o ASVS. As chaves de segurança criptográfica são cartões inteligentes ou FIDO, em que o usuário precisa conectar ou parear o

dispositivo criptográfico ao computador para concluir a autenticação. Os verificadores enviam um valor de uso único para o

dispositivos criptográficos ou software, e o dispositivo ou software calcula uma resposta com base em um

chave criptográfica armazenada), tornando esse requisito fora do escopo do CASA, já que o risco de autenticação de dispositivos físicos é coberto pela versão 4.3.1 para fins de MFA (físico ou software).

2,9,3

Esse requisito abrange dispositivos físicos de acordo com o ASVS. As chaves de segurança criptográfica são cartões inteligentes ou FIDO, em que o usuário precisa conectar ou parear o

dispositivo criptográfico ao computador para concluir a autenticação. Os verificadores enviam um valor de uso único para o

dispositivos criptográficos ou software, e o dispositivo ou software calcula uma resposta com base em um

chave criptográfica armazenada), tornando esse requisito fora do escopo do CASA, já que o risco de autenticação de dispositivos físicos é coberto pela versão 4.3.1 para fins de MFA (físico ou software).

2.10,1

O requisito é uma contradição de 2.10.2.

2.10.3

Coberto pela versão 2.4.1. Verifique se uma das seguintes funções de hash de senha é usada ao armazenar a senha do usuário para o aplicativo: argon2id, scrypt, bcrypt ou PBKDF2, que abrange o risco de ataques off-line e armazenamento de senhas.

2.10,4

Coberta pela versão 6.4.2. Verificar se o material da chave não está exposto ao aplicativo, mas usa um módulo de segurança isolado como um cofre para operações criptográficas.

3.2.3

Coberto pelas versões 3.4.1, 3.4.2 e 3.4.3

3.5.1

O usuário pode revogar os tokens pelo provedor de OAuth

4,3,3

A solicitação é coberta pela autenticação multifator (MFA) para interfaces de administrador e acesso privilegiado

5.1.3

Essa exigência é coberta por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real de lógica de negócios, isso poderá ser uma gravidade menor. Por exemplo, a não validação do número de telefone resulta apenas na exibição incorreta do número de telefone na página de informações, o que não tem implicações diretas de segurança.

5.1.4

Essa exigência é coberta por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real de lógica de negócios, isso poderá ser uma gravidade menor. Por exemplo, a não validação do número de telefone resulta apenas na exibição incorreta do número de telefone na página de informações, o que não tem implicações diretas de segurança.

5.3.2

A parte desse requisito que especifica todos os caracteres Unicode é válida pode dificultar o teste. Nem todos os aplicativos incluem um formulário de texto grande o suficiente para acomodar todos os caracteres Unicode. Também há falta de suporte a alguns sistemas operacionais e ferramentas de invasão para todo o espaço Unicode. Isso faz com que não seja possível testar isso mesmo que o servidor ofereça suporte. Valor de segurança questionável em geral. Originalmente incluída na versão Beta, mas foi removida devido a problemas nos testes.

6.2.5

coberto pelas versões 6.2.4 e 6.2.3

6.2.6

coberto pelas versões 6.2.4 e 6.2.3

6.3.1

coberto pelas versões 6.2.4 e 6.2.3

6.3.3

cobertos por outros requisitos para geração de números aleatórios.

7.1.2

coberto pela versão 7.1.1

7.1,3

coberto pela versão 7.1.1

7.3.1

coberto pela versão 7.1.1

7.3.3

coberto pela versão 7.1.1

8.1.3

É difícil descrever o que é um parâmetro aceitável ou necessário. Não é um caso testável. O que constitui o necessário? Como determinar se uma exceção é válida? Considerado fora do escopo da CASA

8.3.3

Não é um requisito testável, relevante para a Política de Privacidade e os Termos de Serviço, e não para a segurança do aplicativo. Esta é uma análise legal e de conformidade e está fora do escopo da CASA

8.3.6

O controle é específico do sistema (variantes do Windows/Linux) e específico do dispositivo e, na maioria dos casos, não é de controle do aplicativo.

8.3.8

Cobertura 1.8.1, 1.8.2 e 1.1.4

9,2,5

cobertos pela versão 8.3.5 e as avaliações de políticas de registro do aplicativo.

10,1,1

A cobertura é uma revisão de arquitetura e é uma prática recomendada. Não é possível testar o requisito

10.2.3

Não é possível fazer isso em um período razoável. Qualquer código estranho pode ser documentado e revisado. No entanto, definir a tarefa específica para garantir que os backdoors não estejam presentes exige uma análise detalhada do código de linha por linha e não garante que os backdoors não estão presentes.

Dificuldade em testar funções maliciosas bem projetadas

10,2,4

Não é possível testar. Não é possível fazer isso em um período razoável. Qualquer código estranho precisa ser documentado e revisado. No entanto, definir a tarefa específica para garantir que backdoor não exige uma análise detalhada do código de linha por linha e não garante que nenhum backdoor está presente.

Dificuldade em testar funções maliciosas bem projetadas

10,2,5

Não é possível testar. Não é possível fazer isso em um período razoável. Qualquer código estranho precisa ser documentado e revisado. No entanto, definir a tarefa específica para garantir que backdoor não exige uma análise detalhada do código de linha por linha e não garante que nenhum backdoor está presente.

Dificuldade em testar funções maliciosas bem projetadas

13,1,1

Coberto pelas versões 5.2.6 e 5.3.9.

12,3,1

risco de passagem de caminho coberto por outros requisitos existentes do{101} capítulo 5 (Validação, Sanitização e Codificação) do ASVS{101} e CASA

12,3,3

Coberto pelas versões 5.2.6 e 5.3.9.

12,3,6

Coberto por 10.3.2 12.4.1 e 12.4.2

12,5,1

cobertas pelas versões 10.3.2 e 12.4.2

12,5,2

Coberto por 10.3.2 12.4.1 e 12.4.2

13,1,5

Essa exigência é coberta por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real de lógica de negócios, isso poderá ser uma gravidade menor. Por exemplo, a não validação do número de telefone resulta apenas na exibição incorreta do número de telefone na página de informações, o que não tem implicações diretas de segurança.

13,2,2

Essa exigência é coberta por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real de lógica de negócios, isso poderá ser uma gravidade menor. Por exemplo, a não validação do número de telefone resulta apenas na exibição incorreta do número de telefone na página de informações, o que não tem implicações diretas de segurança.

13,2,3

Coberto pela versão 4.2.2

13,2,5

Essa exigência é coberta por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real de lógica de negócios, isso poderá ser uma gravidade menor. Por exemplo, a não validação do número de telefone resulta apenas na exibição incorreta do número de telefone na página de informações, o que não tem implicações diretas de segurança.

13,3,1

Essa exigência é coberta por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real de lógica de negócios, isso poderá ser uma gravidade menor. Por exemplo, a não validação do número de telefone resulta apenas na exibição incorreta do número de telefone na página de informações, o que não tem implicações diretas de segurança.

14,4,1

coberto pela 5.3.1

14,4,2

Essa exigência é coberta por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real de lógica de negócios, isso poderá ser uma gravidade menor. Por exemplo, a não validação do número de telefone resulta apenas na exibição incorreta do número de telefone na página de informações, o que não tem implicações diretas de segurança.

14,4,3

coberto pelas versões 5.2.7 e 5.3.3.

14,4,5

coberto pelas versões 6.2.1 e 9.2.1.

14,4,7

coberto pela 12.4.1

14,5,3

coberto pela 14.5.2

2,1,5

coberto pela versão 2.1.1

2,1,6

coberto pela versão 2.1.1

2.2.3

Não é relevante para Casa, já que o risco é coberto por outros controles antiautomação.

2.5.6

coberto por outra proteção por senha

3.1.1

Baixo risco de exposição e coberto por outros controles do ASVS

3.2.1

Baixo risco de exposição e coberto por outros controles do ASVS

3,4,4

Baixo risco de exposição e coberto por outros controles do ASVS

3.4.5

Baixo risco de exposição e coberto por outros controles do ASVS

4.2.1

coberto pela 13.1.4

5.2.8

coberto por outras verificações de validação e higienização de entrada

5,3,5

coberto por outras verificações de validação e higienização de entrada

7.4.1

cobertos pelas verificações de geração de registros

8.2.3

coberto pela 8.1.1

9,1,1

coberto pelas versões 6.2.1 e 9.2.1.

1.2.3

coberto por 1.1.4, 1.8.4 e 1.8.2

1.4.4

coberto por 1.1.4, 1.8.4 e 1.8.2

1.5.2

coberto por 1.1.4, 1.8.4 e 1.8.2

1.5.3

coberto por 1.1.4, 1.8.4 e 1.8.2

1.5.4

coberto por 1.1.4, 1.8.4 e 1.8.2

1.9.1

coberto por 1.1.4, 1.8.4 e 1.8.2

1.11.3

coberto por 1.1.4, 1.8.4 e 1.8.2

1.14.1

coberto por 1.1.4, 1.8.4 e 1.8.2

1.14.2

coberto por 1.1.4, 1.8.4 e 1.8.2

1.14.3

coberto por 1.1.4, 1.8.4 e 1.8.2

1.14.4

coberto por 1.1.4, 1.8.4 e 1.8.2

1.14.5

coberto por 1.1.4, 1.8.4 e 1.8.2

1.14,6

coberto por 1.1.4, 1.8.4 e 1.8.2

6.1.2

Coberto pela versão 6.1.1

6.1.3

Coberto pela versão 6.1.1

2.10.2

Coberto pela versão 2.5.4

2.2.1

Coberto pela versão 11.1.4

2.7.3

Coberto pela versão 2.7.2

2.7.4

Coberto pela versão 2.7.2

5.1.2

Coberto pelo controle antiautomação

6.2.2

algoritmos criptográficos aprovados não definidos

8.2.1

Coberto pela versão 8.1.1

9.1.2

Coberto pela versão 9.2.1

9,1,3

Coberto pela versão 9.2.1

5.5.1

Coberto pela versão 1.8.2

14,2,1

Coberto pela versão 1.14.6

3.3.4

Isso não é verdade para aplicativos que usam o AuthN/Z sem estado. Concorde com a recomendação de remoção do Grupo NCC. Isso precisa ser coberto pela versão 3.3.3.

req_id

Descrição

1.1.4

Verifique a documentação e a justificativa de todos os limites de confiança, componentes e fluxos de dados significativos do aplicativo.

1.8.1

Verificar se todos os dados confidenciais são identificados e classificados em níveis de proteção

1.8.2

Verifique se todos os níveis de proteção têm um conjunto associado de requisitos de proteção, como requisitos de criptografia, integridade, retenção, privacidade e outros requisitos de confidencialidade, e se eles são

aplicada na arquitetura.

2.1.1

Verificar se as senhas definidas pelo usuário têm pelo menos 12 caracteres.

2,5,4

Verificar se contas compartilhadas ou padrão não estão presentes (por exemplo, "raiz",

"admin" ou "sa").

4.2.1

Verifique se os dados e as APIs confidenciais estão protegidos contra ataques de referência direta não segura (IDOR, na sigla em inglês) direcionados a criar, ler, atualizar e excluir registros, como criar ou atualizar o registro de outra pessoa, visualizar os registros de todos ou excluir todos os registros.

1.14,6

Verifique se o aplicativo não usa sem suporte, não seguro ou descontinuado

tecnologias do lado do cliente, como plug-ins NSAPI, Flash, Shockwave, ActiveX,

miniaplicativos Silverlight, NACL ou Java do lado do cliente.