API Security – Wat je moet weten

Het 2022 Year-End API ThreatStatsTM Report biedt een aantal zeer interessante inzichten in de toename van attacks op API endpoints. Ze hebben zichzelf de gigantische taak gesteld om door een berg attacks te duiken om patronen en trends te ontdekken, en ik juich dat absoluut toe.

De punten die ik het meest interessant vond, zijn de schaal waarop attacks op API’s zijn toegenomen (+192% vanaf 2022), de herhaling van het feit dat aanvallers zich niets aantrekken van de OWASP Top 10 en de focus op Open Source Software (OSS).

Waarom Open Source geweldig is

Om met het laatste te beginnen, Open Source Software heeft veel grote voordelen. De eerste en belangrijkste is het feit dat het jou en iedereen in staat stelt om in de code te duiken, bugs te vinden, ze te rapporteren en bugfixes aan developers door te geven.

De keerzijde van dit voordeel is dat het aanvallers ook in staat stelt om in de code te duiken, bugs te vinden, ze niet te rapporteren en ze te gebruiken om toegang te verkrijgen tot je gegevens. Een ander nadeel van OSS is dat veel mensen in staat zijn om bugs te vinden, maar het gemiddelde OSS-project vertrouwt op slechts één of misschien een paar developers om alles te fixen.

Maar Open Source heeft zijn nadelen

Zoals je je waarschijnlijk wel voor kunt stellen, kan dit een groot probleem worden. Een van de belangrijkste voorbeelden hiervan is de Log4Shell vulnerability waar we allemaal onder te lijden hadden in december 2021.

Hoewel het team van developers achter Log4j uit 16 developers bestond, waren ze allemaal onbetaalde vrijwilligers. Dit betekent dat alle developers van het project ook de verantwoordelijkheid dragen van een dagtaak en in hun vrije tijd alle verantwoordelijkheden van een persoonlijk leven moeten combineren met de verantwoordelijkheden van het reageren op bug meldingen.

Ook al was Log4j op zichzelf niet zo’n waanzinnig groot project, betekende het wijdverspreide gebruik ervan in bijna alle grote, op Java gebaseerde programma’s, dat de impact van deze fout extreem was.

Terugkijkend op Log4j, kunnen we zeggen dat op zijn minst meerdere mensen de tijd hadden kunnen vinden om het lek te vinden en te repareren. Maar stel je voor wat er gebeurt als een enkele developer iets geniaals bouwt dat door de halve wereld wordt gebruikt. De kans dat die ene developer regelmatig naar zijn/haar code van jaren geleden kijkt, is vrij klein. Dit betekent dat als je afhankelijk bent van de activiteit in een Open Source project, het een eeuwigheid kan duren voordat er zelfs maar een fix wordt geprobeerd.

Nu zeg ik niet dat je geen Open Source Software moet gebruiken, maar je moet bereid zijn om ontwikkelingstijd te investeren om problemen met die software op te lossen. Zelfs als het alleen is om je eigen veiligheid te garanderen.

Als ik een hacker zou zijn, zou ik de OWASP Top 10 waanzinnig nuttig vinden

Het tweede punt dat ik opvallend vond, was de OWASP Top 10. Hoewel het misschien als een oplossing klinkt om de OWASP Top 10 te blokkeren (en dat is het ook), moeten we ook begrijpen wat de belangrijkste tekortkomingen van de OWASP Top 10 zijn.

De eerste is misschien voor de hand liggend: het is een top 10. Dit betekent dat het nooit een volledige lijst is. Het is alleen de lijst van de populairste aanvalsvectoren op een bepaald moment. Vanuit dat perspectief is het hetzelfde als traditionele AV: omdat we niet alle AV-handtekeningen kunnen opnemen, nemen we alleen de top-X van virushandtekeningen op, zodat je dat wat actief rondgaat kunt stoppen.

Het nadeel van die aanpak is altijd geweest dat je (in het geval van AV) de oudere of minder ‘populaire’ virussen niet ziet. Voor API-security betekent dit dat als je je alleen richt op de top 10, je ook niets anders detecteert en blokkeert dan die top 10 aan meest populaire aanvalsvectoren.

Als ik een hacker zou zijn, zou ik de OWASP Top 10 waanzinnig nuttig vinden. Het zou me de tien aanvalsvectoren geven die over het algemeen geen kans maken, zodat ik weet wat ik niet hoef te proberen. Het bespaart me gewoon tijd bij mijn pogingen om je API binnen te dringen.

Waarom is dit dezelfde aanpak ans next-gen AV?

Voor API-security moeten we dezelfde aanpak kiezen als next-gen AV heeft gedaan. Maak strikte API-specificaties en controleer elke API-call tegen die strike API-specificatie. Alles wat afwijkt van de verwachte input moet altijd worden geblokkeerd. Het is simpelweg geen input zoals de developer het bedoeld heeft.

Waarom is dit dezelfde aanpak als next-gen AV? Next-gen AV kijkt niet meer naar de top-X van meest actieve virussen, maar kijkt naar elke executable en elk bestand om te controleren of het echt veilig is, en het doet dit door gebruik te maken van de cloud. Waarom zetten we de cloud niet in voor onze API-security? Voortdurend aanvalsvectoren toevoegen aan ons API-security product en voortdurend de kennis vergroten van wat er op ons afkomt.

Het belangrijkste voordeel van API-security is de API-specificatie. Met AV moet je de cloud gebruiken omdat je niet weet welke executable je gebruikers morgen kunnen starten, of welke gecompromitteerde bestanden ze kunnen ontvangen. Met een API-specificatie kunnen we in feite dicteren wat we willen ontvangen en hoe dat eruit moet zien. Maak dus API-specificaties en blijf ze verbeteren om voortdurend je aannames te valideren over wat het verwachte gedrag van je API werkelijk is.

Containers zijn een van de weinige oplossingen die ik ken die goed werken met een allowlist

Als je containers gebruikt om je API’s te publiceren, worden de mogelijkheden voor security nog groter. Waarom zou je stoppen bij het kijken naar de API-calls als je je containers kunt beperken met alleen verwachte processen? Containers zijn een van de weinige oplossingen die ik ken die goed werken met een allowlist; ze hebben verwacht gedrag dat gemakkelijk te bepalen is! Zelfs als je API gecompromitteerd is en een aanvaller (vanuit een API perspectief) processen in je container zou kunnen starten, kan je container securityoplossing dat detecteren en de draaiende container onmiddellijk beëindigen om verdere compromittering te voorkomen. Dit, in combinatie met het bouwen van applicaties met behulp van de 12-factor app-principes, beperkt je blootstelling aan bedreigingen en, als er toch bedreigingen opduiken, beperkt deze combinatie de impact die deze bedreigingen (kwetsbaarheden) hebben op je gegevens..

De meeste API-security oplossingen kunnen zoveel meer!

Nu over naar het eerste punt in mijn lijst van interessante bevindingen: ik denk dat het absoluut logisch is dat de aanvallen van API’s in aantal toenemen. Steeds meer van onze wereld verschuift naar een API-gebaseerde aanpak. De monoliet is niet meer (of zou dat niet meer moeten zijn) en de applicaties die je op je apparaten draait worden steeds meer een lege huls die API-calls gebruikt om je gegevens te presenteren. Uiteindelijk zitten de gegevens niet in de applicatie die je gebruikt, maar in de API’s waarmee je communiceert. Dus waarom een UI aanvallen als je direct de API kunt aanvallen?

Zorg ervoor dat je je API’s beschermt met de beste oplossingen die je hebt (of koop er een!) en zorg ervoor dat je niet stopt na het configureren van je oplossing om alleen de top-X bedreigingen te blokkeren. De meeste API-security oplossingen kunnen zoveel meer dan dat!