I det här inlägget tar vi upp några av de vanligaste frågorna vi får om IT-säkerhet. Från att förstå vikten av att integrera säkerhetsåtgärder under kravhantering till att hålla sig uppdaterad om de senaste säkerhetstrenderna. Vi kommer också att utforska säkerhetens kritiska roll i utvecklingsprocessen och ge insikter om hur man säkrar äldre system samt implementerar kontinuerliga interna kontroller.
Vad kan vi göra under kravhanteringen för att bidra till informationssäkra applikationer?
OWASP Top 10 är en bra lista 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 mjukvaruapplikationer.
För några år sedan publicerades OWASP ASVS (Application Security Verification Standard), ett utmärkt kompendium att använda för att identifiera säkerhetsproblem i kravhanteringen. Det kan användas som ett kravdokument för applikationer. ASVS fungerar som en checklista på tre olika nivåer: börja med nivå ett, jämför med vad du har på plats och vad som behöver tillämpas innan du går vidare till nästa nivå. Alla applikationer måste klara nivå ett. Ett tips är att börja långsamt och öka gradvis, många företag gör misstaget att införa för mycket på en gång, vilket organisationen till slut inte kan hantera.
Hur håller man sig uppdaterad inom IT-säkerhet?
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å säkerhetsbloggar, till exempel Daniel Miessler, samt podcaster som Darknet Diaries. Utöver det letar vi efter verktyg, kodsnuttar eller skript som människor har släppt och analyserar vad de försöker göra.
När det gäller sårbarheter sitter vi inte varje dag och håller koll på nya sårbarheter för specifika produkter. Istället tittar vi på aktuella sårbarheter när vi får uppdrag med en viss applikationsstack. LinkedIn är också en bra källa för att hålla sig uppdaterad.
Före Covid organiserades stora säkerhetsevenemang i Las Vegas varje sommar, som Black Hat, Def Con och BSides. Dessa är utmärkta tillfällen att nätverka och lyssna på intressanta sessioner.
Vad är säkerhet i utvecklingsprocessen?
Om vi ser på det ur ett penetrationstestperspektiv och baserat på våra uppdrag har vi märkt att säkerhet kommer in i utvecklingsprojekt 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 ett säkerhetstest. I värsta fall hittar vi då många 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 brukar prata om Shift Left Testing när det gäller säkerhet, det vill säga att vi inte applicerar säkerhet som en tilläggsfunktion i slutet, utan istället inkluderar den från början. Säkerhet bör ingå i kravspecifikationen.
Hur hanterar man säkerhet både i infrastrukturen och på applikationsnivå när systemen är något äldre i version?
Genom att bygga säkerhet runt systemet, till exempel genom kompenserande kontroller såsom lager 7-brandväggar, djup paketinspektion och genom att granska applikationslagret. Överväg också om du bör använda ett Intrusion Detection System (IDS) och/eller ett Intrusion Prevention System (IPS). Dessa är några alternativ för att säkra dina något äldre system.
Finns det en Best Practice för att bygga en stabil process kring kontinuerliga interna kontroller?
Arbeta med de 20 CIS-kontrollerna. Vilka kontroller finns på plats i företaget idag?
När vi pratar om kontroller handlar det om allt från:
– Har ni ett antivirus-system?
– Håller ni koll på företagets tillgångar?
– Har ni en översikt över företagets applikationer?
– Genomför ni regelbundna penetrationstester?
– Har ni kunskap om administrativa behörigheter?
– Använder ni en säker e-postlösning?
Det är ett ganska brett område, men det är en mycket bra riktlinje att följa om ni vill börja få kontroll, struktur och uppföljning. Som med allt annat, försök inte att hantera allt på en gång – börja smått och ta er tid. Säkerhet är inget man gör på en månad, det är en lång process. Stora företag arbetar och kämpar kontinuerligt med CIS-kontrollerna, och det är en omfattande uppgift om man vill uppfylla alla 20.
Hur utvecklar man säkra applikationer i molnet?
Om du separerar infrastrukturen från applikationen och börjar med applikationsdelen, ser vi ingen större skillnad i tillvägagångssättet och vad den ska kunna hantera. Infrastrukturen däremot, såsom hantering av nycklar och hemligheter, skiljer sig jämfört med att ha den lokalt i ett datacenter. I molnet finns det många säkerhetsfunktioner direkt tillgängliga, sådant som du kanske inte har i ditt eget datacenter, till exempel spårbarhet av åtkomster. Men för att det ska fungera som avsett måste det konfigureras, och konfigureras 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.
Finns det en bra checklista du kan rekommendera för att belysa säkerhetsfrågor i kravhanteringen?
Ja, OWASP ASVS
Is there a way to verify that you have a safe product?
Yes, the Shift Left methodology. Start with security at the very beginning of development and test the product early. Other ways to verify that you have a secure product are penetration testing, SAST scanning (static analysis) and dynamic analysis in the form of web application scanning. These allow you to keep track of your application in the long run.
You can also make use of Threat modeling. Take your application, your developers and stand in front of a whiteboard and draw the application. You can break it down into smaller components or draw it more basic. Look at data flows, how and where they come in and out, what functions are available and start listing different possible attack modes and possible vulnerabilities. Then try to build and implement security into it.
Vad är Privacy by Design?
Privacy by Design är ett uttryck som innebär att du bör tänka på säkerhet redan i ett tidigt skede genom att inkludera säkerhet i dina krav från början.
Threat modeling, som beskrivits tidigare, är en mycket bra start tidigt i utvecklingsprocessen. Analysera vilken persondata du har och försök att följa de juridiska riktlinjerna – GDPR gäller för personuppgifter, och PCI DSS är ett välutvecklat juridiskt ramverk för hantering av kreditkortsdata. När det gäller konfidentiell information kan du undersöka vilka juridiska ramverk som behöver beaktas.
Därefter är det viktigt att införa säkerhetsprocesser, såsom säkerhetskrav, threat modeling, kodgranskning, DAST-verktyg, penetrationstester och infrastrukturtester med hjälp av automatiserade verktyg.
Skulle ett automatiserat test vara ett alternativ eftersom mänskliga resurser är en bristvara? Eller bör man ha en kombination? Kan du rekommendera några tester?
Vår rekommendation är att automatisera mer där det är möjligt. Vi anser att du kan automatisera alla kontroller som är möjliga, till exempel i ASVS eller i en CI/CD-process. Använd automatiserade verktyg, DAST-verktyg, kodgranskningsverktyg eller liknande.
Vår expertis behövs för de mer komplexa frågorna och de tester som är svårare att genomföra. Ofta när vi ska utföra penetrationstester har företagen varken gjort kodgranskningar eller kört DAST-verktyg. Detta innebär att vi behöver identifiera alla typer av sårbarheter, vilket är en omfattande uppgift.
De bästa fallen är när vi får en rapport från ett sårbarhetsskanningsverktyg och när vi granskar infrastrukturen och det visar sig att kodgranskning och DAST-verktyg har använts. Då kan vårt arbete fokusera på de delar som verktygen inte kan hantera, som exempelvis 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 applikationen faktiskt ska fungera. Automatisera så mycket som möjligt och använd vår expertis för det som verktygen inte kan hantera.
Tester vi rekommenderar:
OWASP ASVS, nivå ett är skrivet så att du i princip kan automatisera det helt och hållet. En annan är OWASP Testing Guide, en mycket bra guide om typer av problem och hur man identifierar sårbarheter.
När det gäller verktyg beror det på företaget. Inget verktyg passar alla.
Jon Jezierski, Patrik Jezierski, Mattias Döj
