Dal dato grezzo alla classificazione: il certainty factor

ISE raccoglie attributi sugli endpoint attraverso le probe del profiler (RADIUS, DHCP, DNS, SNMP, HTTP, NetFlow, NMAP, pxGrid, AD). Questi attributi alimentano le profiling policy, ciascuna composta da una o più condizioni. Ogni condizione soddisfatta non produce un semplice match booleano: contribuisce con un certainty factor (CF), un valore numerico che ISE somma per quell’endpoint.

Una policy “matcha” quando il totale dei certainty factor delle sue condizioni verificate raggiunge o supera il suo Minimum Certainty Factor (MCF). Quando più policy superano la propria soglia, ISE assegna l’endpoint alla policy con il CF totale più alto, memorizzandola nell’attributo EndPointPolicy (con TotalCertaintyFactor a supporto).

Esempio: una condizione su dhcp-parameter-request-list che matcha un fingerprint noto può valere +10, l’OUI del vendor ricavato dal MAC +10, una porta TCP aperta rilevata da NMAP +20. Sommando i contributi, l’endpoint supera l’MCF della policy Workstation e viene profilato come tale.

La gerarchia delle profiling policy

Le policy sono gerarchiche: policy generiche come Workstation, IP-Phone, Printer fanno da genitore a policy figlie sempre più specifiche (vendor, modello, OS). Regola chiave d’esame: una policy figlia viene valutata solo se la policy genitore ha già matchato. Se Cisco-Device non raggiunge il suo MCF, ISE non scende a valutare Cisco-IP-Phone-7965 sotto di essa.

Questo meccanismo produce la classificazione “più specifica possibile”: l’endpoint scende lungo l’albero fino alla foglia con il CF più alto tra i fratelli che superano la propria soglia. Se nessuna figlia matcha, l’endpoint resta classificato al livello del genitore.

Endpoint identity group: dinamici e statici

Gli endpoint identity group sono contenitori usati poi nelle authorization policy. ISE ne fornisce di predefiniti (Profiled, RegisteredDevices, GuestEndpoints, Unknown, Blocked/Blacklist) e sotto Profiled alcuni di sistema (Workstation, Cisco-IP-Phone, ecc.).

Assegnazione dinamica — Nella profiling policy l’opzione Yes, create matching Identity Group genera un gruppo omonimo e vi inserisce gli endpoint matchati; in alternativa No, use existing Identity Group hierarchy mantiene la gerarchia standard. Il gruppo dinamico segue il profiling: se l’endpoint cambia comportamento ed è riprofilato, il profiler lo sposta.

Assegnazione statica — Un amministratore può assegnare manualmente un endpoint a un gruppo e spuntare Static Assignment. Da quel momento l’endpoint è “congelato” nel gruppo: il profiler continua a raccogliere attributi ma non ne cambia più l’identity group. Serve per eccezioni note (un dispositivo IoT particolare), ma va usata con parsimonia.

Caratteristica Dinamico Statico
Origine profiling policy admin manuale
Segue il riprofiling sì no (congelato)
Attributo StaticAssignment=false StaticAssignment=true

Uso nelle authorization policy

Nelle authz si può matchare a due livelli di granularità: sull’identity group (IdentityGroup:Name EQUALS Endpoint Identity Group:Profiled:Workstation) oppure direttamente sulla profiling policy (EndPoints:EndPointPolicy EQUALS Apple-iPad) o su un Logical Profile che raggruppa più policy. Ricorda che un cambio di profilo può generare un CoA (secondo la Global CoA policy: No CoA / Port Bounce / Reauth) per riapplicare l’autorizzazione corretta.

Trappole tipiche d’esame

  • Soglie di certainty in conflitto tra figlie → se due policy figlie condividono condizioni e i CF non le differenziano, vince quella con CF totale più alto; se una figlia specifica ha un MCF troppo elevato non matcha e l’endpoint resta sul genitore generico. Risposta giusta: regolare MCF e incrementi di CF, non aggiungere probe a caso.
  • Genitore che non matcha → una policy figlia molto specifica non scatta mai perché il genitore non raggiunge il suo MCF: la valutazione gerarchica blocca la discesa. Verificare prima il matching del parent.
  • Static Assignment che sovrascrive il profiling → un endpoint messo staticamente in un gruppo NON verrà più riprofilato dinamicamente; se “il dispositivo non cambia gruppo nonostante nuovi attributi”, la causa è StaticAssignment=true.
  • Identity group vs EndPointPolicy → per una regola authz molto granulare conviene matchare su EndPointPolicy/Logical Profile, non solo sull’identity group generico Profiled.
  • Nessun CoA configurato → l’endpoint è riprofilato correttamente ma conserva l’autorizzazione vecchia perché la Global CoA è su “No CoA”: il profiling è giusto, manca il re-enforcement.