Nyckelinsikter:

  • Du ska veta vilka mjukvaror som används 
  • Säkerställ att endast godkänd programvara kan installeras och exekvera
  • Använd dig av vitlistning för programvaror och skript
  • Integrera hårdvaruinventering med mjukvaruinventeringen
  • Utnyttja inventeringen även för licenshantering

Detta är ett onekligen ganska omfattande åtgärdsområde som inte är helt enkelt att införa. Vissa delar är relativt enkla, som att inventera installerade mjukvaror. Men svårighetsgraden ökar snabbt när vi ska börja agera utifrån den insamlade informationen genom att exempelvis införa vitlistning, eller använda signerade skript.

Likt föregående inlägg har jag skapat en uppdaterad CSF-profil som du kan använda för att strukturera och få en slags plan på införandet. 

Åtgärdsområdets målsättning

Den övergripande målsättningen med åtgärdsområdet är att ge dig en förmåga att på ett kontrollerat och säkert sätt hantera programvaror i din organisation. Inte alldeles enkelt om vi ska beakta alla nyanser av vad detta innebär.

Initialt handlar det om att identifiera mjukvara vilket ger förutsättningarna för att få koll på vilken mjukvara som finns men sedan för att kunna införa upptäckande (eng. detect) och hanterande (eng. respond) åtgärder.

Inom åtgärdsområdet finns det totalt 10 olika specifika åtgärder som tillsammans ger förmågan att Inventera och hantera mjukvarutillgångar.

Införande

Nytt för det här inlägget är ett ytterligare försök att strukturera införande och arbete med åtgärdsområdet. Jag har i det här inlägget valt att dela upp i ett antal steg, där det första steget avser att göra en enklare bedömning av mognad.

I steg 2 och 3 handlar det om arbetet med att införa åtgärder och i steg 4 mer om att mäta effektivitet.

Steg 1 – Avgör mognad

Nytt för det här inlägget är att jag vill introducera ett förslag på hur ni kan avgöra organisationens mognad inom ramen för aktuellt åtgärdsområde. Tanken med att introducera en mognadstrappa är att detta kan användas för att snabbt ge en övergripande bild av vilka förmågor som finns, eller skulle behöva prioriteras.

Det kan också användas som ett rapporteringsverktyg uppåt i kedjan för att kunna ge en hint om organisationens cybersäkerhet och förmåga att värja sig mot hot och hantera risker.

MognadsnivåKriteria
Ingen förmågaVi gör i princip ingenting inom åtgärdsområdet, det kan bara bli bättre.
Partiell förmågaNågra initiala åtgärder har införts och avser i huvudsak identifierande åtgärder. Vi använder ingen vitlistning av programvaror eller skript.
God förmågaVi har god koll på godkända programvaror, använder oss i huvudsak av vitlistning och har god koll på vilka enheter som har vilka programvaror.

Om ni gillar idéen av en mognadstrappa per åtgärdsområde kan jag se till att varje framtida (och existerande) inlägg får detta också. Jag sammanställer sedan dessa i ett separat inlägg/dokument som kan laddas ner för att göra en snabb kartläggning.

Steg 2 – Påbörja införande

Beroende på var ni befinner er i mognadstrappan har ni lite olika vägar att gå. Om området är relativt nytt skulle ni kunna börja med två aktiviteter:

  1. Beskriv övergripande hur ni avser hantera godkännande och övrig hantering av programvaror. Även om ni inventerar måste ni göra något med informationen som ni inhämtar. Syftet med den här aktiviteten är att bestämma vad ni vill göra med informationen ni inhämtar. Observera att denna dokumentationsövning även bör inkludera en lista på vilka programvaror som behövs av vilka affärsverksamheter.
  2. Påbörja inventering av mjukvara. Skaffa en programvara som låter er inventera och gärna styra godkännande av programvaror. Se gärna över möjligheten att låta den här programvaran kunna fungera i kombination med inventering av hårdvara.

Innan ni går vidare till steg 3 kan det vara vettigt att börja mäta införandet av dessa initiala åtgärder, se steg 4 för detta.

Steg 3 – Fortsatt införande

I detta steg är tanken att ni fortsätter införandet av övriga åtgärder som finns inom ramen för detta åtgärdsområde. De initiala åtgärderna avser som tidigare nämnt i huvudsak identifierande

  1. Agera på icke-godkända installationer av programvaror. Om ni inte redan förhindrar detta bör ni i det här steget se till att nya programvaror inte kan installeras hur som helst.
  2. Inför vitlistning av vilka applikationer som är möjliga att installera och exekvera.
  3. Signera skript för att säkerställa att endast godkända skript får exekveras.

Steg 4 – Mäta effektivitet

När ni väl påbörjat arbetet med att etablera förmågan vore det på sin plats att försöka mäta hur pass effektiv den är. Mätning av de här specifika åtgärderna är svåra att koppla till hur exakt de bidrar till att påverka cybersäkerheten. Det är antagligen bättre att se till hur förmågan i sin helhet bidrar till ökad cybersäkerhet. Framförallt skulle jag säga att förmågan att veta vilka programvaror som finns, vilka versioner som används är särskilt användbart för exempelvis sårbarhetshantering.

  1. Har organisationen förmåga att identifiera och inventera installerade programvaror?
  2. Hur lång tid tar det för organisationen att upptäcka installation av nya programvaror?
  3. Har organisationen förmåga att avgöra vilka programvaror som är nödvändiga för verksamheten och inte?
  4. Hur lång tid tar det att godkänna en ny programvara?
  5. Hur många otillåtna programvaruinstallationer sker varje dag?
  6. Har organisationen förmåga att hantera icke-godkända programvaror?

Sammanfattning och nästa inlägg

Lite ny struktur på det här inlägget, och ett nytt avsnitt genom mognadstrppan. Är den vettig? Saknar ni något som skulle vara smutt att få med i framtiden? Målsättningen är att inläggen inte bara ska översätta text utan faktiskt tillföra lite struktur och förslag på genomförande. Saknar ni detaljer, eller hamnar det på rätt nivå?

Oavsett ytterligare en åtgärd avklarad, åtminstone för min del. Det stora arbetet ligger ju faktiskt hos er att bedriva arbetet med att införa åtgärderna. Det kan vara vettigt att låta någon rådgivare inom cybersäkerhet dra i koordinationen, men säkerställ att det är ni själva som gör det faktiska jobbet. Rådgivaren ska trots allt bara betraktas som ett oberoende bollplank och någon som kan styra upp om det blir knepigt.

I nästa inlägg kommer vi avhandla Kontinuerligt hantering av sårbarheter. Ses då!