Aggiornamenti CASA

Aggiornamento 29-03-2023

Per allinearsi alle tendenze e alle best practice del settore, il gruppo di lavoro dell'App Defense Alliance (ADA) ha condotto sessioni di revisione nel primo trimestre del 2023 per aggiornare, semplificare e standardizzare le procedure di test CASA. In base a queste sessioni di lavoro, i requisiti e la procedura CASA sono stati aggiornati come segue:

  • I requisiti CASA sono stati aggiornati da 134 a 73 (vedi i dettagli di seguito).

  • Per superare la valutazione CASA, un'applicazione deve superare o soddisfare tutti i 73 requisiti CASA, indipendentemente dalla classificazione CWE.

  • Descrizioni dei livelli aggiornate per includere il livello 2 condotto in laboratorio.

  • Aggiunte informazioni sull'assicurazione per ogni livello.

  • Aggiornamento minore per semplificare la procedura di scansione autonoma di livello 2.

Aggiornamento dei requisiti CASA

  • L'elenco aggiornato dei requisiti attuali è disponibile qui

  • Sono stati rimossi i seguenti requisiti


req_id

Feedback del gruppo di lavoro

8.1.6

Rivaluterei questo requisito per renderlo più attuabile (ad es. i backup devono essere conservati solo per un periodo di tempo X, i backup devono essere monitorati per furto/corruzione, i backup devono essere controllati regolarmente per confermare la loro capacità di essere spostati di nuovo in produzione). L'ipotesi attuale è troppo generica e richiederebbe una definizione più precisa.

5.1.4

Duplicato di altri scenari di test. Questo è un caso di test che richiede molto impegno e offre poco valore. Consigliato per la rimozione.

7.3.3

Duplicato di altri scenari di test. Questo è un caso di test che richiede molto impegno e offre poco valore. Consigliato per la rimozione.

1.2.2

rimuovere a causa della copertura in altri requisiti, ad esempio 4.1.1

2.2.4

Rimuovi il requisito in quanto è coperto dalla sezione 4.3.1

(4.3.1 Verifica che le interfacce amministrative utilizzino un'autenticazione a più fattori appropriata per

impedire l'utilizzo non autorizzato), che copre la resistenza all'usurpazione contro il phishing nelle interfacce di amministrazione e in altri percorsi di accesso interni

2.2.5

Rimuovi perché mTLS non è supportato dalla maggior parte dei CSP e la maggior parte degli sviluppatori che hanno eseguito test per CASA utilizzerà l'autenticazione basata su password

2.4.3

Lo standard così com'è scritto non è abbastanza specifico da essere applicabile

2.4.5

Requisito rimosso nella versione 5 di ASVS e gli algoritmi di hashing consigliati nella sezione 2.4.1 non possono soddisfare questo requisito

2.7.5

Test non fattibile in quanto potrebbe richiedere un'analisi di fornitori OOB di terze parti. Il rischio è basso in quanto il codice di autenticazione ha una durata breve.

2.8.2

requisito è pertinente solo alle soluzioni MFA personalizzate, coperte anche dai punti 6.4.2 e 6.4.1

2.8.5

Rimuovi il requisito in quanto è coperto anche dal punto 2.7.6. La registrazione dei tentativi non riusciti è coperta dal requisito di logging dell'ASVS.

2.8.6

L'OTP fisica a livello di applicazione non è un caso d'uso comune, questa richiesta è necessaria per le interfacce di amministrazione. Tuttavia, il requisito 4.3.1 (Verifica che le interfacce amministrative utilizzino l'autenticazione a più fattori appropriata per impedire l'utilizzo non autorizzato) copre l'autenticazione MFA per le interfacce amministrative e coprirà questo rischio

2.9.1

Questo requisito copre i dispositivi fisici in base all'ASVS (i token di sicurezza crittografici sono smart card o chiavi FIDO, in cui l'utente deve collegare o accoppiare il

dispositivo crittografico al computer per completare l'autenticazione. I verificatori inviano un nonce di verifica al

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

chiave crittografica archiviata), rendendo questo requisito fuori dall'ambito di CASA, in quanto il rischio di autenticazione dei dispositivi fisici è coperto dal punto 4.3.1 ai fini dell'autenticazione a più fattori (fisica o software).

2.9.3

Questo requisito copre i dispositivi fisici in base all'ASVS (i token di sicurezza crittografici sono smart card o chiavi FIDO, in cui l'utente deve collegare o accoppiare il

dispositivo crittografico al computer per completare l'autenticazione. I verificatori inviano un nonce di verifica al

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

chiave crittografica archiviata), rendendo questo requisito fuori dall'ambito di CASA, in quanto il rischio di autenticazione dei dispositivi fisici è coperto dal punto 4.3.1 ai fini dell'autenticazione a più fattori (fisica o software).

2.10.1

Il requisito è in contraddizione con il punto 2.10.2

2.10.3

Coperto dalla sezione 2.4.1 (Verifica che venga utilizzata una delle seguenti funzioni di hashing della password quando viene memorizzata la password dell'utente per l'applicazione: argon2id, scrypt, bcrypt o PBKDF2), che copre il rischio di attacchi offline e di archiviazione delle password.

2.10.4

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

3.2.3

Coperto dai punti 3.4.1, 3.4.2 e 3.4.3

3.5.1

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

4.3.3

La richiesta è coperta dall'autenticazione a più fattori per le interfacce amministrative e l'accesso con privilegi

5.1.3

Questa richiesta è coperta da altri requisiti di convalida dell'input e se la mancanza di convalida non introduce una vulnerabilità effettiva della logica aziendale, allora può essere di gravità inferiore. Ad esempio, la mancata convalida corretta del numero di telefono comporta solo la visualizzazione errata del numero di telefono nella pagina delle informazioni, che non ha implicazioni dirette per la sicurezza.

5.1.4

Questa richiesta è coperta da altri requisiti di convalida dell'input e se la mancanza di convalida non introduce una vulnerabilità effettiva della logica aziendale, allora può essere di gravità inferiore. Ad esempio, la mancata convalida corretta del numero di telefono comporta solo la visualizzazione errata del numero di telefono nella pagina delle informazioni, che non ha implicazioni dirette per la sicurezza.

5.3.2

La parte di questo requisito che specifica che ogni carattere Unicode è valido può rendere difficile il test. Non tutte le applicazioni includeranno un modulo di testo sufficientemente grande da contenere tutti i caratteri Unicode. Inoltre, non sono supportati determinati sistemi operativi e strumenti di hacking per l'intero spazio Unicode, il che ti impedisce di eseguire il test anche se il server lo supporta. Valore di sicurezza complessivo discutibile. Originariamente inclusa nella versione beta, ma rimossa a causa di problemi durante i test.

6.2.5

coperti dai punti 6.2.4 e 6.2.3

6.2.6

coperti dai punti 6.2.4 e 6.2.3

6.3.1

coperti dai punti 6.2.4 e 6.2.3

6.3.3

coperti da altri requisiti di generazione di numeri casuali.

7.1.2

coperto dalla sezione 7.1.1

7.1.3

coperto dalla sezione 7.1.1

7.3.1

coperto dalla sezione 7.1.1

7.3.3

coperto dalla sezione 7.1.1

8.1.3

È difficile descrivere quali sono i parametri accettabili o necessari. Non è un caso testabile. Che cosa costituisce necessità? Come determineremo se un'eccezione è valida? Considerato fuori ambito per CASA

8.3.3

Non è un requisito verificabile, pertinente alle norme sulla privacy e ai termini di servizio e non alla sicurezza dell'applicazione. Si tratta di una revisione legale e di conformità che non rientra nell'ambito di CASA

8.3.6

Il controllo è specifico del sistema (variante Windows/Linux) e del dispositivo e nella maggior parte dei casi non è un controllo dell'applicazione.

8.3.8

coperti dalle versioni 1.8.1, 1.8.2 e 1.1.4

9.2.5

coperti dalle revisioni delle norme di registrazione e dalla sezione 8.3.5 dell'applicazione.

10.1.1

Coperto dalla revisione dell'architettura e rappresenta una best practice consigliata. Il requisito non è testabile

10.2.3

Non è possibile farlo in un lasso di tempo ragionevole. Qualsiasi codice strano deve essere documentato e rivisto, tuttavia l'impostazione dell'attività specifica per garantire che non siano presenti backdoor richiederebbe una revisione approfondita del codice riga per riga e non garantisce che non siano presenti backdoor.

Difficoltà a testare funzioni dannose ben progettate

10.2.4

Nessun modo possibile per eseguire il test. Non è possibile farlo in un lasso di tempo ragionevole. Qualsiasi codice strano deve essere documentato e rivisto, tuttavia l'impostazione dell'attività specifica per garantire che non siano presenti backdoor richiederebbe una revisione approfondita riga per riga del codice e non garantisce che non siano presenti backdoor.

Difficoltà a testare funzioni dannose ben progettate

10.2.5

Nessun modo possibile per eseguire il test. Non è possibile farlo in un lasso di tempo ragionevole. Qualsiasi codice strano deve essere documentato e rivisto, tuttavia l'impostazione dell'attività specifica per garantire che non siano presenti backdoor richiederebbe una revisione approfondita riga per riga del codice e non garantisce che non siano presenti backdoor.

Difficoltà a testare funzioni dannose ben progettate

13.1.1

Coperto da 5.2.6 e 5.3.9

12.3.1

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

12.3.3

Coperto da 5.2.6 e 5.3.9

12.3.6

coperti dai punti 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 dai punti 10.3.2, 12.4.1 e 12.4.2

13.1.5

Questa richiesta è coperta da altri requisiti di convalida dell'input e se la mancanza di convalida non introduce una vulnerabilità effettiva della logica aziendale, allora può essere di gravità inferiore. Ad esempio, la mancata convalida corretta del numero di telefono comporta solo la visualizzazione errata del numero di telefono nella pagina delle informazioni, che non ha implicazioni dirette per la sicurezza.

13.2.2

Questa richiesta è coperta da altri requisiti di convalida dell'input e se la mancanza di convalida non introduce una vulnerabilità effettiva della logica aziendale, allora può essere di gravità inferiore. Ad esempio, la mancata convalida corretta del numero di telefono comporta solo la visualizzazione errata del numero di telefono nella pagina delle informazioni, che non ha implicazioni dirette per la sicurezza.

13.2.3

Coperto da 4.2.2

13.2.5

Questa richiesta è coperta da altri requisiti di convalida dell'input e se la mancanza di convalida non introduce una vulnerabilità effettiva della logica aziendale, allora può essere di gravità inferiore. Ad esempio, la mancata convalida corretta del numero di telefono comporta solo la visualizzazione errata del numero di telefono nella pagina delle informazioni, che non ha implicazioni dirette per la sicurezza.

13.3.1

Questa richiesta è coperta da altri requisiti di convalida dell'input e se la mancanza di convalida non introduce una vulnerabilità effettiva della logica aziendale, allora può essere di gravità inferiore. Ad esempio, la mancata convalida corretta del numero di telefono comporta solo la visualizzazione errata del numero di telefono nella pagina delle informazioni, che non ha implicazioni dirette per la sicurezza.

14.4.1

coperto dalla sezione 5.3.1

14.4.2

Questa richiesta è coperta da altri requisiti di convalida dell'input e se la mancanza di convalida non introduce una vulnerabilità effettiva della logica aziendale, allora può essere di gravità inferiore. Ad esempio, la mancata convalida corretta del numero di telefono comporta solo la visualizzazione errata del numero di telefono nella pagina delle informazioni, che non ha implicazioni dirette per la sicurezza.

14.4.3

coperti dalle versioni 5.2.7 e 5.3.3

14.4.5

coperti dai punti 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 per casa in quanto il rischio è coperto da altri controlli anti-automazione

2.5.6

coperto da un'altra protezione della password

3.1.1

Rischio basso di esposizione e coperto da altri controlli di ASVS

3.2.1

Rischio basso di esposizione e coperto da altri controlli di ASVS

3.4.4

Rischio basso di esposizione e coperto da altri controlli di ASVS

3.4.5

Rischio basso di esposizione e coperto da altri controlli di ASVS

4.2.1

coperto dalla sezione 13.1.4

5.2.8

coperti da altri controlli di convalida e pulizia dell'input

5.3.5

coperti da altri controlli di convalida e pulizia dell'input

7.4.1

coperto dai controlli di logging

8.2.3

coperto dalla sezione 8.1.1

9.1.1

coperti dai punti 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

Coperta da 6.1.1

6.1.3

Coperta da 6.1.1

2.10.2

Coperto dalla sezione 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 dalla versione 1.8.2

14.2.1

Coperto dalla versione 1.14.6

3.3.4

Ciò non vale per le applicazioni che utilizzano l'autenticazione/autorizzazione stateless. Accetta il consiglio di rimozione di NCC Group. Questo dovrebbe essere coperto dal punto 3.3.3



  • Sono stati aggiunti i seguenti requisiti:


req_id

Descrizione

1.1.4

Verifica la documentazione e la giustificazione di tutti i componenti, i limiti di attendibilità 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 tutti i livelli di protezione abbiano un insieme associato di requisiti di protezione, come requisiti di crittografia, requisiti di integrità, conservazione, privacy e altri requisiti di riservatezza e che questi siano

applicato nell'architettura.

2.1.1

Verifica che le password impostate dall'utente contengano 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 i dati sensibili e le API siano protetti da attacchi di riferimento diretto a oggetti non protetto (IDOR) che hanno come target la creazione, la lettura, l'aggiornamento e l'eliminazione di record, ad esempio la creazione o l'aggiornamento del record di un'altra persona, la visualizzazione dei record di tutti o l'eliminazione di tutti i record.

1.14.6

Verifica che l'applicazione non utilizzi funzionalità non supportate, non sicure o obsolete

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

Silverlight, NACL o applet Java lato client.