Én konto.
Alt borte?
Ikke nødvendigvis.
NIS2 foreskriver ti risikotiltak. Med Managed Red Tenant og Dark Tenant støtter vi den tekniske implementeringen. For en betydelig redusert angrepsrisiko og visshet om at du er handlingsdyktig igjen i løpet av timer i en krisesituasjon.
Det interessante med Stryker-angrepet 11. mars 2026 er ikke antallet berørte enheter, selv om 80.000 enheter i 79 land er et påfallende tall, men banaliteten i midlet: ingen exploit, ingen zero-day, ingen sofistikert angrep på infrastrukturkomponenter som bare få kjenner til. Én enkelt kompromittert Intune-admin-konto var nok, og angrepet så utenfra ut som normal drift, fordi det i teknisk forstand var det, bare utført av noen andre. Hva som nøyaktig skjedde, står i bloggartikkelen om Stryker-angrepet.
De fleste bedriftsinfrastrukturer er bygget slik at denne skaden er mulig, ikke fordi de ansvarlige har vært uaktsomme, men fordi privilegerte kontoer med omfattende rettigheter i årevis har blitt ansett som praktiske: en konto som har tilgang overalt sparer tid i det daglige arbeidet, og tid er som kjent det eneste i IT-avdelinger som er enda knappere enn budsjettet. NIS2 artikkel 21 trekker konsekvenser av denne praksisen: privilegerte identiteter må være isolert på en slik måte at kompromittering av dem ikke river hele infrastrukturen med seg, og den som likevel blir rammet, må være handlingsdyktig igjen i løpet av timer.
Hva NIS2 er og hvem direktivet gjelder for, forklarer vi her. På denne siden handler det om støtte til teknisk implementering av risikotiltakene med Managed Red Tenant og Managed Dark Tenant.
Managed Red Tenant: slik at en kompromittert konto ikke blir hovednøkkelen
Angrepsmønsteret som fungerte i Stryker-hendelsen er ikke nytt: angripere kompromitterer en konto som gir dem tilgang til privilegerte systemer, beveger seg derfra til resten av infrastrukturen og påfører den skaden de har flest rettigheter til. Det fungerer så pålitelig fordi det i de fleste bedrifter ikke finnes noen strukturell separasjon mellom normale arbeidsmiljøer og de administrative tilgangene som faktisk ville være tilstrekkelige til å overta hele infrastrukturen.
Managed Red Tenant bryter dette mønsteret ved å flytte administrative identiteter og tilhørende endeenheter til en fullstendig separert Microsoft-tenant, med egne Entra ID-kontoer, egne herdede enheter og ingen nettverksforbindelse til produksjonsmiljøet som en angriper kan utnytte gjennom lateral movement. Den som fra en kompromittert standard arbeidsplass forsøker å arbeide seg frem til de kritiske systemene, møter her en grense som ikke fantes før.
Til Managed Red Tenant
Managed Dark Tenant: det forberedte miljøet for situasjonen som ikke skal inntreffe, men kan
Etter et omfattende ransomware-angrep deler problemene et selskap må håndtere seg i to kategorier: de tekniske, som lar seg løse, om enn ikke raskt, og de organisatoriske, der ingen på forhånd har fastsatt hvem som gjør hva i en krisesituasjon, i hvilken rekkefølge beslutninger tas, og på hvilket grunnlag det i det hele tatt er mulig å kommunisere når den egne infrastrukturen ikke lenger er til å stole på. Coveware måler den gjennomsnittlige nedetiden etter et ransomware-angrep til 24 dager, og erfaringer fra virkelige hendelser viser at tidsbruken ikke først og fremst skyldes mangel på tekniske midler, men at prosesser man aldri trenger i normal drift, må oppfinnes for første gang under ekstremt press.
Managed Dark Tenant er et forhåndsklargjort, fullstendig isolert Microsoft-miljø som i en krisesituasjon aktiveres via en 24/7-hotline og som stiller einsatsbereite Kommunikation, Windows 365-arbeidsplasser og en AD-recovery-pipeline til rådighet for kriseteamet i løpet av få timer, alt basert på Infrastructure as Code, alt allerede definert og testet før det trengs. Arkitekturprinsippet bak heter Minimum Viable Company: kommunikasjon først, deretter kritiske dokumenter, deretter kjerneapplikasjoner, i en rekkefølge som er fastsatt på forhånd og jevnlig øvd gjennom fire drills.
Til Managed Dark TenantVi støtter den tekniske implementeringen
| 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 tjenester, ett svar på NIS2 artikkel 21
Managed Red Tenant
Privilegerte identiteter og endeenheter i en fullstendig separert Microsoft-tenant uten nettverksforbindelse til produksjonsmiljøet. Ingen lateral movement, ingen kompromittert standardkonto som blir hovednøkkelen.
Managed Dark Tenant
Et forhåndsklargjort, isolert Microsoft-miljø som i en krisesituasjon aktiveres via en 24/7-hotline. Kommunikasjon, Windows 365-arbeidsplasser og AD-recovery-pipeline er definert og testet før de trengs.
MRT og MDT sammen
Red Tenant reduserer sannsynligheten for at et angrep rammer hele infrastrukturen. Dark Tenant reduserer nedetiden hvis det likevel gjør det. NIS2 hit eller dit: begge deler sammen gir mening uavhengig av regulatorisk press.
Mer om temaet
Admin og hverdag på samme maskin? Game Over.
Hvorfor én tenant ikke er nok for CIO-er, og hvorfor den andre sjelden blir tenkt på. Managed Red Tenant skiller ...
