CSA: Cisco Security Agent

Introduzione

Cisco Security Agent ha il compito di proteggere varie tipologie di hosts da diversi tipi di attacco: da tipo Accesso a DoS, o anche solo di ricerca di vulnerabilità. Tramite il deployment di agenti installabili sui clients che si andranno a difendere, è possibile, con una gestione completamente centralizzata, tenere sotto controllo e proteggere un largo numero di Workstations e Servers, con regole personalizzabili, a seconda delle applicazioni e servizi in uso e in base a gruppi di appartenenza.

CSA Management Center è il software di creazione, configurazione e deployment dei Kits e delle Policies contenenti le regole utilizzate dagli Agenti.
CSA MC è un modulo interno alla suite CiscoWorks VPN/Security Management Solutions (VMS), suite contenente diverse funzionalità security-oriented: Cisco Works Common Services (modulo di base, necessario in qualsiasi installazione), MC for VPN Routers, MC for Firewalls, MC for IDS Sensors, Security Monitor e MC for Performance, selezionabili o meno singolarmente, secondo necessità e scopi prefissati, durante il processo d’installazione.
Altri moduli sono reperibili al dì fuori del bundle; è possibile fare riferimento al link http://www.cisco.com/en/US/products/sw/cscowork/ps2330/index.html per maggiori informazioni.

Installazione di Cisco VMS

E’ necessario installare dapprima Cisco VMS, disponibile in versione 2.3, e in seguito Cisco Security Agent, attualmente alla versione 4.5.
L’installazione di testing e’ sul sistema operativo Windows 2000 Server/Adv Server aggiornato a Service Pack 4 come da requisiti minimi; i requisiti hardware indicati nel manuale d’installazione sono molto precisi e definiscono le risorse necessarie e i diversi setup che è bene adottare in base al numero di agenti che si avrà bisogno di gestire.

Il server di testing è dotato di una CPU P4 2,60 Ghz e 1Gb di Ram. La quantità di memoria è il minimo consigliato e la pesantezza di Java è il motivo principale delle alte richieste. Comunque, 1 Gigabyte è sufficiente finchè il numero di clients da gestire non va oltre i 500 Agenti e si installano esclusivamente i Common Services e il CSA MC. Quando il numero di agenti da gestire comincia a crescere in modo considerevole (quantificabile in 1000 e oltre secondo documentazione Cisco), la quantità di Ram necessaria diventa un fattore primario, soprattutto qualora si decidesse di utilizzare una versione di MS SQL più adatta a gestire un grande numero di agenti, diversa da quella fornita in bundle (in questo caso una soluzione migliore sarebbe spostare il database su un server dedicato).

La dimensione della memoria virtuale consigliata è di 2Gb e lo spazio su disco richiesto per un’installazione inziale e’ di 9 Gb.
NOTA
Le dimensioni del database tendono a crescere velocemente, soprattutto nel caso si eseguano parecchie Behaviour Analysis e logging a livello Informational (il che è normale nel periodo di testing e deployment iniziale). MS SQL tenta di installarsi nella partizione più capiente che trova.
Nell’installazione di prova, una partizione dedicata al database è stata usata, facendo attenzione a essere generosi nella quantità di spazio assegnatogli.
La versione scaricabile di VMS comprende due immagini CD1 e CD2, contenute in archivi compressi e splittati. E’ possibile masterizzarle su CD o installarle direttamente scompattandole con un software di decompressione compatibile col formato Zip (WinRAR supporta gli splits e decomprime perfettamente il tutto).

L’installazione è la classica InstallShield Wizard. E’ possibile personalizzare il path di installazione e ci si muove tramite i soliti next-menus per soddisfare alcune richieste del programma.

E’ fondamentale che Cisco Works sia installato su una partizione NTFS. Come si può sperimentare utilizzando una Fat32, una finestra pop-up ci avvisa che non saranno disponibili alcune features di security proprie del file system NT utilizzando un filesystem diverso; ci verrà chiesto di confermare o di cambiare destinazione a un path residente su filesystem formattato NT.

E’ possibile selezionare quali componenti installare tra quelli disponibili. Se si intende installare Cisco VMS con il solo scopo di utilizzare il server come Cisco Security Agent Management Center (decisamente sconsigliato fare diversamente) è necessario selezionare solo il componente Cisco Works Common Services.

E’ inoltre caldamente consigliato installare solo ed esclusivamente il necessario per limitare l’utilizzo delle risorse e preservarne per il futuro, per garantire un minimo di scalabilità.
Cisco sconsiglia l’installazione e l’utilizzo di altri componenti che non siano i Common Services, il Security Monitor e il CSA su un server di Management.

L’installer chiederà di inserire la password per l’utente admin, utilizzato per l’accesso al Management Center Server, e poi chiederà di poter creare l’utente casuser, necessario per la gestione dei processi che non necessitano di privilegi di amministratore.

Inizierà la copia dei files e al termine verrà chiesto di riavviare.

Al riavvio, è consigliato controllare, prima di avviare l’installazione del CSAMC, che tutto sia funzionante, in modo da limitare il numero di cause di possibile malfunzionamento, per mantenere un minimo di troubleshooting strutturato, nel caso il CSA non faccia il suo dovere quando più tardi andremo a provarlo.
Puntare il browser all’indirizzo: http://localhost:1741.
A questo punto verrete avvisati della possibile mancanza del plugin Java, oppure che la vostra versione non è supportata (nel caso non abbiate la 1.42_02): una pagina di supporto con tanto di link ai Jre sul sito Sun vi verrà linkata. Eseguite quanto descritto e tornate al link precedente.

Nel caso stiate utilizzando un browser diverso da Microsoft IE (necessaria la versione 6 sp1), potreste essere avvisati del mancato supporto per il vostro sconosciuto browser: Mozilla, Firefox e Opera funzionano perfettamente a patto di avere il supporto Java installato e funzionante. Testati con successo i tre browsers citati in Windows 2000, Linux, Solaris e BSD.
Si segnala, inoltre, che Netscape è ufficialmente supportato a partire dalla versione 7.
NOTA
Gli Host che ospiteranno il Management Center o Cisco Security Agent abortiranno l’installazione nel caso sia presente il software “Cisco IDS Host Sensor” (e Console)

Installazione CSA Management Center (Server Side Software)

Si può procedere all’installazione del Management Center contenuto nell’apposito archivio.
Se avete meno di 1Gb di Ram una finestra vi avviserà che non è abbastanza e vi chiederà se volete continuare.
Dopo di che dovrete decidere se installare in locale il database che conterrà i dati di CSA o se avvalervi dell’uso di un database engine remoto già esistente.

Se non avete un database a disposizione, magari su macchina dedicata in remoto (consigliato se si ha intenzione di gestire un parco macchine di grandi dimensioni superiore ai 1000 agenti), l’installer provvederà a installare il motore di MS SQL Desktop 2000 v8 dove risiederà la vostra base dati.

Questa soluzione è adatta per installazioni di testing e soluzioni medio-piccole.

Si consiglia di fare alcune valutazioni prima di procedere:

1. definire il numero di Agenti, che influisce sul tipo di installazione distribuibile così:
   1. MC, Polling e Database Locale per una piccola rete di poche decine fino a meno di 500 di Agenti
   2. Sistema su due Server. Uno per il Mngmt Center e il Polling e l’altra contenente un’installazione di MS SQL server 2000 dedicata al database. Consigliato in caso di numero di Agenti di 500 o superiore.
   3. Sistema su tre Server. Un server MC, un server per il Polling e uno per il Database.

Cisco prevede un supporto per pochi fino a 100.000 Agenti.

Esempi di utilizzo delle tre configurazioni in rapporto al numero di clients da gestire è presente sul Documento CSAMC_InstallGuide.pdf disponibile nel pacchetto scaricabile e su CD.
Purtroppo, parlando di numeri, la documentazione a disposizione più volte si contraddice, generando confusione.

NOTA
Alcuni accorgimenti sono necessari nel caso la rete sia vicina al numero massimo di agenti supportati secondo Cisco (100.000), ad esempio il Polling va configurato in modo tale che non più di 20 agenti per volta facciano una Query al MC; inoltre sarebbe utile avere un caching dei contenuti su servers intermedi in modo da diminuire le richieste di download di policies e kits.

– DNS e WINS servers dovrebbero essere correttamente configurati e funzionanti per permettere una corretta comunicazione tra MC e Agenti. In fase di testing, un DNS malfuzionante ha impedito completamente la comunicazione di alcune macchine.

– Se il parco macchine interessato sarà molto grande, è sconsigliabile installare fin dall’inizio gli Agenti su tutti gli hosts. E’ decisamente più semplice iniziare con un piccolo numero di stazioni e allargare il deployment degli Agenti un po’ alla volta, in modo da avere delle policies correttamente funzionanti e corrispondenti alle aspettative prima di un deployment di grosse dimensioni. E’ importante che la configurazione delle macchine client coinvolte nell’installazione iniziale corrisponda, nel tipo di applicazioni installate e destinazione d’uso, a quella del resto delle macchine che verranno aggiunte, in modo che costituiscano il giusto template. Si consiglia di partire con almeno tre macchine per ogni tipologia di client (divisibili in gruppi che utilizzano diversi Agent Kits), sulle quali fare largo uso di tutti gli applicativi disponibili. In questo modo verranno generati log attendibili e vicini al risultato atteso; questi potranno poi essere attentamente esaminati e utilizzati come base per la creazione delle rules.
NOTA
E’ possibile utilizzare più Management Center su diversi servers e fargli condividere un unico database remoto. Nel caso di installazioni distribuite, è raccomandato sincronizzare gli orologi, magari tramite un Server NTP comune, in modo da evitare comportamenti inaspettati e eventuali problemi.

Se si intende installare CSA MC con un supporto SQL Server 2000 esterno bisogna configurare il server remoto in anticipo;
Creare un database e un nuovo login ID associato a un ID utente con permessi di accesso al database di CSA. L’autenticazione SQL Server deve essere attiva per il nuovo database. E’ anche necessario creare un gruppo files con nome “analysis” contenente almeno un file.

Se si incontrano problemi e l’installazione dovesse fallire per qualsiasi ragione potete fare riferimento al log di installazione per avere maggiori dettagli sulle cause del fallimento. Potete trovare il file nella directory log\ all’interno di CSAMC45\.

Installazione di Cisco Security Agent (Client Side Software)

Lato client il software viene generato e reso disponibile tramite interazione e configurazione con il Management Center da parte dell`amministratore. Con un`attenta pianificazione (vedere documento Csa-Config-Roadmap contenente i passi da compiere per la configurazione), si creano dei pacchetti chiamati Kits, personalizzati in base ai gruppi in cui si e` deciso di dividere la propria rete, contenenti il software d’installazione del client CSA e le policies che ne detteranno il comportamento.

I kits sono resi disponibili tramite URL per il download. Dal menu Systems–>Agent Kits si ha comodo accesso alla lista dei kits ( visibile anche all`indirizzo https://nome-host/csamc45/kits/ ), e all`indirizzo di download la cui diffusione puo` essere fatta via e-mail.

Network Shim

In alcuni casi può rendersi necessario non installare questo componente. Esso è responsabile del controllo delle funzionalita di rete. Ad esempio nel caso di un Firewall o di un software per VPN, Network SHim e le sue features potrebbero dare adito a conflitti e problemi poco piacevoli. E` possibile disabilitare NS.
E’ bene disabilitare questo componente in casi specifici, creando un apposito gruppo nel quale spostare i clients nei quali sorgessero problemi di compibilità; il software usato in questi specifici casi farà le veci di Network Shim qualora sia assolutamente necessario.

IMPORTANTE: quando si cambiano policies e rules che riguardano questo componente, è indispensabile riavviare perchè tutti i cambiamenti abbiano effetto. In linea generale i cambiamenti si applicano solo ai processi generati dopo l’update, mentre quelli preesistenti rimangono immuni.

Gestione delle Utenze

Cisco Works permette di creare diversi livelli di utenza per il management.
Di default, durante l’installazione viene creato l’utente “admin”, con privilegi illimitati e possibilità di gestire ogni aspetto della suite.
Un secondo account, nominato “Guest”, è configurato di default, con privilegi minimi. Inoltre esiste un utente casuser, ma è utilizzato internamente per lanciare processi che non necessitano di privilegi di amministratore.

Il primo accesso a CSA avviene dall’interno di Cisco Works puntando il browser all’indirizzo http://nomehost:1741.
Dal cassetto VPN/Security Management Solutions si può accedere al pannello del CSA MC.

E’ possibile creare le utenze addizionali dall’interfaccia di amministrazione di Cisco Works, in base a ruoli caratterizzabili in tre categorie. Essi hanno valore globale e sono disponibili in tutti i moduli della suite, compreso CSA MC:

• Amministratore di Monitoraggio
• Amministratore di Deployment
• Amministratore di Configurazione

Una volta configurata una utenza e dopo che è avvenuta la registrazione dell’account è possibile attuare modifiche e affinare i privilegi. La registrazione avviene, come per gli hosts e il MC, la prima volta che ci si mette in contatto col server di management, loggandocisi.

In aggiunta alle capacità stabilite da Cisco Works, è possibile affinare le preferenze di ciascun utente dall’interno di CSA. Si tratta di preferenze legate all’impostazione dell’interfaccia e sono raggiungibili tramite i menu Maintenance–>Admin Preferences.

I livelli di sicurezza, in Cisco Works, sono visibili all’interno delle interfacce di creazione, modifica e eliminazione delle utenze, e sono descritti nel documento incluso nel pacchetto scaricabile e nel CD “User Guide for CiscWorks Common Services” pagine 39-42.

Interazione con CiscoSecure ACS

Le utenze create vengono registrate nel database interno della suite. Una valida alternativa, per rinforzare la sicurezza del login, e’ utilizzare l’applicativo Cisco ACS Secure per gestire le authentications. Naturalmente i Login Modules contemplano diverse soluzioni, disponibili sia su piattaforma Microsoft che sugli Unix (eccettuato il sistema di autenticazione locale proprio dei due sistemi), tra cui:

MS Active Directory

• Netscape Directory
• Radius
• Kerberos
• IBM SecureWay Directory
• TACACS+
• Cisco Works Local

Con l’ausilio di Cisco ACS è possibile utilizzare i moduli Radius e TACACS+. Sul server di testing abbiamo installato ACS 3.3 scegliendo la seconda soluzione, proprietaria Cisco, avendo piena compatibilità con Cisco Works.
NOTA E’ necessario che la versione di ACS in uso sia almeno la 3.1, la versione minima supportata da Cisco Works.

Per usufruire di questo metodo di autenticazione abbiamo compiuto i seguenti passi:

Su Cisco Secure ACS 3.3

In Network Configuration: Se non esiste già è necessario creare l’AAA server, impostando la Key, l’indirizzo IP (nel nostro caso è quello locale) e Cisco Secure ACS come AAA Server Type.
Il server Cisco Works, va configurato come AAA client, con il suo ip, la stessa Key che abbiamo messo in AAA server e TACACS+ selezionato nel menu a tendina Authenticate Using.

In Group Setup: Scegliere un gruppo vuoto e rinominarlo a qualcosa di familiare per i nostri scopi. Ad esempio CSA MC Users. Questo gruppo conterrà tutti gli utenti di cui si avranno bisogno per il management di CSA.

In User Settings: Potete creare l’utente predefinito con nome e password, così come le avete impostate durante l’installazione di Cisco Works.

Su Cisco Works VMS Solutions:

Cassetto Server Configuration: in Setup–>Security–>Select Login Module

Selezionate TACACS+ e premete Next. Impostate i dati quali indirizzo porta e Key e scegliete se volete il fallback nell’eventualità che il server ACS non sia disponibile, se lo volete permettere solo ad alcuni utenti o per nulla.

Ulteriori informazioni sono disponibili nel documento disponibile su CD o versione scaricabile “User guide for CiscoWorks Common Services”, pagine 142-154.

RoadMap Creazione Agent Kits di Cisco CSA

Pianificazione del tipo di installazione: considerare il numero di Agenti e i gruppi in cui verranno suddivisi (prima pianificazione generica dei gruppi).
Questo determinerà il carico che il/i Server/s di Management, Polling, Database dovranno sostenere. Influirà sul tipo di installazione. Fare riferimento al par. 3 (Installazione CSA Management Center — Server Side Software).
Definire i gruppi nei quali verranno inseriti i Servers e le Workstations da gestire, in base a:

• Tipologia dell’host: Stazione Desktop, Stazione Server, Stazione Management
• Software installati
• Locazione fisica all’interno della topologia
• Esposizione a Internet
• Ecc

Creazione dei gruppi: Tutti gli host faranno parte dei tre gruppi predefiniti:

• All Windows
• All Linux
• All Solaris

E’ possibile che un host faccia parte di più gruppi, tra quelli predefiniti o di nuovi creati secondo necessità. Il server MC fa sempre gruppo a sè. Esiste un gruppo già predisposto e un kit preconfezionato, il CiscoWorks VMS Kit che viene installato di default sulla macchina che ospita CSA MC, subito dopo la fine dell’installazione dello stesso. Lo stesso vale per il server che ospita MS SQL 2000, nel caso di installazione separata in grandi reti; questi gruppi conengono regole di default create ad hoc per la difesa di queste postazioni. I gruppi vengono creati premendo il pulsante “New” (in basso a sinistra), nella interfaccia apposita in System Groups. E’ naturalmente possibile adattare i gruppi preesistenti alle proprie esigenze.
Creazione degli Agent Kits: In base a quanto fatto fin’ora, è necessario creare i kits. I kits devono essere consegnati agli utenti utilizzanti le postazioni da proteggere tramite link da cui scaricare il programma (via browser). E’ anche possibile dare l’indirizzo della directory che contiene tutti i Kits e lasciare all’utente la scelta di quello più adatto alle sue esigenze. Questo per dare la possibilità di attuare diverse politiche di deployment.

Risorse hardware dei clients Le caratteristiche necessarie all’utilizzo di CSA sono alla portata della maggior parte dei sistemi. Da segnalare:

Il supporto per Windows è presente per le versioni 2003 Server, XP tutte, 2000 Server e Adv Server e Pro, e NT4.

Per quanto riguarda Solaris si parla della versione 8 o più recente. Sebbene sia molto limitata l’informazione è possibile approfondire sul pdf disponibile su CD o versione scaricabile “Using Management Center for Cisco Security Agent 4.5”, pagine 482-485.

Per Linux, l’installazione dei moduli necessari su un kernel 2.6 non è andata a buon fine, il pacchetto è dotato di un installer (in bash) che dovrebbe occuparsi di tutto, ovvero installare il pacchetto RPM incluso e poco altro.

Funziona solo su kernel Linux 2.4, probabilmente su distribuzioni RedHat-like. E’ possibile reperire poche altre informazioni sul pdf disponibile su CD o versione scaricabile “Using Management Center for Cisco Security Agent 4.5”, pagine 487-488.
Prima Distribuzione: E’ bene distribuire il kit a una piccola quantità di clients, rappresentativa dell’intera rete. E’ possibile utilizzare i kits in modalità di Test. Vi sono kits di Test preconfezionati. Il loro scopo è simulare il funzionamento delle policy ma fermarsi al logging senza applicare le regole e quindi, nessun tipo di protezione o limitazione. In questo modo è possibile testare le regole incluse nelle Policies contenute nei kits osservando gli effetti ed eliminando il rischio di creare problemi di utilizzo agli utenti con regole troppo restrittive o con impostazioni errate.

Questa è una scelta che spetta all’amministratore, che valuterà il livello di disagio che potrà permettersi di creare nel caso qualcosa non vada nel modo giusto. Nel caso il numero di hosts sia molto alto è bene effettuare un periodo di testing e modificazione dei kits e delle Policies accluse. Quando si avrà qualcosa di affidabile sarà possibile allargare il deployment a un numero sempre maggiore di hosts, dividendoli in scaglioni, e notando eventuali differenze nel logging (abilitare il verbose logging) tramite il pannello Events Event Monitor.
Una volta che i Kits saranno stati distribuiti e installati tra le stazioni di testing, avverrà una registrazione automatica sul Server MC. I clients regolarmente registrati saranno visibili da subito in System–> Hosts. E’ necessario prestare attenzione al fatto che, a seconda del tipo di installazione prestabilita dall’amministratore, il kit potrebbe voler riavviare la macchina e avviare un countdown per il shutdown. In fase di testing, su un client che non poteva essere riavviato per ancora alcune ore, è stato possibile interrompere il “conto alla rovescia” intervenendo sul processo per fermarlo; dal Task Manager, selezionare la scheda Processi e Terminare shutdown.exe.
Per evitare problemi simili è bene avvertire l’utenza in anticipo o disabilitare il forcing al riavvio durante la creazione del kit. Si ricorda che un client non riavviato non sarà completamente protetto, soprattutto nel caso il Network Shim sia incluso nel kit.
Una Policy è un insieme di regole (Rules), può essere legata a più gruppi, e supportare diverse piattaforme. Naturalmente è possibile definire le proprie Policies. All’interno delle Policy si inseriscono le Rules. Le Rules hanno un ordine di priorità in base alla “Action” che svolgeranno. La priorità stabilisce quale regola ha effetto al di sopra di altre simili o che agiscono sugli stessi Targets. Naturalmente è possibile definire le proprie Rules.

E’ possibile utilizzare le policies predefinite o modificarle. A questo proposito si consiglia di non modificare irreversibilmente ciò che vi è di predefinito in CSA MC; è molto meglio clonare le poliy già esistenti e modificarle a piacimento cambiandovi il nome e applicandole nei kits per testarle. Sarà più semplice tornare alle regole predefinite nel caso le modifiche non sia soddisfacenti.

CSA MC ha un ottimo Wizard per la modifica delle regole. E’ il modo migliore per eseguire modifiche. Vale la pena di descrivere dettagliatamente il suo utilizzo (capitolo seguente). Essendo il sistema di Policies di questo software complesso ed esteso, è il miglior metodo per creare le sfumature e bilanciare al meglio quelle che saranno le regole applicate alla nostra rete (almeno finchè non si sarà davvero esperti e confidenti con CSA).

Event Management Wizard, Events Log e modifica delle Rules

La rete di testing, a questo punto, dovrebbe essere pronta: gli Agenti installati hanno fatto la registrazione e sono visibili nel pannello Systems Hosts.
I pannelli probabilmente più utilizzati, sono quelli di monitoring, disponibili in Events. Event Log e Event Monitor (simili, sebbene il secondo abbia funzione di refresh incorporata) raccolgono qualsiasi violazione o nota degna dell’attenzione dell’amministratore (che decide e imposta cosa e da quale livello è giusto visualizzare agendo sul pannello Events Event Sets).

Ogni evento sarà munito di:

• un numero identificativo univoco

• momento in cui è stato scatenato (GG/MM/ANNO HH:MM:SS)

• livello di Severity

• Descrizione accurata.

In aggiunta sono disponibili alcuni pulsanti, che saranno presenti in base a quanto è possibile interagire con un dato evento:

• Details: una descrizione maggiormente approfondita che ci istruisce sull’evento. Il livello di accuratezza è molto alto. Si va dalla descrizione del tipo di applicazione, servizio o quant’altro abbia causato l’intervento di una Rule, agli IP, Porte e Protocolli interessati, alcune informazioni sull’host sul quale ha agito l’Agente, il tipo di intervento applicato.

• Rule <NUMERO>: il link alla Rule che ha deciso di intervenire. Uno shortcut diretto al pannello di controllo della regola per permettere all’amministratore di esaminarla, rivalutarla e eventualmente agire per una modifica.

• Wizard: il metodo migliore, sicuro e più semplice con il quale intervenire sulle regole che hanno scatenato il logging di un evento.

Premendo sul pulsante Wizard è possibile agire in modi diversi.

Un esempio molto frequente, durante i primi periodi di testing, è il logging di un evento che descrive l’avvenuto blocco di una operazione ordinaria da parte di una regola troppo restrittiva. Durante il development del kit non ci siamo accorti che una regola non permette l’utilizzo di Acrobat Reader a un utente, in quanto applicazione sconosciuta e potenzialmente pericolosa.

L’amministratore vede la riga di logging e decide di intervenire. Decide di usare il wizard e lo apre in corrispondenza della riga interessata nell’event log.

Il pop-up che si apre in genere da tre opzioni come possibilità:

• L’azione loggata è da giudicare sicura e quindi da permettere. Si può creare una exception rule che permetterà l’azione che ha scatenato l’evento.

Una EXCEPTION RULE è una utile feature. Anzichè andare a modificare irreversibilmente una regola predefinita o creata dall’amministratore, creerà una regola che si affiancherà a questa e sarà giudicata prioritaria. In questo modo qualsiasi cambiamento sarà reversibile e il testing delle regole meno rischioso da applicare, anche quando le modifiche cominciano a diventare complesse e numerose. E’ possibile esaminare le exception rules create, all’interno delle Policies, nei rispettivi moduli di Rules.

• L’azione loggata è già conosciuta e non ha bisogno di interventi e/o modifiche. Si può creare una Exception Rule che ne eviterà il logging

• Nel caso di quest’esempio, l’amministratore sa di cosa si tratta, in quanto riconosce nell’evento l’elemento scatenante: Acrobat Reader. Nel caso non sia comprensibile in modo così facile quale sia l’applicazione, processo o servizio interessato, e che quindi l’evento scatenato non sia ben comprensibile sarà difficile poter intervenire. L’opzione Perform a Behaviour Analysis proposito del processo scatenante l’evento permette di avviare un’analisi approfondita nel caso di logs poco comprensibili, oppure concernenti eventi molto complessi.

Naturalmente è possibile avvalersi di diverse tipologie di Analisi a propria discrezione in qualsiasi momento si giudichi opportuno. Sono disponibili nel pannello Analysis le Application Deployment Analysis e Reports e le già citate Application Behaviour Investigation e Reports. Si può fare riferimento al documento Using Management Center for Cisco Security Agent 4.5, pagine 383-442 per istruzioni dettagliate sull’utilizzo delle Cisco Security Agent Analysis.

Rapporto tra CSA MC Server e Clients Agenti in CSA

L’aggiornamento delle regole legate a ciascun Agente avviene a tempi predefiniti. Il periodo di Polling è configurabile nell’apposito campo al momento della creazione del gruppo. Il default è quasi sempre 24 ore, con qualche eccezione.

Scaduto il periodo predefinito il client eseguirà il Polling e scaricherÀ dal server le eventuali regole aggiornate presenti sul server a cui l’amministratore ha lavorato nel frattempo. E’ importante definire l’intervallo di Polling a seconda dei bisogni facendo attenzione al numero di clients (ed evitare floods) e configurando i vari gruppi per fare il Polling in tempi diversi.

Durante il periodo iniziale di definizione delle policies, quando esse verranno spesso aggiunte, modificate e rimosse, è bene settare il check degli updates nell’ordine dei minuti. Un ambiente avviato e configurato in modo soddisfacente, invece, permette di settare un Polling di 24 ore o più, in quanto i cambiamenti saranno minimi.

E’ comunque possibile forzare il download e l’update delle Policies: è sufficiente spuntare la casella “Send Polling Hint” che si trova di fianco alla input text box che definisce l’intervallo di Polling all’interno del pannello di configurazione dei gruppi in System –> Groups.

Quando l’amministratore aggiornerà le policies, un pacchetto UDP verrà inviato ai clients interessati dalla modifica e “consiglierà” allo stesso di fare un Polling straordinario.