API’s zijn onmisbaar, maar ook een securityrisico

API’s zijn overal tegenwoordig. Je kunt vrijwel geen gesprek voeren over IT zonder het erover te hebben. Deze alomtegenwoordigheid zorgt er echter ook voor dat API’s steeds vaker doelwit worden van aanvallers. Hoe zorg je ervoor dat je API’s veilig zijn en blijven? Bij Noname Security zeggen ze een antwoord te hebben op deze vraag. Wij gingen hierop in met Steven Duckaert, EMEA Solutions Architect bij deze aanbieder van API-security software.

De API is een klein maar onmisbaar onderdeel geworden binnen veel organisaties. Als je verschillende omgevingen, systemen, applicaties of workloads met elkaar wilt laten communiceren en integreren, doe je dat middels een API. Moderne software-oplossingen ondersteunen API’s vrijwel zonder uitzondering. Dat wil zeggen, je kunt vrijwel iedere applicatie en ieder proces aan elkaar koppelen. Dat levert veel mogelijkheden op om zaken te stroomlijnen binnen je organisatie. Zo kun je op deze manier je ERP-data en je CRM-data samenvoegen, om zo nog beter inzicht te krijgen in bijvoorbeeld je supply chain.

Het afzetgebied van API’s is vanzelfsprekend enorm, omdat de voordelen van het integreren van systemen en oplossingen evident zijn. Je bespaart er veel tijd mee en kunt veel meer en betere inzichten uit je data halen, om enkele voordelen te noemen. Het is daarnaast ook nog eens niet ingewikkeld. “De code van een API is twee keer niks”, in de woorden van Duckaert. “Je kunt heel eenvoudig services exposen middels API’s en dus ook heel snel integraties live zetten”, legt hij verder uit.

Kracht van API’s is ook de zwakte

De eenvoud van API’s op het gebied van de code is zonder twijfel een pluspunt als je er als ontwikkelaar mee aan de slag gaat. Je kunt immers lekker snel werken. Dat is bij het moderne werken in sprints, waarbij je om de paar weken nieuwe functionaliteit op moet leveren, extra prettig. De code is verder ook redelijk stateless, dus je hoeft weinig rekening te houden met afhankelijkheden. Dat helpt ook bij het realiseren van een relatief hoge ontwikkelsnelheid.

De eenvoud van de code van API’s is echter ook meteen een zwak punt, geeft Duckaert aan. Vaak gebruik je API’s om data uit een process, systeem of applicatie in het back-end bloot te stellen aan een client of andere service. Dit gebeurt snel en hoogstwaarschijnlijk ook regelmatig zonder er goed bij na te denken. Dan is er ook nog het risico dat API’s na verloop van tijd vergeten worden of sowieso al niet goed beheerd worden. Volgens Duckaert is dat laatste het geval bij gemiddeld 30 procent van het API-verkeer bij klanten die de public cloud gebruiken. Die 30 procent wordt dus niet afgehandeld door een API Gateway of Web Application Firewall (WAF). Zonder zo’n gateway of WAF heb je geen zicht op wat er gebeurt en kun je geen bescherming bieden.

Het mag duidelijk zijn dat het belangrijk is om API’s goed te beveiligen. Je loopt potentieel een groot risico als kwaadwillenden via die API’s binnen kunnen komen. Ze kunnen via de API’s relatief eenvoudig in de kern of het back-end van je organisatie komen. Algemeen wordt aangenomen dat API’s zeer snel de voornaamste aanvalsvector zullen zijn, als ze dat niet al zijn. 

Nieuwe benadering nodig

Het beschermen van je API’s is echter eenvoudiger gezegd dan gedaan. Bestaande (security-)oplossingen zoals een Web Application Firewall of API Gateway kunnen je namelijk niet beschermen, geeft Duckaert aan. Het gaat volgens hem namelijk vaak om code in je back-end die niet in orde is. En daar krijg je met een WAF of API Gateway geen inzicht in. Met andere woorden, je hebt een security-oplossing nodig die zich specifiek richt op de veiligheid van de API’s. Dat is waar Noname Security om de hoek komt kijken.

Noname Security mag dan een naam hebben die bedacht lijkt te zijn in een jolige bui, het aanbod op het gebied van API-security is zeker serieus te noemen. Noname maakt gebruik van het acroniem DART om duidelijk te maken waar het zich mee bezighoudt. DART staat voor Discover, Analyze, Remediate en Test.

Discover en Analyze

Binnen het Discover-deel kun je realtime alle API’s in kaart brengen. Je brengt hier ook zombie API’s en unmanaged API’s mee in kaart. Je kunt aan de API bijvoorbeeld ook zien of deze PII-informatie bevat. Bij AWS kun je eventuele issues meteen aan een instance en infrastructuur koppelen. Dat soort zaken komen goed van pas bij het Analyze-gedeelte. Dat is gericht op het opsporen van misconfiguraties of policy violations. Dat laatste is erg nuttig met het oog op GDPR/AVG. API’s die PII-informatie doorzetten worden anders behandeld dan API’s die dit niet doen. Je kunt meteen een ticket aan laten maken binnen het platform van Noname als er een policy violation ontdekt wordt.

Remediate en Test

Binnen het Remediate-gedeelte van de benadering van Noname Security, komen de integraties om de hoek kijken. Als een gebruiker bijvoorbeeld overdreven veel API-verzoeken uitstuurt, moet je daar natuurlijk ook actie op kunnen ondernemen. Dat kan Noname zelf niet doen, omdat hun oplossing out-of-band opereert. (Zie het kader elders op deze pagina voor meer informatie hoe dit werkt.) Daarvoor moet het de integraties met andere componenten inzetten. Een API Gateway kan in het geval van overdreven gebruik ingrijpen en de API afknijpen.

Binnen het Remediate-gedeelte van de benadering van Noname krijg je ook meteen een indicatie van de doelgroep van het bedrijf. Als je geen gebruik kunt maken van in-house integraties met andere API-componenten, val je buiten de doelgroep. Noname zoekt met name klanten met een stevig aantal in-house developers. Duckaert heeft het tijdens ons gesprek over 50+ developers. Dan ga je waarschijnlijk ook technologieën gebruiken waarmee Noname kan integreren, geeft hij aan. Bedrijven die kiezen voor de standaard SaaS of on-prem tooling, zonder verder zelf in-house te ontwikkelen, zijn geen al te goede match voor Noname.

Kijken we weer naar DART, dan blijft na Remediate alleen Test nog over. Hiermee is het mogelijk om de Noname-oplossing in te zetten om rapportages te produceren. Daar staan dan ook aanbevelingen in om API-security te verbeteren. Verder kan dit onderdeel ook helpen bij pentesting. Denk hierbij onder andere aan fuzzing, oftewel het bestoken van applicaties/API’s met onzinnige en bewust foute data, om zo eventuele bugs te ontdekken. Je kunt dit onderdeel tot slot ook gebruiken om een API te testen bij het ontwikkelen van een applicatie met al dan niet een integratie met je DevOps Tools.

Brede relevantie API’s maakt focus lastig

Het is duidelijk uit bovenstaande dat zowel API’s als de oplossing van Noname Security veel verschillende facetten hebben. API’s raken veel onderdelen van een organisatie, wat het binnen organisaties soms lastig maakt om duidelijk te krijgen wie nu eigenlijk de product owner is van API-security. Daar loopt Noname Security ook tegenaan in de praktijk. Deels is de brede toepasbaarheid van API’s namelijk ook terug te zien in de oplossing die het bedrijf heeft ontwikkeld. “De tool stelt je in staat om zaken zoals governance goed in te richten, maar is ook onderdeel van de CI/CD-pipeline,” vat Duckaert het samen. Je kunt hem zelfs gebruiken voor awarenessdoeleinden.

Deze brede toepasbaarheid maakt het voor Noname af en toe best een uitdaging om de juiste mensen binnen organisaties aan te spreken. API-security is sowieso al iets wat nog niet voldoende op de kaart staat. Daarbij komt nog de vraag wie binnen organisaties de beste doelgroep is. De tool van Noname zal als securitytool vanzelfsprekend een plaats hebben binnen het securityteam van een organisatie. Daar zal over het algemeen ook het budget vandaan moeten komen. Een tweede owner is over het algemeen het team of de persoon die eindverantwoordelijk is voor API’s binnen organisaties.

Noname richt zich echter ook op toepassing in de CI/CD-pipeline. Het gaat dan specifiek om de rechterkant van de pipeline, dus in het feedback-gedeelte nadat de developer klaar is met het ontwikkelen van features of applicaties. De developer zelf gebruikt de tool van Noname Security dus niet en is dus niet de doelgroep van Noname Security. DevOps-teams zijn dat wel, benadrukt Duckaert. Die moeten controleren of alles klopt. En die zijn doorgaans niet op de hoogte dat een API Gateway geen security platform is en dat je voor je API-security naar een andere tool moet kijken.

Overbrugt Noname Security het gat tussen security en IT/operations?

Uiteindelijk zullen de gesprekken vanuit Noname Security toch primair met het securityteam van organisaties plaats moeten vinden. Die gaan immers over het budget en Noname Security stelt feitelijk voor om nog een extra investering in security te doen, bovenop de bestaande securitytooling. Maar API-verantwoordelijken en DevOps moeten ook overtuigd worden van het belang. Dat is niet eenvoudig, omdat die teams van origine niet nauw samenwerken met het securityteam. Het gaat hier om het overbruggen van het gat tussen security en operations. Dat is al sinds jaar en dag een probleem.

Je kunt het echter ook andersom zien. Noname Security zou ervoor kunnen zorgen dat die onderdelen binnen organisaties meer met elkaar gaan praten en samenwerken. Dat zou in ieder geval een interessante bijvangst zijn. Niets doen lijkt ons op basis van wat we over de kwetsbaarheid van API’s weten in ieder geval geen optie en geen API’s meer gebruiken al helemaal niet.

Tip: Lees ook ons artikel over de grondlegger van API-security, Salt Security. Dat doe je via deze link.