Il Secure Web Appliance (WSA), evoluzione del vecchio Web Security Appliance (già Ironport), è un proxy di sicurezza web che si interpone tra gli utenti interni e Internet. Il suo compito è ispezionare il traffico HTTP/HTTPS per applicare policy di accesso, bloccare malware e categorie di URL indesiderate, e dare visibilità granulare sulle applicazioni. In SCOR è il pilastro della web security on-prem, contrapposto al modello cloud di Cisco Umbrella.
Modalità di deployment: explicit vs transparent
Il WSA può ricevere il traffico in due modi.
- Explicit (esplicito): il browser è configurato per puntare al proxy, manualmente o via PAC file / WPAD. Il client sa di parlare con il proxy. È semplice e deterministico, ma dipende dalla corretta configurazione dell’endpoint e si può aggirare.
- Transparent (trasparente): il client non sa dell’esistenza del proxy; è la rete a dirottare il traffico web verso il WSA. La redirezione avviene tipicamente con WCCP (Web Cache Communication Protocol) su uno switch o firewall (ASA/Firepower), oppure con PBR (Policy-Based Routing).
WCCP costruisce un tunnel GRE (o L2 rewrite) tra il device di rete e il WSA, negoziando service group (di default il web-cache, service ID 0 per la porta 80, e il 90/91 per HTTPS). Attenzione al design: il return path deve essere coerente, va evitato l’asymmetric routing e occorre pianificare quale device fa da redirector.
URL filtering, categorizzazione e reputation
Il WSA classifica ogni richiesta con il Cisco Talos URL database in oltre 80 categorie (es. gambling, social networking). Le Access Policies decidono per gruppo/utente e categoria se Allow, Block, Warn, Monitor. In parallelo agisce la Web Reputation Score (WBRS), un punteggio da -10 a +10: valori molto bassi vengono bloccati, quelli intermedi inviati a scansione più approfondita. URL non categorizzati ricadono nella categoria Uncategorized, gestibile con una regola dedicata.
Application Visibility and Control (AVC)
L’engine AVC riconosce le applicazioni a livello 7 (non solo per porta) e permette controllo granulare: ad esempio consentire Facebook ma bloccarne chat e upload, o limitare la banda dei media streaming. Va oltre il semplice URL filtering perché ispeziona il comportamento applicativo.
Malware scanning
Il WSA integra più engine anti-malware: firme anti-malware/AMP (Advanced Malware Protection) con file reputation e file analysis (sandboxing verso Secure Malware Analytics/Threat Grid), più scanning DVS con motori come Webroot/Sophos/McAfee a seconda della licenza. Supporta anche il Cognitive/Global Threat per traffico sospetto.
Identificazione utente e autenticazione
Per applicare policy per utente/gruppo serve identificare chi naviga:
- Autenticazione trasparente tramite integrazione con directory (LDAP o Kerberos/NTLM via realm), spesso con SSO basato su Kerberos.
- Autenticazione esplicita con prompt (Basic/NTLMSSP).
- ISE integration: il WSA può ricevere le informazioni di identità e gruppo (SGT/pxGrid) da Cisco ISE, evitando un secondo login.
Decryption HTTPS/TLS
Poiché la maggior parte del traffico è cifrato, senza HTTPS decryption il WSA vede solo l’hostname (SNI) e non il contenuto. La Decryption Policy decide, per categoria/reputation, se Decrypt, Pass-through, Drop o Monitor. Nella decrittazione il WSA fa da man-in-the-middle: presenta al client un certificato firmato dalla propria root CA, che quindi deve essere distribuita e considerata trusted su tutti gli endpoint (via GPO/MDM), altrimenti l’utente riceve errori di certificato. Per privacy/compliance categorie come banking o health si lasciano tipicamente in pass-through.
WSA on-prem vs Umbrella Secure Web Gateway (cloud)
| Aspetto | WSA (on-prem) | Umbrella SWG (cloud) |
|---|---|---|
| Deployment | Appliance/VM in sede | SaaS globale, nessun HW |
| Redirezione | WCCP, PBR, explicit/PAC | Tunnel IPsec, SWG proxy, roaming client, PAC |
| Utenti remoti | Backhaul verso la sede | Copertura nativa off-network |
| Controllo | Molto granulare (AVC, DVS) | Ampio ma gestito dal cloud |
| Scalabilità | Legata all’hardware | Elastica |
Umbrella parte come DNS-layer security e con l’SWG aggiunge full-proxy, decryption e AMP nel cloud. La scelta dipende da footprint remoto, compliance sui dati e volontà di gestire appliance.
Trappole tipiche d’esame
- La decryption non funziona / errori di certificato sui client → la root CA del WSA non è stata distribuita come trusted sugli endpoint: è un requisito di gestione dei certificati, non un problema di policy.
- Serve ispezionare il contenuto HTTPS, non solo bloccare per SNI → occorre una Decryption Policy con azione Decrypt; il solo URL filtering L4/SNI non basta.
- Deployment trasparente senza toccare i browser → WCCP (o PBR); se lo scenario dice “configurare il proxy nel browser/PAC” è invece explicit mode.
- Traffico web che bypassa il proxy o loop/asimmetria → problema di design WCCP (service group, return path, routing simmetrico), non delle policy.
- Policy per utente/gruppo senza secondo login → integrazione identità con ISE/realm Kerberos; scegliere authentication (transparent SSO) e non solo l’IP sorgente.
- Controllo granulare intra-applicazione (es. bloccare upload ma non browsing) → è compito dell’AVC, non del semplice URL category filtering.