De dreigingsindicatoren van Cloudflare omzetten in realtime WAF-regels

Zodra een dreigingsindicator het systeem binnenkomt, beginnen de regels het verkeer te blokkeren. Deze actie ziet er erg netjes uit. Het tempo is hoog, de feedback is snel en de rapporten zijn prachtig. Maar zodra dit ding in productie is genomen, is de echte moeilijkheid niet langer om van de indicator een regel te maken, maar om deze regel bestand te maken tegen verkeer, valse positieven en terugdraaiingen.

Toen ik Turning Cloudflare’s threat indicators into real-time WAF-regels las, dacht ik niet aan de mooie woorden ‘automatisering van inlichtingentoegang’, maar aan een aantal zeer praktische afbeeldingen: een IP-adres werd rood gemarkeerd en werd tien minuten later onderschept; een ASN werd gemarkeerd als een hoog risico, en als gevolg daarvan was er sprake van een volledige gedeelde exit; een kortstondige aanvalssteekproef was zojuist de regelbasis binnengekomen en het aanvalsverkeer was afgesneden, waardoor een oude regel overbleef die nog steeds van kracht is. Realtime gaat hier niet alleen over snelheid, het comprimeert de levenscyclus van regels, de geloofwaardigheid van gegevens en de verantwoordelijkheden voor de dispositie in hetzelfde venster.

Regels kunnen snel zijn, op voorwaarde dat ze kunnen worden ingetrokken

Wanneer een dreigingsindicator een WAF binnenkomt, is de eerste die zijn geduld verliest meestal niet de aanvaller, maar de dienstdoende persoon. Want zodra een regel van kracht wordt, volgt er geen abstracte ‘verbetering van de veiligheid’, maar specifieke accidentele verwondingen, beroepsprocedures, terugdraaiingen en audits. Indicatoren op IP-niveau zijn het gemakkelijkst te delegeren. Ze hebben single-point treffers, korte overlevingstijden en lage herstelkosten. Indicatoren zoals ASN, netwerksegment, TLS-vingerafdruk en verzoekcombinatie zijn veel voorzichtiger. Ze bestrijken een groter gebied en hebben moeilijkere bijwerkingen bij het slaan.

Het echt waardevolle hiervan is dat de regels niet in één keer worden geschreven en dan klaar zijn, maar verschijnen met TTL, source, hit range en undo-voorwaarden. Zonder deze velden zullen real-time regels snel ontaarden in een reeks verlopen banrecords. Als u vandaag een aanval blokkeert, begint u morgen met het blokkeren van normale gebruikers. De meest voorkomende stank in de productie is dat de basis van regels steeds dikker wordt, en wat behouden blijft is geen effectief oordeel, maar historische emoties.

Er moet een buffer worden gelaten tussen de indicatorlaag en de actielaag.

Het direct vertalen van dreigingsindicatoren naar blokregels is natuurlijk de snelste, maar deze stap is ook de gemakkelijkste om inlichtingenfouten te vergroten tot online ongelukken. Een stabielere aanpak is meestal om een ​​bufferlaag tussen de indicator en de actie achter te laten, waardoor hetzelfde signaal eerst door observatie, uitdaging en snelheidslimiet kan gaan en vervolgens kan beslissen of het echt moet worden geblokkeerd. Zodra deze bufferlaag ontbreekt, geldt: hoe sneller de indicatoren worden bijgewerkt, hoe sneller de regels per ongeluk worden beschadigd.

Wanneer deze regel daadwerkelijk wordt geïmplementeerd, is het het beste om geen platte aan/uit-schakelaar te zijn, maar een reeks toestanden die de intensiteit van de actie kunnen uitdrukken: eerst opnemen, dan uitdagen, dan de stroom beperken en uiteindelijk de onderschepping ingaan. Het voordeel hiervan is eenvoudig: de regels kunnen geleidelijk worden geëscaleerd naarmate het bewijsmateriaal sterker wordt, en kunnen snel worden gedegradeerd wanneer het bewijsmateriaal zwakker wordt. Voor het beveiligingsteam kan dit de geloofwaardigheid beter behouden dan het in één keer invullen van alle regels; voor de zakelijke kant kunnen ze in ieder geval abnormale schommelingen zien wanneer ze voor het eerst verschijnen, in plaats van te wachten tot de klantenservicetickets zijn opgestapeld om erachter te komen wat er is gebeurd.

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

Deze structuur lijkt eenvoudig, maar is eigenlijk heel belangrijk. Wanneer confidence laag is, lijkt het eerst uitdagen meer op technisch oordeel dan op directe onderschepping; ttl vervalt automatisch na het verstrijken om te voorkomen dat oude informatie blijft hangen; scope wordt gereduceerd tot een pad of verkeerssegment, zodat het schadegebied niet oneindig wordt vergroot.

Zonder herziening worden de regels alleen maar langer en zien ze eruit als een vuilnisbelt.

De grootste angst voor real-time WAF is niet het lage trefferpercentage, maar dat niemand weet wat er na de hit is gebeurd. Nadat de regels zijn vrijgegeven, moet je naar drie dingen kunnen terugkijken: hoeveel echte aanvallen werden geblokkeerd, hoeveel normale verzoeken per ongeluk werden gedood en of er na de treffers nieuwe bypass-methoden waren. Alleen door deze drie dingen met elkaar te verbinden kan de regel als uitvoerbaar en handhaafbaar worden beschouwd; zonder een van hen zal het uiteindelijk een traagheidsactie worden van “het toch eerst blokkeren”.

Dit is ook het meest onderschatte onderdeel van de automatisering van dreigingsindicatoren. Er kunnen vele bronnen van indicatoren zijn, en inlichtingenupdates kunnen frequent zijn, maar zonder een stabiele feedbacklus zullen de regels altijd alleen maar vooruitgaan. Een echt volwassen systeem registreert het trefferpercentage, het aantal terugdraaiingen, het aantal handmatige releases, gerelateerde alarmen en bedrijfsverliezen van elke regel. Op dit moment zijn de regels niet langer eenvoudigweg beveiligingsconfiguraties, maar verwijderingsgegevens met een bewijsketen.

Deze set tools is alleen geschikt voor teams die al over verwijderingsmogelijkheden beschikken

Het in realtime omzetten van dreigingsindicatoren in WAF-regels is niet voor alle scenario’s geschikt. Voor systemen met weinig verkeer, een klein aanvalsoppervlak en een handmatige bediening die snel genoeg is, is het vaak lastiger om te blijven vertrouwen op statische regels en handmatige updates. Degenen die deze mogelijkheid echt nodig hebben, zijn meestal teams met veel verkeer, een hoge aanvalsdichtheid, frequente regelwijzigingen en al over logs, beoordelings- en taakprocessen.

Als dit type systeem eenmaal is geïmplementeerd, ligt de waarde niet alleen in ‘sneller stoppen’. Wat belangrijker is, is het transformeren van het veiligheidsbeleid van een eenmalig handmatig oordeel naar een herroepbare, controleerbare en gradeerbare uitvoeringsketen. Het voordeel van een platform als Cloudflare om dit te doen is niet alleen dat het meer dreigingssignalen kan ontvangen, maar ook dat het de mogelijkheid heeft om de signalen naar de regellaag te pushen en vervolgens de regellaag weer te verbinden met monitoring, rollback en auditing. Zonder deze keten zal real-time ervoor zorgen dat fouten alleen maar sneller gebeuren; met deze keten kunnen de regels echt de productie ingaan.