Mit blogindlæg kommer denne gang til at handle om API (Application Programming Interface)-sikkerhed. Et emne som falder lidt uden for vores normale sfære i forbindelse med infrastruktursikkerhed. Den transformation vi ser i øjeblikket – fra en klassisk applikationsmodel mod en moderne måde at bygge applikationer på, baseret på mikroservice og cloud services – betyder, vi er nødt til at udvide vores sikkerhedsværtøjer til at inkludere API-sikkerhed. Noget kan gøres med værktøjer, noget skal ske organisatorisk – forklaring følger.
Applikationernes transformation:
API’er og API-kald er nøglekomponenter i moderne applikationer. Størstedelen af IT-projekter er i dag drevet af forretningskrav. Det betyder, vi møder projekter som digital transformation, cloud-migrering, mobilitet og applikationsudvikling. Løsningerne bag denne type projekter benytter meget ofte API’er.
Så vi bruger flere API’er end nogensinde før, API’erne er alle meget kapable, og de eksponerer mere data end nogensinde før.
API’er er den mest hypede angrebsflade
I 2017 forudsagde Gartner, at API’er ville være den mest hyppige angrebsflade ved udgangen af 2022. Den forudsigelse måtte de redefinere allerede i 2021, forstået på den måde, at forudsigelsen blev til virkelighed i 2021. Oftere og oftere ser vi overskrifter i nyhederne, hvor API-sårbarheder er blevet udnyttet eller data er blevet lækket. Et resultat af hyppigere hændelser kombineret med at mange virksomheder er bagud i forhold til at sikre deres API’er.
Udnyttelse af API-sårbarheder har typisk tre forskellige indvirkninger.
- Dataeksfiltrering, uautoriseret dataoverførelser eller datatyveri
- Account Takeover, uautoriseret ejerskab af brugerkonti
- Serviceafbrydelser og/eller datamanipulation
Dataeksfiltrering er selvfølgelig problematisk for enhver virksomhed eller organisation. Som produktionsvirksomhed er det en katastrofe, hvis fabrikshemmeligheder bliver lækket, og som offentlig organisation er fx et læk af persondata et anseeligt problem. Serviceafbrydelser er ligeledes en fælles problemstilling, uanset om man er virksomhed eller organisation. Konsekvenserne er mange, og de spænder fra økonomiske til livstruende.
Hvis man driver forretning som E-handelsvirksomhed er Account Takeover en problemstilling, som kan få store konsekvenser. Mange konti har typisk et kreditkort tilknyttet, og selvom man som cyberkriminel måske ikke har direkte adgang til kortinformationer, kan man stadig lave indkøb på via brugerens konto, hvis den er blevet kompromitteret.
Som sundhedsorganisation er man sikkert bekymret for datamanipulation – forestillingen om, at en cyberkriminel kan ændre testresultater for flere hundrede patienter, kan man næsten ikke tænke til ende. Eksemplerne, jeg har taget med her, er selvfølgelig blot nogle få blandt mange.
Heldigvis har IT-sikkerhedsproducenterne fået øjnene op for temaet, men det har forskellige Communities som for eksempel OWASP også – Open Web Application Security Project – som er et online-fællesskab, der producerer frit tilgængelige artikler, metoder, dokumentation, værktøjer og teknologier inden for webapplikationssikkerhed. OWASP udarbejder og vedligeholder en top-10-liste over de mest relevante sikkerhedstrusler. Listen giver en vis fælles konsensus vedrørende API-sikkerhed, hvorfor de fleste sikkerhedsproducenter ofte refererer til OWASP10, når de positionerer deres løsninger. Og eftersom listen er drevet af et fællesskab, hvor der er mange inputsgivere, giver den god mening at skele til, når man skal prioritere sin sikkerhedsindsats. Jeg har angivet den seneste OWASP10 liste nedenfor.
Selv om API-sikkerhed kun omfatter en mindre del af det samlede sikkerhedslandsskab, er området stadig omfattende og komplekst. Men findes der ikke en masse tools derude, som kan hjælpe? Fristes man til at spørge.
Hvilke værktøjer kan man bruge til at øge API sikkerhed?
Der findes selvfølgelig en række tools, men nye udfordringer kræver nye metoder, og metoderne er både værktøjer og nye tilgange til sikkerhed. Moderne applikationer (container-baserede) bygges og køres efter tre principper Build, Deploy og Run(time). API-sikkerhed bør bygges ind i alle tre stadier.
Med fokus på en ”shift-left” tilgang, stiller man krav allerede i Build-fase, altså hvor koden bygges. Udviklerne skal have fokus på sikkerhed, bygge med sikker autentifikation og en så lille angrebsflade som mulig. Koden skal selvfølgelig testes inden den rulles ud. Det er givetvis også nemmere og billigere at rette fejl i Build-fasen end i Run-fase.
Visibilitet og netværkssikkerhed er vigtigt i Deploy-fasen. Netværket fungerer som det første forsvar for at forhindre cyberkriminelle i at nå workloads. Samtidig kan netværkssikkerhed beskytte data mod at blive eksponeret. Netværket kan også forsinke angreb i at sprede sig internt øst-vest ved en korrekt implementeret mikrosegmenteringsteknologi. Læs mere om Mikrosegmentering her.
På samme måde bør virksomheder og organisationer højne deres Runtime-containersikkerhed ved at sikre, at unormal adfærd på netværket bliver opdaget. Det kræver naturligvis, man kikker dybere i datatrafikken – typisk vil man undersøge trafikken i API gateways, load balancers eller lignende enheder. Kombineret med ML/AI og tilsvarende typer af teknologier, vil man kunne opdage unormal adfærd, og på denne måde detektere mere sofistikerede angreb.
Som nævnt kan tools ikke stå alene. Sikkerhed skal bygges ind tidligt i processen (Build). Organisationen bør desuden bygges op til at kunne reagere på de hændelser (Detect & Response), som måtte opstå i Deploy og Runtime.
De rette værktøjer er selvfølgelig også afgørende for at højne API-sikkerheden. Jeg har for overblikkets skyld samlet nogle generiske eksempler på tools – proative og reaktive – i nedenstående tabel.
Leverandører der arbejder med API-sikkerhed
Conscia repræsenterer tre leverandører, som alle har deres bud på API-sikkerhed.
Cisco købte Portshift i 2020 og har efterfølgende rebranded Portshift som Panoptica. Cisco-Panoptica højner API-sikkerheden fra Build til Runtime. Panoptica har en fælles brugerflade til container-, serverless-, API-, servicemesh- og Kubernetes-sikkerhed og integrerer med kendte CI/CD-værktøjer på tværs af flere clouds.
Palo Alto Prisma Cloud er en paraply af omfattende sikkerhedsprodukter med fokus på Cloud-sikkerhed. Prisma Cloud har ligeledes en fælles brugerflade. Den del af porteføljen som dækker API-sikkerhed er blandt andet IaaC kodeskanning, Web Application og API-sikkerhed (WAAS).
VMware købte AVI Networks i 2019. AVI er en softwarebaseret load balancer, som VMware har integreret i NSX. Som stand-alone sikkerhedsprodukt har AVI også et play. AVI’s Web og API-beskyttelse (WAAP) kan beskytte applikationerne i Runtime.
Conscia rådgiver om API-sikkerhed på tværs af leverandører
Conscia er Cisco, Palo Alto og VMware Partner. Vores sikkerhedskonsulenter har gennemgået uddannelse og har stor erfaring med producenternes sikkerhedsløsninger. Vi har naturligvis også en række reference-kunder, som styrker vores value-add, når vi vejleder vores kunder i forhold til sikkerhed. Skulle denne artikel have affødt spørgsmål vedrørende sikkerhedsløsninger, er du velkommen til at kontakte os.
Henrik Møll
CTO
Kilder:
owasp.org/www-project-top-ten/
paloaltonetworks.com/prisma/cloud
avinetworks.com/web-application-security/