Vanliga frågor om IT-säkerhet

Här samlar vi alla de vanligaste frågorna vi får in om IT-säkerhet!
Tveka inte att höra av dig om du har en eller flera frågor som inte finns besvarade, vi hjälper dig gärna!

Frågor & svar

    • OWASP top 10 är jättebra att gå efter, det är en lista med de vanligaste sårbarheterna i webbapplikationer. OWASP står för Open Web Application Security och är en organisation som jobbar med säkerhet i mjukvaruapplikationer.  
       
      För några år sedan kom OWASP ASVS (Application Security Verification Standard)en fantastiskt kompendium att titta på för att fånga upp säkerhetsfrågor inom kravhanteringen. Den kan man använda som kravställning för applikationerASVS är som en checklista på tre olika nivåer, börja med nivå ett och jämför med vad ni har och vad som behövs appliceras och fortsätt vidare i nivåerna. Nivå ett ska alla applikationer kunna uppnåVill du får in säkerhet i din kravställning skulle jag börja med dennaEtt tips är att börja lågt och öka successivt, många företag gör misstaget att applicera för många saker med en gång som organisationen till slut inte kan hantera.

    • Jag följer många säkerhetspersoner på Twitter, därifrån får jag bra uppdateringar om någonting skulle ha hänt eller om något nytt verktyg släppts. Jag följer också bloggar om säkerhet t ex  Daniel Miessler, Podcast, darknet diaries. Utöver det så gillar jag att själv leta efter verktyg, kodsnippet eller skript som folk har släppt eller som de släpper och ta reda på vad de försöker göra.  
       
      När det kommer till sårbarheter sitter jag inte varje dag och håller koll på om det släpps en ny sårbarhet för ett specifik produkt, utan det blir om jag har ett uppdrag. Har jag ett uppdrag som innefattar en applikation med en viss form av applikationsstack så läser jag på innan uppdraget och tittar på vilka sårbarheter som finns just nu. Annars är Linkedin en bra källa när det gäller att hålla sig uppdaterad av nya släpp av sårbarheter.  
       
      Innan Covid arrangerades stora säkerhetsevent i Vegas varje sommar Black Hat, Def Con och BSides. Ett fantastiskt ställför att nätverka och lyssna på intressanta föreläsningar.  

    • Om vi tittar på det från ett pentestperspektiv och utifrån våra uppdrag har vi märkt att vi kommer in extremt sent i utvecklingsprojekten.  Många gånger blir vi uppringda när produkten väl ska släppas till produktion för att företaget kommer på att de behöver göra ett säkerhetstest, och i värsta fall hittar vi då massor av sårbarheter som behövs rättas till innan produkten kan går ut i produktion. Det leder till en fördröjning av projektet samt ökade kostnader.  
       
      Vi skulle vilja se att företag jobbar med pentest tidigare i utvecklingsfasen. Man brukar prata om Shift Left Testing när det kommer till säkerhet, dvs att vi inte applicerar säkerhet som en add-on feature i slutet utan att det ska vara med från början. Redan i kravställningen ska säkerhet vara med. 

    • Genom att bygga säkerhet runt systemet, som kompenserande kontroller runt omkring med layer sju-brandväggardeep packet inspection och genom att titta på applikationslagret. Fundera även på om ni inte bör ha Intrusion Detection System (IPS) och Intrusion Detection System (IDS). Detta är en del alternativ för att säkra upp era lite äldre system. 

    • Jobba med de 20 CIS-kontrollerna. Vilka kontroller finns i bolaget idag? När vi pratar om kontroller så är det allt från:  

       - Har du antivirussystem?  
       - Har du koll på dins assets i bolaget?  
       - Har du koll på din applikationer i bolaget?  
       - Kör du regelbundna penetrationstester 
       - Har du koll på administrativa privilegier?  
       - Har du email web protection? 
       
      Det är ganska brett men en väldigt bra sak att följa om du vill börja få kontrollstruktur och någon uppföljning att titta på. Som med allt annat bör du inte ta dig an allt på samma gång, börja smått och ta din tid. Säkerhet är inget man gör på en månad utan det är en lång process. Stora bolag jobbar och kämpar kontinuerligt med CIS-kontrollerna, det är en stor grej att implementera om ni vill följa alla 20. 

    • Om man separerar infrastrukturen och applikationen och börjar med applikationsdelen så ser vi ingen stor skillnad på tillvägagångssättet och vad den ska klara av att hantera. Infrastrukturen däremot, som Key Management och Secrets är annorlunda jämfört med att dra det on-prem i ett datacenter. Man har mycket av säkerheten i Cloud:et direkt, saker som man kanske inte har i sitt eget datacenter som exempelvis spårbarhet till accesser.Men för att det ska fungera som tänkt gäller det att konfigurera det och konfigurera det rätt. Cloud är inte säkert by default, utan det är användaren som måste konfigurera och aktivera dessa features innan miljön går live ut på internet.

    • Ja, tänk Shift Left-metodiken. Börja med säkerhet redan i början av utvecklingen och testa produkten tidigt. Andra sätt att verifiera att man har en säker produkt är pentest, SAST-skanning (statisk analys) och dynamisk analys i form av webbapplikationsskanning. Dessa gör att du på sikt kan hålla koll på din applikation.  
       
      Du kan även använda dig av Hotmodellering. Ta din applikation, dina utvecklare och ställ er framför en whiteboard och rita upp applikationen. Du kan bryta ner den i mindre beståndsdelar eller rita upp den mer basic. Titta på dataflöden, hur och var de kommer in och ut, vilka funktioner som finns och börja lista upp olika möjliga attacklägen och möjliga sårbarheter. Försök därefter att bygga och implementera säkerhet på det.  

    • Privacy by design är ett finare ord med betydelsen att man ska tänka på säkerhet i ett tidigt stadie, att man ska ha med säkerhet redan i sin kravställning.  
       
      Hotmodellering tidigt i utvecklingen är en mycket bra start. En teknik där du och dina utvecklare ritar upp er produkt på en whiteboard, ganska basic eller i mindre beståndsdelar som funktioner för att få en övergripande bildHar du inte gjort hotmodellering innan rekommenderar vi att göra det så enkelt som möjligt och få in mindsettet. Titta på vad ni har för persondata och försök följa juridiska riktlinjer, GDPR gäller vid personuppgifter och PCI DSS är ett väl utvecklat juridiskt dokument för hur du ska hantera kreditkortsuppgifterNär det gäller sekretessbelagd information får du kolla på vilka rättliga ramverk du måste ha i beaktning. Efter det gäller det att få in säkerhetsprocesserna, såsom säkerhetskrav, hotmodellering, kodgranskning, DAST-verktyg, pentest och infrastrukturtest i form av automatiserande verktyg. Det är många saker som ska på plats, men det är så det ser ut. 

    • Vår rekommendation är att automatisera mer där det går att automatisera. Alla kontroller som går att automatisera exempelvis ASVS eller i en CICD-process tycker vi du kan göra. Använd automatiserade verktyg, använd DAST-verktyg, kodgranskningsverktyg eller liknande.  
       
      Vår kompetens kommer in vid de mer komplexa frågeställningarna och när de mer komplexa testerna ska göras. Många gånger när vi kommer och ska utföra pentester kan det hända att företag inte gjort varken kodgranskning eller kört DAST-verktyg, det gör att vi behöver identifiera alla typer av sårbarheter vilket blir väldigt mycket. De allra bästa fallen är när vi kommer till ett företag och får en rapport från ett sårbarhetsskanningsverktyg och när vi kollar på infrastrukturen visar det sig att de har kört kodgranskning och DAST-verktyg. Vårt arbete blir då att fokusera på alla andra saker som verktyg inte är lika duktiga på när det kommer till ren logik. Som logikhantering i en applikation, ren business logik och liknande, det är inte automatiserade verktyg speciellt duktiga på att identifiera, för de har inget koncept över hur applikationen i sig egentligen ska fungera. Automatisera så mycket det går och använd vår kompetens till de saker verktygen inte klarar av. 
       
      Tester vi rekommenderar: 
      OWASP ASVS, nivå ett är skriven så att du i stort sett ska kunna automatisera helt och hållet. En annan är OWASP Testing Guide, en mycket bra guide på typer av problem och hur ni ska identifiera sårbarheten. 
       
      När det kommer till rena verktyg är det beroende på företag. Inget verktyg passar alla.  

Vi som svarat på frågorna

Jon Jezierski

Jon Jezierski

IT-SÄKERHETSEXPERT

Jon är en passionerad IT-säkerhetsspecialist med mer än 14 års erfarenhet inom ett brett område av discipliner. Under åren har han hunnit verkat inom de flesta sektorer och utfört över 700 tekniska analyser i 12 olika länder. 

 

Jon på Linkedin

Patrik Jezierski

Patrik Jezierski

IT-SÄKERHETSEXPERT

Patrik har jobbat aktivt med IT-säkerhet sedan 2010. Under dessa år har han huvudsakligen arbetat som en penetrationstestare men har under sina långvariga uppdrag kunnat ta flera olika roller inom IT vilket har resulterat i hans breda kunskap inom området.


Patrik på Linkedin

Mattias Döj

Mattias Döj

IT-SÄKERHETSEXPERT

Mattias har sedan 2016 arbetat med en stor mängd komplexa system. Till en början som utvecklare och testautomatiserare, men under majoriteten av tiden har han arbetat som IT-säkerhetskonsult på en mängd olika globala företag.

 

Mattias på Linkedin

Behöver ni hjälp med IT-säkerhet?

Allt mer data görs dagligen tillgänglig för våra kunder, leverantörer, partners etcetera genom olika integrationer av IT-system såsom mobil– / webb–applikationer eller API:er. Det här ställer allt högre krav på att utvecklare och systemarkitekter integrerar säkerhet i sin utvecklingsprocess eller designfas för att motverka angrepp. Då nya tekniker och metoder för angrepp kontinuerligt upptäcks är det ofta svårt för företag att skapa rätt kravställning.

Vi ser till att du får mest värde och nytta för din investering utifrån just era behov, förutsättningar och mål.

Vill du veta mer om hur vi kan hjälpa till baserat på er situation?

Våra senaste inlägg om IT-säkerhet

IT-säkerhet vid SaaS lösningar - vad ska du tänka på
Lästid: 7 min

IT-säkerhet vid SaaS lösningar - vad ska du tänka på

Läs mer
Vi reder ut begreppen inom IT-säkerhet
Lästid: 13 min

Vi reder ut begreppen inom IT-säkerhet

Läs mer
Skillnaden mellan sårbarhetsskanning och pentest
Lästid: 9 min

Skillnaden mellan sårbarhetsskanning och pentest

Läs mer