Detta är en artikel om CIS-kontrollerna, version 7 och i den här artikeln kommer du få läsa om Skydd mot skadlig programvara. Ett angrepp i cyberdomänen kommer högst sannolikt innebära någon form av skadlig kod. Det är nästan svårt att föreställa sig ett angrepp utan skadlig programvara vilket också är anledningen till varför skyddet mot skadlig programvara är så viktigt.
Nyckelinsikter
- Skyddet mot skadliga programvaror är omfattande och samtidigt väldigt viktigt. Underskatta inte omfattningen.
- Operativsystemen blir bättre, utnyttja deras inbyggda funktioner och konfigurera allt som går att konfigurera. Ni har det trots allt redan installerat…
- Säkerställ att löstagbara medier inte har möjlighet att automatiskt exekvera program.
- Åtgärden behöver en mer omfattande och djupgående artikel…
Inledning
Jag har valt att göra en enklare förändring i den här artikeln under avsnittet för att påbörja införandet. Där har jag inkluderat en punktlista för exakt vilka åtgärder som CIS-kontrollerna föreslår. Jag tidigare utelämnat dessa eftersom jag inte alltid tycker de är särskilt vettiga, men samtidigt tar det inte särskilt lång tid att skriva en liten lista så att du som läser får en mer komplett bild av CIS-åtgärden.
Vettigt eller ej? Jag vet inte, men hör av er om det borde finnas i alla artiklar.
Skadlig kod och Skadliga programvaror
På svenska säger vi gärna skadlig kod och är en översättning av engelskans malicious code. Namnet på åtgärden i CIS är malware defenses och avser skydd mot skadlig programvara, malicious software (malware). Jag är nog dessvärre ganska slapp i min egen användning av olika begrepp som virus, trojaner, skadlig kod osv. Jag blandar skadlig kod och skadlig programvara, när jag egentligen tycker att det finns en väsentlig skillnad mellan dessa klassificeringar.
Det finns alltså några distinktioner jag tycker är väsentliga att snabbt avhandla. På ett övergripande plan kan vi dela upp enligt nedan:
- Skadlig kod
- Skadlig programvara
Skadlig kod
Skadlig kod användas för att beskriva angrepp där just “tolkningen” av koden leder till problem, tänk XSRF, XSS eller SQL-injection. Det är först när koden ska läsas av en interpreter som problemet uppstår genom exempelvis otillräcklig filtrering av indata. Du skyddar dig från skadlig kod genom ordentlig datavalidering.
Sedan skulle vi kunna diskutera om huruvida det är nödvändigt att separera skadlig kod från skadliga data. Jag tänker nog personligen att det inte är nödvändigt, men det kanske finns tillfällen då distinktionen är nödvändig och föranleder olika typer av åtgärder. Eller?
Skadlig programvara
Skadlig programvara är kompilerade (C/C++ etc.) program där det huvudsakligen är programmets programmerade funktioner som är “skadligt”, byte-kod kompilerade program eller scriptade program (Python, Bash, PowerShell). Du skyddar dig mot skadlig programvara genom klassificering och analys av beteenden.
Ett PowerShell-script anser jag exempelvis bör betraktas som skadlig programvara eftersom du inte använder funktioner som “data-validering” eller “tvätt” på PowerShell-script.
Nå väl. Jag gör skillnad på skadlig kod och skadlig programvara även om jag slarvar med begreppen i samtal med kollegor.
Om CIS-åtgärden
Åtgärden består av totalt åtta åtgärder och omfattar följande:
- installera en centralt administrerad AV-produkt.
- Därefter ska ni säkerställa att signaturerna uppdateras.
- Sedan går ni över till operativsystemet och utnyttjar alla de funktioner som finns där, DEP, Application Guard, EMET osv.
- Säkerställ att lagringsmedier som USB-stickor och annat krimskrams skannas när det pluggas in i datorn.
- Säkerställ att “autorun”-innehåll inte fungerar.
- Skicka larm till central loggning
- Slå på DNS-loggning
- Slå på loggning av command line. (Tänk PowerShell-loggning!)
Givetvis är ingen av dessa åtgärder särskilt snabba eller överhuvudtaget enkla att införa, men där har du dom. Jag väljer att skriva lite om några av dessa.
Åtgärdsområdets målsättning
Förhindra att skadlig programvara kommer in, exekverar, sprider sig och fungerar. Målsättningen med åtgärdsområdet är alltså att stoppa skadliga programvaror. Det finns inte så mycket mer att säga. Stoppa skadliga programvaror, stoppa intrång.
Införandet
Ett skydd mot skadlig kod och skadliga programvaror är egentligen väldigt mycket mer än att varje klient har ett skydd. När ett larm genereras om att skadlig kod upptäckts kan det kanske kännas skönt. Jag skulle bli nervös. Jasså? Hur länge har den funnits där? Vad har den gjort? Osv. Larm om skadlig kod kan bli första steget i en större incidentutredning om ett pågående intrång.
Så, för att införa ett skydd mot skadlig kod och skadliga programvaror börjar vi med att avgöra mognaden… som vanligt.
Steg 1 - Avgör mognad
| Mognadsnivå | Kriteria |
|---|---|
| Ingen förmåga | Sporadiskt installerade produkter, ingen central styrning eller koll på signaturer uppdateras. |
| Partiell förmåga | Centralt styrd, signaturer uppdateras ofta, vi samlar in larm centralt men borde göra mer. Termer och begrepp som EMET, Application Guard, ASLR, DEP är vi bekanta med… men borde göra mer. |
| God förmåga | Larm skickas till vår SIEM, vi utreder varje larm, använder oss utav detonationskammare för potentiellt skadlig kod och, följer noga utveckling och trender inom skadlig kod. Vi kan bli bättre, men den lågt hängande frukten har vi tagit bort. |
Steg 2 - Påbörja införande
Något som kanske är att slå in öppna dörrar men som jag ändå måste få rekommendera är att ni först och främst sonderar terrängen. Marknaden utvecklas, tekniker förbättras och produkter åldras. Här följer några saker att fundera över innan ni skaffar eller byter produkt
- Hur passar skyddsåtgärden in i er övriga säkerhetsarkitektur?
- Vilka andra åtgärder har ni som skyddar mot skadlig kod och vilket eventuellt överlapp får ni med ytterligare en produkt?
- Vilka andra eventuella säkerhetsprodukter behöver den här produkten integrera med?
- Har ni ett SIEM och vilka eventuella krav ställer den på ingestion?
- Har ni en produkt för säkerhetsorkestrering som den behöver integrera med? Vilka API:er finns tillgängliga då?
- Vilka funktioner är det ni egentligen behöver?
- On-prem administration eller cloud?
- STIX/TAXII-stöd?
- Vad behöver ni stöd för?
- Serverless-infrastruktur, cloud, servrar, klienter?
- Fundera en extra gång på hur verksamheten ser ut idag, och vart ni är på väg.
Steg 3 - Mäta effektivitet
Jag har sagt det så många gånger, men jag säger det igen. Att mäta säkerhetseffekt är svårt… men jag försöker ändå. Här är några förslag på hur ni mäter effekterna av er lösning:
- Upprätta en basnivå, hur många larm genererar ni idag per månad/kvartal? Gör gärna detta INNAN ni köper en ny lösning.
- Efter ny lösning, hur många larm genererar ni nu per månad/kvartal?
- Av antalet genererade larm, hur många har visat sig vara falska?
- Hur många larm är kopplade till löstagbart lagringsmedia? Hur ser det ut, relativt, andra larm?
Sammanfattning
Att införa ett skydd mot skadliga programvaror och skadlig kod är ett omfattande arbete om det ska göras ordentligt. För att kunna maximera nyttan behöver många andra säkerhetsrelevanta förmågor finnas på plats som t.ex. en SOC och incidentutredning. Vidare kanske ni vill integrera produkten i serverparken som finns i molnet, eller i någon slags hybridlösning.
Påminn mig att det här området förtjänar en längre och mer omfattande, och detaljerande artikel. En mer djupgående artikel om hur utvecklingen ser ut på området och vilka tekniska framsteg som gjorts. Det kanske vore på sin plats med något sådant?