Misure di sicurezza
Rischio medio

1. Misure di sicurezza rischio medio

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

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

1.1 Metodologia

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

THREATSCOPE
SPOOFINGAuthenticity
TAMPERINGIntegrity
REPUDIATIONNon-repudiability
INFORMATION DISCLOSUREConfidentiality
DENIAL OF SERVICEAvailability
ELEVATION OF PRIVILEGEAuthorization

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. [SD] I dati non devono mai apparire in forma non cifrata;

  2. [SD] Le chiavi di cifratura non devono essere mai inserite staticamente nel codice

  3. Le credenziali di accesso all’applicazione devono imporre criteri adeguati al tipo di dati trattati. In generale:

    • [PM/SA] La password accettabile, ove non sia presente una specifica policy, deve almeno essere composta da n° 8 caratteri oppure, nel caso in cui lo strumento elettronico non lo permetta, da un numero di caratteri pari al massimo consentito e deve essere composta da un insieme di caratteri alfabetici minuscoli, maiuscoli, numerici e speciali.
    • [PM/SA] L’applicazione deve gestire le password in modo da forzare la loro sostituzione al primo accesso da parte dell’utente e periodicamente (almeno ogni n° 6 mesi o n° 3 mesi nel caso di trattamenti di dati personali particolari o giudiziari);
    • [PM/SA] L’applicazione deve accettare solo un numero limitato di tentativi di accesso errati (max 5) e successivamente disabilitare l'account per 60 minuti (valutare policy simili ma più restrittive per il livello medio);
    • [PM/SA] [SD] [SYS/OPS] L'applicazione deve impedire attacchi brute force e in generale automatici impedendo tentativi di login troppo ravvicinati ed effettuati da IP inusuali (es. utilizzo WAF)
    • [PM/SA] [SD]Le password mantenute dall’applicazione devono essere conservate in forma cifrata (hash);
    • [SD] Le password/dati, se conservate, devono esserlo in maniera sicura (Keychain/Preferences Criptate) ^^
    • [PM/SA] [SD] Account di default e relative password devono essere cancellati o opportunamente configurati/disabilitati.
  1. [PM/SA] [SD] Nel caso di utilizzo di cifratura (sia con chiave simmetrica che asimmetrica) i secret/chiavi private dei certificati devono essere conservate in forma cifrata. Le informazioni sulle password e sulle chiavi private devono risiedere in container (es. aree del File System, tabelle del Database, ecc.) differenti rispetto ai dati dell’applicazione;
  1. [PM/SA] [SD] Le password memorizzate sotto forma di hash (es. MD5/SHA-1, ecc.), devono prevedere l’introduzione di un ulteriore fattore casuale durante la loro generazione (cosiddetto Salt);
  1. [PM/SA] [SD] L’applicazione sviluppata non deve utilizzare meccanismi di autenticazione con chiave condivisa (Pre-Shared Secret).
  1. [PM/SA] [SD] La password accettabile non può essere la stessa già utilizzata tra le ultime 5 e non deve corrispondere a delle tipologie di password comprese in una "password syntax black list"
  1. [PM/SA] [SD] L'applicazione deve impedire attacchi brute force e in generale automatici impedendo tentativi di login troppo ravvicinati, per implementare questo l’applicazione deve accettare solo un numero limitato di tentativi di accesso errati (max 5) e successivamente disabilitare l'account per 60 minuti;
  1. [PM/SA] [SD] L’applicazione deve permettere di registrare la data di ultimo accesso dell’utente dimodoché, nel caso in cui le credenziali non siano utilizzate per un certo periodo di tempo, queste siano automaticamente bloccate e sbloccabili solo con l’intervento dell’amministratore;

2.2 Trasmissione delle password in rete

  1. [PM/SA] [SD] Prevedere l’aggiunta di una chiave segreta alla hash, in modo tale da consentire la convalida della password solo a coloro che la conoscono. Ciò è possibile solo cifrando l’hash con algoritmo AES oppure includendo la chiave segreta nell’hash utilizzando poi un algoritmo di hashing come HMAC;
  1. [PM/SA] [SD] È sconsigliato l’utilizzo di funzioni di hash crittografico veloce come MD5, SHA-1, SHA-256, SHA-512, RipeMD, WHIRLPOOL, SHA-3, ecc.
  1. [SD] Per quanto riguarda la trasmissione delle password in rete è necessario utilizzare adeguati protocolli crittografici (es. Transport Layer Security, Secure Socket Shell, ecc.) che impiegano algoritmi di derivazione delle chiavi crittografiche basata su password detti anche algoritmi di Slow Hashing (es. PBKDF2, Scrypt, Bcrypt, ecc.) i quali, rallentando di molto la funzione di hashing, rendono inefficaci eventuali attacchi di forza bruta per finalità di Password Cracking.

2.3 Autenticazione: procedura di accesso dell'applicazione

La procedura di accesso e Log-On dell’applicazione deve ridurre al minimo le informazioni fornite agli utenti non ancora autenticati e prevedere determinati comportamenti.

In particolare:

  1. [PM/SA] [SD] Deve prevedere l'utilizzo di autenticazione a due fattori, tipicamente username/password e un token. I token dell’applicazione devono essere generati utilizzando algoritmi True Random ed analizzati ogniqualvolta l’utente richiede autorizzazione a svolgere una qualsiasi azione, al fine di determinarne permessi e privilegi.
  1. [PM/SA] [SD] Non deve, con messaggi specifici, fornire alcun tipo di aiuto né rendere comprensibile se il processo di autenticazione è fallito a causa del nome utente o della password errata;
  1. [PM/SA] [SD] Deve visualizzare un messaggio di avviso sulle sanzioni derivate dall’accesso fraudolento all’applicazione;
  1. [PM/SA] [SD] Deve visualizzare all'utente, al completamento della procedura di autenticazione, la data, l’ora e le informazioni sull’ultimo sistema (es. indirizzo IP/FQDN) che ha completato la fase di Log-On per una specifica utenza;
  1. [PM/SA] [SD] Deve visualizzare nella console dell’amministratore o nei file di Log, i dettagli di tutti i precedenti tentativi infruttuosi di accesso per una specifica utenza.
  1. [SD] [SYS/OPS] Attivare logging sugli errori di accesso e attivare opportuni warning di avviso quando appropriato (ad esempio failures ripetute).
  1. [SD] Invalidare la sessione dopo il logout utente.

2.4 Autorizzazione: assegnazioni dei privilegi all’utente

  1. [PM/SA] [SD] Le operazioni degli utenti e le fasi di autorizzazione ed assegnazione dei permessi devono essere subordinate alla regola secondo la quale ogni azione è negata se non espressamente consentita
  1. [SD] L’applicazione non deve assegnare alcun privilegio e/o permesso all’utente fin quando il processo di autenticazione e autorizzazione non è stato completato;
  1. [SD] [SYS/OPS] L’applicazione, in esecuzione, non deve utilizzare privilegi amministrativi. Ove ciò non fosse possibile, minimizzare la richiesta per l’esecuzione delle singole componenti;
  1. [PM/SA] [SD] I privilegi associabili al ruolo dell’utente devono avere una adeguata granularità sia per quanto riguarda l’accesso alle funzioni sia per quanto riguarda l’accesso ai dati, allo scopo di garantire che esso possa accedere solo a dati e funzioni di propria competenza e relativi al proprio incarico;

2.5 Gestione delle sessioni

  1. [PM/SA] [SD] L’applicazione deve prevedere la terminazione automatica della sessione utente dopo un certo periodo configurabile (in base al rischio) di inattività della sessione stessa;
  1. [PM/SA] [SD] Tutte le sessioni riconducibili all’applicazione, svolte dalle utenze amministrative/operative, devono essere supportate da meccanismi di tracciamento idonei e cifrate con algoritmi crittografici. In questo modo si garantisce il non ripudio delle singole sessioni, ovvero la possibilità di determinare nel tempo l’occorrenza o la non occorrenza di un evento.

2.6 Controllo degli accessi

  1. [SD] [FE] Ridurre al minimo l'utilizzo di CORS;
  1. [SD] I modelli di controllo di accesso devono rafforzare la "record ownership" in alternativa ad esempio a permettere che l'utente possa creare, leggere, aggiornare o eliminare qualsiasi record;

2.7 Tracing

  1. [SD] Si devono tracciare tutti i tentativi di accesso a risorse inibite ai servizi come, ad esempio, tentativi di accesso alla root di un server web, modifica a configurazioni per mezzo di credenziali non appropriate, etc.

3. TAMPERING

3.1 Schemi di sicurezza e crittografia

Per quanto riguarda gli schemi di sicurezza e i controlli crittografici occorre adottare le seguenti regole:

  1. [PM/SA] [SD] Le directory contenenti informazioni o dati personali, critici e sensibili, residenti nella Document Root del Web Server devono apparire come cifrate nell’URL del browser lato Client;
  1. [PM/SA] [SD] Le informazioni, i dati o gli allegati trasmessi tramite i Batch Job dell’applicazione (es. sessioni FTP o altri protocolli di rete non cifrati o proprietari), devono utilizzare canali di comunicazione sicuri come SSL o TLS, in cui le chiavi di cifratura simmetriche vengono scambiate all’interno di una comunicazione protetta attraverso algoritmo crittografico asimmetrico (es. RSA con dimensione delle chiavi uguale o superiore a 1024 bit);
  1. [PM/SA] [SD] Le funzioni di importazione e/o esportazione di dati personali e/o sensibili, solo nei casi di assoluta necessità per altre attività di trattamento previste dal titolare o comunque dal proprietario dei dati, devono prevedere la cifratura, attraverso meccanismi adeguati secondo le misure di controllo già definite.
  1. [PM/SA] [SD] Le funzioni di importazione e/o esportazione di dati personali e/o sensibili, solo nei casi di assoluta necessità per attività di analisi, devono prevedere la pseudonimizzazione del file, attraverso meccanismi adeguati.
  1. [PM/SA] [SD] Gli schemi di sicurezza devono essere semplici e ben documentati: è vietata la costruzione di schemi non standard di autenticazione, crittografia o e/o gestione delle chiavi.

  1. [PM/SA] [SD] Il processo di creazione e assegnazione delle chiavi di cifratura dell’applicazione, in base al cifrario utilizzato:

    • Non deve generare Weak Keys (chiavi crittografiche che, utilizzate con uno specifico cifrario, portano l'algoritmo crittografico ad operare in modo improprio);

    • Nel caso di algoritmi di hashing, non deve generare alcuna Collision (situazione che avviene quando due diversi input producono lo stesso output tramite una funzione hash).

3.2 Integrità delle informazioni

[PM/SA] [SD] Nessuna misura specifica per questo livello di rischio, la gestione di questa tematica è delegata al RISCHIO ALTO.

3.3 Input Data Validation e Injection

[SD] L’applicazione deve assicurare, attraverso opportuni meccanismi di convalida, che tutti i parametri in input specificati dall’utente siano congruenti a quanto atteso. In particolare per un livello di rischio MEDIO:

  1. [SD] [FE] [MOB] Verificare la congruità di estensione e dimensione dei file uploadati
  1. [SD] [FE] [MOB] Va verificato sia lato frontend che lato backend che non siano inseriti script potenzialmente dannosi (problematiche di injection).

4. REPUDIATION

Il Regolamento (UE) 679/2106 in materia di protezione dei dati personali (di seguito, il Regolamento) suggerisce che il software che tratta dati personali debba adottare sistemi idonei per la registrazione delle attività che gli utenti effettuano secondo criteri differenziati in base al tipo di trattamento ed al rischio della libertà e dei diritti dei diritti degli interessati.

[PM/SA] Oltre a quanto già riportato nel RISCHIO BASE in ambito di 'Protezione Dati Personali', sono qui riportati degli elementi di contesto non direttamente attinenti la scrittura del software:

  1. [PM/SA] le registrazioni devono essere conservate per un congruo periodo, non inferiore a sei mesi.

  2. [PM/SA] le registrazioni non devono poter essere alterate e quindi deve essere gestito un ambiente protetto garantendone l’integrità.

  3. [PM/SA] le registrazioni devono avere caratteristiche di completezza, inalterabilità e possibilità di verifica della loro integrità.

4.1 Contenuto dei Log

[PM/SA] [SD] Il Log deve contenere almeno le seguenti informazioni:

  1. l’utente soggetto dell’evento;

  2. data ed ora dell’evento;

  3. il tipo codificato di evento

  4. altre eventuali informazioni richieste dal tipo di evento

Durante lo sviluppo del codice vengono inserite particolari funzioni di tracciamento che, operanti in determinati e specifici punti dell’applicativo, permettano la rilevazione e il tracciamento di eventi sospetti o anomali o di frode, significativi per la sicurezza dell’organizzazione.

In seguito, le segnalazioni prodotte e inserite in appositi file di Log, discriminate per mezzo di Tag (es. DETCode) opportuni, possono essere elaborate e utilizzate come fonte per attività di Audit degli eventi di sicurezza.

Questa strategia di rilevazione risulta strettamente necessaria per superare i limiti tecnologici intrinseci delle tecnologie antintrusione commerciali. In particolare, tali tecnologie non permettono:

  1. l’analisi di flussi applicativi di applicazioni di tipo custom (le soluzioni di mercato sono progettate per l’esclusivo utilizzo su applicazioni di tipo commerciale);

  2. l’analisi di flussi applicativi che fanno uso di meccanismi di cifratura delle informazioni;

  3. la rilevazione di vulnerabilità software determinate da errori di input dell’utente;

  4. la rilevazione di vulnerabilità software determinate dall’assenza di controlli applicativi durante le operazioni di allocazione nelle aree di memoria volatile.

4.2 Tipologie di eventi da registrare (GDPR)

Elenco degli eventi da registrare:

  1. [PM/SA] [SD] Log-In e Log-Out di un utente registrato andati a buon fine e falliti;

  2. [PM/SA] [SD] cambio di ruolo di un utente da parte di un amministratore;

  3. [PM/SA] [SD] modifiche alle configurazioni dell’applicazione;

  4. [PM/SA] [SD] accesso ai dati (inserimento, modifica, lettura, rimozione) andati a buon fine e falliti;

  5. [PM/SA] [SD] apertura/lettura di file;

4.3 Metodo Trace

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

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

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

4.6 Operazioni su dati personali (GDPR)

  1. [SD] Le operazioni di "visualizzazione" di insiemi di dati personali da parte di operatori "privilegiati" devono essere regolarmente tracciate. Le operazioni di impersonificazione di utenti da parte di operatori devono essere regolarmente tracciate. Le operazioni di cancellazione di dati personali di utenti, totali o parziali, devono essere regolarmente tracciate.

5. INFORMATION DISCLOSURE

5.1 Separazione dei dati personali (GDPR)

  1. [SD] La struttura E-R del Database deve essere progettata in modo da separare i dati identificativi da altri dati personali collegandoli da chiavi esterne anonime. In questo modo è possibile limitare l'eventuale applicazione di tecniche di cifratura ai soli dati identificativi.
  1. [PM/SA] Il software sviluppato deve sempre permettere la cancellazione dei dati a scadenza (che può essere esplicitamente espressa in fase di consenso o gestita autonomamente dal titolare a seconda del tipo di trattamento e delle finalità). [SD] Per permettere questo TUTTE le tabelle che contengono dati personali devono aggiungere agli attributi del record ALMENO i campi [SD] "DATA CREAZIONE" (obbligatoriamente istanziato), [SD] "DATA SCADENZA" (istanziato nel caso sia esplicitamente definito nel consenso) e [SD] "DATA ULTIMA MODIFICA" (obbligatoriamente istanziato per avere un elemento relativo alla esattezza/affidabilità del dato).

5.2 Controllo delle informazioni dei messaggi di errore

Seppur non strettamente collegati all’attività di attacco, i messaggi di errore o gli alert generati dal server e presentati al client possono contenere informazioni interessanti da utilizzare eventualmente per aumentare le possibilità di successo di altri attacchi.

  1. Le informazioni restituite da script (es. Type mismatch: '[string: "'"]' - /script/anagrafica.asp, line 190 o Microsoft OLE DB Provider for ODBC Drivers error '80040e14' - [Microsoft][odbc sql server driver][SQL Server]Incorrect syntax near the keyword 'or' - /login.asp, line 11)

  2. Le informazioni restituite dal tracing dello stack(es. applicazioni in .net o java spesso descrivono lo stack dell’errore che può svelare i nomi delle classi e dettagli su package/framework che in un qualche modo hanno avuto a che fare con l’errore e dare indicazioni per attacchi di tipo Denial of Service).

  3. Le informazioni restituite dai messaggi di debug (impostare sempre a "false" il valore della proprietà "DEBUG" o operazioni simili)

  4. [PM/SA] [SD] Utilizzare sempre encryption per trasmettere dati tra i vari componenti applicativi o con gli utenti;

  1. [SYS/OPS] Garantire che il web server non fornisca response headers or background information che rivelino dettagli tecnici a proposito di tecnologie utilizzate dal backend, versioni o dettagli di setup;
  1. [SD] [SYS/OPS] Garantire che tutti i servizi attivi sulle porte del server non rivelino informazioni su build e versioni di componenti software di sistema;
  1. [SD] Garantire che tutte le eccezioni siano gestite e che non siano riportate informazioni tecniche nei messaggi di errore;

6. DENIAL OF SERVICE

Una condizione di Denial Of Service viene comunemente causata da un aggressore che sfrutta errori di programmazioni riconducibili a problematiche di Overflow o come effetto di un attacco non andato a buon fine, ovvero che mirava originariamente all’esecuzione di uno shellcode.

[SD] Tutto l’input utente processato dall’applicazione deve passare per funzioni sicure di gestione delle stringhe che ne prevedono il bound-checking. L’applicazione deve risultare immune da problematiche di tipo stack overflow, off by one/off by few overflow o heap overflow. Quindi nei sorgenti dell’applicazione il formato delle stringhe deve essere sempre specificato nei parametri delle funzioni che lo prevedono e mai dato per assunto. L’applicazione deve risultare immune da problematiche di tipo format string overflow.

[SD] In fase di comparazione di due variabili numeriche dove il contenuto di almeno una deriva da input utente, il casting o l’assegnazione di un valore da una variabile all’altra deve avvenire in base alla stessa tipologia (ad esempio assegnare un valore intero a una variabile di tipo short è un errore). L’applicazione deve risultare immune da problematiche di tipo integer overflow, cambi di segno, troncamento di valori numerici o altri errori di programmazione logico-computazionali.

7. ELEVATION OF PRIVILEGE

7.1 Remote code execution

Questa casistica riguarda casi in cui un processo elabora un input utente non validato. Le mitigazioni da applicare sono:

  1. [PM/SA] [SD] Se un processo esegue dati di input i dati devono essere validati in modo che sia preclusa la possibilità di eseguire codice generico

8. Library weakness

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

Rischio baseRischio alto