Controllare l`accesso alla rete: la sfida

Protect what you value.
Controllare l'accesso alla rete:
la sfida
Riflessioni realistiche per la strategia e l'implementazione
Compendio sulla soluzione
www.mcafee.com/it
Indice
Definizione di NAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Autenticazione dell'utente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Valutazione del terminale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Applicazione della policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Controllo dell'accesso alla rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I problemi aziendali oggi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
N. 1 Limitare l'accesso alla rete di utenti non autorizzati. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Ammettere utenti ospiti autorizzati su sistemi gestiti sani . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Ammettere utenti ospiti autorizzati su sistemi sani non gestiti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Ammettere utenti autorizzati su sistemi non gestiti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
N. 2 Limitare l'accesso alla rete ai sistemi non gestiti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Gestione di dispositivi ingestibili. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
N. 3 Conformità con le normative. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
N. 4 Stato di salute dei sistemi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Scenari di implementazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Accesso a LAN cablate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Perimetro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Lo standard 802.1X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Inline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Accesso gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Accesso DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Accesso LAN wireless. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
VPN ad accesso remoto (IPSEC & SSL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Forza lavoro mobile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Sistemi personali da casa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
La soluzione McAfee NAC: Unified Secure Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Compendio sulla soluzione
www.mcafee.com/it
Controllare l'accesso alla rete:
la sfida
Riflessioni realistiche per la strategia e l'implementazione
Il NAC può presentare svariati scenari utente semplici da comprendere, ma che
fanno affidamento su vari approcci tecnici che possono essere difficoltosi da progettare e
implementare correttamente. Il presente documento si prefigge di spiegare i casi d'uso più
comuni, gli approcci tecnici più appropriati per ogni caso e di richiamare alcuni problemi tipici di
ciascuno di questi approcci. Lo studio alla base di questo documento, deriva da un'aggregazione
di interazioni con clienti e prospect, suggerimenti tramite conversazioni dirette e articoli di vari
analisti e giornalisti e, naturamente, molte discussioni con gli esperti interni di McAfee.
Definizione di NAC
Il concetto di Network Admission Control, sebbene si
basi sul lavoro e i concetti di molte altre fonti, viene
generalmente attribuito all'attività marketing di Cisco che
nel 2003 lo diffuse sul mercato. Il concetto era semplice:
invece che spendere l'intero budget di sicurezza per
difendere il perimetro e i terminali, perché non aggiungere
un livello che permettesse di accedere alla rete solo agli
utenti autorizzati dopo aver passato un semplice test
che assicuri che siano adeguatamente "sani". Non era
inteso come una rete "pigliatutto" tranne che per gli
utenti autorizzati, si trattava piuttosto di un metodo per
evitare che dipendente di un'azienda facesse un lavoro
insufficiente nel proteggere le risorse aziendali lasciando
entrare malware nell'ambiente, che all'epoca era un'origine
primaria di malware all'interno dell'azienda. A questo
proposito, le caratteristiche e le funzioni comuni per NAC
erano anche semplici:
Autenticazione dell'utente
Mentre non tutti gli approcci a NAC consentono
l'applicazione di limitazioni in base ai ruoli sulla base
dell'identità autenticata, un prodotto NAC deve come
minimo essere in grado di bloccare l'accesso alla rete di
ogni dispositivo finché:
• L'utente si è autenticato con successo,
• L'utente viene definito come parte di un elenco di
eccezioni / bypass, o
• Il sistema viene definito come parte di un elenco di
eccezioni / bypass.
Valutazione del terminale
Devono essere intrapresi alcuni metodi di valutazione
per comprendere se il terminale è considerato
"sufficientemente sano" per poter accedere alla rete,
come definito da una policy NAC. Ciò generalmente
richiede che un agent sia implementato sul terminale
o una combinazione di quarantena e scansione remota
certificata. Qualsiasi approccio venga utilizzato per valutare
il terminale, l'attuale stato di conformità con la policy deve
essere verificabile. Generalmente include regole come
l'esistenza di anti-virus e firewall funzionanti, le patch di
sicurezza Microsoft più recenti e qualche volta l'assenza di
malware o applicazioni inserite in blacklist. Per i dispositivi
"ingestibili" che non possono essere valutati, saranno
utilizzati alcuni metodi di "eccezione", e preferibilmente
saranno combinati con alcuni metodi di verifica del tipo di
dispositivo.
Applicazione della policy
Portare gli utenti autorizzati sulla rete con un sistema
sano il più velocemente possibile. Spesso ciò richiede che
il sistema sia in grado di applicare automaticamente la
policy corretta sulla base di chi è l'utente, che si tratti di
un sistema gestito, la sede dalla quale l'utente si collega
o quale sistema operativo e applicazioni sono presenti sul
sistema. Uno dei componenti più critici per raggiungere
questo obiettivo è una rapida risoluzione di qualsiasi
problema di salute all'interno della zona di quarantena, e
l'aspettativa generale del cliente è che ciò avvenga in modo
automatico utilizzando le loro soluzioni di remediation.
3
Compendio sulla soluzione
Controllo dell'accesso alla rete
Nel tempo il termine NAC più in generale ha iniziato
a essere utilizzato come acronimo per Network Access
Control, con grande attenzione da parte di stampa, analisti
e vendor focalizzata su quali fossero inizialmente i requisiti
della periferica:
• Quali requisiti per ospiti e collaboratori con i propri
dispositivi?
• Quali requisiti per gli utenti che si collegano da casa via
VPN?
• Se si sa chi sono e hanno la capacità di controllare il
proprio accesso, perché non applicare tali controlli su
dove vanno e cosa possono fare?
• Cosa accade se diventano "malsani" una volta collegati?
• Cosa fare con dispositivi "ingestibili" come stampanti
e telefoni IP? Se si considera solo l'indirizzo MAC, cosa
impedisce a qualcuno di prendere le veci di altri?
I problemi aziendali oggi
Come già menzionato, il concetto relativo a cosa è il NAC
e quali sono i problemi che risolve sembra essere cambiato
negli ultimi anni. E' inoltre fondamentale prendere in
considerazione chi, all'interno dell'azienda, si focalizza
su ogni problema, e se ciò tende o meno a tradursi in
budget e spesa reali. I budget disponibili sostanzialmente
stabiliranno le caratteristiche e le funzioni dei prodotti
considerati.
Una barriera per NAC per molte organizzazioni, su cui
spesso si sorvola, è anche la complessità dell'ambiente
delle 'relazioni politiche'. In molti casi, un dato rischio
verrebbe mitigato in modo più appropriato con un
controllo che richiede la collaborazione e l'ownership
di diversi gruppi funzionali. In alcuni casi, un rischio
all'interno di un gruppo verrebbe meglio risolto con un
controllo che sia completamnete all'interno del dominio
di un altro, e per complicare ulteriormente la questione
il controllo dovrebbe essere designato e testato da un
terzo. Per esempio, in molti casi i gruppi di desktop/
sistemi sono realmente i titolari dei rischi posti da
malware o accesso non autorizzato alla rete, il gruppo
di rete diventa il responsabile dell'implementazione del
controllo (e generalmente il reale acquirente) e il gruppo
di sicurezza definirà infine il controllo e richiederà un certo
livello di report. Il gruppo di rete in questa situazione
potrebbe essere contrario all'acquisto di una soluzione
che dipenda dal gruppo di sistemi (come Microsoft
NAP per esempio) o che carichi su di loro un onere di
workflow, ma potrebbe anche essere contrario a qualsiasi
soluzione che consenta al gruppo dei sistemi di accedere
ai componenti infrastrutturali di rete (per esempio SNMP
scrive le credenziali all'interno del sistema di gestione ePO
di McAfee). Una suddivisione appropriata dei compiti per
voci di configurazione, workflow, policy e reportistica è
fondamentale.
www.mcafee.com/it
Dati tali fattori, gli autori hanno tentato di prioritizzare gli
approcci che hanno visto influenzare le decisioni d'acquisto
in progetti NAC contemporanei.
N. 1 Limitare l'accesso alla rete di utenti non autorizzati
L'esigenza che sembra essere aumentata al massimo per
la maggior parte delle organizzazioni: "Se un utente non
autorizzato ottiene accesso fisico a un drop di rete, dovrebbe
essere bloccato immediatamente". Sembrano esserci vari
motivi per cui sia stato dato risalto a tale funzionalità in
molte discussioni su NAC, tra cui il fatto che è:
• Un controllo automatico semplice da comunicare ai
revisori
• Un valore ragionevolmente semplice da far comprendere
agli executive
• Ben posizionato nel regno di fornitori tradizionali di
dispositivi di rete
• Ben posizionato nel regno dei dipartimenti tradizionali
per la progettazione della rete
• Molto simile (se non identico - standard 802.1X) ai
controlli implementati per la sicurezza wireless in molte
organizzazioni
Generalmente questo requisito non vale da solo, ma
è diventato, in molti casi, un fattore negativo se non
soddisfatto adeguatamente. Inoltre, per la maggior parte
dei clienti, questo requisito ha generato varie supposizioni
controverse:
Ammettere utenti ospiti autorizzati su sistemi gestiti sani
Un contractor/ospite che cerca di accedere alla rete
da una risorsa gestita sana deve essere ammesso sulla
rete. Generalmente l'ospite dovrebbe essere aggiunto
al dominio per collegarsi al sistema gestito comunque,
perciò dovrebbe rientrare nello stesso caso di un utente
regolare su un sistema gestito. Comunque, potrebbe essere
necessario porre attenzione alla policy specifica applicata a
quell'utente.
Ammettere utenti ospiti autorizzati su sistemi sani non
gestiti
Un contractor/ospite che cerca di accedere alla rete da un
sistema non gestito dovrebbe disporre sia di un meccanismo
per autenticarsi (generalmente una sorta di modulo web)
sia un metodo affinché ne sia valutato lo stato di salute.
Mentre molti utenti ospiti in effetti hanno pieni diritti sui
loro sistemi per l'installazione di un agent temporaneo o per
disabilitare il loro firewall o HIPS, molti altri non li hanno.
4
Compendio sulla soluzione
Ammettere utenti autorizzati su sistemi non gestiti
Nella maggior parte dei casi ci si aspetta che esista un
metodo per gli utenti abituali per accedere alla rete con
risorse organizzative che non rientrano nei meccanismi
standard di autenticazione, o con i loro propri sistemi,
sia che siano fisicamente collegati internamente o che
utilizzino una VPN da casa, caso molto più comune.
Generalmente ciò significherebbe ampliare le loro
credenziali utenti di back-end (come AD) affinché vengano
utilizzate come parte dell'autenticazione NAC, come per
esempio tramite un modulo web o un client VPN. Come nel
caso di utenti ospiti autorizzati, sarebbero richiesti alcuni
metodi per valutare la salute del sistema.
N. 2 Limitare l'accesso alla rete ai sistemi non gestiti
Strettamente correlato al sotto-requisito di cui sopra
"Ammettere utenti autorizzati su sistemi non gestiti", ci
sono molti clienti che enfatizzano NAC direttamente su
quanto bene la soluzione gestisca il problema del "sistema
non gestito". La differenza in questo caso è che la soluzione
è in grado di limitare l'accesso esattamente a tutto ciò che
non è esplicitamente ammesso poiché "gestito" o che non
rappresenta esplicitamente un'"eccezione". Spesso viene
posta particolare enfasi su tali problemi che sembrano
essere troppo complessi per molte delle soluzioni presenti
oggi sul mercato, come tailgating e impersonation (vedere
la discussione sullo standard 802.1X). Quei clienti che hanno
analizzato seriamente i propri scenari, o che hanno già
effettivamente tentato di implementare una soluzione
NAC, tendono ad avere problematiche significative di
fruibilità nell'occuparsi di dispositivi "ingestibili".
Gestione di dispositivi ingestibili
Per organizzazioni con un numero significativo di risorse
che sono di fatto "ingestibili", la capacità della soluzione
NAC di automatizzare porzioni del workflow necessarie
per assicurare che i dispositivi autorizzati non siano MAI
messi in quarantena e che i dispositivi non autorizzati siano
SEMPRE messi in quarantena, può essere un elemento
significativo dell'utizzabilità del prodotto. Alcuni clienti
potrebbero voler importare elenchi di dispositivi come
eccezioni, mentre altri preferiranno utilizzare il codice
fornitore OUI per assegnare dinamicamente le eccezioni,
praticamente nessuno supporterà l'immissione manuale
nell'indirizzo MAC/IP o il doverli mettere prima in
quarantena per poi "eliminarli con un click".
Uno dei casi d'utilizzo più chiari è negli ospedali, molti
dei quali hanno migliaia di dispositivi basati su IP che
vengono staccati, spostati e ricollegati ovunque all'interno
dell'ospedale e che potrebbero essere necessari in una
situazione di vita o di morte nel momento in cui sono
collegati. Comunque, è inoltre fondamentale che utenti
non autorizzati non siano sullo stesso segmento di rete di
quei dispositivi o sulla stessa rete dei sistemi informativi
sanitari pieni di dati dei pazienti privati e regolamentati.
Allo stesso tempo, la maggior parte degli ospedali operano
www.mcafee.com/it
in un ambiente competitivo e cercano di essere considerati
all'avanguardia con accesso internet per i pazienti e
interfacce dirette per consentire ai pazienti di accedere ai
propri documenti.
N. 3 Conformità con le normative
Mentre molte delle esigenze su cui si basa NAC possono
essere facilmente collegate alla conformità, per la maggior
parte il comportamento d'acquisto a questo punto del
ciclo di vita del NAC non si è focalizzato sulla conformità
in se stessa come necessità. La maggior parte delle aziende
considererebbe una best practice il fare il possibile per
mantenere gli utenti e i sistemi non autorizzati al di
fuori della rete e il malware al di fuori dal loro ambiente.
Tuttavia, le aziende che ottengono il budget per acquistare
una soluzione NAC, che ritengono che l'intolleranza
dell'utente nei confronti del NAC possa essere annullata,
probabilmente sperano di evitare il ripetersi di un incidente
di sicurezza significativo, considerando il rischio della non
conformità con le normative, oppure operano in un settore
dove il rischio di pubblicità negativa derivante da un
incidente è un rischio sufficiente per spingere a un acquisto
importante. In ciascuno di questi casi ci sono probabilmente
alcuni requisiti per dimostrare periodicamente
(generalmente tramite buone attività di reporting) che la
conformità è stata rispettata, o ancor meglio per dimostrare
che il sistema è stato configurato in modo che applichi la
conformità (controllo automatico).
Un esempio di un collegamento molto stretto tra la
conformità e il NAC è rappresentato dai requisiti PCI
(Payment Card Industry):
5.1 Implementare software anti-virus su tutti i sistemi
comunemente colpiti da virus (in particolare personal
computer e server) Nota: i sistemi comunemente colpiti dai
virus tipicamente non includono sistemi operativi UNIX o
mainframe.
5.1.1 Garantire che i programmi antivirus siano in grado
di rilevare, rimuovere e proteggere contro altre forme di
software dannoso, inclusi spyware e adware.
5.2 Garantire che tutti i meccanismi antivirus siano attuali,
operativi attivamente e in grado di generare log di verifica.
Questo requisito potrebbe essere soddisfatto senza NAC.
Comunque, la sfida per questo tipo di requisiti non risiede
necessariamente nel raggiungimento della conformità, ma
nel dimostrare la conformità in un modo ragionevole e
ripetibile. Ci sono molti approcci che i revisori utilizzano per
determinare la conformità di questi tipi di requisiti, ma più
le opzioni disponibili si discostano dai controlli di sistema
automatici, più probabilmente accadrà che alcuni revisori
non accetteranno i piani di test o anche controlli che altri
accetterebbero.
5
Compendio sulla soluzione
Esempio: Il gruppo interno di verifica o il team di sicurezza
potrebbe pensare che McAfee ePO sia in grado di assicurare
che VirusScan Enterprise è configurato correttamente,
operativo e che i file DAT sono aggiornati. Il revisore
potrebbe però non accettarlo come controllo automatico
senza una prova che ePO sia effettivamente in funzione.
I report all'interno di ePO che possono dimostrare il
livello di conformità dell'antivirus dei sistemi gestiti
sono utili, ma è semplice poi incorrere nel problema di
dimostrare che ePO stia realmente gestendo tutti i sistemi.
Il rilevamento dei sistemi inaffidabili è un eccellente
controllo di monitoraggio, così che il test diventa un modo
di dimostrare che è in grado portare tutti i sistemi rilevati
come "inaffidabili" in conformità, o che una persona
monitora realmente tale stato in modo sufficiente da
inividuarli tutti e gestirli in modo opportuno. Un metodo
per testarlo è quello di riesaminare i log per ogni sistema
inaffidabile rilevato e verificare che siano tutti diventati
gestiti (o un'eccezione). Se la quantità di dati è molto
ampia, può essere accettabile analizzare solo un campione
di sistemi inaffidabili, ma anche così è necessario lavorarci
molto. Alcuni revisori potrebbero inoltre voler riesaminare
un campione casuale o selettivo di sistemi per verificarne lo
stato. Se troppi si dimostrano non aggiornati o non gestiti
da ePO, allora il campione verrà ampliato o addirittura
diventerà il 100%. Questo è il tipo di controllo a catena che
ha comportato costi molto elevati per molte aziende come
risultato di verifiche Sarbanes Oxley e PCI.
Chiaramente NAC è un controllo molto più efficace; per
come è progettato, un utente non può entrare in rete
senza aver dimostrato il suo "stato di salute". La policy
che definisce lo stato di salute può essere facilmente
presentata per applicare l'antivirus, e ogni eccezione
può essere dimostrata chiaramente. Il revisore può
semplicemente focalizzarsi sul test del controllo automatico
dei sistemi, che significa in realtà un solo test senza
spazio di errore. Per la maggior parte sarà necessario
documentare chiaramente la configurazione e i flussi di
lavoro, dimostrando la registrazione persistente di tutte
le operazioni effettuate, e dimostrare controlli basati sui
ruoli che non permetterebbero a un amministratore o a un
addetto dell'help desk di bypassare i controlli senza seguire
i processi approvati. Sarebbero necessari molti di questi
requisiti normativi, che potrebbero portare a potenziali
risparmi nel processo di preparazione, consultazione e
convalida della verifica, prima che NAC possa generare
un ROI positivo. Comunque, un revisore IT interno o risk
manager di buon senso che abbia riconosciuto il potenziale
di NAC non interferirà molto nel processo di selezione
una volta passato al gruppo di progettazione di rete come
progetto richiesto.
N. 4 Stato di salute dei sistemi
La funzionalità di valutazione della soluzione NAC è,
per molti acquirenti, considerata prematuramente come
una tecnologia di consumo che ogni soluzione dovrebbe
essere in grado di eseguire al meglio. Questo sembra
www.mcafee.com/it
essere il caso non solo dell'agent (gestito) persistente, ma
anche dell'agent (non gestito) "solubile". Per la maggior
parte delle organizzazioni le funzionalità dell'agent
manterranno alla fine un ruolo significativo nel successo o
fallimento dell'implementazione NAC, perciò far prendere
in considerazione in modo adeguato all'acquirente quali
siano realmente le sue necessità in quest'area e come la
concorrenza non sempre è all'altezza, è un'impresa per i
gruppi di vendita e marketing. Ciò è particolarmente vero
per il prodotto McAfee Network Access Control (MNAC),
generalmente considerato un prodotto di primo piano
per quanto riguarda la funzionalità dell'agent e i controlli
disponibili (contenuto).
Molti di coloro che acquistano NAC sono alla ricerca di un
agent leggero che effettui una rapida scansione, permetta
controlli personalizzati e ponga rimedio automaticamente a
ogni problema. Dovebbe comunicare chiaramente all'utente
il suo stato se in scansione o in quarantena. Una volta posto
rimedio, l'agent dovrebbe rapidamente ricollegare l'utente
alla rete e informare l'help desk dell'accaduto. Nessuno può
accedere alla rete se non si trova in uno stato "sano".
Gli ospiti e i contractor non gestiti desiderano un agent
scaricabile di dimensioni molto contenute che non richieda
diritti da amministratore o debba essere installato sul
sistema. Ci si aspetta inoltre di disporre di una funzionalità
di scansione da remoto sia per supportare le funzionalità
dell'agent che per prendere qualsiasi piattaforma per cui un
agent non è attualmente disponibile.
Scenari di implementazione
NAC può essere implementato in molti diversi scenari,
ciascuno dei quali spesso ha più di un approccio tecnico
all'implementazione. Fondamentalmente le tecnologie e
gli scenari d'implementazione utilizzati dovrebbero essere
associabili agli obiettivi previsti per NAC e agli aspetti
peculiari dell'ambiente. Inoltre, è sempre più comune
vedere organizzazioni che pianificano un'implementazione
di NAC a più fasi nel tempo, considerando molti degli
scenari di implementazione come fasi indipendenti.
Accesso a LAN cablate
L'esigenza più comune per NAC è quella di proteggere una
LAN cablata da laptop utilizzati in viaggio, da un ospite
o da un contractor, o anche dall'utente non autorizzato
che entra in una sala conferenze. Fondamentale per tale
esigenza è evitare in qualche modo che tale sistema di
colleghi alla rete finché non sono state completate le
verifiche di autenticazione e lo stato di salute. Per il sistema
gestito, il software per i terminali McAfee Network Access
Control e pochi altri prodotti sul mercato sono in grado
di mettersi in quarantena automaticamente tramite il
firewall di filtering dei pacchetti incorporato. Comunque,
per il sistema non gestito deve esserci un meccanismo
all'interno della rete stessa per applicare la quarantena e la
valutazione.
6
Compendio sulla soluzione
Perimetro
A parità di circostanze, è sempre preferibile implementare
l'applicazione di NAC il più vicino possibile al terminale
al Livello 2. Per LAN cablate tipiche ciò significherebe
bloccare l'utente alla prima tappa dal terminale, che per la
maggior parte delle reti oggi significherebbe uno switch
di distribuzione gestibile. In teoria il miglior approccio
sarebbe quello di implementare switch intelligenti
sull'intero livello di distribuzione con esame stateful dei
pacchetti su ogni porta, dove sarà applicato un accesso
basato su autenticazione, stato di salute e identità.
Comunque, i vendor che cercano di vendere questo tipo
di soluzione oggi non dominano il mercato per vari motivi
fondamentali, alcuni dei quali includono:
• Il prezzo per porta è relativamente alto
• Esistono altri metodi più economici di ottenere la
funzionalità NAC con le attrezzature già presenti nella
maggior parte delle organizzazioni
Detto ciò e considerando altre sfide, l'approccio più comune
è quello di utilizzare gli standard e le tecnologie esistenti
all'interno dell'architettura di cui molte aziende già
dispongono. Mentre viene applicato sugli switch periferici,
il componente NAC effettivo spesso si trova da qualche
parte nella rete e comunemente viene riportato come
applicazione "out-of-band o fuori banda".
Lo standard 802.1X
Molti degli switch attualmente implementati nei livelli
centro, accesso e distribuzione hanno funzioni di
applicazione dello standard 802.1X. Alcuni sono in grado
di effettuare autenticazione e assegnazione VLAN di base,
alcuni possono assegnare ACL in base all'autenticazione e
altri possono fare entrambi. La complessità e le limitazioni
di impostare VLAN all'interno dell'organizzazione
generalmente favoriscono l'implementazione dello
standard 802.1X con ACL quando disponibile. Comunque,
è importante ricordare che lo standard 802.1X non è
stato progettato come protocollo NAC e generalmente è
focalizzato completamente sull'utente piuttosto che sul
sistema.
Se un sistema rimane statico sulla stessa porta, allora lo
standard 802.1X funzionerà bene assegnando un'ACL
statico o VLAN a quella porta per essere utilizzato dopo
l'autenticazione. Comunque, se molti utenti entrano
attraverso una porta (come entrando da un hub, telefono
IP, AP wireless, VM, NAT / internet sharing), non è
ovviamente accettabile che i sistemi effettuino un'attività
di "tailgate" dopo che uno si è autenticato. Devono essere
riconosciuti e autenticati individualmente. Tale attività
viene generalmente denominata "multi-auth" e non
sembra violare lo standard 802.1X, perciò vari vendor di
switch spesso avranno livelli variabili di funzionalità per
vincere la sfida. E' fondamentale che ogni soluzione NAC sia
in grado di sfruttare la funzionalità offerta dallo switch.
www.mcafee.com/it
Se un sistema si può muovere e entrare tramite porte/
punti d'accesso diversi, allora dovrebbe essere supportata
un'opzione di assegnazione di una VLAN dinamica come
opportuna per l'utente/sistema che si sta autenticando.
Ancor meglio è il concetto di ACL dinamico, anche se non è
chiaro quanto sia diffusamente supportato sugli switch più
implementati.
Laddove un utente non è riuscito a autenticarsi o il sistema
non dispone del richiedente appropriato, dovrebbe essere
supportata una VLAN o ACL limitata. Preferibilmente sarà
isolata come VLAN o ACL privata o dinamica per evitare
contaminazioni incrociate o mettere in pericolo altri utenti
in quarantena. Molti switch oggi supportano anche la
funzionalità Web Auth, in modo che qualsiasi sistema che
non dispone del richiedente appropriato possa comunque
avere la possibilità di autenticarsi tramite un modulo web.
Se un sistema non è conforme alle policy, deve essere
presente un'opzione per spostarlo su una VLAN di
remediation o applicare un'ACL di remediation finché il
problema non viene risolto. Dal momento che lo standard
802.1X non è stato creato per NAC, non esiste realmente
il concetto di porre rimedio al sistema e toglierlo dalla
quarantena. Le soluzioni NAC perciò spesso devono
'inventarsi' un modo per far sì che lo switch o il terminale
reimpostino il collegamento una volta che l'attività di
remediation è stata completata e imporre allo switch di
riautenticare e riassegnare la VLAN o l'ACL.
Se un sistema autorizzato non è gestibile o non dispone
di un richiedente ma deve essere sulla vlan fidata, deve
essere presente un metodo di bypass dell'autenticazione
MAC che permetta al dispositivo di passare oltre sulla base
dell'indirizzo MAC di un qualche tipo di identificatore
unico. Comunque, gli indirizzi MAC e alcuni altri elementi
di identificazione vengono facilmente raggirati, perciò è
importante che siano presenti controlli di compensazione
per mitigare il rischio. Spesso ciò prevede alcuni livelli
di funzionalità di fingerprinting, la capacità di filtrare i
protocolli che non dovrebbero essere utilizzati da questi
dispositivi (come le stampanti) e/o qualche forma di
autorizzazione MAC o web.
Inline
Non è sempre possibile utilizzare tutti i dispositivi
perimetrali per un'attività di applicazione o sostituitirli,
nel qual caso l'applicazione "inline" può rappresentare
un'alternativa efficace. L'obiettivo è quello di autenticare
e valutare lo stato di salute dei dispositivi il più vicino
possibile al punto d'ingresso della rete, e di porre rimedio
a ogni sistema non conforme il più velocemente possibile
in modo che possano entrare sulla rete. Laddove non è
praticabile il NAC di Livello 2 allora il NAC di Livello 3 è la
riserva più appropriata.
7
Compendio sulla soluzione
Sfortunatamente la qualità del dispositivo inline cui molte
aziende si affiderebbero per mantenere un'applicazione
inline con velocità via cavo con buone funzionalità di
failover potrebbe essere troppo costosa da scalare per
posizionarla alle spalle di ogni dispositivo perimetrale. Per
questo motivo l'applicazione inline potrebbe essere più
adatta per segmenti di rete specifici con un rischio o valore
particolarmente elevato, come i punti d'accesso gateway.
Accesso gateway
In questo scenario di implementazione, NAC viene
applicato al limite del Livello 3 in una rete campus
distribuita. Tale scenario può rivelarsi utile come fase
di un'implementazione NAC quando l'applicazione
perimetrale non è fattibile, ma può dimostrarsi anche un
metodo di applicazione efficace tra segmenti di rete come:
• tra una rete fidata e una meno fidata,
• tra una filiale e il campus principale,
• tra il campus principale o il sito di un visitatore e l'accesso
a Internet,
• tra una extranet e una intranet, e
• all'accesso a server protetti in un data center.
Un terminale, per sua natura, potrebbe aver bisogno di
incrociare il percorso di più di un punto di applicazione,
perciò è importante che il server per la gestione delle
policy sia in grado di conciliare un workflow che potrebbe
altrimenti far passare il terminale attraverso varie fasi di
autenticazione e valutazione.
Accesso DHCP
L'implementazione di NAC tramite DHCP da solo raramente
soddisferà le esigenze di una strategia NAC di un'azienda,
dal momento che DHCP opera solo al Livello 3, e avrebbe
un ruolo solo nell'accordare l'accesso se il sistema richiede
effettivamente di affittare un indirizzo. L'assegnazione
di un indirizzo statico, può, in teoria, bypassare
completamente il controllo. In alcuni casi può anche
essere possibile imitare un indirizzo MAC e/o un indirizzo
IP di un'eccezione per ricevere pieno accesso alla rete
contando sul rilevamento tramite DHCP. Qualsiasi solida
soluzione NAC che utilizza NAC basato su DHCP deve avere
qualche metodo per rilevare tutti gli indirizzi IP assegnati
staticamente che non sono esclusi, facendo utilizzare il
DHCP a questi nodi, e convalidando le eccezioni per gli
impostori.
Attualmente esistono vari approcci tecnici per
implementare NAC basato su DHCP:
• La soluzione NAC può eseguire il suo servizio DHCP
sostituendo completamente l'attuale servizio del cliente.
Quando riceve una richiesta di affitto, la soluzione NAC
assegnerà un campo normale o in quarantena sulla base
dello stato del terminale. Questo metodo fornisce un
www.mcafee.com/it
elevato controllo, ma può anche rivelarsi di disturbo
per l'ambiente durante la fase di subentro. Molti clienti
di più grandi dimensioni fanno fatica a credere che un
fornitore di soluzioni NAC possa fornire un servizio così
importante e cruciale, specialmente quei vendor che non
sono fornitori conosciuti di servizi di rete di fascia alta. Si
tratta inoltre di una soluzione che può essere costosa da
scalare per quei clienti che hanno ambienti distribuiti con
molti server DHCP.
• La soluzione NAC può operare in qualità di proxy dove
le richieste vengono effettuate al dispositivo NAC che
poi passa le richieste al server DHCP primario del cliente
se il terminale viene rilevato in buona salute. Altrimenti,
il proxy assegna il suo stato di quarantena per azioni
di remediation. Questa soluzione può essere costosa da
scalare in ambienti distribuiti, dal momento che il proxy
deve sempre essere davanti ai server DHCP primari.
• La soluzione NAC può essere eseguita in modalità
'ascolto' delle richieste DHCP per intercettare solo quelle
che non sono autenticate e in salute. Ai dispositivi
sconosciuti (o quelli non in salute) viene assegnato uno
stato di quarantena o vengono deviati su un segmento
di rete per la quarantena con il proprio servizio DHCP.
Questo approccio può essere costoso da scalare in
ambienti con server DHCP distribuiti, poiché il dispositivo
NAC deve sempre essere inline tra il server DHCP e il
terminale. Spesso richiede inoltre che il cliente metta a
disposizione un nuovo server DHCP per l'ambiente di
quarantena se il dispositivo NAC non è in grado di gestire
lo stato di quarantena.
• Alcuni dei servizi comuni DHCP permettono di installare
plug-in software, che possono interagire direttamente
con il servizio stesso. In questo modo, un componente
NAC può essere installato su ogni server DHCP per
intervenire in queste richieste di affitto che arrivano da
sistemi sconosciuti o non in salute. Dove disponibile, ciò
può essere un modo economico per occuparsi di ambienti
DHCP distribuiti.
Accesso LAN wireless
In questo scenario, NAC tipicamente girerà a livello
perimetrale - il primo dispositivo Livello 2 dal terminale
- ma in questo caso sarà tipicamente un punto d'accesso
wireless (WAP). I punti d'accesso wireless gestiscono molti
utenti per dispositivo, e spesso hanno una varietà di metodi
per gestire il processo di autenticazione. La maggior parte
dei punti WAP hanno usato per molto tempo lo standard
802.1X come metodo standard di autenticazione a causa
della crescente necessità di protezione. Alcuni punti WAP
hanno più possibilità di altri per cercare di attivare una
quarantena o un processo di remediation, e alcuni hanno
anche concetti molto definiti di gruppi e ACL. Tuttavia,
si tratta spesso di effettuare un altro controllo dopo il
processo di remediation e di riammettere automaticamente
8
Compendio sulla soluzione
il sistema sulla rete senza confondere totalmente gli utenti
rispetto a cosa sta accadendo o richiedere loro di passare
attraverso hoop che separano le migliori soluzioni NAC.
E' possibile spingere l'applicazione immediatamente dietro
un punto d'accesso wireless (per esempio uno switch o
un dispositivo inline), ma ci sono alcuni aspetti critici da
considerare:
• Il punto di applicazione non può funzionare al Livello 2,
dal momento che ogni terminale arriverà dalla stessa
unica porta sul WAP. Chiaramente non è accettabile
mettere in quarantena una rete WAP intera perché arriva
un utente sconosciuto o non in salute.
• Il punto di applicazione deve essere in grado di inviare
alcuni terminali al processo di remediation, alcuni
direttamente sulla rete sicura, altri in quarantena, i
quali richiederanno remediation manuale, e altri ancora
proprio fuori da internet senza essere stati neanche in
grado di toccare un sistema enterprise privato.
• Il punto di applicazione dovrebbe essere in grado di
fermarsi se un'autenticazione 802.1X o un'altra forma
accettabile sia già avvenuta come parte del processo di
autenticazione WAP, e non richiede la riautenticazione
dell'utente. Comunque, la salute del sistema dovrebbe
essere valutata ancora se il WAP non fosse in grado di
considerarlo come parte del processo di autenticazione
utilizzato.
• Se al sistema è stato dato qualche tipo di bypass o
esenzione dallo stato di salute, allora dovrebbero esserci
alcuni livelli di coordinamento tra il punto di applicazione
che è responsabile per determinare l'esenzione MAC e il
sistema che sta convalidando che il sistema che utilizza
l'indirizzo MAC corrisponda al tipo previsto.
VPN ad accesso remoto (IPSEC & SSL)
In questo scenario, NAC viene applicato sul punto dove
i sistemi remoti ottengono accesso alla rete enterprise.
Questa è una fase iniziale comune per l'implementazione
di NAC dal momento che può essere fatto senza influire sul
resto degli utenti della rete ed è spesso un gateway ad alto
rischio che serve gli utenti mobile e, in alcuni casi, accorda
collegamenti dai sistemi domestici dei dipendenti.
In questo scenario il dispositivo "edge" sarebbe realmente
il punto di terminazione della VPN (per esempio il
concentrator VPN), sebbene al presente tentare di applicare
NAC sulla VPN stessa può essere sia difficoltoso che
limitativo data la loro natura proprietaria. In molti casi non
è particolarmente importante se l'applicazione NAC avviene
sul dispositivo VPN, inline proprio dietro il dispositivo VPN,
o anche su uno switch attraverso il quale è necessario
passare prima di entrare su una rete sicura. Ciò che è
importante è che gli utenti possano autenticarsi, essere
www.mcafee.com/it
valutati (e messi in conformità se necessario), e ottenere
accesso alle reti interne per cui sono autorizzate in un
workflow ragionevolmente rapido e semplice. Come in altri
scenari, è fondamentale che ogni utente e sistema venga
considerato indipendentemente e ottenga il proprio livello
di accesso appropriato.
Forza lavoro mobile
Per la forza lavoro mobile in movimento o che lavora da
casa, è importante un processo omogeneo di valutazione
e remediation. In molti casi la policy utilizzata per il
sistema quando è mobile non è la stessa della policy che
verrebbe utilizzata una volta collegati alla rete aziendale,
così la soluzione NAC deve essere in grado di effettuare
la valutazione in base alla policy appropriata. E' inoltre
necessario che, come parte della valutazione, la policy
NAC stessa venga controllata per essere certi che non sia
obsoleta.
Sistemi personali da casa
Risultata fondamentale in questo caso che un utente
autorizzato sia in grado di autenticarsi da un sistema non
gestito tramite il collegamento VPN ed essere reindirizzato
per scaricare un agent temporaneo o persistente. Se dopo
la valutazione risulta essere conforme, allora l'utente
deve essere automaticamente autorizzato sulla rete come
appropriato per il proprio livello di accesso autorizzato. Se
non conforme, la soluzione NAC deve offrire le istruzioni
appropriate per un'attività di remediation automatica.
La soluzione McAfee NAC: Unified Secure
Access
Fino ad oggi, le soluzioni NAC richiedevano cambiamenti
ai clienti: cambiare le reti, cambiare le policy e modificare
il modo di fare business aumentando il costo operativo, la
complessità e gli errori. Le soluzioni NAC Unified Secure
Access di McAfee si adattano al business e all'infrastruttura
dei clienti riducendo i costi operativi, gli errori e la
complessità associati ad altre soluzioni.
Le soluzioni NAC Unified Secure Access di McAfee
permettono alle aziende di gestire l'accesso alle reti e ai
sistemi sulla base di una conoscenza approfondita della
salute del sistema, conformità e identità dell'utente
e di applicare la conformità sia pre che post ingresso
con un'ampia gamma di opzioni di applicazioni,
inclusi terminali, inline e opzioni di integrazione
dell'infrastruttura. Ciò, insieme all'avanzata infrastruttura
di gestione delle policy di McAfee, consente, per la prima
volta, implementazioni NAC estremamente semplificate
che riducono costi e risorse operative garantendo accesso
affidabile per sistemi e personale approvati. Rispetto a
soluzioni switch o basate su router che richiedono upgrade
costosi all'infrastruttura di rete e definizioni delle policy
complesse e fragili, le soluzioni McAfee Unified Secure
Access si adattano al livello della minaccia che si desidera
9
Compendio sulla soluzione
www.mcafee.com/it
gestire, alle applicazioni da proteggere, agli utenti che si
desidera autorizzare e ai sistemi che si vuole conformare
alle proprie policy di sicurezza.
Passaggio 5: Monitoraggio
Passaggio 1: Policy
Monitoraggio del
Definizione della policy
per stato di salute, identità
conformità costante
macchina/utente, applicazione
gio
rag
ito
on
1. P
oli
cy
5.
M
terminale per garantire
1
4
3
e
3. Applicazione
Reazione in base al
risultato di un controllo della
policy o comportamento
2. Indiv
idu
az
ion
Passaggio 4: Remediation
2
diation
eme
4. R
5
Passaggio 2: Individuazione
Effettua la scansione
alla ricerca di dispositivi
inaffidabili, allarmi e report
Passaggio 3: Applicazione
Controllo dello stato di
salute pre e post accesso
rispetto alla policy.
Monitoraggio di
comportamenti pericolosi.
Per maggiori informazioni su come le soluzioni McAfee
Unified Secure Access possono soddisfare le tue esigenze di
sicurezza, conformità e controllo accessi, visita il sito
www.mcafee.com/it o contatta il tuo rappresentante
commerciale o partner McAfee.
McAfee Srl
Via Fantoli 7
20138 Milano
02.554171
www.mcafee.com/it
© 2008 McAfee, Inc. è vietato riprodurre completamente o in parte il presente
documento senza l’autorizzazione scritta di McAfee, Inc. Le informazioni
fornite in questo documento hanno puri fini educativi e a favore dei clienti
di McAfee. Le informazioni qui contenute possono essere modificate senza
preavviso, e vengono fornite “come sono” senza garanzia o assicurazione
relativamente all'accuratezza o applicabilità delle informazioni a situazioni
o circostanze specifiche. McAfee, Avert e Avert Labs sono marchi registrati
o marchi di McAfee, Inc. negli Stati Uniti e in altri Paesi. Tutti gli altri nomi e
5008brf_nac_challenge_1008
marchi possono essere proprietà di terzi.
10