Artikelserie: DevOps del 2 av 3

DevOps - Plan till Test

I den här artikeln beskriver vi den första halvan av en utvecklingslivscykel (SDLC, Software Development Lifecycle) som är inspirerad av DevOps-loopens åtta delar, där vi mappar ut utvecklings- och säkerhetsaktiviteter till respektive del.

Plan 

När ni planerar er applikation är det viktigt att ni pratar om de sekretess-, riktighets- och tillgänglighetskrav (CIA) och integritetsskydds-krav som är relevanta för er vid: 

• Skapande (t.ex. indatavalidering) 

• Processande (t.ex. integritetskontroll och prestanda) 

• Lagring (t.ex. plats och åtkomstkontroller) 

• Överföring (t.ex. kryptering, kontroll av avsändare/mottagare) 

• Förstöring (t.ex. säker borttagning och fysisk destruktion) 

Gör en hotmodellering för att identifiera och hantera potentiella säkerhets- och integritetsskydds-relaterade hot i er föreslagna arkitektur/lösning. En hotmodellering kan vara så enkel som att ni i teamet ställer er följande frågor: 

• Vad är det vi jobbar med? 

• Vad kan gå fel? 

• Vad kan vi göra åt det? 

• Gjorde vi ett bra jobb? (feedback loop) 

Alternativt kan ni använda er av en metod som är anpassad för att ge värde utan att vara alltför tidskrävande som t.ex. ”Rapid Threat Model Prototyping”. Mer information om hotmodellering hittar ni på Threat Modeling Manifesto.

Jobba med att begränsa attackytan mot er applikation. Det kan handla om att inte aktivera/installera funktioner som inte kommer användas eller stänga portar som inte behöver vara öppna. 

Kom ihåg säkerhetsprinciperna “lita inte på indata”, “lägsta behörighet” och “försvar på djupet”. 

Code 

Checka inte in hemligheter (lösenord, connection-strängar, api-nycklar) som ligger i koden eller i konfigurationsfiler. Använd en lösning för att lagra hemligheter som t.ex. HashiCorp Vault, Azure Key Vault eller AWS Secrets Manager. 

Konfigurera “branch protection” för ert kod-repository så att det krävs en pull request för att kunna checka in kod. Komplettera gärna ert pull request förfarande med en lite mer formell peer review där någon annan i teamet tittar på koden ur olika perspektiv. Kanske har ni kommit överens om en peer review checklista där det finns ett antal säkerhetsaspekter ni tittar efter. Granskningen skall absolut vara lättviktig och inte kännas omfattande och tidskrävande. Om ni jobbar med parprogrammering försvinner kravet på peer review som en bonus. 

För att kunna uppnå ännu bättre kodleveransförmåga överväg att jobba med ”trunk-based development” med kortlivade brancher (en dag, max två) istället för långlivade feature/release brancher. 

Använd det inbyggda stödet för striktare kontroller i utvecklingsverktyget om det finns, t.ex. kompilera med högsta varningsnivå, betrakta varningar som fel, aktivera lintning i er IDE etc. 

Validera indata och “escapa” utdata i er applikation. Använd s.k. Allow-listor istället för Deny-listor, om det är möjligt. Mer information om indatavalidering hittar ni i OWASP Cheat Sheet series om indatavalidering.

Implementera applikationsloggning så att den kan användas av er själva vid en incident där ni behöver titta i loggarna för att kunna svara på vad som verkligen har hänt. Mer information om applikationsloggning hittar ni i OWASP Cheat Sheet series om applikationsloggning. 

Se till att det blir en vana att skapa enhetstester för alla nya funktioner/metoder ni skriver. 

Kom ihåg säkerhetsprinciperna “lita inte på indata”, “lägsta behörighet”, och “försvar på djupet” även då ni kodar. 

Build 

Använd en automatiserad CI/CD pipeline. Integrera kod ofta (dagligen om det är möjligt), arbeta inte med långlivade brancher i koden. 

Skanna koden efter gamla eller sårbara externa komponenter. Gärna med ett verktyg som är integrerat i er bygg-pipeline. 

Se till att det skapas en BoM (bill of material) som listar alla ingående externa komponenter som ni använder. (Det går nästan alltid att få ut en sådan lista från det verktyg ni använder ovan för att skanna koden). Denna lista kan vara bra om det dyker upp en sårbarhet i en komponent och ni behöver kunna svara på om ni använder just denna komponent. 

Skanna koden ni själva skriver efter farliga eller sårbara kodningsmönster med ett SAST (Static Application Security Testing) verktyg. Verktyget kan antingen integreras i er bygg-pipeline eller i utvecklarnas IDE.  

Test 

Automatisera så många testfall som möjligt. Dessa testfall tillsammans med pull request/peer review är grunden som ger er självförtroendet att våga releasa ofta och till slut helt automatiskt. 

Härled testfall från er hotmodellering för att säkerställa att era skyddande åtgärder verkligen fungerar.  

Överväg så kallad fuzz-testning av parametrar och API-er för att säkerställa att de står emot felaktig- eller slumpmässig indata. 

Genomför automatiserade tester med ett DAST (Dynamic Application Security Testing) verktyg, t.ex. genom att köra OWASP ZAP baseline scan som en del i att releasa till en testmiljö eller genom att köra ett längre test över natten.