req_id

Feedback do grupo de trabalho

8.1.6

Reconsidere esse requisito para algo mais prático (por exemplo, os backups só devem ser mantidos por X tempo, os backups devem ser monitorados para evitar roubo/corrupção, os backups devem ser auditados regularmente para confirmar a capacidade de serem movidos de volta para a produção). A proposição atual é muito ampla e precisa de mais definição.

5.1.4

Duplicata de outros casos de teste. Este é um caso de teste de alto esforço e baixo valor. Recomendamos a remoção.

7.3.3

Duplicata de outros casos de teste. Este é um caso de teste de alto esforço e baixo valor. Recomendamos a remoção.

1.2.2

removido devido à cobertura em outro requisito, como 4.1.1

2.2.4

Remova "Req", já que ele é abordado em 4.3.1.

(4.3.1 Verifique se as interfaces administrativas usam a autenticação multifator adequada para

evitar 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

Remova porque o 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

O requisito foi removido na V5 do ASVS, e os algoritmos de hash recomendados em 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 OOB terceirizados. O risco aqui é baixo, já que o código de autenticação tem curta duração.

2.8.2

O requisito é relevante apenas para soluções personalizadas de MFA, também cobertas por 6.4.2 e 6.4.1.

2.8.5

Remove requirement as it is covered by 2.7.6 additionally logging failed attempts is covered by the logging requirement of the ASVS

2.8.6

O OTP físico no nível do aplicativo não é um caso de uso comum. Essa solicitação é necessária para interfaces de administrador. No entanto, o requisito 4.3.1 (Verificar se as interfaces administrativas usam a autenticação multifator adequada para evitar o uso não autorizado) abrange a MFA para interfaces administrativas e vai cobrir esse risco.

2.9.1

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

criptográfico ao computador para concluir a autenticação. Os verificadores enviam um nonce de desafio para o

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

armazenada), o que torna esse requisito fora do escopo da CASA, já que o risco de autenticação de dispositivos físicos é coberto por 4.3.1 para fins de MFA (físico ou de software).

2.9.3

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

criptográfico ao computador para concluir a autenticação. Os verificadores enviam um nonce de desafio para o

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

armazenada), o que torna esse requisito fora do escopo da CASA, já que o risco de autenticação de dispositivos físicos é coberto por 4.3.1 para fins de MFA (físico ou de software).

2.10.1

O requisito contradiz 2.10.2

2.10.3

Coberto por 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 cobre o risco de ataques off-line e armazenamento de senhas.

2.10.4

Coberto por 6.4.2. Verifique 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 por 3.4.1, 3.4.2 e 3.4.3

3.5.1

O usuário pode revogar tokens pelo provedor OAuth

4.3.3

O requisito é coberto pela MFA para interfaces de administrador e acesso privilegiado

5.1.3

Esse requisito é coberto por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real na lógica de negócios, a gravidade pode ser menor. Por exemplo, não validar o número de telefone corretamente resulta apenas na exibição inadequada do número na página de informações, o que não tem implicações diretas de segurança.

5.1.4

Esse requisito é coberto por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real na lógica de negócios, a gravidade pode ser menor. Por exemplo, não validar o número de telefone corretamente resulta apenas na exibição inadequada do número 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 que todo caractere Unicode é válido pode dificultar o teste. Nem todos os aplicativos incluem um formulário de texto grande o suficiente para caber todos os caracteres Unicode. Também não há suporte para determinados sistemas operacionais e ferramentas de invasão para todo o espaço Unicode, o que impede que você teste isso mesmo que o servidor seja compatível. Valor de segurança questionável no geral. Originalmente incluído na versão Beta, mas removido devido a problemas nos testes.

6.2.5

cobertas por 6.2.4 e 6.2.3

6.2.6

cobertas por 6.2.4 e 6.2.3

6.3.1

cobertas por 6.2.4 e 6.2.3

6.3.3

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

7.1.2

coberto por 7.1.1

7.1.3

coberto por 7.1.1

7.3.1

coberto por 7.1.1

7.3.3

coberto por 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 "necessário"? Como vamos 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. Essa é uma revisão jurídica e de compliance que está fora do escopo da CASA.

8.3.6

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

8.3.8

cobertas por 1.8.1, 1.8.2 e 1.1.4

9.2.5

cobertos por 8.3.5 e revisões de políticas de geração de registros do aplicativo.

10.1.1

Coberto pela revisão de arquitetura e é uma prática recomendada. O requisito não pode ser testado

10.2.3

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

É difícil testar funções maliciosas bem projetadas.

10.2.4

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

É difícil testar funções maliciosas bem projetadas.

10.2.5

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

É difícil testar funções maliciosas bem projetadas.

13.1.1

Coberto por 5.2.6 e 5.3.9

12.3.1

Risco de travessia de caminho coberto por outros requisitos existentes do capítulo 5 (validação, limpeza e codificação) do ASVS e da CASA

12.3.3

Coberto por 5.2.6 e 5.3.9

12.3.6

cobertas por 10.3.2, 12.4.1 e 12.4.2

12.5.1

cobertas por 10.3.2 e 12.4.2

12.5.2

cobertas por 10.3.2, 12.4.1 e 12.4.2

13.1.5

Esse requisito é coberto por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real na lógica de negócios, a gravidade pode ser menor. Por exemplo, não validar o número de telefone corretamente resulta apenas na exibição inadequada do número na página de informações, o que não tem implicações diretas de segurança.

13.2.2

Esse requisito é coberto por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real na lógica de negócios, a gravidade pode ser menor. Por exemplo, não validar o número de telefone corretamente resulta apenas na exibição inadequada do número na página de informações, o que não tem implicações diretas de segurança.

13.2.3

Coberto por 4.2.2

13.2.5

Esse requisito é coberto por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real na lógica de negócios, a gravidade pode ser menor. Por exemplo, não validar o número de telefone corretamente resulta apenas na exibição inadequada do número na página de informações, o que não tem implicações diretas de segurança.

13.3.1

Esse requisito é coberto por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real na lógica de negócios, a gravidade pode ser menor. Por exemplo, não validar o número de telefone corretamente resulta apenas na exibição inadequada do número na página de informações, o que não tem implicações diretas de segurança.

14.4.1

Coberto por 5.3.1

14.4.2

Esse requisito é coberto por outros requisitos de validação de entrada. Se a falta de validação não introduzir uma vulnerabilidade real na lógica de negócios, a gravidade pode ser menor. Por exemplo, não validar o número de telefone corretamente resulta apenas na exibição inadequada do número na página de informações, o que não tem implicações diretas de segurança.

14.4.3

abordado por 5.2.7 e 5.3.3

14.4.5

cobertos por 6.2.1 e 9.2.1

14.4.7

coberto por 12.4.1

14.5.3

coberto por 14.5.2

2.1.5

coberto por 2.1.1

2.1.6

coberto por 2.1.1

2.2.3

Não é relevante para a casa, já que o risco é coberto por outros controles antiautomáticos.

2.5.6

cobertos 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 por 13.1.4

5.2.8

cobertos por outras verificações de validação e limpeza de entrada

5.3.5

cobertos por outras verificações de validação e limpeza de entrada

7.4.1

cobertas por verificações de registro

8.2.3

coberto por 8.1.1

9.1.1

cobertos por 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 por 6.1.1

6.1.3

Coberto por 6.1.1

2.10.2

Coberto por 2.5.4

2.2.1

Coberto por 11.1.4

2.7.3

Coberto por 2.7.2

2.7.4

Coberto por 2.7.2

5.1.2

Coberto pelo controle antiautomático

6.2.2

algoritmos criptográficos aprovados não definidos

8.2.1

Coberto por 8.1.1

9.1.2

Coberto por 9.2.1

9.1.3

Coberto por 9.2.1

5.5.1

Coberto pela versão 1.8.2

14.2.1

Coberto por 1.14.6

3.3.4

Isso não é verdade para aplicativos que usam AuthN/Z sem estado. Concordar com a recomendação do NCC Group de remoção. Isso deve ser abordado por 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

Verifique se todos os dados sensíveis foram 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 criptografia, integridade, retenção, privacidade e outros requisitos de confidencialidade, e se eles são

aplicado na arquitetura.

2.1.1

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

2.5.4

Verifique se não há contas compartilhadas ou padrão (por exemplo, "root",

"admin" ou "sa".

4.2.1

Verifique se os dados sensíveis e as APIs estão protegidos contra ataques de referência direta insegura a objetos (IDOR) que visam criação, leitura, atualização e exclusão de 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 funções sem suporte, não seguras ou descontinuadas

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

Silverlight, NACL ou applets Java do lado do cliente.