Är OCSF nyckeln till demokratisering av säkerhetsdatasjöar?
Att upptäcka och stoppa dagens cyberattacker kräver en samordning mellan många olika säkerhetsverktyg. Tyvärr är tiden och resurserna som teamen lägger ner på att förena dessa säkerhetsloggdata en accepterad kostnad för att utföra den analys som krävs för att utrota potentiella attacker. Syftet med projektet Open Cybersecurity Schema Framework (OSCF) är att ändra det så att team kan lägga mindre tid på att analysera och mer tid på att skydda deras miljöer. Låt oss ta en titt på vad som gör detta nya tillvägagångssätt så viktigt och angeläget just nu.
För att händelsedata för säkerhetsloggar ska vara användbara måste varje logg ha ett schema som definierar de fält som finns tillgängliga för sökning, aggregering eller detektering ovanpå loggen. Till exempel om en nätverksanslutningslogg har en käll-IP som initierade anslutningen och en destinations-IP som tog emot och betjänade ett svar på begäran, skulle schemat ha fält som t.ex. src and dest så att säkerhetsanalytiker vet att de kan ställa frågor kring dessa fält.
Det finns dock lite överensstämmelse mellan loggtyper eller verktyg för dessa scheman. Med samma exempel extraherar CrowdStrike IP-källan i nätverksloggar som ip och destinationen som RemoteAddressIP4. PAN Firewalls kallar käll-IP src och destinations-IP dst. Vissa loggar är fullständigt ostrukturerade och käll- och destinations-IP:erna kan endast fastställas genom att förstå loggformatet och platsen för IP:n inuti logghändelsen.
Ofta vill analytiker ställa frågor över stora underenheter av loggar. Till exempel kanske de vill veta (över alla nätverksloggar) om någon värd någonsin har anslutits till en viss IP-adress För detta behöver vi inte bara ett schema för varje loggtyp, utan även dessa scheman för att komma överens. Det finns inget bättre sätt att hämta in och analysera data med mindre manuell ansträngning!
Utmaningarna med loggnormalisering
Hittills har Salesforce löst detta med en komplex intern lösning som kallas "Events Data Dictionary" (DDI). Denna listar varje enskilt fält i varje enskild logg och vi har fastställt datafältsextraktionsregler (DFE) som analyserar loggarna och upprätthåller datakatalogen som ett schema. I detektions- och svarsarkitektur sker denna process i ett system som kallas "Normalizer"
Efter normaliseringen har har alla loggar, inklusive tidigare ostrukturerade loggar, matchande scheman och en uppsättning fält utifrån vilka vi kan ställa frågor. Vi extraherar RemoteAddressIP4 i CrowdStrike-loggar och ändrar namn till IPDestination (på samma sätt som dst från PAN-loggar ändras till IPDestination) och analytiker skriver helt enkelt frågor om de vill se till vilken en viss IP var ansluten genom att fråga alla loggar och fråga vilken IPDestination == [.. .
Fantastiskt, detta är jättebra! Analytiker kan söka. Men loggnormalisering genererar även deras egna utmaningar:
- Det finns hundratals fält i datakatalogen, varav många är NULL, vilket slösar mycket på utrymme.
- När vi får en ny loggtyp kan det hända att fält inte överensstämmer med vad vi tidigare har definierat och därmed generera konstiga gränsfall (t.ex. användare, användarnamn, användarpost beroende på att loggtyp betyder olika saker).
- Vi måste manuellt tolka varje ny loggtyp eller subloggtyp som en del av införandet av en ny loggkälla genom att skriva reguljära uttryck eller tolkningsregler.
- Eventuella ändringar av loggstrukturen, tillägg eller ersättning av fält, kan leda till att de befintliga reglerna missar att analysera relevanta fält. Detta är ett stort datakvalitetsproblem.
- Dessutom finns det inget bra sätt att validera eller hålla reda på reglerna i stor skala. Det är mycket troligt att reglerna är duplicerade. Det är krävande att underhålla eller uppdatera regeluppsättningen eftersom utfasning av regler medför en betydande risk. Detta kan leda till regressioner där nya regler skriver över gamla regelfunktioner.
Allt detta arbete har en ständigt växande kostnad. Istället för att i första hand fokusera på att upptäcka och reagera på händelser, lägger teamen tid på att manuellt normalisera denna data som en förutsättning.
Införande av OCSF
Open Cybersecurity Schema Framework (OCSF), offentligt aviserad som en öppen schemastandard på BlackHat (aug '22), är ett första projekt i sitt slag, ett omfattande försök att generalisera data över flera cybersäkerhetskällor. Syftet med detta ramverk är att leverera en förenklad och leverantörs-agnostisk taxonomi för att underlätta för alla säkerhetsteam att bättre inse snabbare dataintag och analys utan den tidskrävande normaliseringsuppgiften som annars behöver göras i förväg.
Målet är att ha en öppen standard som kan användas i alla miljöer, vilket program som helst och för vilken lösningsleverantör som helst, som passar in i befintliga säkerhetsstandarder och processer. OCSF är ett ramverk med öppen källkod som liknar vår datakatalogsmetod genom att den syftar till att lösa både det initiala problemet som beskrivs ovan, men även de smärtpunkter som uppstår från vårt tillvägagångssätt genom att definiera en delmängd av fält som ska schematiseras baserat på analytikers användande.
Vår Chief Trust Officer, Vikram Rao, säger"Varje företag står inför kravet att bli digitalt, snabbt. Men att skapa en säkerhetshållning som uppfyller nivåer av digitalt förtroende i internetskala kan vara en stor utmaning. Nya standarder såsom OCSF minskar komplexiteten för säkerhetsteam, vilket ger dem möjlighet att fokusera på ett mer effektfullt arbete såsom hotanalys och attackförebyggande.”
Testkörning
Salesforce detekterings- och responsteam utvärderade OCSF, både med hänsyn till att tillämpa det här schemat på Salesforce-genererade loggar och anpassa vårt nuvarande tillvägagångssätt för normalisering för att generera loggar med OCSF-definierade scheman, i stället för våra specialdefinierade scheman som kommer från händelsedatakatalogen.
För att förstå OCSF bättre, genomförde vi först en övning för att omvandla och utvärdera en hypotetisk Salesforce säkerhetsdetekteringshändelse till OCSF-format. Nedan visas skärmdumparna för händelsen i vårt nuvarande DDI-format jämfört med OCSF-format.
När vi arbetade med den här övningen och utforskade OCSF-schemat, hittade vi intressanta fält som vi potentiellt skulle kunna använda. T.ex. fältet åtgärdsobjektet som hjälper till att länka artiklarna i kunskapsbasen, beskrivningen som är till hjälp för analytikerna nedströms när de utreder incidenter och hjälper dem att vidta ytterligare åtgärder.
Vi har börjat med att arbeta med interna team och prototyper, och utvärdera omvandlingen av våra interna applikationsloggar sfdc_applog, för att så småningom bli OCSF-kompatibla loggproducenter. Vi ser fram emot att vara fortsatta samarbetspartners framåt. Om du vill samarbeta och använda detta schema för att standardisera dina loggar, kan du komma igång och dela OCSF GitHub [här].
Bra gjort!!
Projektet Open Cybersecurity Schema Framework, vars syfte är att förenkla dataklassificering i ett leverantörsneutralt ramverk för att hjälpa säkerhetsteam att lägga mindre tid på att normalisera data och mer tid på försvar, förtjänar en applåd. OCSF inkluderar bidrag från Cloudflare, CrowdStrike, DTEX, IBM Security, IronNet, JupiterOne, Okta, Palo Alto Networks, Rapid7, Salesforce, Securonix, Sumo Logic, Tanium, Trend Micro och Zscaler.
Vi på Salesforce tycker det här är mycket spännande och har använt OCSF under många år. Dessa tidiga övningar som vi utförde för att omvandla våra bästa loggtyphändelser till OCSF har varit ett bra första steg och har underlättat för olika interna team att känna till ramverket och var det finns. Eftersom OCSF är en öppen standard och möjliggör samverkan inom hela säkerhetsbranschen, med flera intressenter som antar standarden och hjälper den att utvecklas, har den en potential att demokratisera säkerhetsdatasjöar i alla organisationer.
För att OCSF ska få största möjliga effekt behöver vi dessutom molnleverantörer och säkerhetsleverantörer för att anpassa och tillhandahålla loggar i OCSF-schemat. Om du verkar inom denna bransch, ber vi dig hjälpa till med att bryta ner gränser och göra detta till en standard i säkerhetsgemenskapen!