Il security design nel core enterprise

Progettare la sicurezza di rete significa distribuire i controlli su più livelli — perimetro, endpoint, DNS, accesso e segmentazione — in modo che nessun singolo punto di compromissione possa propagarsi liberamente. Nel blueprint ENCOR l’obiettivo non è configurare ogni prodotto, ma sapere quale tecnologia risolve quale scenario e perché.

Threat defense e next-gen firewall

Il next-generation firewall (NGFW) Cisco è Firepower Threat Defense (FTD), l’immagine di enforcement che gira su appliance Firepower o su ASA convertite. FTD unisce stateful firewalling, application visibility and control (AVC), URL filtering e il motore IPS Snort, oltre all’ispezione di malware con Advanced Malware Protection (AMP).

Il punto cruciale d’esame è la separazione dei ruoli:

Componente Ruolo
FMC (Firepower Management Center) Management, policy, logging, correlazione eventi. Non ispetta traffico dati
FTD Data plane / enforcement: applica policy e blocca il traffico

FMC è il “cervello” centralizzato; FTD è il “muscolo” in linea. Perdere l’FMC non ferma l’enforcement già distribuito, ma impedisce di modificarlo e raccogliere eventi.

Endpoint e DNS-layer security

  • Cisco Secure Endpoint (ex AMP for Endpoints) protegge host e server con analisi comportamentale, retrospective security e blocco file malevoli. Copre il livello che il firewall di rete non vede (traffico cifrato locale, USB, movimento laterale interno).
  • Cisco Umbrella offre DNS-layer security: risolvendo le query DNS nel cloud blocca domini malevoli prima che si stabilisca la connessione. È efficace anche per utenti off-network e come primo filtro leggero contro C2 e phishing.

I due livelli sono complementari: Umbrella ferma la richiesta iniziale, Secure Endpoint contiene ciò che è già sull’host.

Segmentazione: TrustSec, SGT e MACsec

La segmentazione riduce la superficie d’attacco isolando i gruppi di risorse. Cisco TrustSec classifica il traffico con i Security Group Tag (SGT): un tag assegnato all’atto dell’autenticazione (via ISE) e propagato nel frame, così le policy (SGACL) si basano sul ruolo e non su indirizzi IP o VLAN. Questo disaccoppia la sicurezza dalla topologia IP.

MACsec (IEEE 802.1AE) cifra invece il traffico hop-by-hop a livello 2, garantendo confidenzialità e integrità sul singolo link (tipicamente switch-host o switch-switch). TrustSec definisce chi può parlare con chi; MACsec protegge il collegamento fisico su cui quel traffico transita.

Network Access Control con ISE

Identity Services Engine (ISE) è il policy server (RADIUS) che governa l’accesso alla rete. Tre metodi principali, in ordine di robustezza:

  • 802.1X — autenticazione forte basata su credenziali/certificati con supplicant sull’endpoint (EAP-TLS, PEAP…). Prima scelta dove è disponibile un supplicant.
  • MAB (MAC Authentication Bypass) — fallback per dispositivi senza supplicant (stampanti, telecamere IP, IoT). Autentica solo sul MAC address, quindi è debole e spoofabile.
  • WebAuth — portale browser per guest, tipicamente con Central Web Authentication (CWA) su ISE.

ISE fornisce inoltre profiling, posture e l’assegnazione dinamica di VLAN o SGT come risultato dell’autorizzazione.

Sicurezza delle REST API

Il control plane programmabile (FMC, DNAC, ISE) espone REST API che vanno protette:

  • HTTPS/TLS obbligatorio: mai credenziali o token in chiaro.
  • Token-based auth: ci si autentica una volta e si ottiene un token a scadenza (bearer/session token), usato nelle chiamate successive al posto della password.
  • Rate limiting: limita le richieste per client per mitigare brute force e DoS (risposta HTTP 429 Too Many Requests).
  • Principio del least privilege su account e scope API, più logging delle chiamate.

Trappole tipiche d’esame

  • Scenario: dispositivo senza supplicant che richiede sicurezza forte → NON è MAB. MAB autentica solo sul MAC, facilmente spoofabile: se lo scenario esige robustezza, la risposta è 802.1X; MAB è solo il fallback per endpoint che non possono fare 802.1X.
  • Scenario: “quale componente ispeziona/blocca il traffico?” → FTD, non FMC. FMC gestisce e configura le policy ma non è in linea sul data plane; l’enforcement è di FTD. Confonderli è l’errore classico.
  • Scenario: policy basate sul ruolo indipendenti da IP/VLAN → TrustSec/SGT, non MACsec. MACsec cifra il link L2 hop-by-hop; non definisce chi può parlare con chi. Se la domanda parla di cifratura di livello 2, allora è MACsec.
  • Scenario: bloccare domini malevoli prima della connessione → Umbrella (DNS-layer), non NGFW. Umbrella agisce alla risoluzione DNS; l’NGFW ispeziona il traffico già instradato.
  • Scenario: proteggere una REST API da abuso/brute force → rate limiting (HTTP 429) + token su HTTPS. Non basta “usare una API key”: mancano scadenza del token, trasporto cifrato e limiti di frequenza.