1. Misure di sicurezza rischio alto

Nel presente documento vengono elencate le misure di sicurezza da implementare per livello di rischio alto.

Nei progetti in cui l'analisi del rischio identifica per una o più categorie STRIDE il livello di rischio ALTO, verranno applicate tutte e sole le misure elencate in questo documento relative alle suddette categorie. Le misure legate al rischio MEDIO delle medesime categorie e tutte quelle legate al rischio BASE sono sempre da applicare.

1.1 Metodologia

Le seguenti misure sono organizzate secondo il THREAT MODEL denominato STRIDE:

1.2 Checklist

È consigliabile compilare una CHECKLIST che permetta ai gruppi di lavoro di documentare e verificare quali misure siano coperte o meno in ogni progetto che richieda di essere gestito seguendo le misure di sicurezza di seguito documentate.

1.3 Legenda

Legenda delle tipologie di ruolo legate al ciclo di vita del software

[PM/SA] = Project Manager o Responsabile Tecnico / Security Architect

[SYS/OPS] = Sistemista o DevOps

[SD] = Software Developer (generico, comprende BE/MOB/FE)

[BE] = Backend Developer

[MOB] = Mobile Developer

[FE] = Frontend Developer

2. SPOOFING

2.1 Funzioni di gestione delle credenziali di accesso

1. [PM/SA] [SD] Prevedere una autenticazione a due fattori. Se non richiesto diversamente dal cliente, viene implementato il primo fattore tramite autenticazione con username e password (elemento di conoscenza) e il secondo fattore un codice OTP associato ad un dispositivo (elemento di possesso, implementazione di riferimento Google Authenticator).

2.2 Trasmissione delle password in rete

Nessuna misura specifica per questo livello di rischio oltre a quelle già identificate per i livelli inferiori.

2.3 Autenticazione: procedura di accesso dell'applicazione

1. [SD] [SYS/OPS] Attivare logging sugli errori di accesso e attivare opportune notifiche/allarmi quando appropriato [ad esempio failures ripetute].

2.4 Autorizzazione: assegnazioni dei privilegi all’utente

Nessuna misura specifica per questo livello di rischio oltre a quelle già identificate per i livelli inferiori.

2.5 Gestione delle sessioni

Nessuna misura specifica per questo livello di rischio oltre a quelle già identificate per i livelli inferiori.

2.6 Controllo degli accessi

Nessuna misura specifica per questo livello di rischio oltre a quelle già identificate per i livelli inferiori.

2.7 Tracing

[PM/SA] [SD] [SYS/OPS] L’attivazione ed il tracciamento per gli eventi di Alarm Detection sono fortemente raccomandati, poichè riguardano alcune delle principali debolezze applicative che, se utilizzate per scopi malevoli, possono comportare un elevato fattore di rischio. Si elencano di seguito alcune misure relative a attacchi DoS:

1. [SD] [SYS/OPS] Validazione Input: si devono tracciare tutti gli input (provenienti da Client o da Server) non conformi con quanto atteso dall’applicativo;

2. [SD] [SYS/OPS] Buffer Overflow: si devono tracciare tutti gli avvisi e/o le eccezioni generate dall’applicativo a fronte di un tentativo di Buffer Overflow);

3. [SD] [SYS/OPS] Sessioni applicative anomale: si devono tracciare le occorrenze di eventi che non rientrano nella corretta gestione delle sessioni applicative, come tentativi massivi di autenticazione, sessioni multiple dell’utente non previste e/o consentite, presenza di cookie con contenuti incomprensibili, referrer errato inconsistente con la funzione o pagina chiamata, etc.;

4. [SYS/OPS] Process Issue: si devono tracciare gli avvisi, generati in ambito Server Applicativo, relativi all’esecuzione di moduli applicativi che risultano diversi in quantità e dimensione rispetto a quanto atteso/definito in fase di progettazione/realizzazione dell’applicativo stesso (ad es. numero eccessivo di istanze duplicate, esecuzione di istruzioni non previste, eccessiva occupazione di memoria, etc.);

5. [SYS/OPS] Funzioni input/output anomale: si devono tracciare i tentativi inaspettati di dichiarazioni di funzioni e/o comandi in input ed in output;

6. [SD] Violazioni delle policy configurate: si devono tracciare le violazioni o i tentativi di bypass delle regole di autorizzazione che definiscono ruolo e permessi assegnati all’utente nonché le operazioni ad esso concesse in base alla tipologia di profilatura.

3. TAMPERING

3.1 Schemi di sicurezza e crittografia

1. [PM/SA] [SD] I dati dell’applicazione memorizzati nel Database o nel File System devono essere cifrati tramite algoritmi con chiave simmetrica pari almeno a 192 bit (inclusi i bit di parità);

2. [PM/SA] [SD] Nell'ottica di rendere l'applicazione conforme agli standard internazionali in materia di sicurezza delle informazioni e protezione dei dati personali è richiesto l’utilizzo esclusivo di algoritmi riconosciuti nell’industria del software. Gli standard internazionali devono essere strettamente seguiti per lo sviluppo di algoritmi crittografici e processi di autenticazione.

3.2 Integrità delle informazioni

[PM/SA] [SD] Tutti i dati di natura critica, conservati e mantenuti dall’applicazione, oltre che cifrati, devono prevedere l’utilizzo di algoritmi di hashing o firma digitale per poterne vagliare l’integrita'/autenticita'. La criticità del dato e la tecnica per preservarne l'integrità andrà concordata e studiata assieme al cliente contestualizzandola allo specifico usecase.

3.3 Cifratura

Tutti i dati personali di natura critica o sensibile ("particolari") conservati e mantenuti dall’applicazione vanno registrati e conservati in modalità cifrata in modo che non siano comprensibili a chi accede senza autorizzazioni e devono prevedere l’utilizzo di algoritmi di hashing o firma digitale per poterne vagliare l’integrità/autenticità. Si dovranno applicare alcune regole:

1. [PM/SA] [SD] Definizione precisa di tutto ciò che deve essere crittografato (incluso dischi rigidi, file, dati provenienti da un database o canali di comunicazione) in base alla forma in cui sono memorizzati i dati personali, i rischi individuati e le prestazioni richieste;

2. [PM/SA] [SD] Definizione del tipo di crittografia da utilizzare (simmetrica o asimmetrica) in base al contesto e ai rischi specifici individuati;

3. [PM/SA] [SD] Adozione di soluzioni di crittografia basate su algoritmi pubblici notoriamente forti;

4. [PM/SA] [SD] Definizione di misure per garantire la disponibilità, l'integrita' e la riservatezza delle informazioni necessarie per recuperare le informazioni perse (incluse le password di amministratore e dati di ripristino). In generale la progettazione del database dedicherà ai dati personali delle tabelle logicamente distinte e solo a quelle applicherà gli algoritmi e le funzioni di cifratura.

3.4 Anonimizzazione

Tutti i dati personali di natura critica o sensibile ("particolari") conservati e mantenuti dall’applicazione vanno registrati e conservati in modalità anonimizzata, cioè svincolando i dati personali dai dati identificativi attraverso un codice di collegamento. A discrezione del responsabile di progetto e di chi analizza il rischio la possibilità di approfondire ulteriormente la tematica tramite la Checklist GDPR EU (opens in a new tab) .

Si dovranno applicare alcune regole:

1. [PM/SA] [SD] Determinare ciò che deve essere anonimo in base al contesto, alla forma in cui vengono memorizzati i dati personali (compresi i campi del database o estratti dai testi) e rischi individuati;

2. [PM/SA] [SD] Anonimizzare permanentemente i dati che richiedono tale criterio di protezione in base alla forma dei dati (inclusi database e record testuali) e i rischi individuati;

3. [PM/SA] [SD] Se questi dati non possono essere anonimizzati in modo permanente, scegliere strumenti (inclusi la cancellazione parziale, la cancellazione, la ricerca di hashing e l'indice) che rispondano innanzitutto alle esigenze funzionali.

4. REPUDIATION

Nel caso vengano effettuate transazioni potenzialmente ad alto valore viene attivato un sistema di audit trail con tecniche per l'immodificabilità e/o controlli di integrita' per prevenire la perdita di dati o della loro integrita'.

4.1 Contenuto dei Log

Il Log deve contenere almeno le seguenti informazioni:

1. [PM/SA] [SD] Un identificativo dell’interessato a cui sono stati modificati i dati ed eventualmente i dati significativi;

2. [PM/SA] [SD] Dati significativi prima e dopo l’evento;

3. [PM/SA] [SD] La postazione o l’IP da cui è stato effettuato;

4. [PM/SA] [SD] Il riferimento temporale dell'evento.

[PM/SA] [SD] [SYS/OPS] Il software deve disporre di un meccanismo che registri le attività di accesso dell’utente, gli indirizzi e le tipologie dei device da cui sono state effettuate le attività, inoltre il software deve prevedere meccanismi di controllo dei device/indirizzi di rete da cui vengono normalmente svolte le operazioni di accesso con segnalazione all'utente di allarmi/warning nel caso avvengano accessi da sorgenti differenti e gestione del flusso di escalation verso gli amministratori di sistema in caso di accessi dichiarati sospetti.

4.2 Tipologie di eventi da registrare (GDPR)

Elenco degli ulteriori eventi da registrare per un livello di rischio medio della minaccia REPUDIATION oltre al livello "medio":

1. [SD] modifica interattiva di un dato personale da parte di un incaricato e nome tabella implicata;

2. [SD] effettuazione di estrazioni massive di dati personali (consentite, ma limitate e controllate nell’utilizzo) con l’eventuale motivazione che l’utente dovrà imputare interattivamente prima di eseguirla.

4.3 Metodo Trace

[SD] [SYS/OPS] Nelle applicazioni Web è obbligatoria la disattivazione lato server del metodo HTTP Trace.

4.4 Profili utente

Nessuna misura specifica per questo livello di rischio oltre a quelle già identificate per i livelli inferiori.

4.5 Protezione dei sorgenti e delle librerie

[FE] L'offuscamento del codice viene applicato al frontend web solo per questo livello di rischio.

4.6 Operazioni su dati personali (GDPR): sospensione credenziali

1. [SD] Nel caso il Titolare del trattamento (per il tramite del suo DPO) abbia normato automatismi per NON utilizzo prolungato delle credenziali da parte di un utente, il software deve prevedere funzioni che eseguano, in automatico o con attività manuale, la sospensione dell'account con opportune procedure di riattivazione disponibili o la cancellazione del nominativo in base a quanto dichiarato nell’informativa. Nei casi in cui venga previsto e disposto che i dati personali siano automaticamente cancellati o siano anonimizzati in modo irreversibile, nel caso debbano continuare a persistere per motivi statistici o amministrativi, il software deve mettere a disposizione opportune funzionalità di ausilio all'operazione.

5. INFORMATION DISCLOSURE

5.1 Separazione dei dati personali (GDPR)

[PM/SA] [SD] I dati collegati ad una persona fisica devono essere partizionati su tre livelli: dati personali identificativi, altri dati personali, dati relativi all’applicazione in modo da ridurre la possibilità che i dati personali possano essere correlati e che possa verificarsi una violazione di tutti i dati personali. I database sono progettati in modo da facilitare le operazioni di anonimizzazione, pseudonimizzazione, modifica e cancellazione dei dati personali (specificare dettagliatamente le operazioni di progettazione da mettere in campo).

5.2 Controllo delle informazioni dei messaggi di errore

Nessuna misura specifica per livello di rischio alto oltre quelle già identificate per base, basso e livello medio.

6. DENIAL OF SERVICE

Nessuna misura specifica per livello di rischio alto oltre quelle già identificate per base, basso e livello medio.

7. ELEVATION OF PRIVILEGE

Nessuna misura specifica per livello di rischio alto oltre quelle già identificate per base, basso e livello medio.

8. Library weakness

Per il livello di RISCHIO ALTO va previsto un processo di analisi e gestione delle vulnerabilità legate alle librerie di terze parti utilizzate nel software proprietario.