ID_req

Feedback sul gruppo di lavoro

8,1,6

Riteniamo che questo requisito sia più fruibile (ad es. i backup devono essere conservati solo per un periodo di tempo X, i controlli devono essere monitorati per furto/corruzione, i backup devono essere controllati regolarmente per confermare la loro possibilità di tornare in produzione). Il presupposto attuale è troppo ampio e necessita di una maggiore definizione.

5,1,4

Duplicare altri scenari di test. Questo è uno scenario di test a basso valore di impegno elevato. Consigliato per la rimozione.

7,3,3

Duplicare altri scenari di test. Questo è uno scenario di test a basso valore di impegno elevato. Consigliato per la rimozione.

1,2,2

rimuovere a causa della copertura in altri requisiti, come 4.1.1

2,2,4

Rimuovere Req come previsto dalla sezione 4.3.1

(4.3.1 Verificare che le interfacce amministrative utilizzino l'autenticazione a più fattori appropriata per

prevenire l'uso non autorizzato) e copre la resistenza al furto d'identità contro il phishing nelle interfacce di amministrazione e in altri percorsi di accesso interni

2,2,5

Rimuovi poiché mTLS non è supportato dalla maggior parte dei CSP; la maggior parte degli sviluppatori testati per CASA utilizzerà l'autenticazione basata su password

2,4,3

La norma scritta non è sufficientemente specifica per poter essere applicata

2,4,5

Il requisito rimosso nella versione V5 di ASVS e gli algoritmi di hashing consigliati nella versione 2.4.1 non soddisfano questo requisito

2,7,5

Test non fattibili in quanto potrebbero richiedere un'analisi di provider OOB di terze parti, poiché il rischio qui è basso perché il codice di autenticazione è di breve durata.

2,8,2

è pertinente solo per le soluzioni MFA personalizzate, coperte anche dalle versioni 6.4.2 e 6.4.1

2,8,5

Rimuovi il requisito poiché è coperto da 2.7.6; inoltre, il tentativo di logging non riuscito è coperto dal requisito di logging dell'ASVS

2,8,6

L'OTP fisico a livello di applicazione non è un caso d'uso comune, necessario per le interfacce di amministrazione. Tuttavia, il req 4.3.1 (verifica che le interfacce di amministrazione utilizzino l'autenticazione a più fattori appropriata per prevenire l'uso non autorizzato) e copre la MFA per le interfacce di amministrazione e coprirà questo rischio

2,9,1

Questo requisito riguarda i dispositivi fisici in conformità con ASVS (i token di sicurezza crittografici sono smart card o chiavi FIDO, in cui l'utente deve collegare o associare il

crittografico al computer per completare l'autenticazione. I verificatori inviano una sfida nonce al

software o dispositivi crittografici e il dispositivo o il software calcola una risposta in base a

la chiave di crittografia archiviata). Rendere questo requisito fuori dall'ambito di CASA poiché il rischio di autenticazione dei dispositivi fisici è coperto dalla versione 4.3.1 per l'MFA (fisico o software).

2,9,3

Questo requisito riguarda i dispositivi fisici in conformità con ASVS (i token di sicurezza crittografici sono smart card o chiavi FIDO, in cui l'utente deve collegare o associare il

crittografico al computer per completare l'autenticazione. I verificatori inviano una sfida nonce al

software o dispositivi crittografici e il dispositivo o il software calcola una risposta in base a

la chiave di crittografia archiviata). Rendere questo requisito fuori dall'ambito di CASA poiché il rischio di autenticazione dei dispositivi fisici è coperto dalla versione 4.3.1 per l'MFA (fisico o software).

2,10,1

Il requisito è una contraddizione di 2.10.2

2,10,3

Coperto da 2.4.1 (verifica che venga utilizzata una delle seguenti funzioni di hashing delle password quando si archivia la password dell'utente per l'applicazione: argon2id, scrypt, bcrypt o PBKDF2) che copre il rischio di attacchi offline e archiviazione delle password.

2,10,4

Coperto da 6.4.2 Verifica che il materiale della chiave non sia esposto all'applicazione, ma che utilizzi un modulo di sicurezza isolato, come un vault per le operazioni di crittografia.

3,2,3

Coperto da 3.4.1, 3.4.2 e 3.4.3

3,5,1

L'utente può revocare i token tramite il provider OAuth

4,3,3

La richiesta è coperta dalla MFA per le interfacce di amministrazione e l'accesso con privilegi

5,1,3

Questa richiesta è coperta da altri requisiti di convalida degli input e se la mancanza di convalida non introduce una vulnerabilità logica di business effettiva, la gravità può essere inferiore. Ad esempio, la mancata convalida del numero di telefono può comportare solo una visualizzazione non corretta del numero nella pagina delle informazioni, il che non ha implicazioni dirette in termini di sicurezza.

5,1,4

Questa richiesta è coperta da altri requisiti di convalida degli input e se la mancanza di convalida non introduce una vulnerabilità logica di business effettiva, la gravità può essere inferiore. Ad esempio, la mancata convalida del numero di telefono può comportare solo una visualizzazione non corretta del numero nella pagina delle informazioni, il che non ha implicazioni dirette in termini di sicurezza.

5,3,2

La parte di questo requisito che specifica ogni carattere Unicode è valida può complicare il test. Non tutte le applicazioni includeranno un modulo di testo abbastanza grande da contenere tutti i caratteri Unicode. L'assenza di supporto per alcuni sistemi operativi e strumenti di pirateria informatica per l'intero spazio Unicode rende impossibile il test anche se il server lo supporta. Valore di sicurezza discutibile nel complesso. In origine era inclusa nella versione beta, ma è stata rimossa a causa di problemi durante il test.

6,2,5

coperti da 6.2.4 e 6.2.3

6,2,6

coperti da 6.2.4 e 6.2.3

6,3,1

coperti da 6.2.4 e 6.2.3

6,3,3

coperti da altri requisiti casuali di generazione dei numeri.

7,1,2

coperto da 7.1.1

7,1,3

coperto da 7.1.1

7,3,1

coperto da 7.1.1

7,3,3

coperto da 7.1.1

8,1,3

È difficile descrivere un parametro accettabile o necessario. Non è un caso testabile. Cosa costituisce la necessità? Come stabiliremo se un'eccezione è valida? Considerazione fuori dall'ambito della CASA

8,3,3

Non è un requisito testabile, pertinente alle norme sulla privacy e ai termini di servizio e non alla sicurezza delle applicazioni. Questa è una revisione legale e di conformità e non rientra nell'ambito della CASA

8,3,6

Il controllo è specifico per il sistema (variante Windows/linux) e specifico per dispositivo e nella maggior parte dei casi non è il controllo dell'applicazione.

8,3,8

coperti da 1.8.1, 1.8.2 e 1.1.4

9,2,5

coperto da 8.3.5 e logging delle revisioni dei criteri dell'applicazione.

10,1,1

È coperta dalla revisione dell'architettura ed è una best practice consigliata. Il requisito non è verificabile

10,2,3

Non è possibile effettuare questa operazione in un lasso di tempo ragionevole. Qualsiasi codice strano deve essere documentato e rivisto, ma l'impostazione dell'attività specifica per assicurarsi che le porte esterne non siano presenti richiederebbe una revisione approfondita riga per riga e non garantisce che queste ultime non siano presenti.

Difficoltà di eseguire test per funzionalità dannose ben progettate

10,2,4

Impossibile eseguire il test. Non è possibile farlo in tempi ragionevoli. Qualsiasi codice strano deve essere documentato e rivisto, ma l'impostazione dell'attività specifica per assicurarsi che le porte esterne non siano presenti richiederebbe una revisione approfondita riga per riga e non garantisce che queste ultime non siano presenti.

Difficoltà di eseguire test per funzionalità dannose ben progettate

10,2,5

Impossibile eseguire il test. Non è possibile farlo in tempi ragionevoli. Qualsiasi codice strano deve essere documentato e rivisto, ma l'impostazione dell'attività specifica per assicurarsi che le porte esterne non siano presenti richiederebbe una revisione approfondita riga per riga e non garantisce che queste ultime non siano presenti.

Difficoltà di eseguire test per funzionalità dannose ben progettate

13,1,1

Coperto da 5.2.6 e 5.3.9

12,3,1

rischio di attraversamento percorso coperto da altri requisiti esistenti del capitolo 5 (Convalida, sanitizzazione e codifica) di ASVS e CASA

12,3,3

Coperto da 5.2.6 e 5.3.9

12,3,6

coperti da 10.3.2 12.4.1 e 12.4.2

12,5.1

coperti da 10.3.2 e 12.4.2

12,5.2

coperti da 10.3.2 12.4.1 e 12.4.2

13,1,5

Questa richiesta è coperta da altri requisiti di convalida degli input e se la mancanza di convalida non introduce una vulnerabilità logica di business effettiva, la gravità può essere inferiore. Ad esempio, la mancata convalida del numero di telefono può comportare solo una visualizzazione non corretta del numero nella pagina delle informazioni, il che non ha implicazioni dirette in termini di sicurezza.

13,2,2

Questa richiesta è coperta da altri requisiti di convalida degli input e se la mancanza di convalida non introduce una vulnerabilità logica di business effettiva, la gravità può essere inferiore. Ad esempio, la mancata convalida del numero di telefono può comportare solo una visualizzazione non corretta del numero nella pagina delle informazioni, il che non ha implicazioni dirette in termini di sicurezza.

13,2,3

Coperto da 4.2.2

13,2,5

Questa richiesta è coperta da altri requisiti di convalida degli input e se la mancanza di convalida non introduce una vulnerabilità logica di business effettiva, la gravità può essere inferiore. Ad esempio, la mancata convalida del numero di telefono può comportare solo una visualizzazione non corretta del numero nella pagina delle informazioni, il che non ha implicazioni dirette in termini di sicurezza.

13,3,1

Questa richiesta è coperta da altri requisiti di convalida degli input e se la mancanza di convalida non introduce una vulnerabilità logica di business effettiva, la gravità può essere inferiore. Ad esempio, la mancata convalida del numero di telefono può comportare solo una visualizzazione non corretta del numero nella pagina delle informazioni, il che non ha implicazioni dirette in termini di sicurezza.

14,4,1

coperto da 5.3.1

14,4,2

Questa richiesta è coperta da altri requisiti di convalida degli input e se la mancanza di convalida non introduce una vulnerabilità logica di business effettiva, la gravità può essere inferiore. Ad esempio, la mancata convalida del numero di telefono può comportare solo una visualizzazione non corretta del numero nella pagina delle informazioni, il che non ha implicazioni dirette in termini di sicurezza.

14,4,3

coperti da 5.2.7 e 5.3.3

14,4,5

coperti da 6.2.1 e 9.2.1

14,4,7

coperto da 12.4.1

14,5,3

coperto da 14.5.2

2,1,5

coperto da 2.1.1

2,1,6

coperto da 2.1.1

2,2,3

Non pertinente alla casa perché il rischio è coperto da altri controlli anti-automazione

2,5,6

coperto da altra protezione tramite password

3,1,1

Basso rischio di esposizione e coperto da altri controlli della ASVS

3,2,1

Basso rischio di esposizione e coperto da altri controlli della ASVS

3,4,4

Basso rischio di esposizione e coperto da altri controlli della ASVS

3,4,5

Basso rischio di esposizione e coperto da altri controlli della ASVS

4,2,1

coperto da 13.1.4

5,2,8

coperti da altri controlli di convalida e sanificazione

5,3,5

coperti da altri controlli di convalida e sanificazione

7,4,1

coperti dai controlli di logging

8,2,3

coperto da 8.1.1

9,1,1

coperti da 6.2.1 e 9.2.1

1,2,3

coperti da 1.1.4, 1.8.4 e 1.8.2

1,4,4

coperti da 1.1.4, 1.8.4 e 1.8.2

1,5,2

coperti da 1.1.4, 1.8.4 e 1.8.2

1,5,3

coperti da 1.1.4, 1.8.4 e 1.8.2

1,5,4

coperti da 1.1.4, 1.8.4 e 1.8.2

1,9,1

coperti da 1.1.4, 1.8.4 e 1.8.2

1,11,3

coperti da 1.1.4, 1.8.4 e 1.8.2

1,14,1

coperti da 1.1.4, 1.8.4 e 1.8.2

1,14,2

coperti da 1.1.4, 1.8.4 e 1.8.2

1,14,3

coperti da 1.1.4, 1.8.4 e 1.8.2

1,14,4

coperti da 1.1.4, 1.8.4 e 1.8.2

1,14,5

coperti da 1.1.4, 1.8.4 e 1.8.2

1,14,6

coperti da 1.1.4, 1.8.4 e 1.8.2

6,1,2

Coperto da 6.1.1

6,1,3

Coperto da 6.1.1

2,10,2

Coperto da 2.5.4

2,2,1

Coperto da 11.1.4

2,7,3

Coperto da 2.7.2

2,7,4

Coperto da 2.7.2

5,1,2

Coperto dal controllo anti-automazione

6,2,2

algoritmi crittografici approvati non definiti

8,2,1

Coperto da 8.1.1

9,1,2

Coperto da 9.2.1

9,1,3

Coperto da 9.2.1

5,5,1

Coperto da 1.8.2

14,2,1

Coperto da 1.14.6

3,3,4

Questo non vale per le applicazioni che utilizzano AuthN/Z stateless. Accetta il consiglio di NCC Group di rimuovere. Questo deve essere coperto da 3.3.3

ID_req

Descrizione

1,1,4

Verifica la documentazione e la giustificazione di tutti i confini di attendibilità, i componenti e i flussi di dati significativi dell'applicazione.

1,8,1

Verifica che tutti i dati sensibili siano identificati e classificati in livelli di protezione

1,8,2

Verifica che a tutti i livelli di protezione sia associato un insieme di requisiti di sicurezza, come quelli relativi alla crittografia, ai requisiti di integrità, alla conservazione, alla privacy e ad altri requisiti di riservatezza, e che questi siano

applicata all'architettura.

2,1,1

Verifica che le password impostate dagli utenti siano lunghe almeno 12 caratteri

2,5,4

Verifica che non siano presenti account condivisi o predefiniti (ad es. "root",

"admin" o "sa").

4,2,1

Verifica che le API e i dati sensibili siano protetti dagli attacchi IDOR (Insecure Direct Object Reference) che mirano a creare, leggere, aggiornare ed eliminare record, ad esempio creare o aggiornare il record di un'altra persona, visualizzare i record di tutti o eliminare tutti i record.

1,14,6

Verifica che l'applicazione non utilizzi dispositivi non supportati, non sicuri o deprecati

tecnologie lato client come plug-in NSAPI, Flash, Shockwave, ActiveX,

Applelet di Silverlight, NACL o Java lato client.