De developer kan vandaag gewoon niet winnen. Het is een voortdurend touwtrekken tussen bedrijfsdoelstellingen – de product manager die “sneller, sneller, sneller!” nieuwe features wil uitbrengen, en het beveiligingsteam, dat releases blijft tegenhouden vanwege onveilige codes- met de ontwikkelaar in het midden.
Sommige teams proberen security in de development fase te ‘plakken’, met als gevolg nog meer taken op de al te overvolle to-do-lijsten van ontwikkelaars, en zo het beste er van te hopen. Deze strategie eindigt vaak met de noodzaak om duur beveiligingspersoneel in te huren om de dag te redden en inbreuken achteraf op te ruimen.
Geen van beide partijen heeft helemaal ongelijk en geen van beide partijen heeft helemaal gelijk. Met de huidige “fail-fast, fail early” CI/CD-omgeving, is er een extreme druk om releases snel op de markt te krijgen om concurrerend te blijven. Maar slechte codeconstructie brengt ook hoge kosten met zich mee: inbreuken zijn duur en kosten tijd, geld en klanten.
Het is een high-stakes, no-win situatie voor de ontwikkelaar… en het is vermoeiend.
Het schuldspel: ligt het aan de tool of de gebruiker?
De effectiviteit van elk beveiligingshulpmiddel hangt af van zowel de architectuur als van het juiste gebruik. Een robuust beveiligingshulpmiddel is gebrekkig als het slecht wordt gebruikt, en een slecht ontworpen beveiligingshulpmiddel is kwetsbaar, zelfs als de gebruikers zich houden aan de best practices. Dat is de reden waarom beveiligingstraining (werknemers leren phishing te herkennen, wachtwoorden te beveiligen, enzovoort), in combinatie met het gebruik van gebruiksvriendelijke beveiligingstools (multi-factor/biometrische authenticatie, single-sign on en security scanners) een alledaagse combinatie zijn geworden in Enterprise Security.
De vraag is: waarom doen we niet hetzelfde voor ontwikkelaars, als er zo veel op het spel staat? Kunnen we risico’s voor de onderneming verminderen en sneller features op de markt uitbrengen door ontwikkelaars lichtgewicht beveiligingseducatie te bieden, aangevuld door gebruiksvriendelijke tools? We kunnnen een ontwikkelaar informeren en begeleiden bij het bouwen van veilige code. Maar zou het niet een betere strategie zijn om echt ‘secure by design’- software te realiseren door beveiligingsmogelijkheden met een lage instapcurve in het ontwikkelingsproces te bieden? We moeten ontwikkelaars in staat stellen om gedetailleerde beveiliging te definiëren zonder de traditionele complexiteit.
Declaratieve beveiliging
Het volgende is een voorbeeld van hoe u de beschreven benadering kunt inschakelen.
De neiging van ontwikkelaars om aanvalsvectoren te creëren is gerelateerd aan de complexiteit van de code die nodig is om access control te implementeren. Deze complexiteit maakt ruimte voor fouten, zoals slechte codeconstructie en kwetsbaarheden. CWE-248: Onjuiste toegangscontrole beschrijft deze zwakke punten.
In plaats daarvan zouden we de complexiteit naar de achtergrond kunnen duwen met een declaratieve stijl van beveiligingsimplementatie, met behulp van deployment descriptors die buiten de applicatie worden afgehandeld. Dit kan in de vorm van een bestaande module (open-source security vetted) met een robuuste architectuur en een vrij eenvoudige implementatie, zoals een access control list(ACL) die gebruik maakt van een goed gedocumenteerd beveiligingsmechanisme. De betrouwbaar en wijdverbreid gebruik van dergelijke tools gaat hand in hand, waardoor standaardisatie de sleutel tot succes is.
API’s beveiligen
Beveiliging in de developer fase raakt veel technologieën en een declaratieve beveiligingsstijl heeft het potentieel om vele technologieën in het developer facet te beïnvloeden. Één van de gebieden die onmiddellijke actie vereist, is de cloud-native architectuur. Door de wildgroei aan API’s (die lijden aan een gebrek van beveiligingsstandaardisatie) is API-beveiliging een steeds populairder onderwerp geworden.
Populaire API-frameworks, zoals FastAPI, Flask, enz., zijn gebaseerd op de OpenAPI- specificatie ,die een standaard biedt voor het beschrijven van API’s met een uitgebreide reeks functies. Maar op het gebied van beveiliging negeert het autorisatie volledig.
De OpenAPI -specificatie en de bijbehorende frameworks laten de ontwikkelaar elke vorm van autorisatie overwegen, ontwerpen en implementeren, zonder beveiligingsstandaardisatie – een riskante propositie met veel ruimte voor fouten. Echter, net als bij access control, kan declaratieve beveiliging helpen om de beveiliging te waarborgen en deze vorm van access control te standaardiseren in een geüpdate OpenAPI Specificatie.
Het 2019 Open Web Application Security Project (OWASP)rapport plaatste Broken Object Level Authorization (BOLA) en Broken User Authentication (beide directe resultaten van ontbrekende of slecht geïmplementeerde access control) als de top twee op de lijst.
Afbeelding 1. Normaal scenario vs BOLA attack
Met een declaratief beveiligingshulpmiddel kan de ontwikkelaar de regels voor access control eenvoudig definiëren, waardoor de ruimte voor fouten wordt verkleind.
Het beveiligen van API’s is een intensieve onderneming waarbij verschillende technologieën en deelnemers binnen en buiten het zichtveld van de API-provider worden aangepakt. Data van realtime API-verkeer en de afhankelijkheden ervan zouden van grote waarde zijn voor full stack observability.
Een open source tool die hierin gespecialiseerd is, is APIClarity. APIClarity voert het vastleggen en analyseren van gegevens uit, biedt direct inzicht in API-verkeer en identificeert potentiële risico’s.
Het onlangs gelanceerde product van Cisco , Panoptica , gaat een stap verder van APIClarity en biedt een diepere reeks API-beveiligingsfunctionaliteiten als SaaS-aanbod.
Om het zelf uit te proberen, zijn er drie opties:
1. Probeer Panoptica’s API-beveiliging gratis in uw eigen Kubernetes-omgeving. Deze gratis laag werkt op maximaal 15 nodes en één cluster (geen creditcard vereist ) en u kunt deze zo lang gebruiken als u wilt. Om toegang te krijgen tot deze gratis laag, gaat u naar de website en klikt u op ‘Sign up Free’ in de rechterbovenhoek.
2. Bekijk het van dichterbij met een interactieve point-and-click webdemo
3. Probeer het probleemloos in een veilige, vooraf geconfigureerde sandbox-omgeving
Authors