Trasformare gli indicatori di minaccia di Cloudflare in regole WAF in tempo reale

Non appena un indicatore di minaccia entra nel sistema, le regole iniziano a bloccare il traffico. Questa azione sembra molto accurata. Il ritmo è veloce, il feedback è rapido e i report sono bellissimi. Ma una volta che questa cosa è stata messa in produzione, la vera difficoltà non è più trasformare l’indicatore in una regola, ma fare in modo che questa regola resista al traffico, ai falsi positivi e ai rollback.

Quando ho letto Trasformare gli indicatori di minaccia di Cloudflare in regole WAF in tempo reale, ciò che mi è venuto in mente non sono state le parole fantasiose “automazione dell’accesso all’intelligence”, ma diverse immagini molto pratiche: un IP è stato contrassegnato in rosso ed è stato intercettato dieci minuti dopo; un’ASN è stata contrassegnata ad alto rischio e, di conseguenza, è stata coinvolta un’intera uscita condivisa; un campione di attacco di breve durata era appena entrato nella rule base e il traffico dell’attacco era stato interrotto, lasciando una vecchia regola che continua ad essere in vigore. In questo caso, il tempo reale non è solo una questione di velocità, ma comprime il ciclo di vita delle regole, la credibilità dei dati e le responsabilità di disposizione nella stessa finestra.

Le regole possono essere veloci, a condizione che possano essere ritirate

Quando un indicatore di minaccia entra in un WAF, il primo a perdere la pazienza solitamente non è l’aggressore, ma la persona di turno. Perché una volta che una norma entra in vigore, ciò che segue non è un astratto “miglioramento della sicurezza”, ma specifici infortuni accidentali, ricorsi, revoche e controlli. Gli indicatori a livello IP sono i più facili da delegare. Hanno colpi a punto singolo, tempi di sopravvivenza brevi e bassi costi di recupero. Indicatori come ASN, segmento di rete, impronta digitale TLS e combinazione di richieste sono molto più cauti. Coprono un’area più ampia e hanno effetti collaterali più difficili quando colpiscono.

La parte davvero preziosa di questo è che le regole non vengono scritte una volta e poi completate, ma appaiono con TTL, fonte, portata di successo e condizioni di annullamento. Senza questi campi, le regole in tempo reale degenererebbero rapidamente in un mucchio di record di ban scaduti. Se blocchi un attacco oggi, inizierai a bloccare gli utenti normali domani. Il cattivo odore più comune nella produzione è che la base normativa diventa sempre più spessa e ciò che viene conservato non è un giudizio effettivo, ma emozioni storiche.

Dovrebbe essere lasciato un buffer tra il livello indicatore e il livello azione.

Tradurre gli indicatori di minaccia direttamente in regole di blocco è ovviamente il passaggio più veloce, ma questo passaggio è anche il più semplice per amplificare gli errori di intelligence in incidenti online. Un approccio più stabile consiste solitamente nel lasciare uno strato di buffer tra l’indicatore e l’azione, consentendo allo stesso segnale di passare prima attraverso l’osservazione, la sfida e il limite di velocità, quindi decidere se bloccarlo davvero. Una volta che questo strato buffer viene a mancare, più velocemente gli indicatori vengono aggiornati, più velocemente le regole verranno danneggiate accidentalmente.

Quando viene effettivamente implementata, la regola è meglio non essere un semplice interruttore on/off, ma un insieme di stati che possano esprimere l’intensità dell’azione: prima registrare, poi sfidare, quindi limitare la corrente e infine inserire l’intercettazione. Il vantaggio di ciò è semplice: le regole possono essere rafforzate gradualmente man mano che le prove diventano più forti e possono essere rapidamente declassate quando le prove diventano più deboli. Per il team di sicurezza, questo può mantenere la credibilità meglio che compilare tutte le regole contemporaneamente; per quanto riguarda gli affari, almeno possono vedere le fluttuazioni anomale quando appaiono per la prima volta, invece di aspettare che i ticket del servizio clienti vengano accumulati per scoprire cosa è successo.

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

Questa struttura sembra semplice, ma in realtà è molto importante. Quando confidence è basso, la prima sfida assomiglia più a un giudizio ingegneristico che a un’intercettazione diretta; ttl scade automaticamente dopo la scadenza per evitare che vecchie informazioni rimangano appese sul lato; scope viene ridotto a un percorso o a un segmento di traffico in modo che l’area del danno accidentale non venga ampliata all’infinito.

Senza revisione, le regole diventeranno solo più lunghe e sembreranno un mucchio di spazzatura.

La più grande paura del WAF in tempo reale non è il basso tasso di successo, ma che nessuno sappia cosa sia successo dopo l’hit. Dopo che le regole sono state rilasciate, devi essere in grado di guardare indietro a tre cose: quanti attacchi reali sono stati bloccati, quante richieste normali sono state uccise accidentalmente e se ci sono stati nuovi metodi di bypass dopo gli attacchi. Solo collegando queste tre cose la regola può essere considerata operativa e mantenibile; senza nessuno di essi, alla fine diventerà un’azione inerziale di “bloccarlo comunque prima”.

Questa è anche la parte più sottovalutata dell’automazione degli indicatori di minaccia. Potrebbero esserci molte fonti di indicatori e gli aggiornamenti di intelligence potrebbero essere frequenti, ma senza un ciclo di feedback stabile, le regole andranno sempre avanti. Un sistema veramente maturo registrerà il tasso di successo, il numero di rollback, il numero di rilasci manuali, gli allarmi correlati e le perdite aziendali di ciascuna regola. A questo punto le regole non sono più semplicemente configurazioni di sicurezza, ma registrazioni di smaltimento con una catena di prove.

Questo set di strumenti è adatto solo ai team che dispongono già di funzionalità di smaltimento

Trasformare gli indicatori di minaccia in regole WAF in tempo reale non è adatto a tutti gli scenari. Per i sistemi con poco traffico, superficie di attacco ristretta e operazioni manuali sufficientemente veloci, spesso è più problematico continuare a fare affidamento su regole statiche e aggiornamenti manuali. Coloro che hanno realmente bisogno di questa funzionalità sono solitamente team con traffico intenso, elevata densità di attacchi, frequenti modifiche alle regole e già dotati di registri, processi di revisione e di servizio.

Una volta implementato questo tipo di sistema, il valore non è semplicemente quello di “fermarsi più velocemente”. Ciò che è ancora più importante è trasformare lo smaltimento della sicurezza da un giudizio manuale una tantum in una catena di esecuzione revocabile, rivedibile e graduabile. Il vantaggio di una piattaforma come Cloudflare nel fare questo non è solo che può ricevere più segnali di minaccia, ma che ha la capacità di inviare i segnali al livello delle regole e quindi ricollegare il livello delle regole al monitoraggio, al rollback e all’auditing. Senza questa catena, il tempo reale non farà altro che velocizzare gli errori; con questa filiera le regole possono davvero entrare in produzione.