Is OCSF de sleutel tot democratisering van data lakes voor beveiliging?

Beveiligingsgegevens verzamelen en analyseren kost veel tijd en resources, maar het Open Cybersecurity Schema Framework (OCSF) wil daar verandering in brengen. Dit is wat het Salesforce DnR-team vond toen ze het OCSF uitprobeerde.
Is OCSF de sleutel tot democratisering van data lakes voor beveiliging?

Er is coördinatie nodig tussen veel verschillende beveiligingstools om de huidige cyberaanvallen te detecteren en stoppen. Helaas zijn de tijd en resources die het het team kost om deze beveiligingsloggegevens samen te voegen, geaccepteerde kosten voor het uitvoeren van de analyses die nodig zijn om potentiële aanvallen uit te roeien. Het Open Cybersecurity Schema Framework (OCSF)-project wil daar verandering in brengen zodat teams minder tijd hoeven te besteden aan analyseren en meer aan het beschermen van hun omgevingen. Laten we eens kijken naar wat deze nieuwe aanpak zo belangrijk en tijdig maakt.

Om beveiligingslog-eventgegevens zinvol te laten zijn, moet elk log een schema hebben dat de velden definieert die beschikbaar zijn voor zoeken, verzamelen of detecteren bovenop het log. Een log van netwerkverbinding zou bijvoorbeeld een bron-IP kunnen hebben dat de verbinding tot stand bracht, en een doel-IP dat het verzoek ontving en dit beantwoordde — het schema zou velden als src en dest hebben zodat beveiligingsanalisten weten dat ze query's rond die velden kunnen maken.

Er is echter weinig overeenstemming tussen logtypes of tools voor deze schema's. Met hetzelfde voorbeeld haalt CrowdStrike de IP-bron in netwerklogs eruit als ip en het IP-doel als RemoteAddressIP4. PAN Firewalls noemen de bron-IP src en de doel-IP dst. Sommige logs zijn compleet ongestructureerd en de bron- en doel-IP kunnen enkel worden bepaald door het logformaat en de locatie van de IP vanuit het logevent te doorgronden. 

Vaak willen analisten query's maken over grote subsets van logs. Ze willen bijvoorbeeld weten of in alle netwerklogs een host ooit verbinding heeft gemaakt met een bepaald IP-adres. Hiervoor hebben we voor elk logtype een schema nodig en deze schema's moeten ook overeenkomen. Was er maar een betere manier om gegevens op te nemen en te analyseren zonder handmatig zo veel moeite te moeten doen.

De uitdagingen van lognormalisatie

Tot nu toe heeft Salesforce dit aangepakt met een complexe, interne oplossing genaamd 'Events Data Dictionary' (DDI), die elk veld in elk logboek opsomt, en we hebben regels voor het extraheren van gegevensvelden (DFE's) gedefinieerd die de logs parsen en het woordenboek als schema gebruiken. In de detectie- en reactiearchitectuur vindt dit proces plaats in een systeem genaamd de 'Normalizer'. 

Na de normalisatie hebben alle logs, waaronder voorheen ongestructureerde logs, overeenkomende schema's en een set velden waarmee we query's kunnen uitvoeren. We extraheren RemoteAddressIP4 in CrowdStrike-logs en hernoemen het naar IPDestination, net als dat 'dst' van PAN-logs wordt hernoemd naar IPDestination. Analisten kunnen, als ze willen zien of er verbinding is gemaakt met een bepaald IP-adres, eenvoudig query's schrijven door alle logs te onderzoeken en vragen waar IPDestination == [...].

Dit is ideaal! Analisten kunnen zoeken. Lognormalisatie kent ook zijn eigen uitdagingen:

  1. Er zijn honderden velden in het gegevenswoordenboek, waarvan er veel 'NULL' zijn en dus veel ruimte innemen.
  2. Wanneer we een nieuw logtype krijgen, kunnen velden afwijken van wat we eerder hebben gedefinieerd en zo randgevallen genereren (gebruiker, gebruikersnaam en gebruikerse-mail betekenen afhankelijk van het logtype iets anders).
  3. We moeten handmatig elk nieuw logtype of sublogtype parsen als onderdeel van het onboarden van een nieuwe logbron door regex- of parsingregels te schrijven.
  4. Elke wijziging in de logstructuur, toevoeging of vervanging van velden kan ertoe leiden dat de bestaande regels de relevante velden niet parseren. Dit is een groot probleem voor de gegevenskwaliteit.
  5. Er is bovendien geen goede manier om de regels op schaal te valideren of bij te houden. Het is zeer waarschijnlijk dat de regels worden gekopieerd; het is een uitdaging om de regels te behouden of bij te werken, omdat het afschaffen van regels een aanzienlijk risico met zich meebrengt. Dit kan tot regressies leiden waarbij nieuwe regels de functionaliteit van de oude regels overschrijven.

Al dit werk gaat gepaard met kosten die steeds hoger worden. In plaats van zich hoofdzakelijk te richten op het detecteren van en reageren op events, besteden teams veel tijd aan het handmatig normaliseren van deze gegevens als voorwaarde.

OCSF-invoering

Het Open Cybersecurity Schema Framework (OCSF), dat bij BlackHat (augustus 2022) openbaar is gemaakt als een standaard voor open schema's, is een eerste-van-zijn-soort project, een aanzienlijke inspanning om gegevens over meerdere cybersecurity-bronnen te generaliseren. Dit framework streeft ernaar een vereenvoudigde en leveranciersonafhankelijke taxonomie te leveren dat alle beveiligingsteams helpt om betere en snellere gegevensopname en -analyse te realiseren zonder de tijdrovende normalisatietaak die eraan vooraf gaat. 

Het doel is om een open standaard te hebben die kan worden ingevoerd in elke omgeving, elke toepassing en elke oplossingsprovider die past bij bestaande beveiligingsstandaarden en -processen. OCSF is een open-source framework dat vergelijkbaar is met onze gegevenswoordenboek-aanpak in de zin dat het tot doel heeft het initiële probleem als hierboven omschreven op te lossen en ook de pijnpunten aan te pakken die voortkomen uit onze aanpak door een subset aan velden te definiëren die geschematiseerd moeten worden op basis van gebruik door analisten.

Onze Chief Trust Officer, Vikram Rao, vertelde: "Elk bedrijf wordt geconfronteerd met de noodzaak om snel digitaal te gaan. Maar het kan een behoorlijke uitdaging zijn om een beveiliging op te bouwen die voldoet aan de online niveaus van digitaal vertrouwen. Nieuwe standaarden als OCSF verminderen de complexiteit voor beveiligingsteams, waardoor ze kunnen focussen op meer impactvol werk zoals bedreigingsanalyses en aanvalspreventie."

De test

Het engineeringteam voor detectie en respons van Salesforce beoordeelde OCSF, waarbij het overwoog om zowel dit schema te handhaven op gegenereerde logs van Salesforce als onze huidige aanpak van normalisatie aan te passen om logs uit te voeren met de door OCSF gedefinieerde schema's, in plaats van onze aangepaste gedefinieerde schema's van het Events Data Dictionary.

Om OCSF beter te begrijpen, hebben we eerst een oefening gedaan om een hypothetische beveiligingsdetectiegebeurtenis van Salesforce om te zetten in een OCSF-formaat en om te evalueren. Hieronder volgen de schermafbeeldingen van de gebeurtenis in ons huidige DDI-formaat versus OCSF-formaat. 

image
Salesforce beveiligingsgebeurtenis - DDI geschematiseerd
image
Salesforce beveiligingsgebeurtenis - OCSF geschematiseerd

Terwijl we aan deze oefening werkten en het OCSF-schema verkenden, vonden we interessante velden die we mogelijk kunnen gebruiken; het herstel-object bijvoorbeeld, dit veld helpt bij het koppelen van de Knowledge base-artikelen, de beschrijving die handig kan zijn voor de analisten downstream bij het in kaart brengen van incidenten en hen helpen om tot verdere actie over te gaan.

We hebben een vliegende start gemaakt door met interne teams en prototypes te werken, de transformatie van onze interne toepassingslogs 'sfdc_applog' te evalueren, om uiteindelijk OCSF-compatibele logproducenten te worden. We streven naar een voortdurende samenwerking waarbij we vooruitgang willen boeken. Wilt u samenwerken en dit schema gebruiken om uw logs te standaardiseren? Ga aan de slag en splits de OCSF-GitHub [hier].

Een groot compliment

Het Open Cybersecurity Schema Framework-project, bedoeld om gegevensclassificatie te vereenvoudigen in een leveranciersonafhankelijk framework zodat beveiligingsteams minder tijd besteden aan het normaliseren van gegevens en meer aan verdediging, verdient een applaus. Het OCSF omvat bijdragen van Cloudflare, CrowdStrike, DTEX, IBM Security, IronNet, JupiterOne, Okta, Palo Alto Networks, Rapid7, Salesforce, Securonix, Sumo Logic, Tanium, Trend Micro en Zscaler.

Wij, bij Salesforce, zijn enthousiast en zijn tevens early adopters van OCSF. Deze eerdere oefeningen die we hebben uitgevoerd om onze belangrijkste logtype-gebeurtenissen om te zetten in OCSF, waren een goede eerste stap en hielpen verschillende interne teams onboard om het framework en de locatie ervan te leren kennen. Gezien het feit dat OCSF de open standaard en de gezamenlijke inspanning is in de beveiligingsindustrie, met meerdere belanghebbenden die de standaard invoeren en helpen ontwikkelen, heeft het potentie om data lakes voor beveiliging in alle organisaties te democratiseren.

Om ervoor te zorgen dat OCSF de grootste invloed heeft, hebben we ten slotte cloudproviders en beveiligingsleveranciers nodig om logs in het OCSF-schema op elkaar af te stemmen en te verstrekken. Als dit in uw straatje past, help dan om grenzen te doorbreken en dit een standaard te maken in de beveiligingscommunity!

Aanbevolen verhalen