Consigli per un’azienda a prova di attacco

Molto spesso, quando si parla di Information security, si leggono studi e articoli che possono impaurire, per dati e contenuti tecnici. Tuttavia, la letteratura e le attività di studio correlate non devono essere tacciati di terrorismo, anzi: devono essere presi come spunti di informazione. L’obiettivo di questo articolo è di fornire alcune indicazioni su come orientarsi nell’analisi delle problematiche.

Identificare le risorse da proteggere

È sicuramente il primo passo. Dato per assunto che esistono varie accezioni del termine sicurezza, uno dei fattori fondamentali da inquadrare è quello delle risorse da proteggere. La pratica consulenziale ritiene opportuno commensurare la sicurezza al valore delle risorse stesse. Parte di questo valore è costituita dalla quantificazione della risorsa al momento della sua valutazione (di solito si attribuisce detto valore durante la procedura di auditing). Altra parte è costituita dalla quantificazione del valore del lavoro necessario in fase di disaster recovery (la fase di ricostruzione del patrimonio informativo). A questa seconda porzione va affiancata la quantificazione dello sforzo necessario per rendere nuovamente “trusted” (degna di affidabilità) la struttura compromessa.

Pensare come un difensore

Molte sessioni di training vengono impostate in maniera errata. Si bada, infatti, a trasmettere all’allievo (che poi è un amministratore o un security manager) come effettuare un attacco, dando per assunto che lo stesso operatore provveda a pianificare la contromisura. Non so quanto ci sia di malafede in questo (quanti di voi sono rimasti attratti da brochure del tipo “vi insegnamo a penetrare il vostro sistema per difenderlo meglio”?), ma i sintomi che si tratti di un appoccio errato al problema sono almeno due. Il primo è che, in questo modo, non si impara a riconoscere un attacco in corso perché si presta poca attenzione alla fase di log analisys. Il secondo, invece, è che un attacker non sempre ha uno skill e una predisposizione a essere un buon defender, anzi, il contrario.

Per questo è consigliabile pensare come quest’ultimo, non come un lamer.

La sicurezza come un processo

Questo è l’approccio corretto. L’Information security non è una mera installazione di un box o di una qualsiasi applicazione. È un insieme coordinato di politiche, analisi, verifiche di vunerabilità e, ovviamente, di tecnologie. Il tutto gestito da uomini e, quindi, soggetto alla debolezza dell’errore umano. Di base, un progetto di questo tipo è composto da un’analisi della situazione basata su un confronto tra lo scenario e la conoscenza delle problematiche. L’analisi è seguita da una sintesi, cioè da un condensato delle notizie acquisite con una parte propositiva, cioè una soluzione di tipo organico.

Il processo termina con una valutazione di quanto analizzato e proposto, finalizzata al riscontro delle aspettative. In caso di mancata compliance, questa fase comprenderà una rielaborazione di quanto pianificato in precedenza.

Imparare quanto più possibile sugli argomenti di interesse

Internet è piena di informazioni su tutto. Reperire dette notizie può essere semplice o impossibile, a causa dell’incredibile mole di notizie relative ai vari argomenti. Uno degli scopi da raggiungere è reperire il massimo numero di informazioni possibile con la massima organicità e precisione.

Gestire con flessibilità la fase di design

Specialmente nei nuovi ambienti, la fase di architecture design può essere più laboriosa del previsto. Questo perché molto spesso non si valutano alcuni aspetti contingenti e alcune situazioni non prevedibili. Il consiglio che viene dato in questi casi è di dedicarsi (magari un poco di più del previsto) alla fase di design e di analisi, piuttosto che a quella di implementazione vera e propria. A quanto sopra bisogna aggiungere un aspetto metodologico non indifferente, che consiste nell’effettuare una verifica di quanto disegnato con particolare riferimento agli aspetti “patologici” cioè le potenziali vulnerabilità che potrebbero interessare l’architettura nel suo complesso e/o eventuali porzioni di questa.

Effettuare l’implementazione in maniera conforme al design

In qualsiasi momento si deve poter verificare che l’implementazione sia identica a quella che è stata disegnata. Questo perché, in caso di riconoscimento di bug, deve essere possibile restringere il campo d’azione in qualsiasi momento e con la massima reattività. Inoltre, soprattutto nella fase di verifica delle vulnerabilità e di security assessment, deve essere possibile correlare il flaw (difetto) stesso alla fase di design, in modo tale da modificare anche quella.

Un continuo controllo di quanto implementato

Il fine primario di quanto sopra è la ricognizione immediata di un qualsiasi cambiamento nella struttura. Appare importante rammentare che una semplice addizione di un componente (finanche un pc) alla topologia può costituire un potenziale pericolo per tutta la struttura. Per questo motivo bisogna avere una mappa precisa delle configurazioni in qualsiasi momento. Anche una mutazione apparentemente temporanea può avere le sue potenziali controindicazioni. È stato più volte notato che detti “cambiamenti temporanei” diventano spesso definitivi e che, ancora più frequentemente, si corre il rischio di perdere il controllo di tutta la piattaforma. Perdere il controllo e la mappatura della topologia significa avere, in caso di attacco, grosse difficoltà di rintraccio del punto di entrata.

Pratica continua sull’implementazione

Un monitoraggio continuo, magari corroborato da una serie di “esercitazioni di allarme”, è la via giusta. Questo, infatti, consente agli operatori di verificare anche sul campo eventuali procedure di incident handling e, soprattutto, appurare che la rispettiva comprensione dei princìpi di funzionamento dei meccanismi di sicurezza sia corretta. Questo fa la differenza tra due strutture che utilizzano la stessa piattaforma tecnologica di protezione, con skill differenti.

Rendere semplici le operazioni di routine

Chi amministra sistemi sa che un versante “duro” delle operazioni è costituito dagli utenti di postazione. E questo lo si comprende da due elementi. Il primo è costituito dalle policy (politiche) di sicurezza, che spesso non sono comprensibili a chi di informatica non se ne intende. Questo comporta che, in caso di incidente più o meno doloso, l’attribuzione di determinate responsabilità all’utente può dimostrarsi difficile. Altro aspetto è da attribuirsi al lato pratico. Un utente che non comprende appieno le metodiche operative di routine può generare più problemi che altro. E questo vale anche per gli utenti con privilegi di amministrazione gruppi. Questa categoria può anche non appartenere al team degli amministratori, ma da questi ha ricevuto delle deleghe precise a coordinare porzioni di gruppi. Per questo può essere di importanza strategica semplificare le operazioni di routine, anche a questi livelli. Ricordate che un’architettura è da considerarsi riuscita non solo in ordine all’efficacia in termini di detection e di reazione, ma anche in termini di semplicità di utilizzo e management, a tutti i livelli.

Rendere difficili le operazioni non desiderate

Contrariamente a quanto detto nel paragrafo precedente, l’obiettivo, in questo caso, è contrario: rendere difficili, cioè, le operazioni che non si desidera vengano effettuate. Per fare ciò lo sforzo maggiore deve essere effettuato in sede di architecture design. Si può provvedere, pertanto, ad effettuare un’opera di “interdizione pratica” di alcune attività o servizi che vengono classificati come a rischio. Questa attività si può estrinsecare con una operazione a livello perimetrale, o a livello di policy. Altra possibiltà consiste nel disegnare un’archiettura che renda difficili i cambiamenti per gli operatori non autorizzati.

Semplificare le operazioni di detection

Più la rete risulta estesa, più il numero di informazioni aumenta in maniera esponenziale. Questo significa, di base, una concreta difficoltà nel gestire gli eventi e catalogare gli stessi in maniera organica. La soluzione a questo problema, tanto reale quanto pericoloso, consiste nel prevedere all’interno dell’infrastruttura un sistema avanzato di log analisys/correlation. Questo dovrebbe rendere possibile un’attività di ricostruzione/individuazione degli eventi, strumentale alla detection di attacchi in corso o di tipo post mortem, cioè susseguente alla violazione.

Dedicare massima cura alla gestione dei log file

Non sempre risulta possibile garantire una detection in tempo reale di un attacco in corso. Questa è una caratteristica che si “arrogano” alcuni strumenti di intrusion detection, ma, come più volte la letteratura ha comprovato, la concezione del real time è vista in senso molto lato. Per questo un’importanza fondamentale è data alla gestione dei file di log e alla consequenziale correlation/analisys. I log devono essere gestiti in maniera estremamente granulare e protetta, garantendone l’inattaccabilità dall’esterno e la consequenziale integrità.

Testare tutto più volte all’anno

Tutto quello che è stato progettato e implementato va, contestualmente, mappato. In base a questo, poi, bisogna effettuare una pianificazione di test articolata e distribuita nel tempo. Bisognerà porsi domande sulla reale efficacia del packer filtering implementato, per esempio, verificare l’effettiva resistenza della parte perimetrale, e la corretta configurazione dell’infrastruttura.

Quanto sopra costituisce un health check (verifica dello stato di salute) che va analizzato con grande scrupolo. Questo processo va ripetuto, con continuità, in profondità e con senso di autocritica, avvalendosi solo in extrema ratio di parti esterne.

Un unico obiettivo: migliorare

Quello che oltreoceano viene chiamato improvement, da noi può essere identificato nel termine miglioramento. Migliorare il rendimento dell’Information security si identifica nell’incremento di uno dei più importanti fattori abilitanti dell’e-business. Tutto questo perché la security non si può sottoporre a benchmarking, ma solo valutare come fattore indiretto.