I det här inlägget tar vi upp några av de vanligaste frågorna vi får om IT-säkerhet. Vi går igenom allt från vikten av att integrera säkerhetsåtgärder redan under kravhanteringen till hur man håller sig uppdaterad om de senaste säkerhetstrenderna. Vi kommer också att undersöka den avgörande roll som säkerheten spelar i utvecklingsprocessen och ge tips på hur man säkrar äldre system och inför kontinuerliga interna kontroller.
OWASP Top 10 är utmärkt att följa – det är en lista över de vanligaste sårbarheterna i webbapplikationer. OWASP står för Open Web Application Security och är en organisation som arbetar med säkerhet i programvaruapplikationer.
För några år sedan publicerades OWASP ASVS (Application Security Verification Standard), ett utmärkt kompendium att ta del av för att upptäcka säkerhetsproblem i kravhanteringen. Det kan användas som en kravspecifikation för applikationer. ASVS fungerar som en checklista på tre olika nivåer. Börja med nivå ett och jämför med vad ni redan har på plats och vad som behöver implementeras, och fortsätt sedan till nästa nivå. Alla applikationer måste klara nivå ett. Om ni vill lägga till säkerhetsaspekter i era krav skulle jag börja med detta. Ett tips är att börja i liten skala och öka gradvis; många företag begår misstaget att införa för många åtgärder på en gång, vilket organisationen i slutändan inte klarar av.
Vi följer många säkerhetsexperter på Twitter, där vi får bra uppdateringar om något har hänt eller om ett nytt verktyg har släppts. Vi följer också bloggar om säkerhet, till exempel Daniel Miessler, Podcast och Darknet Diaries. Utöver det letar vi efter verktyg, kodsnuttar eller skript som folk har släppt eller håller på att släppa, och undersöker vad de försöker åstadkomma.
När det gäller sårbarheter sitter vi inte varje dag och håller koll på om en ny sårbarhet har offentliggjorts för en specifik produkt. Det är först när vi har uppdrag som omfattar en applikation med en viss typ av applikationsstack som vi tittar på vilka sårbarheter som finns just nu. Annars är LinkedIn en bra källa för att hålla sig uppdaterad om nya sårbarheter som offentliggörs.
Före covid anordnades stora säkerhetsevenemang i Las Vegas varje sommar: Black Hat, Def Con och BSides. Ett utmärkt ställe att nätverka och lyssna på intressanta föreläsningar.
Om vi betraktar det ur ett penetrationstestperspektiv och utifrån våra uppdrag har vi märkt att säkerhetsaspekten kommer in i utvecklingsprojekten extremt sent. Ofta så sent som när produkten är på väg att släppas i produktion, eftersom företaget inser att de behöver genomföra en säkerhetstest. Och i värsta fall hittar vi massor av sårbarheter som måste åtgärdas. Vilket leder till förseningar i projektet och ökade kostnader.
Vi skulle vilja se att företag arbetar med säkerhet tidigare i utvecklingsfasen. Man talar oftast om ”Shift Left Testing” när det gäller säkerhet, det vill säga att vi inte tillämpar säkerhet som en tilläggsfunktion i slutet, utan istället inkluderar den från början. Säkerhet bör ingå i kraven.
Genom att bygga in säkerhet runt systemet, till exempel med kompenserande kontroller överallt med lager 7-brandväggar, djup paketinspektion och genom att granska applikationslagret. Överväg också om ni bör ha ett intrångsdetekteringssystem (IDS) och/eller ett intrångsförebyggande system (IPS). Det här är några alternativ för att säkra era något äldre system.
Arbeta med de 20 CIS-kontrollerna. Vilka kontroller finns på plats i företaget idag?
När vi talar om kontroller handlar det om allt från:
– Har ni ett antivirusprogram?
– Håller ni reda på företagets tillgångar?
– Har ni en översikt över era applikationer i företaget?
– Genomför ni regelbundna penetrationstester?
– Har du kunskap om administratörsbehörigheter?
– Använder ni en säker e-postlösning?
Det är ganska omfattande, men mycket bra att följa om du vill börja få kontroll, struktur och något att följa upp. Som med allt annat ska du inte ta itu med allt på en gång, utan börja i liten skala och ta dig tid. Säkerhet är inte något man fixar på en månad, det är en lång process. Stora företag arbetar och kämpar kontinuerligt med CIS-kontrollerna; det är en stor uppgift att implementera dem om man vill uppfylla alla 20.
Om man separerar infrastrukturen från applikationen och börjar med applikationsdelen ser vi ingen större skillnad i tillvägagångssättet eller vad den bör kunna hantera. Infrastrukturen däremot, såsom nyckelhantering och hemliga uppgifter, skiljer sig från hur det fungerar när man hanterar det lokalt i ett datacenter. Molnet erbjuder direkt en hel del säkerhetsfunktioner som du kanske inte har i ditt eget datacenter, till exempel spårbarhet av åtkomst. Men för att det ska fungera som avsett är det nödvändigt att konfigurera det – och att göra det korrekt. Molnet är inte säkert som standard, och det är användaren som måste konfigurera och aktivera dessa funktioner innan det går live på internet.
Ja, OWASP ASVS
Ja, med ”Shift Left”-metoden. Börja med säkerheten redan i början av utvecklingsprocessen och testa produkten tidigt. Andra sätt att verifiera att du har en säker produkt är penetrationstestning, SAST-skanning (statisk analys) och dynamisk analys i form av skanning av webbapplikationer. Dessa metoder gör det möjligt för dig att hålla koll på din applikation på lång sikt.
Du kan också använda dig av hotmodellering. Ta med dig din applikation och dina utvecklare, ställ er framför en whiteboard och rita upp applikationen. Du kan dela upp den i mindre komponenter eller rita den på ett mer grundläggande sätt. Titta på dataflödena, hur och var de kommer in och ut, vilka funktioner som finns tillgängliga, och börja lista olika möjliga attackmetoder och möjliga sårbarheter. Försök sedan bygga in och implementera säkerhet i den.
”Privacy by Design” är ett finare uttryck som innebär att du bör tänka på säkerhet redan i ett tidigt skede och se till att säkerhet ingår i dina krav redan från början.
Hotmodellering, som beskrivs ovan, tidigt i utvecklingsprocessen är en mycket bra början. Se över vilka personuppgifter du har och försök att följa lagstiftningen; GDPR gäller för personuppgifter och PCI DSS är ett välutvecklat rättsligt dokument som beskriver hur kreditkortsuppgifter ska hanteras. När det gäller konfidentiell information kan du kontrollera vilka rättsliga ramverk du måste ta hänsyn till. Därefter är det viktigt att införa säkerhetsprocesser, såsom säkerhetskrav, hotmodellering, kodgranskning, DAST-verktyg, penetrationstester och infrastrukturtester med hjälp av automatiseringsverktyg.
Vår rekommendation är att automatisera mer där det är möjligt. Vi anser att man kan utföra alla kontroller som går att automatisera i till exempel ASVS eller i en CICD-process. Använd automatiserade verktyg, DAST-verktyg, verktyg för kodgranskning eller liknande.
Vår expertis behövs för de mer komplexa frågorna och när de mer komplexa testerna ska utföras. Ofta när vi ska utföra penetrationstester har företagen varken gjort kodgranskningar eller kört DAST-verktyg. Det innebär att vi måste identifiera alla typer av sårbarheter, vilket är en hel del. De allra bästa fallen är när vi får en rapport från ett sårbarhetsskanningsverktyg och när vi tittar på infrastrukturen och det visar sig att kodgranskning och DAST-verktyg har använts. Vårt arbete kan då fokuseras på alla de andra sakerna som verktygen inte kan hantera när det gäller ren logik. Till exempel logikhantering i en applikation, ren affärslogik och liknande. Automatiserade verktyg är inte särskilt bra på att identifiera dessa, eftersom de saknar förståelse för hur själva applikationen egentligen ska fungera. Automatisera så mycket som möjligt och använd vår expertis för de saker som verktygen inte klarar av.
Tester som vi rekommenderar:
OWASP ASVS, nivå 1, är utformat så att du i stort sett kan automatisera processen helt. Ett annat verktyg är OWASP Testing Guide, en mycket bra guide om olika typer av problem och hur man identifierar sårbarheter.
När det gäller verktyg beror det på företaget. Inget verktyg passar alla.