In dit artikel wordt data protectie strategie en architectuur besproken op basis van data loss protection (dlp), specifiek welke afwegingen/keuzes dient men te maken als organisatie in het kader van dlp en wat zijn de daarbij behorende rand voorwaardelijke architectuur uitgangspunten. In het eerste deel van dit tweeluik wordt ingegaan op de technologie zelf en in het tweede deel wordt een blik geworpen op byod en cloud in dit kader.
Als men kijkt naar de mogelijkheden voor het beschermen van data dan stuit men al vaak op een discussie over enterprise/information rights management versus data loss/leakage protection. Eerstgenoemde beschermt daadwerkelijk de data zelf en de tweede is in essentie een host-/network-based security-maatregel, specifiek gericht op data. Een term als content firewall dekt in principe de lading van de laatst genoemde het best.
Welke technologie men als organisatie kiest hangt af van de huidige it-architectuur en waar naar toe de it-strategie leidt. Beide oplossingsrichtingen hebben zo hun uitdagingen, maar kunnen met het bepalen en naleven van de juiste architectuur-uitgangspunten succesvol geïmplementeerd worden. Het doel van dit artikel is niet om een discussie te starten welke oplossingsrichting de betere is, maar simpelweg een uitwerking van een van de opties.
Business Driver Data Loss/ Leakage Protection
De eerste vraag die men zich als organisatie moet stellen is of de dlp business driver risk of compliance gedreven is. Indien deze compliance gedreven is, dan bevatten dlp-producten out-the-box heel wat mogelijkheden om snel op weg te kunnen. In het geval van een risk gedreven business driver is het zorgvuldig overdenken hoe men de betreffende data gaat identificeren essentieel. Hierop wordt in de volgende sectie ingegaan.
De tweede vraag die men zich moet stellen is of men accidental loss en/of intentional theft wil voorkomen met dlp. In afwezigheid van additionele security maatregelen is network-based dlp voldoende voor accidental loss en vraagt intentional theft (inclusief accidental loss) minimaal om een host-based dlp-aanpak. Voor beide aanpakken geldt een gedegen access architectuur als randvoorwaarde om effectief te zijn. In het tweede deel van dit artikel wordt ingegaan wat die behelst.
Data loss/leakage protection
De mogelijkheden die dlp biedt om data te beschermen zijn in principe geconstrueerd betreffende drie data toestanden, namelijk data-at-access, data-at-rest, en data-in-flow (data-in-motion/data-in-use), respectievelijk de processen data identification, discovery en protection.
Het eerste proces data identificatie houdt zich bezig met het bepalen van kenmerken voor het herkennen van gevoelige data. Hierin onderscheidt men, in volgorde van minst naar meest fout gevoelig, vier verschillende technieken, namelijk data classification, data tagging, fingerprinting (false negatives), en keywords (false positives). De meeste organisaties zullen een combinatie van deze technieken moeten gebruiken. De technieken zijn het effectiefst toe te passen door te differentiëren in nieuwe data, specifieke data, en big data.
Voor nieuwe data leent data classificatie door eindgebruikers zich uitstekend. Hierbij kent een eindgebruiker een classificatie toe aan een bestand op basis van duidelijk vastgelegde classificatie richtlijnen en met behulp van een classificatie tool. Voor specifieke data, waarvan men vooraf duidelijk weet dat deze gevoelig is, zijn bulk data classificatie, data tagging, en fingerprinting geschikt. Het gebruik van deze identificatie technieken op deze types data leidt tot een lage foutgevoeligheid wat het mogelijk maakt hiervoor discovery en protection efficiënt en effectief in te regelen.
Tot slot is er nog big data,. Deze bevat gevoelige data die niet zo eenduidig is te identificeren. Keywords als identificatie techniek leent zich om hieruit de gevoelige data te destilleren. Echter, vooral in het begin zal het resultaat tijdens de discovery veel false positives opleveren en dus niet geschikt zijn om in het protection proces toe te passen. Dat laatste zou business processen kunnen verstoren en teveel monitoring capaciteit vragen. Eventueel, na enkele keyword policy iteraties of aanwezige self-learning functionaliteit in dlp-tooling, kan dat wel.
De true positives filteren uit de discovery op basis van keywords en deze daarna te behandelen als specific data en van daaruit het protection proces verder aan te sturen., Een goed ingericht data identificatie proces maakt het discovery en protection proces een stuk eenvoudiger. Discovery is in principe het crawlen/scannen van data en daarover rapporteren en het protection proces de clean-up naar aanleiding daarvan en het beschermen van data-in-flow.
Voor het beschermen van data-in-flow zijn er verschillende mogelijkheden. Men kan overtredingen uitsluitend loggen (detectie), eind gebruikers waarschuwen (notificeren) in het geval van een dreigende overtreding, of de overtreding voorkomen (preventie), en dit geheel centraal via de dlp-oplossing monitoren. Technisch wordt data-in-flow functionaliteit geïmplementeerd op web gateways en mail relay servers in het geval van network-based dlp en op workstations in het geval van host-based dlp.
Al met al is dlp een zeer geschikte techniek om gevoelige data te beschermen. De kritiek dat dit niet het geval is stoelt voornamelijk op eisen die men elders negeert en oneigenlijk tot dlp-eis verklaart. Het gaat hierbij voornamelijk om byod en cloud-gerelateerde uitdagingen. In het tweede deel van dit artikel wordt hierop ingegaan.
