5 Verktøy for Sikkerhet i DevOps

Nylig ga jeg en presentasjon på NDC Oslo om sikkerhet i utvikling, og fikk flere spørsmål om hvilke verktøy som kan hjelpe. Spesielt i organisasjoner hvor en vil utvikle fort og levere verdi på hyppig basis kan det være stort fokus på automatisering. Stegene fra oppdatering av kildekode til levering av ny funksjonalitet ute i drift skal helst automatiseres gjennom “continuous delivery pipelines”. Da kan ikke utvikling stoppe opp for en manuell- eller tidkrevende sikkerhetsgjennomgang.

Heldigvis finnes det diverse verktøy som kan synliggjøre potensielle svakheter og kvalitetsproblemer tidlig. Men hvilke skal en velge, og hva betyr alle disse begrepene?

I denne artikkelen vil jeg forklare litt hva de forskjellige typer verktøy gjør, og hvilken nytte de gir deg. Noen av verktøyene passer bedre til forskjellige rammeverk og miljøer enn andre, og vi kan slå fast at det ikke finnes ett verktøy som vil løse alle oppgaver.

Verktøy 1: Statisk analyse (SAST)

“Static Analysis Security Testing” er en betegnelse for verktøy som automatisk analyserer kildekode for å finne potensielle sikkerhets- og kvalitetsproblemer. Disse verktøyene er flinke til å finne “bugs”, som når programmet benytter verdier mottatt fra en bruker uten først å sjekke om verdiene er gyldige. 

Noen SAST verktøy er flinke til å gå dypt og finne skikkelig komplekse svakheter som ikke hadde vært lett å oppdage manuelt, mens andre verktøy kjører mye fortere og er flinke til å oppdage enkelte typer svakheter. Noen verktøy er flinke til å analysere Java, mens andre er bedre på .NET, JavaScript eller noe annet. En del SAST verktøy rapporterer gjerne svakheter de tror kanskje eksisterer (“false positives”), mens andre prøver å ikke si noe med mindre de er veldig sikre at de har funnet noe, som kan bety at de ikke rapporterer noe som er et faktisk problem (“false negatives”). 

Her må en gjerne prøve seg frem til et verktøy som fungerer bra for dere, spesielt med tanke på fart, teknologier som støttes, hvor den skal sitte i “continuous delivery”, og hvor mye tid en vil bruke på å konfigurere den.

Verktøy 2: Analyse av tredjepartskomponenter (SCA)

“Software Composition Analysis” verktøy bryr seg ikke så mye om din egen kildekode, men har fokus på andre komponenter som brukes i løsningen din. I dag er det ganske vanlig å bruke en god del bibliotek eller byggeklosser fra andre utviklere, f.eks. Spring Boot i Java utvikling, diverse NuGet pakker i .NET utvikling, og et svimlende antall NPM pakker i JavaScript utvikling. 

Hvem opprettholder disse pakkene, og hvor sikker er du på at de ikke inneholder svakheter? SCA verktøy prøver å gi deg innsyn i hvilke eksterne komponenter du bruker, hvorvidt de er utdaterte og om de inneholder noen kjente svakheter. I stedet for å gå gjennom all kildekode til ulike komponenter, bruker heller verktøyene store databaser med kunnskap om hvilke versjoner av hvilke pakker som inneholder svakheter.

Det finnes diverse kommersielle SCA løsninger, samt en ganske god “open-source” løsning som heter OWASP Dependency Check. Akkurat som med SAST, er det enkelte løsninger som fungerer bedre med f.eks. Java enn JavaScript, og nøyaktighet og fart kan variere. De fleste verktøyene kan påpeke hvilke tredjeparts komponenter du har eksplisitt importert i løsningen din, men få løsninger kan finne steder hvor en utvikler har simpelthen kopiert inn noen linjer fra et open-source bibliotek eller fra et online-forum. Det er også viktig å huske at verktøyene rapporterer når de finner en komponent med en kjent svakhet, men så langt er det ingen av verktøyene som kan bekrefte at svakheten kan utnyttes i akkurat den løsningen du utvikler. Noen av verktøyene kan også påpeke når du bruker et bibliotek som har problematiske lisensregler, som igjen kan være veldig nyttig for å unngå juridiske tvister.

Verktøy 3: Dynamisk analyse (DAST)

“Dynamic Application Security Testing” betegner som oftest verktøy som kan teste web-baserte løsninger i et “aktivt” testmiljø. Tenk deg en bruker som ikke vet hvordan applikasjonen fungerer, men sender inn masse input hvor formålet er å se om applikasjonen feiltolker verdiene og eksponerer en svakhet. Et DAST verktøy er akkurat dette.

En del DAST verktøy ble utviklet over en årrekke med tanke på enterprise-miljøet. De kunne gå dypt og bruke flere timer på å teste alle mulige input-verdier. Skal en bruke et DAST verktøy som en del av “continuous delivery” ønsker man at verktøyet ikke bruker så mye tid, et krav nyere løsninger prøver å adressere.

DAST er flink til å finne lignende “bugs” som SAST og kan oppdage svakheter som eksisterer i tredjeparts komponenter. Men DAST er ganske “blind”, verktøyet har ikke tilgang til kildekoden og kan bare tolke svarene den får fra applikasjonen når den sender inn test-input. En kan lett ende opp med “false positives” og “false negatives” på grunn av dette.

Verktøy 4: Interaktiv analyse (IAST)

“Interactive Application Security Testing” er et nyere konsept enn de første tre. Her prøves det  først og fremst å løse problematikken rundt “blindheten” til DAST verktøy. IAST verktøy bruker “sensorer” som overvåker de forskjellige komponentene av applikasjonen for å oppdage svakheter. Mens noe mater input i applikasjonen (f.eks. et DAST verktøy eller funksjonelt testverktøy), prøver IAST sensorene å plukke opp når applikasjonen responderer på en måte som kan utnyttes. Sensorene kan da aktivt prøve å endre input-verdiene mens applikasjonen kjører for å bekrefte om det faktisk finnes en svakhet. Idéen er da å redusere “false positives” og samtidig finne svakheter parallelt mens en kjører andre tester, og dermed sparer tid.

Det finnes bare et fåtall IAST verktøy på markedet foreløpig, og de som finnes er ganske avhengige av rammeverket og teknologien applikasjonen din er bygget på. Likevel er det et spennende område å følge innenfor automatisering av sikkerhet.

Verktøy 5: Kultur

OK, dette er strengt tatt ikke et verktøy men det er utrolig viktig! Faktisk er dette mye viktigere enn de fire andre!

For at en skal lykkes med sikkerhet i utvikling, er det viktig at de som er ansvarlig for utvikling forstår seg på sikkerhet. Ikke minst at de setter høy prioritet på kompetanseheving og risikoreduksjon. Minst like viktig er det at de som er ansvarlig for sikkerhet forstår seg på utvikling, og prioriterer verdiskapning og reduksjon av friksjon høyt.

Her kan tverrfaglige team være en stor fordel, med utviklere, arkitekter, designere og andre som sammen skal levere løsninger på kontinuerlig basis. Et slikt team kan få mye nytte av å inkludere noen med kompetanse innen sikkerhet som en slags “security champion”. Noen som forstår sikkerhet, og samtidig har eierskap til løsningen vil kunne gi gode råd til teamet. De vil kunne fasilitere trusselmodellering og andre sikkerhetsaktiviteter, og de vil kunne være hovedansvarlig for at sikkerhetsverktøy blir integrert og gir verdi til resten av teamet. 

Praksis som f.eks. “Test Driven Development” kan også hjelpe med å bake inn sikkerhet i utvikling. Når en definerer funksjonelle tester, for å beskrive de funksjonelle kravene, kan en også definere tester som beskriver sikkerhetskravene. For eksempel: om en input-verdi alltid skal være et positivt heltall, skriver en gjerne en funksjonell test med et positivt heltall. En tilsvarende sikkerhetstest vil gjerne inkludere diverse ugyldige input-verdier, som f.eks. “-1,5”, “ikketall”, “null”, “‘; DROP TABLE customers;–”, osv. for å se om applikasjonen aksepterer ugyldige verdier eller ei.

Slike endringer, i praksis og kultur, skjer ikke over natten. Dette er noe som må bearbeides over tid, for selv om det virker vanskelig er det også noe av det viktigste. Verktøy som SAST, SCA, DAST og IAST kan belyse sikkerhetssvakheter, men de kan ikke fikse problemene for deg. De kan heller ikke forebygge og sørge for at det ikke dukker opp problemer. Det er folkene, teamet og kulturen som først og fremst krever støtte og tillit!