Detta är en artikel i en serie om CIS Controls version 7 och denna artikel handlar om förmågan att etablera åtkomstkontroll enligt need-to-know principen. Målsättningen är att behöriga har åtkomst till exakt den information, system eller resurser som denne behöver för att utföra sina arbetsuppgifter.

Nyckelinsikter

  • Det är nödvändigt att känna till vilka känsliga system, information eller andra tillgångar du har i verksamheten.
  • Börja enkelt genom att exempelvis begränsa klienter från att prata med klienter.
  • Upprätta zoner som motsvarar känsligheten i en given informationsmängd eller system. Styr åtkomst med hjälp av dessa zoner.

Inledning

Åtgärd nummer 14 av totalt 20. Vi börjar närma oss “slutet” och i denna omgång behandlar vi “åtgärden” för att uppnå åtkomstkontroll enligt need-to-know. Detta är ingen enkel åtgärd att införa även om vissa mekanismer inte är särskilt komplicerade att införa (t.ex. inventering av känsliga system). Men ska CIS-åtgärden implementeras till fullo enligt vad de menar är åtgärden (totalt 9 områden) med stor variation på komplexitet och omfattning. Detta är en utmanade åtgärd helt klart.

Mycket nöje!

OM CIS-åtgärden

Inom ramen för åtgärden, eller mer förmågan, finns det totalt 9 skyddsåtgärder:

  1. Segmentera nätverket baserat på informationens känslighet.
  2. Använd brandväggar för att styra åtkomst mellan VLAN.
  3. Förhindra klient-till-klient kommunikation.
  4. Kryptera all känslig information vid transport.
  5. Använd ett verktyg för att identifiera känslig information och data.
  6. Använd ett behörighetskontrollsystem.
  7. Tvinga åtkomstkontroll till data/information med hjälp av automatiserade verktyg.
  8. Kryptera all känslig information vid “vila”.
  9. Tvinga detaljerad loggning för åtkomst, ändringar i känsliga data/information.

Dessa 9 åtgärder beskrivs i mer detalj i källdokumentet och jag väljer att inte översätta dessa texter.

Åtgärdens målsättning

Uppnå ett tillstånd i vilket endast behöriga har åtkomst till de system, information och data som de behöver för att utföra sina arbetsuppgifter.

Införandet

Åtkomstkontroll baserat på “need-to-know” är i min värld en princip. Detta innebär att införandet egentligen är väldigt omfattande, och definitivt inte något som är särskilt enkelt.

Steg 1 – Avgör mognad

MognadsnivåKriteria
Ingen förmågaNeed-to-know vad sa’ru? Nej, alltså vi behöver ju jobba.
Grundläggande förmågaVi klassar information och data, och placerar känsligare system i egna VLAN. Klienter kan fortfarande prata med andra klienter. Våra backuper är däremot krypterade!
God förmågaVarje system har eget VLAN, och klienter kan endast prata med andra system, inte andra klienter. Lateral movement … inte här. Vi använder administrativa “hopp”-servrar för att administrera system i nätverket, aldrig från klienter.
GudomligLapadula, no-read/write-up/down, MLS, CC EAL7 etc. Bygger vi, så bygger vi rätt från början. IPsec mellan varje nätverksnod, ja du fattar. Vi kan det här.

Steg 2 – Påbörja införande

Även om CIS-åtgärden vill få need-to-know att vara en åtgärd så är det en princip. Det är något som måste genomsyra hela organisationen och det är inte enkelt på något sätt. Givetvis behöver det inte vara allt eller inget, så det blir vår vägledande princip här.

  1. Börja med att separera klienter från klienter, låt dem inte kunna kommunicera med varandra. Inom ramen för zero-trust architecture är detta ett fundament. Det kommer vara ett bra sätt att förhindra angripare från att förflytta sig sidledes i nätverket.
  2. Därefter kan ni se till att placera känsligare system i en mer “kontrollerad” zon, kanske genom användandet av VLAN. Detta förutsätter givetvis att ni vet vilka system som är känsliga och därefter relativt smärtfritt faktiskt kan separeras från övriga. Eller om ni kanske föredrar IPsec-tunnlar till dessa. I Microsoft världens fanns (kanske fortfarande) konceptet om server and domain isolation (SDI).
  3. (Avancerat). Fundera på att införa XACML 3.0. Detta skulle ge er en framtida förmåga att separera policy-administration från den logiska åtkomstkontrollen och “punkten” för att besluta om en begäran ska tillåtas eller inte.
  4. (Avancerat). Kravställ vid nyutveckling av känsliga system att de ska implementera mekanismer för att implementera en slags lightweight-version av Lapadula MAC. Detta skulle innebära att systemet får tämligen granulära konfigurationsmöjligheter avseende behörighetsstyrning. Roller, självklart, men även saker som att en användare aldrig ska kunna läsa en känslighetstyp och skriva den till en typ av lägre klassificering (no-write-down-regeln).

Steg 3 – Mäta effektivitet

Nej, jag säger det inte igen… jo, det gör jag. Det är svårt att mäta effektivitet på den här nivån.

  1. Här får det lov att bli lite nytänk. Bestäm er för hur många “åtgärder” som skulle kännas som att ni nått en jäkligt bra nivå, säg 8 st (vilka lämnar jag osagt).
  2. Utred om det för varje åtgärd kan finnas en “nivå” av klar. Kanske finns det typ någon grundläggande förmåga och sedan utökad. NI bestämmer. Men vi säger att det finns tre nivåer; ingen, grund och utökad.
  3. Nu etablerar ni en basnivå. För varje åtgärd enligt punkt (1) bestämmer ni var ni ligger enligt punkt (2).
  4. Voila, detta är er mognad och effektivitet. Ni skulle kunna säga att effektiviteten är 100% när ni har implementerat samtliga åtgärder enligt högsta nivån.

Givetvis inte en optimal effektivitetsmätning, men åtminstone något som är rimligt och genomförbart.

Sammanfattning

Införandet av åtkomstkontroll enligt need-to-know principen är inte särskilt enkelt. CIS-åtgärden vill att det ska handla om kryptering och inventering av känsliga informationsmängder, det kan vi diskutera. Men faktum är att principen/åtgärden är eftersträvansvärd. Att arbeta för att åtkomst till information, system eller andra resurser baseras på att du behöver den för ditt arbete är självklart något bra.