Cisco-Ironport Web Security Appliance: WSA prime policy

Abbiamo installato il nostro primo WSA, effettuato un upgrade ed iniziato a farlo funzionare.

I risultati sono soddisfacenti, ma adesso vorremmo iniziare a costruire delle policy per configurare il nostro appliance per compiti specifici.

Il primo passo è cercare di capire come in WSA sono definiti i soggetti a cui applicare le policy.

Il primo punto da considerare è come definiamo un “navigatore” su internet. Un navigatore su internet è, nella maggior parte dei casi, un utente che si collega ad un computer, accederà con le sue credenziali e userà un browser per accedere ad un certo sito.

Se dovessimo cercare di dare una definizione di parametri che definiscono questo utente potremmo quindi creare un elenco simile:

Utente:

  1. Appartenenza ad una struttura Active Directory o LDAP
  2. Indirizzo TCP-IP appartenente ad un dominio (network) IP specifico
  3. Browser utilizzato
  4. Sito visitato
  5. Protocolli coinvolti
  6. ….

questi parametri insieme servono a definire un gruppo di utenti con caratteristiche comuni.

La variazione di uno di questi parametri può spostare l’appartenenza di un utente da un gruppo ad un altro.

Questo insieme di caratteristiche definisce la identità del gruppo ed in WSA viene detta Identity.

Per chiarire la necessità di definire una utenza non in termini di semplice appartenenza ad Active Directory o LDAP è possibile fare un semplice ragionamento.

Supponiamo di avere un utente IT e che questi, per esigenze di lavoro (ad esempio occupandosi di security) deve poter avere un accesso ad Internet piuttosto libero saltando la maggior parte delle policy di sicurezza. Ora se questo utente si connette da una rete qualsiasi non ci sono grossi problemi, data la specificità delle sue occupazioni, ma immaginiamo ora che questi si connetta dalla sala server per operazioni di manutenzione…è ammissibile che se si logga con le sue credenziali da un server mantenga le stesse libertà di navigazione di cui dispone sulle sue macchine di laboratorio?

La risposta è evidentemente negativa, lo stesso utente deve quindi essere gestito in maniera diversa non solo a seconda della sua appartenenza in un directory service, ma anche in funzione del dominio IP da cui si connette.

Capito questo possiamo fare il passo successivo: una volta definito il gruppo di riferimento con le caratteristiche comuni, la nostra Identity, occorre ora definire delle regole di uso.

Tali regole però possono essere diversi per membri della stessa Identity, deve essere quindi possibile definire sottoinsiemi di una Identity a cui applicare le regole.

Iniziamo quindi a creare una Identity, per fare ciò andiamo sull’appliance, ci logghiamo ed andiamo sul menu:

“Web Security Manager”

e clicchiamo su Identities per entrare nella sezione dedicata.

 

e clicchiamo su “Add Identity…”

La schermata è divisa in due sezioni:

il primo pezzo richiede semplicemente di dare un nome alla policy ed una descrizione.

Il secondo richiede che si definisca i parametri per appartenere ad un gruppo.

come si vede i parametri da considerare in WSA sono:

  1. appartenenza ad una subnet IP
  2. Protocollo utilizzato
  3. Realm di autenticazione (AD o LDAP)
  4. Porta proxy utilizzata
  5. Categoria URL visitata
  6. User Agent (definisce il browser usato)

Per poter definire  ad esempio il browser si può esplodere la voce browser di figura e si ottiene:

le configurazioni possibili sono elevate.

La componente inerente il realm di autenticazione è al momento vuota in quanto non è stato ancora definita la configurazione con una sorgente LDAP.

Iniziamo quindi con una configurazione semplice, supponiamo di voler definire per un IP specifico una policy diversa da quella di default.

Creeremo innanzi tutto una Identity che definisce il nostro gruppo, ad esempio:

dopo di che creeremo la nostra policy. per fare questo occorre andare in Web security manager –> access policy

possiamo quindi iniziare a costruire la nostra policy di accesso.

il primo step chiede di specificare il gruppo cui applicare la policy:

dopo aver definito il nome della policy e la sua descrizione vediamo i parametri che ci possono servire:

possiamo selezionare la Identity cui vogliamo associare la policy. nel caso sia definito un realm LDAP si può specificare anche un gruppo od un utente.

nel mio caso ho selezionato la mia Identity “Home Identity” che era definita solo come subnet IP e quindi non richiedeva autenticazione.

dopo di che seleziono il parametro “Subnets

qui posso definire se usare tutto il dominio IP definito o, ad esempio, un solo indirizzo.

Salvando il tutto e facendo commit ho creato una policy che si applicherà al solo indirizzo 192.168.0.2

a questo punto posso modificare le sezioni application, URL Categories Object e WebReputation and Anti-Malware Filtering a seconda di cosa mi serva.

Si noti che questa configurazione è possibile anche nel caso non si siano definite Identity specifiche, infatti è sempre possibile fare riferimento alla Identity di default che comprende tutti:

in questo caso il riferimento alla Identity sarà “All Identities” ma si può ancora definire gli indirizzi IP coinvolti.

prossimamente giocheremo con altri 2 punti simpatici: la autenticazione LDAP (datemi il tempo di configurare un server LDAP a casa) , custom categories e time range.

salumi e formaggi a tutti

ciao

Antonio

Antonio Ieranò
CSO, Cyber Security Architect, technical evangelist, consultant, writer, journalist and trainer
I am a Security Manager and architect, CSO, BDM, marketing specialist, and tech evangelist with over 20 years of experience serving as a community liaison, subject matter expert, and high-profile trainer for key technologies and solutions. My experience includes acting as the public face of Huawei technology and before Cisco security technologies; leading pan-European technical teams in development of new Cisco security products; and serving as a key public speaker and trainer on behalf of new high-tech products. My expertise spans IT development and implementation, marketing strategy, legal issues, and budget / financial management.

Specialties and Executive Expertise
IT Strategy, Technical Audits, Enterprise Architecture & Applications, Technical Sales Liaison, Solution Architecture, Network Design, Architecture, & Security, Vulnerability Assessment & Management, Systems Engineering, Data Privacy, Cloud Computing, Marketing Strategy, Budget Management, Social Media Marketing, High-Impact Presentations,incident handling, Forensics, Italian companies, Authentication, Infrastructure security, Security manager, Security issues, Attacks, Security infrastructure, Data encryption

Security and Technical Advisoring
Project Management
Business Development and Marketing

To the official site of Related Posts via Taxonomies.

CC BY-NC-SA 4.0 Cisco-Ironport Web Security Appliance: WSA prime policy by The Puchi Herald Magazine is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.