Én konto.
Alt væk?
Ikke nødvendigvis.
NIS2 foreskriver ti risikotiltag. Med Managed Red Tenant og Dark Tenant understøtter vi den tekniske implementering. For en markant lavere angrebsrisiko og vished om, at I er handlingsdygtige igen i løbet af timer, hvis det alligevel sker.
Det interessante ved Stryker-angrebet den 11. marts 2026 er ikke antallet af berørte enheder, selvom 80.000 enheder i 79 lande er et markant tal, men banaliteten i midlet: ingen exploit, ingen zero-day, intet raffineret angreb på infrastrukturkomponenter, som kun få kender. En enkelt kompromitteret Intune-admin-konto var nok, og angrebet så udefra ud som helt normal drift, fordi det i teknisk forstand var det, blot udført af en anden. Hvad der præcist skete, står i blogindlægget om Stryker-angrebet.
De fleste virksomhedsinfrastrukturer er bygget sådan, at netop denne skade er mulig, ikke fordi de ansvarlige har været skødesløse, men fordi privilegerede konti med vidtrækkende rettigheder gennem årene har været betragtet som praktiske: en konto med adgang alle steder sparer tid i det daglige arbejde, og tid er som bekendt det eneste, der er endnu knappere end budgettet i IT-afdelinger. NIS2 artikel 21 drager konsekvensen af den praksis: privilegerede identiteter skal være isoleret i en grad, hvor en kompromittering ikke river hele infrastrukturen med sig, og den, der alligevel bliver ramt, skal være handlingsdygtig igen i løbet af timer.
Hvad NIS2 er, og hvem direktivet omfatter, forklarer vi her. På denne side handler det om støtten til den tekniske implementering af risikotiltagene med Managed Red Tenant og Managed Dark Tenant.
Managed Red Tenant: så en kompromitteret konto ikke bliver til en hovednøgle
Det angrebsmønster, der virkede ved Stryker-hændelsen, er ikke nyt: angriberne kompromitterer en konto, der giver dem adgang til privilegerede systemer, bevæger sig derfra videre til resten af infrastrukturen og retter den skade an, som de har flest rettigheder til. Det virker så pålideligt, fordi der i de fleste virksomheder ikke findes nogen strukturel adskillelse mellem almindelige arbejdsmiljøer og de administrative adgange, som reelt ville være nok til at overtage hele infrastrukturen.
Managed Red Tenant bryder dette mønster ved at flytte administrative identiteter og de tilhørende slutenheder over i en fuldstændigt adskilt Microsoft-tenant, med egne Entra ID-konti, egne hærdede enheder og ingen netværksforbindelse til produktionsmiljøet, som en angriber kunne udnytte til lateral movement. Den, der fra en kompromitteret standardarbejdsplads forsøger at arbejde sig frem til de kritiske systemer, møder her en grænse, som ikke fandtes før.
Til Managed Red Tenant
Managed Dark Tenant: det forberedte miljø til det tilfælde, der ikke skal indtræffe, men kan
Efter et større ransomware-angreb falder de problemer, en virksomhed skal håndtere, i to kategorier: de tekniske, som kan løses, om end ikke hurtigt, og de organisatoriske, hvor ingen på forhånd har fastlagt, hvem der gør hvad i en krisesituation, i hvilken rækkefølge der træffes beslutninger, og på hvilket grundlag der overhovedet kan kommunikeres, når den egne infrastruktur ikke længere er til at stole på. Coveware måler den gennemsnitlige nedetid efter et ransomware-angreb til 24 dage, og erfaringen fra hændelser viser, at tiden ikke primært går tabt på grund af manglende tekniske midler, men fordi processer, man aldrig har brug for i normal drift, skal opfindes fra grunden under ekstremt pres.
Managed Dark Tenant er et forudprovisioneret, fuldstændigt isoleret Microsoft-miljø, der i en krisesituation aktiveres via en 24/7-hotline og stiller einsatsbereite kommunikation, Windows 365-arbejdspladser og en AD-recovery-pipeline til rådighed for kriseteamet inden for få timer, alt sammen på basis af Infrastructure as Code, alt defineret og testet, inden der bliver brug for det. Arkitekturprincippet bag hedder Minimum Viable Company: kommunikation først, derefter kritiske dokumenter, derefter kerneapplikationer, i en rækkefølge, der er fastlagt på forhånd og regelmæssigt afprøvet i fire drills.
Til Managed Dark TenantVi understøtter den tekniske implementering
| Risk Measures | GK Services | NIS2 | CSOC | APT Response | Preventive Services | Managed Red Tenant | Managed Dark Tenant | Data Security | Workplace / Azure |
|---|---|---|---|---|---|---|---|---|
| Risk Analysis and Information System Security | 21.2 a) | |||||||
| Incident Handling | 21.2 b) | NEU | NEU | |||||
| Business Continuity | 21.2 c) | NEU | ||||||
| Supply Chain Security | 21.2 d) | NEU | ||||||
| Security in Network and Information Systems | 21.2 e) | |||||||
| Effectiveness of Cybersecurity Risk Management Measures | 21.2 f) | NEU | NEU | |||||
| Basic Computer Hygiene Practices and Cybersecurity Training | 21.2 g) | |||||||
| Cryptography | 21.2 h) | |||||||
| Human Resources Security, Access Control Policies and Asset Management | 21.2 i) | NEU | ||||||
| Multifactor Authentication or Secured Communication | 21.2 j) | NEU |
To services, ét svar på NIS2 artikel 21
Managed Red Tenant
Privilegerede identiteter og slutenheder i en fuldstændigt adskilt Microsoft-tenant uden netværksforbindelse til produktionsmiljøet. Ingen lateral movement, ingen kompromitteret standardkonto, der bliver til en hovednøgle.
Managed Dark Tenant
Et forudprovisioneret, isoleret Microsoft-miljø, der i en krisesituation aktiveres via en 24/7-hotline. Kommunikation, Windows 365-arbejdspladser og AD-recovery-pipeline er defineret og testet, før der bliver brug for dem.
MRT & MDT sammen
Red Tenant reducerer sandsynligheden for, at et angreb rammer hele infrastrukturen. Dark Tenant reducerer nedetiden, hvis det alligevel sker. NIS2 eller ej, tilsammen giver de to mening uafhængigt af regulatorisk pres.
Mere om emnet
Admin og hverdag på samme computer? Game Over.
Hvorfor én tenant ikke rækker for CIO'er, og hvorfor den anden sjældent bliver tænkt med. Managed Red Tenant adskiller arkitektonisk ...
