Sicurezza

Verificato rispetto a OWASP ASVS 5.0 Level 2

ASVS è lo standard di sicurezza applicativa di OWASP. Il Level 2 è il livello pensato per le applicazioni che trattano dati sensibili. Abbiamo esaminato uno per uno tutti i 253 requisiti del Level 1 e del Level 2 e per ogni requisito abbiamo registrato qual è lo stato — e perché.

Lo stato

222 dei 253 sono conclusi oppure non applicabili, con motivazione. I restanti 31 sono elencati uno per uno nel nostro registro — motivo compreso.

Questi numeri sono ricavati dal registro e verificati a ogni release. Non possono quindi invecchiare in silenzio mentre il registro cambia.

Cosa significa in concreto

Uno standard è astratto. Ecco cosa c'è dentro nella pratica:

• Separazione tra organizzazioni

  Tutte le query su processi, rischi e masterdata passano da un confine tenant che impone l'organizzazione e si chiude se il contesto manca — un confine dimenticato produce un errore, mai in silenzio i dati di qualcun altro. Un utente di un'organizzazione non può recuperare i dati di un'altra, nemmeno indovinando un id.

• Ruoli e permessi sul server

  Chi può fare cosa viene deciso sul server, non nel browser. Un lettore non può modificare nulla dei contenuti, nemmeno facendo ricomparire un pulsante.

• Verifica in due passaggi

  Disponibile tramite un'app di autenticazione, con codici di backup. La offriamo ma non la imponiamo; quella scelta è motivata nel registro.

• Le password compromesse vengono rifiutate

  Quando imposti una password la confrontiamo con il database di Have I Been Pwned. Se compare lì dentro, non è utilizzabile.

• Percorsi di accesso limitati

  I percorsi in cui transitano le credenziali hanno un limite, e quel limite risiede nel database — non nella memoria di un singolo processo, così che un riavvio o un secondo container non lo azzeri.

• Content-Security-Policy rigorosa

  Con un nonce per pagina, così che uno script iniettato non arrivi mai in esecuzione.

• Sessioni

  Il cookie di sessione è HttpOnly, Secure e SameSite. Vale una durata massima assoluta, e le operazioni sensibili richiedono di nuovo la tua password.

• Audit trail e security logging

  Le modifiche ai tuoi processi, ruoli, rischi e controlli vengono registrate con chi, cosa e quando. Un'autorizzazione negata viene registrata a parte — un login fallito è rumore, ma chi con una sessione valida prova a fare qualcosa che non gli è permesso è un segnale.

• Catena di fornitura

  Manteniamo una SBOM delle dipendenze che eseguiamo in produzione, e la pipeline analizza automaticamente ogni modifica alla ricerca di secret committati per errore.

Per capitolo

I 17 capitoli dello standard, con lo stato per capitolo. I titoli dei capitoli sono i nomi dello standard stesso e li lasciamo non tradotti — così restano rintracciabili.

Cosa è ancora aperto

Pubblichiamo anche ciò che non è finito — altrimenti trasparenza è solo una parola da marketing. In questo momento ci sono 10 requisiti aperti e 21 parziali. Il baricentro sta nei requisiti infrastrutturali che abbiamo consapevolmente accettato sulla base del nostro modello delle minacce, a cui si aggiungono alcune scelte di policy che richiedono ancora una decisione, una singola deviazione che risiede in una libreria esterna, e un residuo di hardening che completiamo noi stessi. Ogni punto è nel registro con la sua motivazione — compresi i punti che vogliamo chiudere per primi.

E NIS2?

Se la tua organizzazione rientra in NIS2, devi avere una presa dimostrabile sui tuoi processi, sui tuoi rischi e sulla tua catena. Registrare esattamente questo è ciò per cui Proceshuis è stato costruito: processi, ruoli tramite RASCI, rischi e controlli in un unico sistema, con storico delle versioni e un audit trail su quei contenuti che mostra chi ha modificato cosa e quando.

Il registro completo

Tutti i 253 requisiti con la motivazione riga per riga, compresi i punti aperti e il perché siano aperti. Lo condividiamo su richiesta: contiene dettagli di implementazione che non hanno posto su una pagina pubblica.