Red team och hur de skyddar er verksamhet - del ett

I dagens alltmer digitaliserade värld är det lätt att tro att säkerhet endast handlar om skydd mot it-angrepp och dataintrång. För att möta hotbilden och hotaktörernas avancerade metoder räcker inte enbart traditionella penetrationstester längre. En viktig del av säkerhetsarbetet är att testa organisationen från flera olika kombinerade attackvinklar. 

Red team-testning är en metod som används för att utvärdera organisationens säkerhet genom att simulera hotaktörernas angreppsmetoder. Genom att använda de olika tekniker och taktiker som hotaktörer historiskt har bevisats använda sig av, kan organisationen identifiera brister i sin säkerhet och ta till åtgärder för att säkerställa att dessa brister arbetas bort. Basalt erbjuder tester inom flertalet olika områden och dessa tester går att kombinera enligt kundens önskemål. När flera av dessa enskilda typer av tester kombineras, till exempel fysisk penetrationstest, infrastrukturstest och social engineering, börjar detta likna red team-test.

Den finansiella sektorn ligger steget före

Processen för red team finns beskrivet i flera olika ramverk, där TIBER-EU är ett ramverk för den finansiella sektorn i EU, och det är det första red team-ramverket som har blivit implementerat i Sverige genom Riksbanken (TIBER-SE). Detta ramverk är redan idag ett krav vid genomförande av red team-tester i för bankväsendet och har ett tydligt definierat arbetsflöde. Den finansiella sektorn är ofta tidigt ute med god cybersäkerhet, och resterande verksamheter följer troligtvis med i denna utveckling.

Kombinerade attackvektorer och informationsinhämtning

Testarnas omfattning av tillåtna metoder och avsatt tid utökas i red team-tester och fler attackvektorer kan därför användas, kombineras och utnyttjas för att uppnå maximal penetration i organisationen. I vanliga penetrationstester brukar betydligt mindre andel av tiden läggas på informationsinhämtning, och i stället prioriteras så kallad greybox eller whitebox metodik där mycket information tillhandahålls testarna för att minska eller helt hoppa över informationsinhämtnings-stadiet. Med begränsad tid kan testarna i stället fokusera på att hitta sårbarheter och behöver inte lägga lika mycket tid på att analysera exponeringen av organisationen.

I red team-tester appliceras istället så kallad blackbox-metodik, där ingen intern information tillhandahålls testarna. Mycket tid läggs därför på informationsinhämtningen för att efterlikna verkligheten i det arbete hotaktörerna genomför sin kartläggning av organisationen. Ett red team-test börjar därför alltid med en grundläggande OSINT-undersökning, och kan ibland vara tillräcklig för att identifiera vissa brister i organisationens säkerhet. OSINT står för Open Source Intelligence och innebär att samla in information från offentliga källor för att bygga en bild av organisationen och dess säkerhetskultur. Informationen kan innefatta it-system, byggnader, anställda, affärspartners samt information om säkerhetsåtgärder som används och vilken arbetskultur som finns.

Många organisationer väljer att även ha med fysiska penetrationstester tillsammans med social engineering för att simulera de verktyg som statliga aktörer ofta använder sig av, samtidigt som det är en attackvektor som ofta glöms bort eller ignoreras i traditionella penetrationstester på grund av dess komplexitet. Det är även vanligt att ha med både infrastrukturstester och webbapplikationstester då båda dessa områden ofta kan exploateras vidare om testningsteamet får fysisk åtkomst till servrar eller andra lokala känsliga enheter, eftersom enheterna då även blir sårbara för fysiska attackmetoder som annars inte är tillgängliga i vanliga penetrationstest. Mer om detta i del två.

Vad är då ett blue team?

En viktig del i red team-tester är möjligheten att testa sitt blue team skarpt. Blue team är den gruppering inom organisationen som ansvarar för att försvara it-systemen mot angrepp och kan vara antingen experter på it-avdelningen, it-säkerhetsavdelningen eller kanske vanligast i en SOC (Security Operations Center). Testerna mot blue team genomförs för att se över rutiner, processer och de verktyg som används för att upptäcka och förhindra intrång och för att hitta eventuella förbättringspunkter i it-systemen. Oftast vet alltså inte blue team om att testerna skall ske, utan endast CIO är delgiven inför testet.

När testet är genomfört sitter båda parter ned och går igenom resultatet från testningen, där blue team får reda på sårbarheter och hur de kan implementera nya skyddsmekanismer, samtidigt som att red team även får reda på hur mycket av testerna som har varit synligt. Med denna feedback utvecklas även red team-testerna till att bli effektivare på att gå under radarn, så att svårighetsgraden för blue team ökar inför kommande tester. Detta resulterar på sikt till att båda parters cyberförmåga höjs och ger ett verklighetstroget och relevant cyberskydd.

Skillnaden mellan red team och ett penetrationstest

Den största skillnaden mellan vanliga penetrationstest och red team-tester är att read team nästan alltid arbetar i produktionssystem (skarpa affärskritiska system) och går därför mycket försiktigt fram i syfte att inte göra sönder något i dessa system. Detta tillsammans med försök att undgå upptäckt resulterar ofta i en avsevärt längre testperiod än vanliga penetrationstest, men minskar risken att affärskritiska tjänster blir otillgängliga.

I ett vanligt penetrationstest eftersträvas i stället dedikerade testsystem om det finns tillgängligt, och testsystemen bör avspegla produktionssystemen i alla kritiska och relevanta funktioner, enda skillnaden bör därför vara att den rent innehållsmässigt inte är fylld med känslig produktionsinformation. Då medges mer förstörande tester utan risk för negativa konsekvenser. Dessutom behöver testarna inte fokusera på att försöka undgå upptäckt av ett blue team, och tester av mer aggressiv karaktär kan användas för att snabba upp testfasen. Detta resulterar i att större del av den begränsade testningstiden läggs på att identifiera potentiella sårbarheter.

Läs del två om den mänskliga faktorn och simulerade inbrott här.