API sikkerhet – hva er det, hvorfor nå og hvordan sikre seg.

Hva er API-sikkerhet? 

Applikasjonsprogrammeringsgrensesnitt (API) er byggesteinene i moderne applikasjoner. Tenk på dem som påkjøringsrampene til den digitale verden. De holder alle koblet til viktige data og tjenester, muliggjør alle slags kritiske forretningsoperasjoner og gjør digital transformasjon mulig. 

Antallet API’er vokser raskt. En fersk undersøkelse fra vår strategiske leverandør SALT Security, viser at 26 % av bedriftene bruker minst dobbelt så mange API’er nå som for ett år siden. 

Alle de gode tingene med API’er er også det som gjør dem til hovedmål for angripere. Og det er grunnen til at bedrifter må sikre API’ene sine. 

Open Web Application Security Project (OWASP) definerer API-sikkerhet som å fokusere på strategier og løsninger for å forstå og rederesere de unike sårbarhetene og sikkerhetsrisikoene til API’er. 

Det viktigste aspektet å forstå er at API-sikkerhet ikke er det samme som applikasjonssikkerhet. Les videre for å finne ut hvorfor.   

Hvorfor er API-sikkerhet viktig? 

API’er er en foretrukket angrepsvektor for cyberkriminelle. Og angrepsflaten fortsetter å vokse. Gjennomsnittlig antall API’er per selskap økte med 221 % på 12 måneder. 

Etter hvert som angrepsoverflaten har vokst, og etter hvert som flere dårlige aktører har innsett hvor lukrativt det er å sikte på API’er, har antallet API-angrep skutt i været. Den samme forskningsrapporten viser at 95 % av selskapene hadde en API-sikkerhetshendelse i løpet av de siste 12 månedene, API-angrepstrafikken vokste med 681 % mens den generelle API-trafikken vokste 321 %. 

Poenget er at eksisterende sikkerhetstiltak ikke fungerer for API’er. De hindrer ikke angripere i å stjele sensitive data, påvirke brukeropplevelsen eller forårsake annen skade. 

For å stoppe angrep trenger dere et forankret sikkerhetsprogram, en tydelig sikkerhetsstrategi og teknologi som er formålsbygget for API’er. 

Hvorfor er API-sikkerhet forskjellig? 

Sikkerhetsløsninger inkludert WAF (brannmurer for web-applikasjoner), API-gateway’er, API-administrasjonsverktøy og verktøy for identitets- og tilgangsadministrasjon (IAM) ble ikke utviklet for å forhindre angrep på API’er. Det er fordi sikring av API’er byr på unike utfordringer:     

• Et landskap i stadig endring: Gitt utviklingstakten er det nesten umulig å holde seg oppdatert på nye og endrede API’er. Dokumentasjon er alltid ufullstendig og ofte utdatert. 
• Lavt og sakte angrep: Tradisjonelle angrep, som SQL-injeksjoner eller skripting på tvers av nettsteder, skjer fortsatt, men de vellykkede API-angrepene følger ikke den typen «one-and-done»-mekanismer som utnytter kjente sårbarheter. Hver API er unik, så hvert angrep må være unikt, ettersom dårlige aktører undersøker API’ene for forretningslogikkhull de kan utnytte. 
• Manglene ved «shift-left» taktikk: Standard pre-prodereksjonstesting kan finne noen hull i API-sikkerhetens beste praksis, men de vil ikke avdekke sårbarheter forankret i API-forretningslogikkhull. Og ingen utviklere skriver helt sikker kode hver gang. 

Finn ut hvorfor apper er bygget på API’er, sikkerhetsrisiko-API’ene som finnes, og beste fremgangsmåter for å sikre API’er. Last ned her!

Hva er de vanlige typene angrep på API’er? 

OWASP publiserte API Security Topp 10 for å beskrive de ti vanligste API-feilene. Denne listen er et godt utgangspunkt for å forstå vanlige svakheter og sikkerhetssårbarheter i API’er. Av disse er de vanligste:  

• BOLA (Broken Object Level Authorization) 
• Ødelagt brukerautentisering 
• Overdreven dataeksponering 
• Feilkonfigurasjon av sikkerhet 

BOLA 

Autorisasjon på brutt objektnivå er den vanligste API-trusselen, og står for omtrent 40 % av alle API-angrep. Angripere kan enkelt utnytte API-endepunkter som er sårbare for BOLA ved å manipulere ID’en til et objekt sendt innenfor en API-forespørsel. Fordi serverkomponenten vanligvis ikke sporer klientens tilstand fullt ut, er disse sårbarhetene ekstremt vanlige i API-baserte applikasjoner. Automatisk statisk eller dynamisk testing kan ikke enkelt oppdage BOLA-autorisasjonsfeil. BOLA-autorisasjonsfeil kan føre til dataeksfiltrering så vel som uautorisert visning, modifikasjon eller ødeleggelse av data. BOLA kan også føre til total overtakelse (ATO). 

Tradisjonelle sikkerhetskontroller, som WAF’er og API-gateway’er, mangler evnen til å se denne typen angrep fordi de ikke har noen intelligens til å forstå API-kontekst og kan derfor ikke ta en baseline av normal API-atferd. For å forhindre BOLA-angrep må dere kunne oppdage når en autentisert bruker prøver å få uautorisert tilgang til en annen brukers data, for eksempel. For å forhindre BOLA-angrep trenger API-sikkerhetsløsninger muligheten til å analysere store mengder API-trafikk over tid. Denne tilnærmingen krever store data i skyskala slik at systemet har tilstrekkelig lagringskapasitet til å etablere en rik baseline av normal aktivitet på tvers av millioner av API-anrop og brukere, over dager, uker og til og med måneder. Først da vil systemet ha konteksten som trengs for å oppdage overgrep som BOLA-angrep.  

Ødelagt brukerautentisering. 

Ødelagt brukerautentisering lar angripere bruke stjålne autentiseringsnøkler, legitimasjonsfylling og «brute-force» angrep for å få uautorisert tilgang til applikasjoner. Angripere kan overta brukerkontoer, få uautorisert tilgang til en annen brukers data og foreta uautoriserte transaksjoner. Autentiseringsmekanismer utgjør et enkelt mål for angripere, spesielt hvis de er fullstendig eksponert eller offentlige. Tekniske faktorer som kan føre til ødelagt autentisering i API’er inkluderer blant annet svak passordkompleksitet, manglende kontosperregrenser, for lange varigheter for passord/sertifikatrotasjoner eller bruk av API-nøkler som eneste autentiseringsmateriale. 

Fordi tradisjonelle sikkerhetskontroller mangler evnen til å spore angrepstrafikk over tid, kan de ikke dechiffrere de forskjellige formene for avanserte angrep som er rettet mot autentisering, for eksempel påloggingsfylling og cracking av legitimasjon. En API-sikkerhetsløsning må kunne profilere den typiske autentiseringssekvensen for hver API-flyt for å oppdage unormal atferd, for eksempel manglende legitimasjon, manglende autentiseringsfaktorer eller autentiseringsanrop som er ute av rekkefølge. For å dempe avanserte angrep som retter seg mot autentisering, må en API-sikkerhetsløsning overvåke og analysere store mengder prodereksjons API-trafikk, som krever lagring i skyskala samt AI og ML. 

Overdreven dataeksponering. 

Når generiske API’er gir mer data enn nødvendig, kan en angriper utnytte en applikasjon ved å bruke overflødige data for å trekke ut sensitive data. API’er sender ofte mer informasjon enn nødvendig i et API-svar og lar det være opp til klientapplikasjonen å filtrere dataene og gjengi en visning for brukeren. Å stole på kode på klientsiden for å filtrere eller skjule sensitive data forårsaker problemer, ettersom angripere regelmessig omgår nettapplikasjoner på klientsiden og mobilapplikasjonskode og kaller API’er direkte. 

Tradisjonelle sikkerhetsskannings- og kjøretidsdeteksjonsverktøy vil noen ganger varsle om denne typen sårbarhet, men de klarer ikke å skille mellom legitime data returnert fra API og sensitive data som ikke skal returneres. En API-sikkerhetsløsning må kunne baseline og spore API-tilgang per endepunkt og per bruker for å identifisere overdreven forbruk av sensitive data. Dessuten må en løsning også gi API-kontekst og en rekke svarhandlinger, slik at ikke hver overføring av sensitive data skaper et varsel eller blokkert forespørsel. 

Feilkonfigurasjon av sikkerhet. 

Det finnes en lang rekke sikkerhetsfeilkonfigurasjoner som ofte påvirker API-sikkerheten som helhet negativt og kan utilsiktet introdusere sårbarheter. Sikkerhetsfeilkonfigurasjoner kan inkludere usikre standardkonfigurasjoner, ufullstendige konfigurasjoner, feilkonfigurerte HTTP-hoder, detaljerte feilmeldinger, åpen skylagring og mer. Feilkonfigurasjoner gjør det mulig for angripere å få kunnskap om applikasjonen og API-komponentene under rekognoseringsfasen. Angripere kan også utnytte feilkonfigurasjoner for å dreie angrepene sine mot API’er. 

En API-sikkerhetsløsning må kunne identifisere feilkonfigurasjoner og sikkerhetshull for en gitt API og dens serveringsinfrastruktur. Den må foreslå spesifikke utbedringstrinn som skal brukes når manipulasjonsforsøk gjøres og selve applikasjonsserveren ikke er konfigurert til å avvise forespørselen eller maskere sensitive data i svaret. Med muligheten til å analysere all API-aktivitet og etablere en basislinje for typisk API-aktivitet, kan en API-løsning hjelpe med å identifisere overflødig data og sensitive data sendt i feilmeldinger. 

Men ikke begrens bekymringen for API-sikkerhet til topp 10. Angripere bruker også andre teknikker. De låner teknikker fra applikasjons- eller nettverksangrep. De kombinerer forskjellige utnyttelser for et angrep. De vil også automatisere angrep for å øke sjansen for suksess. 

De mest vellykkede API-angrepene retter seg mot hull i forretningslogikken. For eksempel, i Experian-hendelsen gjorde hackeren mye prøving og feiling og bestemte til slutt at hvis han brukte alle nuller for fødselsdato-felt, kunne han trekke tilbake kredittscore til enhver amerikaner. Utviklerne som skrev API’ene hadde aldri vurdert den typen manipulasjon og krevde ikke at feltene faktisk samsvarte med en gyldig kalenderdato – de krever bare tall. 

Hvilke beste praksiser for sikkerhet kan vi bruke for å rederesere risikoen vår? 

API’er er utfordrende å beskytte. Tradisjonelle løsninger kan ikke håndtere kompleksiteten til API-økosystemet. Angripere vet dette, og det er derfor de fokuserer på API’er.   

Følgende beste fremgangsmåter kan hjelpe deg med å forbedre API-sikkerhetsstillingen din: 

Utvikling og testing: 

1. Fremme sikker API-design og utvikling: Lag sikker koding og konfigurasjonspraksis for å bygge og integrere API’er. OWASP Application Security Verification Standard (ASVS) er en god ressurs. 

2. Redereser eksponering av sensitive data: Unngå å sende for mye data til klientapper og deretter stole på at de filtrerer dataene. 

3. Gjennomfør designvurderinger: Sørg for å inkludere forretningslogikk i designvurderinger. 

4. Dokumenter API’ene deres: Dokumentasjon hjelper folk å forstå hvordan et API er bygget eller integrert. Dere trenger spesielt dokumentasjon for designgjennomganger, sikkerhetstesting og beskyttelse. 

5. Bruk et maskinformat for dokumentasjon: Bruk maskinformater som OpenAPI Specification (OAS). Deretter kan dere bruke spesifikasjonene for grunnleggende testing og beskyttelse. 

6. Oppretthold en nøyaktig API -beholdning: Gi sikkerhetsteamene deres et realistisk syn på angrepsoverflaten med en oppdatert beholdning. Den beste måten å fange opp denne informasjonen på er med automatisert API-oppdagelse som dekker REST, GraphQL og andre API-formater. 

7. Utfør sikkerhetstesting: Bruk sikkerhetstestingsverktøy for å identifisere konfigurasjonsproblemer eller sårbarheter i API’ene deres. Skannere er ikke gode til å analysere forretningslogikk, så dere bør analysere API’ene deres og utføre fuzz-testing i løpet av kjøretiden for å identifisere utnyttbar kode.   

Prodereksjon: 

1. Slå på logging og overvåking: Telemetridata hjelper deg med å oppdage angrep, svare på hendelser og beskytte API’er under kjøring. Bruk dataene som utgangspunkt for normal oppførsel. På den måten kan eventuelle avvikende hendelser raskt identifiseres og løses. 

2. Formidle API’ene deres: Bruk medieringsverktøy som API-porter for å forbedre synlighet og sikkerhet. Utvid mulighetene til disse plattformene med en API-sikkerhetsløsning som gir en dypere kontekst om API’er. 

3. Identifiser API-drift: Sørg for at dere har en plan for å finne ut når en API har endret seg. Igjen, automatiserte plattformer som kan sammenligne dokumentasjon med kjøretidsatferden til API’ene deres, vil hjelpe med å identifisere disse hullene. Oppdater deretter dokumentasjonen i henhold til dette.   

4. Bruk de riktige nettverkssikkerhetskontrollene: Noen nettverkskontroller kan hjelpe med API-sikkerhet. Krypter for eksempel data-API’ene som sender. Dere kan også bruke dynamisk hastighetsbegrensning og IP-adresse tillat og avslå lister (forutsatt at antallet API-brukere er lite).   

5. Kontinuerlig autentiser og autoriser: Gjør tilgangskontroller og identitetslagre eksterne. Inkluder API-gateway’er, identitetsbutikker, IAM, nøkkeladministrasjon, offentlig nøkkelinfrastruktur og hemmelighetsbehandling i dette trinnet. Unngå å bruke API-nøkler for autentisering.   

6. Implementer kjøretidsbeskyttelse: Sørg for at kjøretidsbeskyttelsen din kan identifisere konfigurasjonsproblemer i API-infrastruktur. Den skal også oppdage atferds avvik som påloggingsfylling, brute forcering eller skrapingsforsøk. 

Hvem er ansvarlig for API-sikkerhet? 

Det korte svaret er at API-sikkerhet er alles problem. Men å gjøre det til alles problem betyr ofte at ingen er ansvarlig for å fikse det. 

Det er derfor det anbefales å tilordne ansvaret for API sikkerhet hos en eksisterende rolle i organisasjonen deres. Dere kan for eksempel starte med applikasjonssikkerhetsteamet deres, dersom dere har dette. De kan ofte fungere som sikkerhetsmestere i DevOps-teamene deres, og utviklere kan på sin side lære sikkerhetsteamene deres om API-konstruksjoner. 

Deres API-sikkerhetsekspertise vil sannsynligvis være spredt over hele organisasjonen. Dere kan trolig finne kunnskapsrike mennesker innen utvikling, og andre innen infrastruktur, drift eller sikkerhet. Eller dere kan oppleve at eksperter er konsentrert i API-proderektteam. Dersom dere ikke har slike funksjoner i dag, så kan NetNordic bistå med kompetanse inn til dere enten på permanent basis (as-a-Service) eller i en transisjonsfase. 

På tvers av alle disse roller og bidragsytere er det viktig å drive tverrfunksjons-samarbeid på tvers av alle gruppene for å sikre at oppdagelse, testing, beskyttelse og hendelsesrespons tas opp i API-sikkerhetsstrategien deres. 

Hvordan kan vi beskytte API’ene våre?   

Den beste beskyttelsen for API’er er en dedikert plattform bygget fra grunnen av for API-sikkerhet. Riktig API-sikkerhetsplattform bør automatisk: 

• Oppdag nye og endrede API’er 
• Oppdag og stopp angrep på API’er 

• Eliminer sårbarheter i byggefasen 

Se etter API-sikkerhet som kan samle, lagre og analysere hundrevis av attributter på tvers av millioner av brukere og API-kall, og enda viktigere, utnytte AI og ML for å korrelere dem over tid. Først når automasjonen kommer på plass vil sikkerheten kunne økes! Å få denne bredden av kontekst vil kreve store data i skyskala – server- eller VM baserte tilnærminger vil ganske enkelt ikke ha et bredt nok datasett over tid til å identifisere dagens sofistikerte API-angrep. Bare med denne dybden av kontekst vil dere ha det dere trenger for å beskytte alle API’ene deres – også de dere ikke visste at dere hadde. 

Book et uforpliktende møte i dag!