Safeguard: Security Controls at the Software Defined Network Layer

Sintesi Tecnica: Safeguard – Controlli di Sicurezza al Livello delle Reti Software-Defined

Problematica
La rapida adozione delle reti software-definite (SDN) offre vantaggi significativi in termini di configurazione dinamica e compromessi costo-prestazioni rispetto ai sistemi basati su hardware. Tuttavia, questo passaggio introduce vulnerabilità critiche di sicurezza, in particolare riguardo alla dipendenza da policy guidate dai dati. Sebbene le applicazioni basate sui dati (come i sistemi di rilevamento delle intrusioni basati sul machine learning) possano regolare le policy di rete alla velocità di linea per adattarsi a requisiti fluttuanti, esse sono suscettibili di "sovra-correzione". Se questi sistemi ricevono input maliziosi o incontrano casi limite nel traffico di rete, possono generare conseguenze indesiderate, come il blocco del traffico legittimo (falsi positivi) o l'incapacità di rilevare minacce reali (falsi negativi). Il documento sostiene che lasciare la gestione della policy di rete interamente a design guidati dai dati, senza vincoli definiti dall'uomo, può esporre le reti a scenari di denial-of-service o a posture di sicurezza inefficaci.

Metodologia
Gli autori propongono Safeguard, un framework basato su regole progettato per sovrapporsi e vincolare le policy guidate dai dati al fine di prevenire risposte indesiderate. Il progetto è stato implementato utilizzando risorse CloudLab per istanziare un ambiente SDN simulato. L'architettura del sistema consiste in tre livelli primari:

1. Topologia di Rete e Controller: L'esperimento ha utilizzato un controller Floodlight OpenFlow e un framework Open vSwitch (OVS). I flussi di traffico sono stati catturati dal dataplane e riportati al controller. Il controller è stato configurato per applicare regole di blacklist IP basate sulle istruzioni provenienti dal livello di intelligence.
2. Simulazione di Attacco: Il team ha simulato attacchi di Distributed Denial of Service (DDoS) e di flooding di pacchetti (ICMP, UDP e TCP SYN) utilizzando Hping3. Lo scenario di attacco prevedeva nodi che generavano traffico per sovraccaricare il controller e un host target, con l'obiettivo di interrompere le connessioni legittime tra i nodi.
3. Livello di Intelligence: Questo componente elabora le caratteristiche del traffico in tempo reale (IP sorgente/destinazione, porta, protocollo, timestamp).
   • Design Iniziale: Gli autori avevano inizialmente considerato l'uso di un classificatore basato su machine learning (facendo riferimento a Zhang et al.), ma hanno abbandonato l'idea a causa della mancanza di artefatti riproducibili nella letteratura esistente.
   • Implementazione: Invezione, hanno sviluppato un classificatore basato su firme tarato per "sovra-correggere". Questo sistema è stato deliberatamente configurato per segnalare il traffico in modo aggressivo (ad esempio, pacchetti SYN rapidi, scansione di porte multiple, scansione di IP multipli) per simulare il comportamento di falso positivo tipico dei modelli di machine learning imperfetti.
   • Il Meccanismo di Safeguard: È stato introdotto un set di regole specifico per agire come una "policy di correzione della policy". Questo meccanismo mantiene un elenco di traffico "noto come buono" (ad esempio, connessioni a porte specifiche su server affidabili). Se un host corrisponde a questi criteri, le regole di Safeguard lo escludono esplicitamente dal processo di giudizio, impedendo al livello di intelligence di bloccarlo anche se i suoi schemi di traffico attivano le regole di firma aggressive.

Contributi Chiave

• Proposta di Framework: L'introduzione di Safeguard, un approccio ibrido che combina l'analisi guidata dai dati con vincoli statici basati su regole per mitigare i rischi di eccessiva portata delle policy automatizzate.
• Implementazione di Riferimento: Un prototipo funzionante che dimostra come un livello di intelligence possa emettere dinamicamente comandi di blocco a un controller SDN applicando simultaneamente uno strato di salvaguardia per proteggere il traffico legittimo.
• Dimostrazione della Sovra-correzione: Il sistema ha dimostrato con successo che, senza salvaguardie, una policy basata sull'analisi può bloccare host legittimi (nello specifico, un host con IP 172.16.7.2) quando questi presentano schemi di traffico che si sovrappongono alle firme di attacco.

Risultati Sperimentali
Gli autori hanno condotto una dimostrazione confrontando due scenari: uno che utilizza solo il set di firme aggressive e un altro che utilizza il set di firme aumentato dalle regole di Safeguard.

• Senza Safeguard: Il livello di intelligence ha identificato l'host legittimo (172.16.7.2) come malevolo sulla base dei suoi schemi di traffico ed ha emesso un comando di blocco IP, causando efficacemente un denial of service.
• Con Safeguard: Le regole di Safeguard hanno identificato l'host come una connessione "nota come buona". Di conseguenza, il livello di intelligence è stato impedito di giudicare tale host, e il comando di blocco non è stato emesso.
  I risultati confermano che lo strato Safeguard ha impedito con successo il blocco non intenzionale del traffico legittimo in presenza di un modello di rilevamento eccessivamente aggressivo.

Significatività e Rivendicazioni
Il documento afferma modestamente che Safeguard funge da necessaria "policy di correzione della policy" per garantire il corretto funzionamento delle SDN. Gli autori sostengono che i modelli puramente guidati dai dati per la creazione di policy incontreranno inevitabilmente casi limite che porteranno a esiti indesiderati. Argomentano che, indipendentemente dalla sofisticatezza del design di rilevamento delle intrusioni, le regole di salvaguardia sono cruciali per limitare la sovra-correzione. Sovrapponendo regole statiche alle policy dinamiche, gli amministratori di rete possono raggiungere livelli più elevati di sicurezza adattabile, garantendo che le decisioni guidate dai dati non compromettano la disponibilità della rete per gli utenti legittimi. Il lavoro suggerisce che, sebbene il rilevamento delle anomalie e il machine learning siano preziosi, richiedono un "parapetto" di regole predefinite per essere applicabili nel mondo reale.