DNA 2.0 - Defensible Network Architecture

Io l'ho sempre detto che per fare security ci vuole DNA

Liberamente tratto (tradotto) da un articolo di Richard Bejtlich su TaoSecurity

Quattro anni fa quando scrissi "The Tao of Network Security" introdussi il concetto defensible network architecture poi esteso nel secondo libro Extrusion Detection. Quando in prima battuta presentai l'idea dissi che una "defensible network" è una architettura IT monitorata, controllata, minimizzata e "attuale" (inteso come aggiornata ndA). Secondo questo approccio, una "defensible network architecture, ci da le migliori probabilità di resistere ad una intrusione visto che un vero sistema di IPS (Intrusion Prevension) non sarà mai realizzabile.

Oggi ho il piacere di estendere questi concetti con la Defensible Network Architecture 2.0 (no 2.0 perpetual beta hype! ndA), con la convinzione che possano essere di grande utilità per ogni organizzazione che voglia intraprendere un percorso strategico di assunzione di responsabilità nel mondo della security.
Si potrà notare il contrasto con le "Self-Defeating Network" e le uguaglianze con le mie "Security Operations Fundamentals".

Venendo al nocciolo della questione possiamo quindi dire che la DNA è un'architettura informativa che può essere:

Monitored: Il modo meno costoso per cominciare il deploy di una DNA su di una rete preesistente è quello di inserire dei Network Security Monitor (sensori e/o probe ndA) che riescano a catturare i dati di sessione (come minimo), tutto il contenuto informativo (qualora possibile) e i dati statistici più disparati. Se è possibile accedere ad altri "data source" come firewall, router, IPS, dns server o proxy meglio muoversi anche in quella direzione. L'atto di salvare "coraggiosamente" tutti questi dati "prima che sia troppo tardi" permetterà di raggiungere un piccolo gol cioè quello di mettere gli stessi nelle mani di un piccolo e centralizzato gruppo di persone. Si dovrebbe sempre partire dal monitoraggio, Bruce Schneier insegna since 2001.
(Questo implicherà necessariamente la modifica di alcuni asset e l'acquisto di mammuth database)

Inventored: Implica la conoscenza di ciò che viene hostato nella propria rete. Cominciando a monitorare si possono acquisire passivamente molte di queste informazioni. Nella precedente versione della DNA questo punto era stato omesso per l'assunto che "l'admin dovrebbe conoscere cosa c'è nella sua rete". Molto improbabile! (Troppa fiducia aggiungo io)

Controlled: Ora che conosciamo cosa è operativo all'interno della nostra rete, si possono implementare i primi "network-based control". Applicate questo step a vostro piacimento: filtri in inbound e/o in outbound, network admission control, network access control, proxy connection e così via. L'idea è quella di trasmettere informazione da una "anything goes" network ad un'altra, ma l'attività di comunicazione deve essere precedentemente autorizzata da uno dei sistemi adottati.

NB: Questo è il primo step in cui gli stakeholder potrebbero cominciare a lamentarsi.

Claimed: Con claimed si intende l'identificazione del responsabile dell'asset e il successivo sviluppo di politiche, procedure e piani per operare su di esso, cominciamo realmente a toccare gli stakeholder. Sentitevi liberi di scambiare questo step con il precedente, ma esperienza insegna che è tipicamente più semplice cominciare introducento i controlli prima di responsabilizzare le persone. Si sottolinea come questo step sia prerequisito per l'incident response acquisendo informazioni dal primo step (monitoraggio) e lavorando con un "asset owner" in grado di rispondere, contenere e ripristinare un sistema in fault.

Minimized: Questo step va ad impattare direttamente sulla configurazione ed il comportamento degli assets. In questa fase si lavora con gli stakeholder per ridurre la "superficie d'attacco" dei network device. E' possibile applicare questa idea a: client, server, applicazioni, network link e così via. Riducendo l'area d'attacco si migliora automaticamente l'abilità di eseguire tutti gli altri step, ma non si può avere una minimizzazione fintanto che non si conosce "chi è responsabile di cosa" e di lì a cascata.

Assessed: Questo è un vero e proprio vulnerability assessment utile per identificare le debolezze degli assets. Qualcuno potrebbe argomentare d'aver effettuato, o pagato, un VA come step iniziale ma la prima domanda che deve trovare risposta ancor prima di procedere all'assessment è "Cosa andremo a considerare?". (Il posizionamento dopo la minimizzazione è dovuto anche ad una riduzione dei costi del VA ndA). Va da se che per semplificare questa fase si potrebbe iniziare con il disabilitare i servizi non "indispensabili" ma non si ha coscienza degli stessi prima di aver ultimato il VA. La procedura tipicamente si manifesta sotto forma di attacco simulato a tutti i sottosistemi dell'infrastruttura. Il VA è la fase dove si prende coscienza dell'efficacia delle proprie decisioni passate.

Current: In questa fase si intende configurare e patchare i sistemi fino ad ora considerati in modo tale da renderli inattaccabili (o resistenti) alle vulnerabilità note riscontrare. (Tipicamente è la fase di applicazione delle policy di rientro post VA). E' facile disabilitare quelle funzionalità di cui nessuno fa uso, tuttavia gli aggiornamenti possono bloccare gli applicativi e ridurre l'operatività. (E questo spesso crea delle inevitabili falle nei sistemi legacy ndA)

Con questo chiudiamo la trattazione della DNA 2.0

Il Governo Federale sta adottando parte di questo approccio, come menzionato in "Feds Plan to Reduce, then Monitor".

Secondo voi manca qualcosa ?