This is the multi-page printable view of this section. Click here to print.
Når løsningen er designet og koden er skrevet er det "bare" å deploye, så er vi i mål, eller hva? Vi bruker ofte CICD-løsninger for å bygge og deploye, samt kjøre tester og mye annet. Dersom noen kan kompromittere pipelines, byggagenten som bygger løsningen eller forbindelsen mot ressursene vi deployer til vil vi ha store problemer.
Selv om det er vanskelig å dekke alt i noen få korte artikler, forsøker vi likevel å gi et innblikk i problemstillinger en bør ta opp i leveranseteamet.
Når vi setter opp kjøremiljøer er det viktig å også tenke på hvordan løsningen vi utvikler kan bygges og deployes til disse på en måte som både gjør det enkelt og fjerner behovet for at en person skal måtte bruke tid og energi på å gjøre det samme hver gang.
Continuous Integration og Continuous Delivery, ofte forkortet CI/CD er vanlige tilnærminger for hvordan software bygges og deployes til kjøremiljø, ofte ved hjelp av skript i form av pipelines eller actions. Navn og begreper her avhenger av hvilke verktøy en bruker, men prinsippet er mye det samme.
En slik pipeline kan gjøre mye mer enn bare å bygge, den kan også utføre andre oppgaver som å kjøre automatisert testing, sårbarhetsskanning, skanning av hemmeligheter og mye annet. Uavhengig av hva en bruker den til, er det viktig å være klar over risikoelementene assosiert med CI/CD.
Den store fordelen med CI/CD er automatikken bygd inn i løsningen. Hver gang du kjører igang en pipeline arkiveres kjøringen og alle artifakter og kobles mot versjonskontrollsystemet slik at du kan gå tilbake og se hvilken comitt som ble brukt. Kjøring av CI/CD bør i utgangspunktet være ufarlig gitt at en har kontroll på, og beskytter branchen som brukes som basis for deployment til produksjonsmiljøet.
Bygging er ofte det første steget i prosessen, og gjøres typisk bare en gang per release. Byggmiljøene brukt i en CI/CD prosess, ofte kalt byggagenter kommer ofte i to former:
Med agenter styrt av skyleverandøren brukes standardimages ferdig konfigurert for denne oppgaven. De deployes når du starter en byggeprosess, og inneholder alt av verktøy som trengs for byggingen. Når de er ferdig deployet sjekker de ut kildekoden din, bygger den, lagrer artifakten i et egnet system før instansen stanses og slettes.
Selvstyrte agenter er mer komplekse da du har ansvar for alt av vedlikehold og konfigurasjon selv. Til gjengjeld har du da dedikerte agenter som kun brukes av teamene eller prosjektene som gis tilgang til disse.
Selv om det første alternativet somoftest er godt nok, er det viktig å være klar over mulighetene som finnes, og når en bør vurdere disse. Uansett løsning er det viktig å tenke på at byggmiljøet er et veldig sårbart punkt; dersom dette kompromitteres kan en angriper potensielt utføre endringer som påvirker alt som bygges der.
Dette er spesielt viktig med bruk av tredjepartspakker, og et minimum her bør være at pakker pinnes til spesifikke versjoner og at en aldri henter siste versjon av en pakke automatisk.
Når vi setter opp kjøremiljøer er det viktig å også tenke på hvordan løsningen vi utvikler kan bygges og deployes til disse på en måte som både gjør det enkelt og fjerner behovet for at en person skal måtte bruke tid og energi på å gjøre det samme hver gang.
Når en deployerer en applikasjon tar man utgangspunkt i artifakten som ble bygget, som så lastes opp til ønsket kjøremiljø. For å sikre konsistens er det vanlig å bare bygge en gang, slik at man deployer det samme artifaktet flere steder - dersom miljøene er like og artifaktet er det samme, skal vi se det samme overalt.
Det er vanlig å ha flere steg i pipelinen som håndterer deployment til ulike miljø, slik at en kun deployer til neste miljø dersom steget før var vellykket. Ved behov kan en også restarte et steg i pipelinen dersom det oppstår uventede feil for å utelukke at det var selve deploymenten som resulterte i dette.
I en deployment pipeline er det viktig å ha et forhold til når det er greit å deploye. Å kjøre en deployment skal ikke være farlig, da hele prosessen er automatisert. Men i mange tilfeller vil en unngå å rulle ut endringer eller ny funksjonalitet i enkelte miljø før dette er klarert med produkteier. For å unngå at noen ved et uhell deployer til feil miljø bør en ha noen godkjenningstrinn underveis, der en eksempelvis setter som krav at andre i teamet skal godkjenne en deployment før den får starte.
Sikkerhetstesting og pentesting har mange fellestrekk, men der tilnærminger som DAST primært fokuserer på webapplikasjoner og mer automatiserte tester, vil en pentest være mer omfattende og typisk også inkludere underliggende infrastruktur og nettverk. I noen tilfeller vil den også kunne ha et fysisk element der pentesterne vil forsøke å komme seg inn i lokalene for å avdekke svakheter ved fysisk sikring eller rutiner.
En penetrasjonstest vil alltid ha et avtalt omfang som regulerer hva pentesterne kan gjøre, når de kan gjøre det og hvilke ressurser og tjenester de kan teste.
Det er ikke mulig å bevise at en løsning er sikker, kun at den ikke er sårbar mot gitte angrep. Dersom en leverer en løsning som har strenge krav til sikkerhet eller opererer innenfor et avtaleverk som tilsier det vil en pentest være et nyttig verktøy for å skape visshet i at en løsning og miljøet rundt er sikker.
Etter at testingen er gjennomført vil det normalt overleveres en rapport som beskriver hva som er testet og hvordan, samt en gjennomgang og vurdering av alle funn som er gjort. I noen tilfeller vil funn kunne beskrives som sårbarheter, men uten at disse nødvendigvis må rettes opp i på grunn av andre mitigerende tiltak eller fordi risiko eller konsekvens er lav.
Først og fremst trenger man en eller flere pentestere. Dette er ikke noe man gjør på egenhånd etter å ha sett noen videoer på Youtube! En pentest krever kompetanse på flere områder da noen angrep avhenger av å utnytte flere sårbarheter som hver for seg ikke er spesielt alvorlige.
Som utviklerteam må man sikre at miljøet som skal testet er skikkelig identifisert, slik at alle forstår hvor testingen finner sted. Omfanget av testen må defineres - husk på at det må være mulig å skille et faktisk angrep fra en pentest dersom begge skjer samtidig: Dersom du ser tegn på angrep mot et miljø som ikke er en del av testen og du har segregert miljøene dine bør du ta grep!
Som en del av planleggingen er det viktig å sjekke opp med kunden hvilke rutiner de har for pentesting. I mange tilfeller vil de ha et sikkerhetssenter (Security Operations Center, SOC) og/eller et nettverkssenter (Network Operations Center, NOC) som overvåker infrastrukturen kontinuerlig, disse må være en del av planleggingen for å unngå misforståelser eller problemer når testen begynner.
I noen tilfeller er det ønskelig med en pentest uten at dette varsles, da en ønsker å se om en slik test fanges opp - Husk på at en pentest i praksis er et angrep.
I en perfekt verden bør man gjennomføre en pentester ved alle større endringer, men dette er ikke aktuelt med unntak av hos noen få aktører med særskilte krav. Her vil hver enkelt kunde ha ulike krav og forventninger, så det er viktig å ha retningslinjer på dette før en ser for seg å gjennomføre testen.
Dersom testen er varslet i forkant er det en kjempegod anledning til å følge med på logger og annen monitorering for å se om du ser noe unormalt. Dersom du i etterkant kan korrelere denne informasjonen med testene som blir rapportert har du en god mulighet til å lage automatiske varslingsrutiner som fanger opp avvik fra normalen.
Når teamet får overlevert rapporten i etterkant av en gjennomført test er det viktig å gå gjennom denne med produkteier. Husk alltid på at sikkerhet aldri er enkeltpersoners ansvar - Det er leveranseleders ansvar å sørge for at sikkerhetstiltak implementeres, men det er teamets kollektive ansvar å sikre at det man bygger er i henhold til kravene som settes.
Identifiserte funn må klassifiseres og legges i backloggen. Deretter må man vurdere funnene opp mot viktigheten av å rette dem opp; noen funn kan vente, andre må tas så raskt som mulig. Dette vil variere fra leveranse til leveranse og funn til funn.
Du skal aldri gjennomføre en pentest selv med mindre du vet _veldig_ godt hva du gjør. Det er ikke tillatt å kjøre verktøy som brukes ifm pentesting på Bouvetmaskiner eller i Bouvets nettverk uten at dette er klarert med Intern IT & Sikkerhet i forkant.