Perché il posture in ISE
Il posture è il processo con cui Cisco ISE valuta lo stato di compliance di un endpoint dopo l’autenticazione, prima di concedere l’accesso pieno alla rete. L’autenticazione dice chi sei; il posture dice se il tuo dispositivo è sano: antivirus attivo e aggiornato, patch di sistema installate, disco cifrato, firewall attivo, un certo file o valore di registry presente. Finché la valutazione non è completa lo stato è Unknown, e da lì l’endpoint viene poi classificato come Compliant o NonCompliant.
La gerarchia: condition → requirement → policy
Il modello è a tre livelli e ricorre continuamente nelle domande d’esame.
- Condition: il singolo test atomico. Può essere simple (una verifica) o compound (più condizioni in AND/OR). Tipi comuni: antivirus/antispyware, patch management, file, registry, application, service, firewall, disk encryption, USB.
- Requirement: lega insieme una o più condition + un’azione di remediation + il sistema operativo target, con un messaggio all’utente. È il “contratto”: “su questo OS deve valere questa condition; se non vale, esegui questa remediation”.
- Posture policy: la regola che associa uno o più requirement a un contesto (OS, identity group, altre condizioni). È qui che ogni requirement viene marcato Mandatory, Optional o Audit.
| Tipo requirement | Se la condition fallisce |
|---|---|
| Mandatory | L’endpoint diventa NonCompliant, parte la remediation e/o la quarantena; l’accesso resta bloccato |
| Optional | L’endpoint resta Compliant; la remediation è offerta ma non obbligatoria |
| Audit | Nessuna azione utente: solo reporting silenzioso |
Remediation
La remediation è ciò che ISE propone o esegue per riportare l’endpoint in compliance: aggiornare l’antivirus, applicare le patch, avviare un programma, distribuire un file, mostrare un link/messaggio, attivare firewall o disk encryption. Può essere automatica o manuale (l’utente clicca), con un timer e un numero di tentativi. Dopo la remediation l’agent rilancia l’assessment.
Distribuzione degli agent: Client Provisioning
L’endpoint deve avere un agent che esegua i test. La distribuzione avviene tramite Client Provisioning, guidato dalla Client Provisioning Policy (mappa OS / identity group / altro → agent + compliance module + profilo di posture).
- Cisco Secure Client — ISE Posture Module (ex AnyConnect): agent persistente, installato sull’endpoint, ideale per dispositivi gestiti; supporta la Periodic Reassessment (PRA).
- Temporal Agent: agent temporaneo/dissolvibile che gira una sola volta senza installazione permanente, pensato per host non gestiti/ospiti; non supporta PRA né alcune remediation avanzate.
Il flusso e il ruolo del CoA
- L’endpoint si autentica; il posture è Unknown. L’authorization profile applica redirect ACL e una DACL restrittiva (accesso solo a ISE, DNS, remediation).
- L’endpoint viene rediretto al Client Provisioning Portal; l’agent viene scaricato/eseguito.
- L’agent esegue le condition e invia il risultato a ISE.
- In base all’esito ISE emette un Change of Authorization (CoA) — tipicamente CoA Re-authenticate — che rivaluta le regole di authorization e assegna l’accesso Compliant (DACL piena, rimozione redirect) oppure mantiene la quarantena.
Servono quindi due regole di authorization: una per Unknown/NonCompliant (redirect + accesso limitato) e una per Compliant (accesso pieno). Senza il CoA l’endpoint reso compliant resterebbe bloccato nella DACL restrittiva.
Il compliance / posture feed
Le condition su antivirus, antispyware e patch si basano sul compliance module (feed OPSWAT). ISE deve scaricare periodicamente gli update di posture dal posture feed service per riconoscere le versioni più recenti di prodotti AV/AM. Se il feed è vecchio, un antivirus nuovissimo può risultare “sconosciuto” e l’endpoint viene marcato NonCompliant pur essendo a posto.
Trappole tipiche d’esame
- Endpoint compliant ma ancora bloccato → manca il CoA. Se dopo la remediation l’accesso non cambia, la causa è quasi sempre l’assenza/errata configurazione del CoA Re-authenticate, non la posture policy.
- AV recente segnalato NonCompliant → posture feed non aggiornato. Lo scenario “prodotto legittimo ma non riconosciuto” indica compliance module / feed da aggiornare, non una condition sbagliata.
- Utente bloccato senza motivo → requirement Mandatory dove serviva Optional/Audit. Marcare come Mandatory un controllo non critico blocca inutilmente; per verifiche informative si usa Audit, per raccomandazioni Optional.
- Host non gestito che non deve installare software → Temporal Agent. Se lo scenario vieta un agent persistente (guest/BYOD), la risposta è il temporal agent via client provisioning, non il Secure Client posture module.
- Redirect fallito/agent non scaricato → Client Provisioning Policy o redirect ACL mancante. Se l’endpoint resta Unknown senza mai valutare, verificare la Client Provisioning Policy e la redirect ACL nell’authorization profile.