pxGrid e integrazione dell'ecosistema di sicurezza

pxGrid: il bus di contesto dell’ecosistema di sicurezza

Cisco pxGrid (Platform Exchange Grid) è il framework publish/subscribe con cui Cisco ISE condivide il contesto delle identità e delle sessioni con il resto dell’ecosistema di sicurezza. ISE agisce da controller e da publisher: pubblica informazioni su una serie di topic, e i sistemi terzi (“consumer”) vi si sottoscrivono ricevendo aggiornamenti in tempo reale, senza polling.

Dal punto di vista d’esame conta ricordare la differenza fra le versioni: pxGrid 1.0 usa il trasporto XMPP con un modello single-controller attivo, mentre pxGrid 2.0 adotta WebSocket + STOMP su TLS ed è basato su API REST, più scalabile e con più nodi attivi. In entrambi i casi il trasporto è cifrato e autenticato mutualmente con certificati.

Cosa pubblica ISE

• Session Directory: il mapping IP ↔ utente ↔ dispositivo, con attributi di posture, profiling (device type) e il Security Group Tag (SGT) assegnato alla sessione. È il “chi/cosa/dove” che dà agli altri prodotti un contesto identitario che da soli non hanno.
• TrustSec / SGT: definizioni degli SGT, mapping IP-SGT e le SGACL, così che i consumer possano correlare il traffico ai gruppi di sicurezza.
• ANC (Adaptive Network Control): il topic che permette a un consumer di richiedere azioni di contenimento (quarantine, port-bounce, shutdown).

Consumer tipici

Rapid Threat Containment (RTC)

Lo scenario chiave abilitato da pxGrid è Rapid Threat Containment. Un consumer come FMC o Secure Network Analytics rileva un comportamento malevolo, poi — tramite pxGrid — invoca una policy ANC su ISE. ISE applica l’azione all’endpoint emettendo una CoA (Change of Authorization) verso il NAD, che rimuove o degrada l’accesso (quarantine, cambio di SGT/dVLAN, port-bounce). Il risultato: una minaccia vista al livello applicativo/di flusso viene contenuta al punto di accesso alla rete, in modo automatico e ripetibile.

Approvazione dei client pxGrid

Ogni client deve prima registrarsi al controller ISE e poi essere approvato. L’approvazione può essere automatica o manuale: in produzione la modalità manuale è spesso preferita per controllo, mentre l’auto-approvazione velocizza i lab. Finché un client resta “Pending”, non riceve pubblicazioni.

Il trust dei certificati (il vero collo di bottiglia)

pxGrid usa mutual TLS: sia il nodo pxGrid di ISE sia il consumer si autenticano con certificato. Perché il canale si stabilisca:

• Il certificato pxGrid di ISE deve essere valido e con EKU corretta.
• Il certificato del client deve essere firmato da una CA che ISE fida (trusted store), e il client deve fidarsi della CA che ha firmato il certificato pxGrid di ISE.
• La catena completa deve essere importata su entrambi i lati; è comune usare la CA interna di ISE per emettere i certificati pxGrid.

Se manca anche solo un anello della catena, la registrazione fallisce o il client resta disconnesso — pur essendo “approvato”.

Ridondanza attivo/standby e collocazione della persona

La persona pxGrid si abilita su un nodo del deployment e, per l’alta disponibilità, su due nodi in modalità attivo/standby: i client si connettono al nodo attivo e, in caso di guasto, riconnettono automaticamente al nodo superstite, che promuove sé stesso ad attivo. Le sottoscrizioni vengono ristabilite alla riconnessione.

Scelta critica di design: la persona pxGrid non va collocata su un nodo già saturo (ad esempio un PSN che gestisce un volume elevato di RADIUS/posture). pxGrid può generare carico significativo con molti consumer e sessioni ad alta frequenza di aggiornamento; su nodi dedicati (o quantomeno non congestionati) si evitano latenze e drop delle pubblicazioni.

Trappole tipiche d’esame

• Scenario: FMC non mostra username/SGT sugli eventi pur essendo “approvato” su ISE → Risposta giusta: manca il trust dei certificati (catena CA incompleta nel trusted store di ISE o del client), non un problema di policy ANC.
• Scenario: dopo aver abilitato pxGrid, ISE mostra latenza e i client perdono aggiornamenti → Risposta giusta: la persona pxGrid è su un nodo sovraccarico; spostarla su un nodo dedicato/meno carico.
• Scenario: un client resta in stato Pending e non riceve topic → Risposta giusta: manca l’approvazione del client (auto-approval disabilitato), non un problema di CoA.
• Scenario: serve contenere automaticamente un host segnalato da Secure Network Analytics → Risposta giusta: Rapid Threat Containment via ANC, con ISE che emette la CoA verso il NAD (non un blocco statico sul firewall).
• Scenario: il nodo pxGrid attivo va giù e ci si chiede se serve intervento manuale → Risposta giusta: con HA attivo/standby i client riconnettono da soli al nodo standby promosso ad attivo.