Det är en ljummen junimorgon som ett stort antal intresserade åhörare samlas, både på plats på Bergakungen och på distans via livestreamen, för att delta i Tripnets andra Kunskapsfrukost 2023. Ämnet för dagen handlar om att identifiera sårbarheter och testa sina system. Hur vet man om systemen är säkra? Och hur säkra behöver de egentligen vara? Tripnets systemingenjör Robert Wemmenlöv har sällskap av Jakob Schlyter från Kirei, samt Johanna Abrahamsson och Albin Eldstål-Ahrens från Assured för att tillsammans sprida kunskap på ämnet.
Det är omöjligt att ignorera det högspända säkerhetslandskapet som råder – ett ämne som avhandlades vid Tripnets förra Kunskapsfrukost. Information från Radar/TrueSec visar dessutom en tydlig trendökning i antal attacker sedan februari 2023. Många av attackerna är övergående och många organisationer lyckas återhämta sig. Trots det bör man vara på sin vakt.
– Sverige har varit mer utsatt än övriga nordiska länder. Detta beror delvis på säkerhetsläget kring Östersjön och delvis Sveriges ansökan till NATO, berättar Robert.
Analys av attackerna som sker
Det är viktigt att komma ihåg att en stor del av attackerna idag är automatiserade och därför pågår oavbrutet dygnet runt. Attackerna som sker är heller inte riktade, utan görs i ett försök att träffa en stor yta. Om en attack tillåts fortsätta ökar risken för ett lyckat intrångsförsök.
– De vanligaste attackerna sker utifrån, det är externa attacker, säger Robert. Utav dessa är det vanligast att försöka knäcka lösenord eller lura personer att klicka på länkar i phishingmail. Det är också vanligt att utnyttja exploits och att kontakta anställda för att få tillgång till information, så kallad social engineering.
Webbapplikationer är en fortsatt hög måltavla för attacker. Cirka 70 % av attackerna riktas mot webbapplikationer, där angriparna utnyttjar sårbarheter som exponeras mot internet.
– Den som attackerar ert system har alltid mer tid än de konsulter ni anlitar, konstaterar Jakob. De är många, och de kommer inte sluta förrän de är klara.
Attackerna sker ofta på automatik, över en stor yta, utan att egentligen bry sig om vilken av alla måltavlor de lyckas angripa. Den typen av angrepp kan en sårbarhetsscanning hjälpa dig mot. Logikproblem, å andra sidan, hittas sällan av en automatiserad angripare, men kan identifieras av ett penetrationstest.
– En angripare skyr inte heller några medel. Jag har gjort penetrationstester där man inte vågar testa skarpt. Man har kanske ingen annan miljö för att man har så specialiserade hårdvara, så specialiserade fall. Vi vågar inte riskera att något går sönder, så vi får göra mer som en teoretisk övning, berättar Johanna.
Förklaring av begrepp
Branschen är inte helt ense gällande den exakta betydelsen för de begrepp som används. För att undvika missförstånd förtydligas här nedan vad som menar med de olika begrepp som kommer användas hädanefter. Observera att detta inte är en formell begreppsdefinition.
- Sårbarhetsscanning/sårbarhetsanalys: en helt eller till stor del automatiserad process för att upptäcka kända sårbarheter i produkter som används.
- Säkerhetsgranskning/penetrationstest: offensiva tester, efterliknar vad en angripare skulle göra, men med förutsättning att hitta sårbarheter. Det kan också vara en arkitekturgranskning eller kodgranskning.
- Hotaktörsimulering: red teaming / purple teaming, stimulerar ett riktigt angrepp för att se hur organisationen kan identifiera att det pågår och hur man kan hantera det. En avancerad övning för de som står för väldigt stora angripare.
Bli inte bättre på säkerhet
– Vill ni bli bättre på säkerhet? frågar Johanna publiken. Vill ni bli bättre? Jag vill inte att ni ska bli bättre, jag vill att ni ska bli bra.
Att ha bra säkerhet innebär att ha rätt nivå av säkerhet för den specifika verksamhet som bedrivs, och inte överdriva med säkerhet som inte behövs. Det är möjligt att göra system nästan hur säkra som helst, men det kostar. Det är till exempel svårt att hacka någon som använder penna och papper, men det är också väldigt opraktiskt för organisationen.
Hot- och riskanalys i lightvariant
Det är inte ovanligt att hot- och riskanalys tas upp i en konversation om säkerhet, med betoning på att en sådan måste göras. För många är detta nära förknippat med högar av papper och tidskrävande processer, där dokumenten ändå slutligen landar i något skåp.
– Det finns organisationer som är i behov av den typen av ledningssystem och kvalitetssäkring, men alla organisationer behöver inte samma mängd dokumentation kring sin process. Detta bör i stället läggas i likhet med resten av organisationens processer, förklarar Johanna.
För vissa organisationer kan det mycket väl räcka med en lightversion av hot- och riskanalysen. Det viktiga är att något görs.
En hotanalys behöver inte vara krångligare än vad som kan hända organisationen. Hotet utgörs av tillgångar, som information, servrar eller personer, som råkar ut för en påverkan, som att information sprids eller förstörs, samt eventuellt av en aktör, det vill säga den som vill att det ska ske.
För riskanalysen är det viktigaste att förstå vad som vore resultatet och konsekvenserna om hotet inträffade. För att bedöma hur troligt det är att hotet inträffar kan en extern part kopplas in.
Varför göra en sårbarhetsscanning?
En av anledningarna till att man kan välja att göra en sårbarhetsscanning är för att skapa insikt och identifiera risker. Ibland är vissa av risker redan kända i organisationen, men det kan vara nödvändigt att övertyga eller bevisa för någon annan. En scanning kan också göras i syfte att överblicka sina sårbarheter då företaget inte vet om det finns några. Det är inte ovanligt att tro att säkerhetsnivån är ganska bra, och sedan bli överraskad av resultatet.
– Detta kan resultera i att man tar kontroll över sin egen IT-säkerhet, berättar Jakob. Man får en ökad förståelse för vad som är en kvarstående risk. Efter det kan man bestämma om det något att acceptera eller något man vill lägga pengar på att åtgärda.
Ibland kan det också finnas interna eller externa krav på att genomföra sårbarhetsanalyser.
Vad granskar man mot? Vad är egentligen rätt?
I många fall handlar det om att man vill uppfylla sin egen säkerhetspolicy. Då är det viktigt att bedöma om den egna policyn är rimlig och identifiera specifika kontroller att granska mot. Man kan också ha gjort en egen hot- och riskanalys och vill se om det motsvarar.
Organisationen kan också ha certifieringskrav på sig. Det finns alltifrån väldigt stora ramverk, till exempel för de som faller under PCI DSS (Payment Card Industry Data Security Standard), till mindre sådana. Bra ramverk, som ofta är på en hög nivå, säger inte vad man ska göra, utan har ett uppnående mål. Ofta är det en tredjepartsrevisor i ett senare skede som avgör om lämpliga åtgärder har vidtagits.
– Jag vet inte vad ni tycker, men ofta blir det en upplevd branschnorm som man granskar mot, säger Jakob. Där man som granskare tycker något, baserat på sin egen erfarenhet. Problemet här är att det är en omogen bransch där folk tycker olika saker. Detta gör att det blir svårt att jämföra granskningsrapporter.
Det är inte heller helt ovanligt att kunder och leverantörer kräver att företaget ska genomföra ett penetrationstest. Det händer också att företag efterfrågar certifieringar som ISO 27001 utan att vara medvetna om att det kräver betydande resurser.
Tripnets sårbarhetsanalys
Det finns ett flertal typer säkerhetsanalyser, som till exempel automatisk systemsökning, övervakning av viktig infrastruktur, säkerhetsgenomlysning och systemspecifik analys. Ett exempel på en tjänst för automatisk systemsökning är den sårbarhetsanalys som vi på Tripnet erbjuder våra kunder.
Det finns flera olika verktyg för att utföra sårbarhetsanalyser och ett mycket stort antal leverantörer. Till Tripnets sårbarhetsanalys används för tillfället Nessus Professional, skapat av Tenable. Eftersom Tripnet inte är produktspecifika kan detta dock mycket väl komma att ändras i framtiden.
– Vi tittar mycket på vad produkterna erbjuder och vad de kan hjälpa oss med, berättar Robert. Vi håller hela tiden utkik efter vad som fungerar bäst efter kundernas krav.
Med hjälp av verktyget gör Tripnet automatiserade sårbarhetsscanningar. Dessa görs både internt, för att identifiera sårbarheter inom det egna nätverket, och externt, för att analysera hur systemet ser ut när någon försöker komma åt det från internet. Analyserna genomförs vanligtvis månatligen eller kvartalsvis beroende på kundens önskemål.
Syftet är att få en överblick över befintliga sårbarheter och hur de kan åtgärdas, samt jämföra om det skett några förändringar sedan tidigare scanning.
Hur går analysen till?
Sårbarhetsscanningen görs i flera steg. Först genomförs en inventering för att kartlägga vad som finns och vad som behöver skyddas och sedan utförs själva scanningen, då man försöker hitta sårbarheter. När scanningen är klar analyseras resultatet. Om resultatet inte visar några sårbarheter bör man fundera på andra infallsvinklar eller om något missats. Om sårbarheter har hittats behöver en riskprioritering göras, då man bedömer vilka som är mest kritiska och behöver åtgärdas först. Analysen avslutas med att sårbarheterna åtgärdas.
– Sedan kan man luta sig tillbaka och tycka att allt är fixat, men så är det ju inte! Allt börjar om, så när man är klar med den första, planerar man för nästa, konstaterar Robert.
Syftet med att använda verktyget för analys är att snabbt få en överblick över identifierade sårbarheter. I listan som presenteras är det tydligt vad som behöver prioriteras. Den detaljerade information som finns tillgänglig gör de möjligt att få en ledtråd om vad som måste åtgärdas, vilket gör det enkelt att delegera till rätt tekniker.
Avslutande ord om sårbarhetsscanning
Vid en sårbarhetsanalys är det viktigt att titta på hur man är exponerade; både internt och ut mot internet, för att förstå vad som behöver granskas.
– Är allt rätt konfigurerat? En sårbarhetsanalys visar givetvis inte allt. Det finns saker som den inte detekterar, men den kan ge hintar. Det har hänt att saker av misstag har exponerats, när man jobbat med att till exempel lansera en ny webbapplikation. Det kan en analys avslöja, berättar Robert.
En analys informerar också om huruvida mjukvaran är uppdaterad eller om något har glömts bort, till exempel om man glömt stänga något som använts i labbsyfte.
– Sedan också; vad har hänt sedan sist? Har det skett några förändringar sen vi gjorde den förra scanningen och baselinen? säger Robert.
Analysen ger endast en ögonblicksbild av den nuvarande situationen och mot det som scanningen avser. Den tar därför inte upp logiska problem eller när flera faktorer tillsammans bildar en sårbarhet. Dessutom är analyserna inte alltid så bra på mindre vanliga ramverk.
– Det finns kunder som har saker i molnet som de vill att vi kolla på, och det har vi möjlighet att göra. Allt vi testar behöver inte finnas i vår miljö. AWS, Azure, Google Cloud eller någon annan leverantör, det är inget hinder för att göra kontroller, berättar Robert.
I gränslandet mellan säkerhetsproblem och systemövervakning
Det är viktigt att komplettera med övervakning av viktig infrastruktur för att kunna identifiera problem som behöver snabba åtgärder. Exempel är certifikat som håller på att gå ut, ändpunkter som är konfigurerade med felaktiga inställningar och andra konfigurationsfel som inte upptäcks vid en vanlig systemavsökning. Tripnets kunder kanske känner igen detta som Monit, men det finns även andra verktyg, så som Hardenize.
– Detta behövs när man inte vill vänta på en avsökning om tre månader, utan vill veta inom en timme att det är problem. Jag skulle säga att det här är gränslandet mellan säkerhetsproblem och systemövervakning, men man måste ha båda, påpekar Robert.
Penetrationstester
När man vill komma djupare än automatiska scanningar, är det möjligt att göra ett penetrationstest. Dessa kan delas upp i tre olika varianter baserat på förutsättningarna; white box, grey box och black box. Den förstnämnda är den bästa sorten, och är när de som utför testet har riktigt god kännedom om systemet. Om de har information på förhand kan tiden i stället nyttjas för att sikta mot problemen.
– Vi har gärna kontakt med någon på driften och någon utvecklare. Då kan vi ställa frågor och tillsammans fundera över det vi hittar och hur det kan utnyttjas. Mest bang for the buck, förklarar Johanna.
Grey box är när den vita lådan har blivit lite ”dammig” och det saknas information om vissa delar. Det kan vara brist på uppdaterad dokumentation, en tredjepartsleverantör som inte samarbetar eller en intern utvecklingsavdelning som inte vill bli testade. Grey box blir en ibland okej kompromiss med mindre nytta för pengar.
– Jag säger ofta att black box-tester; det ska man inte göra. Det finns dock ett tillfälle när man ska det och det är när ledningen verkligen inte kan öppna öronen och lyssna, berättar Johanna.
Ett sådant test är när de som utför testet inte har någon information eller någon åtkomst på förhand. Det kräver mer tid och pengar jämfört med de andra varianterna.
– Ett penetrationstest kommer aldrig vara komplett så som en angripare, men vi hittar mer genom att vara effektivare, säger Johanna.
Resultatet av ett penetrationstest
Slutprodukten efter ett genomfört test är den rapport som överlämnas. Rapporten innehåller information om bakgrund till att testet utfördes, omfattningen till testet, vilka verktyg som användes och hur riskbedömningen gjorts. Det finns också självklart information om vilka sårbarheter som identifierades, hur de hittades samt rekommendationer till åtgärder och uppföljande tester.
Ett penetrationstest kan utföras på allt ifrån ett helt nätverk till enskilda komponenter. Ett test kan vara en övergripande granskning på en stor yta för att få information om vart insatserna ska riktas, medan ett annat test kan fokusera på små komponenter i ett större system.
– Vi säger att vi testar allt från mikrochip till båtar. Vi hoppas också på satelliter, men vi är inte riktigt där än, konstaterar Johanna.
Rätt tid för ett penetrationstest
Ett penetrationstest bör utföras när en applikation är nästan redo att släppas, så att funktionerna som ska testas finns på plats. Det är fördelaktigt att testet görs innan applikationen blir tillgänglig för allmänheten, så att sårbarheterna kan åtgärdas innan release.
– När man får en rapport så är den full av sårbarheter. Det kan komma tre sidor med röd text, där allt är fel och dåligt, vilket inte är kul. Vem är ansvarig för att det gått fel? frågar sig Albin.
Oftast är det egentligen ingen enskild som är helt ansvarig för problemet. Det kan i stället bero på misskommunikation mellan beställare och leverantör, och att säkerhetskraven inte var tillräckligt tydliga och specificerade. Av denna anledning kan det vara till fördel att involvera säkerhetsexperter tidigt i processen, vid kravställandet. Det är svårt att på förhand fastställa exakt vad som generellt bör krävas i en specifikation, utan att sätta sig in i den enskilda situationen.
– Det är en ganska omogen bransch och det finns inte så mycket lagkrav. Det finns rekommendationer kopplade till branschstandarder och normer, men det är inte helt lätt att veta vilka dokument man ska rekommendera till sina kunder, berättar Albin.
Agera hotaktör
En hotaktörsimulering kan låta hotfullt, och det är få organisationer som är i behov av sådana. De som utför övningen tar på sig rollen som en riktig angripare för att identifiera hur organisationen hanterar och reagerar på en sådan attack.
– En angripare har typiskt ett mål, till exempel att samla in information. Det finns olika sätt att göra det på, och detta kan sedan kategoriseras efter kända angrepp samt vad och hur hotaktörerna gör, berättar Johanna.
För att övningen ska vara värdefull behöver den vara noggrant specificerad för vad som händer. Det är först då det går att avgöra hur organisationen reagerade, hur processerna fungerade och hur kommunikationen skedde.
Tiden efter en analys
Efter att informationen om eventuella sårbarheter har nått organisationen kan alla möjliga känslomässiga reaktioner uppstå. De flesta kunder är tacksamma, åtminstone den i organisationen som beställt uppdraget, men det kan också finnas utvecklare som är missnöjda med att få en rapport som visar röda punkter. Det är inte heller alltid som sårbarheterna tas på allvar.
– Det händer absolut att vi kommer tillbaka och upptäcker att sårbarheterna inte har åtgärdats, vilket är tråkigt. Ett penetrationstest kostar minst 150 000 kr och tar två veckor, men den stora delen av arbetet bör vara det interna då man tar emot analysen och utför åtgärder, säger Johanna.
I slutändan är det kunden som beslutar vilka risker de accepterar. Det är helt okej att välja att acceptera en högriskobservation, men då får man också vara okej med konsekvenserna.
Kombinering av metoder
Det finns flera sätt att granska sin IT-säkerhet. Ett penetrationstest tittar också på sårbarheter på samma sätt som en sårbarhetsanalys eller scanning. Skillnaden är att en sårbarhetsanalys eller scanning kan utföras regelbundet efter kundens önskemål, medan ett penetrationstest oftast görs mer sällan. Det är viktigt att kombinera olika metoder och hitta det som är mest effektivt.
– Det kommer också nya och mer automatiserade sårbarhetsscanningar, som går på djupet i applikationer. De kan till viss del ersätta sånt som görs under ett penetrationstest. Det kan vara en del av lösningen, men inte hela lösningen, berättar Johanna.
Slutligen, några insiktsfulla råd:
- Få inblick i vad som är skyddsvärt.
- Etablera en baseline, en referenspunkt för att jämföra förändringar över tid.
- Utför regelbundna, automatiska sårbarhetsanalyser.
- Utvärdera resultaten från analysen.
- Genomför penetrationstest i slutskedet, före release.
- Ta hjälp av experter redan i utvecklingsprocessen.
- Ta hellre beslut och gör fel. Om ni har valt att acceptera en risk kan ni också följa konsekvenserna.
- Börja med det (affärs-)viktigaste.
Vilka är dina sårbarheter?
Vill du slippa gissa om dina system är säkra eller inte? Ring eller maila mig så tar jag med mig Robert eller någon annan av våra kunniga systemingenjörer så tittar vi på vilken lösningen kan vara för dig. (Vill du hellre komma till oss och äta mjukglass går det naturligtvis också bra!)
Emmy Ljungvall, säljchef Tripnet
0733-58 25 19
emmy.ljungvall@tripnet.se
