En teknisk tilgang til forebyggelse af datatab (Data Loss Prevention-DLP)
Indholdsbevidsthed i forebyggelse af datatab. Teknikker og fælles praksis.
This post is also available in:
English
For nogen tid siden skrev jeg en artikel om, hvordan du vælger den bedste løsning til forebyggelse af datatab til din virksomhed. Åbenbart havde jeg ikke haft chancen for at gå ind i for mange tekniske detaljer; desto mere grund til at vende tilbage til et emne, der har udløst mere forvirring end hele coronaviruspandemien. Så fordi ord er billige, så lad os komme i gang. Før det, er her et lille smugkig på dagens agenda – Jeg vil diskutere indholdsanalyseteknikker, dataarkitektur, klassificering og politikstyring. Nyd det!
(Re-)Definition af forhindring af datatab (DLP)
SANS Institute’s artikel nævner om forebyggelse af datatab, at DLP-markører er en af de mindst forståede” og “hypede”. Godt ordvalg fra hvor jeg står, da der er mindst fem forskellige navne til at beskrive det samme produkt; min all-time favorit er “extrusion forebyggelse”. Nu må vi, for at indkapsle alle de punkter på vores liste du jour, blive nødt til at justere definitionen.
Så Forhindring af datatab henviser ikke til en, men til en hel produktfamilie, der er designet til at klassificere, beskytte og overvåge data, uanset form, indhold og status (dvs. i brug, i hvile eller i transit). Alle disse operationer udføres ved hjælp af foruddefinerede og centraliserede politikker og dybdegående indholdsanalyseteknikker.
Der har du det – en DLP-løsning skal ‘police’ datastrømme og markere eventuelle politikovertrædelser. Lyder ret ligetil, gør det ikke? Der er ikke noget let eller ligetil, når det kommer til databeskyttelse. Forhindring af datatab som disciplin bruger kontekst- og indholdsbaserede inspektionsteknikker til at identificere eventuelle sikkerhedsbrud. Indholdsbaseret inspektion, der også omtales som dyb indholdsanalyse, er en metode, der bruges til at lokalisere politikovertrædelse, der er låst til flerlagsfiler.
Et eksempel på CBI (indholdsbaseret inspektion (eng: content-based inspection)) ville være ‘at se’ inde på docx-fil, der tidligere er knyttet til en .csv eller .xls fil. Hvad med en arkiveret .pdf fil? Dybe-scanningsteknologier, også nogle vi vil diskutere i denne artikel, bruges til at opnå den førnævnte opgave. Til hvorfor indholdet er relevant i DLP, vil jeg sige dette – Uden det, ville det være næsten umuligt at afgøre, om der er nogen politikovertrædelser.
Okay, men indholdet er intet uden kontekst. Hvad kan passere som en “kontekst” i en DLP-indstilling? Her er et eksempel. Brug af et betalingskort til at foretage et køb fra din arbejdsstation bør straffes. Det minder dig om dit første job, ikke? Denne sætning kan omdannes til en centraliseret politik.
Åbenbart er formuleringen lidt vægende- hvorfor forbyder virksomheden dette? Henviser dette til en personligt eller et firmaudstedt betalingskort? Hvilken slags køb dækker denne politik? Hvad er straffen? Som De tydeligt kan se, gør den manglende sammenhæng det ganske vanskeligt at håndhæve politikken. Lad os mixe tingene lidt op – det der er forbudt og derfor bør straffes, er brugen af klientregistrerede betalingskort for at gennemføre personlige transaktioner på en firmaudstedt maskine.
Nu begynder det at give mere mening, ikke? Lad os mixe tingene lidt igen – hvad ville den alvidende og almægtige DLP sige, hvis en medarbejder ville forsøge at bruge en kundes tidligere registrerede betalingskortoplysninger (dvs. kortnr., navn, udløbsdato, CVV-kode) til at købe en PS5 til sit barn eller et større Android TV?
Det skal lyse op som et juletræ, hvis sikkerhedspolitikken er sat rigtigt op. Som du tydeligt kan se, kontekst er afgørende – at købe personlige ting fra din arbejdsstation er okay, men ved hjælp af en andens finansielle oplysninger gør det dét til en stor no-no. Kontekst er afgørende i DLP, men desværre er det ikke formålet med denne artikel.
Lad os dog tackle indhold og indholdsbaserede teknikker. Spejling af e-mail-sikkerhedsløsninger, der anvender dyb indholdsscanning til at udrydde phishing-links, weaponized makroer og ondsindet kode, generelt vil en DLP-løsning kigge ind i alt, hvad der passerer inden for (og uden for) dit organisatoriske netværk. Der er naturligvis begrænsninger for denne dybe scanningsproces – for eksempel kan en løsning til forebyggelse af datatab ikke åbne en adgangskodebeskyttet fil.
Indholdsscanning opnås ved hjælp af forskellige teknikker – Regex eller regelbaserede og\eller regulære udtryk, DB-fingeraftryk (database fingeraftryk), EDM (eksakt datamatch), PDM (delvis dokumentmatchning), ML-medieret statistisk analyse, leksikon, kategorisering og Bayesian Network-modellering. Af indlysende, kortfattetheds-relaterede årsager, vil jeg i denne artikel, ‘kun’ dække EDM og Regex.
Indholdsbevidsthed i forebyggelse af datatab. Teknikker og fælles praksis.
Er du her stadig? Håber virkelig du er, fordi det er her det sjove begynder.
EDM (Exact Data Match)
Exact Data Match eller EDM er kort sagt en indholdsbaseret datamodelleringsteknik, der bruges til at identificere og klassificere BRUGERDEFINEREDE FØLSOMME OPLYSNINGER. I denne sammenhæng refererer følsomme oplysninger til en mønsterlignende datastreng, der kan forespørges ved hjælp af funktioner eller regulære udtryk. Vi vil tale mere om dem i afsnittet dedikeret til Regex.
I EDM kan brugerdefinerede følsomme oplysninger spores og klassificeres ved hjælp af midler som mønstre, nøgleord, konfidensniveau og nærheden af et tegn eller tegnsæt til et kendt mønster. For at illustrere, hvordan alt fungerer, så lad os se, hvordan en EDM-baseret DLP ‘læser’ fortrolige elementer. Som jeg har nævnt, hviler EDM på tillidsniveauer for at gøre en indholdsbevidst bestemmelse.
Microsoft anerkender tre lag af tillid: høj, medium og lav. Tænk på dem som følsomhedsniveauer. For præcist at opdage en type oplysninger i en e-mail, et dokument, en database, eller hvad som helst, har systemet brug for at vide to ting: et primært element og et understøttende element. Vi kan sige, at denne klassificerings bestræbelse har et højt tillids niveau, hvis det primære element har to eller flere understøttende elementer. Medium tillid har et enkelt støtteelement, og lav tillid har ingen.
Lad os forestille os, at DLP-kuratoren ønsker at skabe en politik, der drejer sig om kreditkortoplysninger. Denne politik kan tjene et vilkårligt antal formål – forhindre brugere i at dele kreditkortoplysninger via e-mail eller chat, tilsløre CVV’er eller kreditkortnumre, mens indkapslingsmediet er i transit eller i hvile osv. Skrivning af politik er en lille del, men hvordan kan du instruere systemet til at anerkende elementer der hører hjemme i finansielle instrumenter såsom debet-eller kreditkort?
Hver e-mail har nogle karakteristiske tegn: afsenderens felt, et emnefelt, meddelelsens brødtekst og lukningen. Ved hjælp af EDM ‘scanner’ systemet e-mailen for primære elementer. I forbindelse med finansielle instrumenter kan et primært felt være et søgeord som “kreditkort” eller “betalingskort”. Når det primære element er blevet identificeret, søger systemet efter understøttende elementer for at bestemme konfidensniveauet.
Lad os antage, at denne imaginære e-mail-brødtekst har et nøgleord/primært element kaldet “kreditkort” og tre understøttende elementer – et sekundært nøgleord kaldet “udløbsdato”, en numerisk streng bestående af 16 gentagne eller ikke-gentagne tal og en anden streng bestående af fire cifre adskilt af et skråstregssymbol.
Rollerne kan også vendes – for eksempel kan den 16-cifrede streng passere som det primære element og nøgleordet “kreditkort” som det understøttende element. Nu antages det, at systemet vil forsøge at beregne et mønster baseret på en foruddefineret ordbog (dvs. en lang liste over nøgleord, der er knyttet til vigtige oplysninger, der er kurateret af den implementerede DLP-løsning).
Mønster etablering kan gøres på mange måder, men kontaktfri er langt den mest effektive metode. Okay, så hvad er det for noget med kontaktfri? Hvis det primære element (nøgleords- eller cifferstreng) er tæt på de understøttende elementer (nøgleord eller sekundær cifferstreng), genkender systemet et af de mønstre, der er knyttet til kreditkortoplysninger.
Kom til at tænke over det, dette her er et skolebogseksempel på en if-do operationen – hvis mønsteret er anerkendt skal den derefter håndhæve politikken. I betragtning af at vi har et primært element, der støttes af tre sekundære, skal nettostyrken derfor være “høj tillid”.
EDMs kan “coaches” til at identificere mønstre i indholdstunge tilfælde. Lad os overveje følgende – et dokument indeholder mange eksempler på, hvad der kan opfattes som primære elementer. Kan systemet etablere et mønster? Svaret er “ja”, og her er hvordan:
Implementering af EDM har mange fordele:
- Færre falsk positive resultater, når der forespørges i store databaser.
- Højt skalerbarhedspotentiale.
- EDM kan bruges med de fleste cloud-tjenester.
- Øget dynamik.
Opsætning af EDM er en trestrenget proces. Først skal du implementere den EDM-baserede klassifikation, en proces, der indebærer at give læse-type adgang til de følsomme data, der er gemt på serveren, oversætte databaseskemaet i et XML-format, oprette regelpakken i samme format og endelig angive administratortilladelserne via PowerShell. Det andet trin handler om hashing og upload af data.
For at beskytte privatlivets fred vil alle de data, der føres ind i DLP, være hashes. For at gøre det skal du oprette en sikkerhedsgruppe og UA, give lokal administrator adgang til maskinen, give læsetypeadgang til de nyudnyttede data og behandle de opdaterede data. Sidst – men ikke mindst – skal de analyserede oplysninger integreres med din DLP-løsning.
Da vi allerede har dækket fordelene ved EDM-baseret indholdsfiltrering, bør vi også sige et par ord om sandsynligvis den vigtigste faktor – dataeksport. EDM giver brugeren mulighed for at eksportere alle følsomme data til enhver app, der er knyttet til DLP-løsningen. Derudover kan disse filer gemmes i .csv eller .xls. Så hvad er fangsten? Nå, en enkelt .xls eller .csv fil kan understøtte op til 100 millioner rækker data, 32 felter pr. datasøgning, og op til fem kolonner hos brugeren kan øremærkes som søgbare.
Sådan arbejder EDM på et øjeblik. Hvis du er interesseret i EDM i din DLP, kan du se vores Microsofts tekniske vejledning til, hvordan du konfigurerer Exact Data Match med Office 365 E5.
Regulære udtryk (REGEX)
Denne indholdsbevidste teknik tager mig virkelig tilbage. Kan du huske dine første lektioner i databasemanipulation? Jeg ønsker ikke at sige, at jeg er så gammel, men tilbage i mine dage, plejede vi at skrive hele kommandolinjer til at forespørge et element i en meget, meget lille FoxPro DB. Tilbage til Regex – en forkortelse for regulære udtryk (eng. regular expression), regex er en streng af tekst, der giver brugeren mulighed for at etablere søgemønstre. Naturligvis vil disse mønstre hjælpe dig med at administrere tekst, finde elementer og matche bidder af data.
Mange programmeringssprog – for eksempel Pearl, – bruger regulære udtryk til datamanipulation. At beherske dem tager et stykke tid, fordi det er så tæt på statistikker, som du nogensinde kommer til at få, men teknikken alene er uvurderlig, især hvis du arbejder med store bidder af tekst. Den største fordel ved Regex er, at det kan bruges med stort set enhver teksteditor derude, herunder Notesblok. Hvordan ser Regex ud?
Til fremvisnings formål, vil jeg låne ComputerHope’s Regex e-mail eksempel. Her er det:
/[\w._%+-] +@[\w.-] + \.[a-zZ-Z]{2,4}/
Det ser ganske forvirrende ud, eller illustrerer hvad der ville blive vist på skærmen, hvis en kat gik over hele tastaturet. Tillad mig at bryde det ned for dig. Den omstændelige thingamajig fundet inden for de to “/” tegn er det udtryk, din maskine skal udføre, når du forespørger en tekst for udtryk eller primære elementer, der matcher mønstre, der er forbundet med e-mail-adresser. Vi kan nedbryde det endnu mere:
- Argumentet [\w._%+-] instruerer computeren i at matche alle typer tegn, der findes i kantede parenteser.
- Argumentet \w, der blev fundet i begyndelsen af de kantede parenteser, vil instruere maskinen i at matche almindelige alfanumeriske tegn. Dette omfatter bogstavet fra A til Z (både store og små bogstaver) og et vilkårligt tal fra 0 til 9.
- Argumentet “+”, der blev fundet før “@”-tegnet, vil instruere maskinen i at matche så mange gange som muligt. Naturligvis vil “@” matche alt, der indeholder symbolet “@”. Det samme gælder for periodesymbolet.
- Argumentet “[a-zZ-Z]” vil instruere maskinen i at matche store og små bogstaver, startende fra “A” og helt op til “Z”.
- Argumenterne “{2,4}”instruerer computeren i, hvor mange der skal udføre den tilsvarende handling. I dette særlige eksempel skal det matche mindst to gange, men bør ikke overstige det fjerde gennemløb.
Dette Regex udtryk er begyndt at give mere mening, er det ikke? Hvis du fokuserer på strukturen som helhed, kan du finde ud af noget, der ligner en mailadresse: /[\w._%+-] –>brugernavn, /[\w._%+-] +@[\ –> e-mail-server og [a-zZ-Z]{2,4}/ –> Domæne på top niveau.
Dybest set har denne Regex tre komponenter: en, der matcher brugernavne, en anden, der matcher e-mail-servernavne, og den sidste, der søger efter domæner på top niveau.
Som jeg har nævnt, kræver Regex ikke en sofistikeret opsætning for at matche genstande. I teorien kan du regex-matche elementer, der er gemt i et notesblokdokument i almindelig tekst eller lokalt gemte .csv filer. Andre fordele:
- Krydskompatibilitet (kan håndtere ethvert operativsystem og sprog)
- UNIX-venlig.
- Mere ‘redigerbar’ sammenlignet med almindelig kode.
- Nemmere at forstå i forhold til almindelig kode.
- Regex kan erstatte almindelig kode. Forholdet er omkring 1:100 (dvs. en Regex linje bærer de samme instruktioner som 100 linjer kode).
Heimdal® Threat Prevention - Network
- No need to deploy it on your endpoints;
- Protects any entry point into the organization, including BYODs;
- Stops even hidden threats using AI and your network traffic log;
- Complete DNS, HTTP and HTTPs protection, HIPS and HIDS;
Politikker for dataforebyggelse og Afskedstanker
Som enden er i syne, har jeg tænkt mig at komme ind på et par linjer om dataforebyggelses politikker. For dem, der ikke kender emnet, er en DLP-politik et sæt brugerdefinerede regler, der regulerer, hvordan data og informationsstrømme håndteres i og uden for organisationen. Hashing af følsomme data, før du uploader dem til virksomhedens sky, er et godt DLP-politikeksempel.
Politikker kan hjælpe dig med at håndhæve compliance, beskytte personlige oplysninger og udrydde tilfælde, der kan blive til sårbarheder. I DLP har vi brug for politikker til at homogenisere følsomme informationsstrømme (dvs. fortrolige oplysninger kan spredes på tværs af mange steder, såsom udvekslingsservere, clouds, applikationer), forhindre forsætlige eller utilsigtede datalækager, holde styr på følsomme oplysninger, der er bosiddende i desktop-applikationer, og øge produktivitetsniveauet.
Med hensyn til sidstnævnte aspekt er det meget vigtigt at uddanne dine medarbejdere i compliance, men sådanne bestræbelser, som normalt tager form af online klasser eller (sterile) seminarer, kan forstyrre deres opgaver. DLP-politikker kan uddanne og samtidig frigøre din medarbejders tid.
Quiztid: Hvordan ser en DLP-politik ud? Nope, det er ikke som Scroll of Truth eller cyber-version af Necronomicon. Groft sagt, er det en udløser. Og hvad har en udløser brug for? Betingelser og handlinger, selvfølgelig. En DLP-politik kræver et sæt betingelser, et sæt handlinger for at udføre, når de brugerdefinerede betingelser er opfyldt, og en placering. Så DLP = Location + Condition + Action. Okay, det er ikke den faktiske wireframe, men du forstår pointen.
Placering
Henviser til det sted, hvor data der klassificeret som følsomme kan findes. Microsofts DLP-politikdokumentation nævner flere forekomster, der kan videregives som placeringer – Microsoft Cloud App Security, enheder der kører Windows 10, MS Teams og kanalers onlinemeddelelser, konti der er knyttet til OneDrive, SharePoint-konti og -websteder og udvekslede e-mails. Placeringen kan beskæres yderligere ved at anvende inklusions- eller udelukkelsesfiltre (f.eks. websteder, forekomster, grupper, konti, distributionsgrupper osv.).
Betingelser
Livet kan være den ultimative uendelige liste over “hvad-hvis’er” og “hvad kunne”, men kan stadig ikke nå computersprog til sokkeholderne. DLP hvad-hvis’er” er afgørende for at finde ud af den rette sammenhæng og afgøre, om et sæt af aktioner kan anvendes. Selvfølgelig ville betingelserne være meningsløse uden for det faktiske indhold.
I DLP, kan betingelserne bruges til at lokalisere (indhold) bæreren af en eller flere typer af følsomme oplysninger, læser etiketterne, bestemmer ejeren eller ejerne af dette indhold, fastslår status (dvs. er det delt? Hvis ja, hvem deles det så med? Deles indholdet uden for virksomheden? Hvis det er sandt, hvem delte indholdet uden for virksomheden eller endnu bedre, hvem er personen uden for virksomheden, der søger de følsomme oplysninger?).
Som du tydeligt kan se, er der mange ting, du skal overveje, når du formulerer en DLP-politik\regel. Du skal dog huske på, at mere ‘granulære’ DLP-politikker alvorligt reducerer oddsene for en kritisk dataovertrædelse.
Handling(er)
Hvis placeringen er gyldig, og alle betingelser er opfyldt, kan DLP’en udføre et sæt brugerdefinerede handlinger. Da vi har at gøre med forebyggelse af datatab, er den mest almindelige handlingstype “begræns”. De fleste DLP’er tillader tre typer restriktive handlinger: begrænse adgangen til X-indhold for alle, begrænse adgangen til personer, der er placeret uden for organisationen, og begrænse adgangen til alle, der har linket (dvs. der er et “men” derinde, bare for at afklare tingene).
Før jeg smutter, er der en ting mere, jeg vil tage fat i: forbindelsessikkerhed. DLP er ikke altomfattende; husk, at dette system var designet til at minimere antallet af overtrædelser af virksomhedens politik, ikke for at beskytte dine endpoints og netværk mod cyber-aggression. Selv den mest finjusterede DLP er hjælpeløs, når den konfronteres med en orm eller en trojansk hest, der gemmer sig bag en omhyggeligt forfalsket makro.
For alle dine sikkerhedsbehov opfordrer jeg dig stærkt til at opdage bindende cybersikkerhed til at dække alle angrebsvektorer. Heimdal™ Security’s Threat Prevention Network beskytter dit netværks perimeter med sin kraftfulde DNS-trafikscanner, Ransomware Encryption Protection bryder angrebskæden i tilfælde af et ransomware-angreb, og vores Næste generations antivirus og MDM udrydder hvert stykke ondsindet kode, der formåede at undgå detektionsgitteret.
Håber du har nydt min artikel om DLP indholdsbaserede teknikker. Hvis du ikke allerede har gjort det, må du sørge for at tjekke min anden artikel om, hvordan du vælger den bedste løsning til forebyggelse af datatab for din virksomhed ud (linket er i introen).
Som altid, stay safe, sørg for at klikke på abonner knappen, og skriv endelig til mig, hvis du har spørgsmål, kommentarer eller rants.