In het eerste deel van dit tweeluik is data loss/leakage protection-technologie (dlp) uitgelegd. In dit tweede deel wordt geadresseerd hoe te kijken naar byod en cloud in dit kader teneinde dlp effectief te kunnen implementeren.
Een veel gemaakte denkfout is dat men byod meeneemt als zijnde bron om te beschermen met dlp. Dit terwijl het beleid veelal zegt dat gevoelige data helemaal niet op byod mag komen. Men laat echter na om dit beleid dan ook af te dwingen men de juiste technologie. Hierdoor introduceert men voor dlp de probleemstelling dat het data moet beschermen vanaf bronnen waar die data in eerste instantie niks te zoeken heeft. Met andere woorden er wordt een requirement voor dlp gecreëerd die er niet thuis hoort en die dlp ook niet gaat oplossen, immers:
- Byod passeert vaak geen web gateways en/of e-mail gateways van de organisatie, dus tot zover data-in-motion protectie op basis van network dlp;
- Byod is vaak beschermd met bijvoorbeeld een host-based firewall (niet onder controle van de organisatie), dus tot zover data-at-rest discovery;
- Byod staat het niet toe om een agent te installeren, dus tot zover data-in-use protectie op basis van host-based dlp.
Waar dient dan geadresseerd te worden dat gevoelige data bij voorbaat niet op byod terecht komt? Het antwoord is de ‘access architectuur’ voor byod overdenken en implementeren. Nou is access architectuur een multi-interpretabel begrip. Zonder in een detail-uitwerking te verzanden wil ik wel kort een access architectuur-context schetsen in zoverre die nodig is in dit kader. Ik onderscheid in access architectuur de volgende layers (verticaal):
- User layer: Welke type gebruikers onderscheidt men?
- Intern, extern
- Device layer: Welke devices onderscheidt men?
- Trusted (company managed, third party managed)
- Untrusted (byod, private, public)
- Network layer: Welke toegangsnetwerken onderscheidt men?
- Internet
- Remote access (end-to-site vpn)
- Closed company network (wan, (w)lan, site-to-site vpn)
- Open company network (wlan)
- System layer: Welke toegangssystemen onderscheidt men?
- Server-based computing
- Virtual desktop infrastructure
- Web-based access
- Mobile access
- Client-server Access
- Application layer: niet relevant voor dit artikel
- Data layer: niet relevant voor dit artikel
Tussen deze layers bevinden zich access control tiers (verticaal), respectievelijk de device access control tier, network access control tier, system access control tier, application access control tier, en data access control tier. Horizontaal onderkennen we een identity and access management tier.
Een geoorloofd access Profile voor byod in het kader van dlp is een interne gebruiker, met een privé-apparaat, die via internet of het open bedrijfsnetwerk (wlan), toegang krijgt tot server based computing (sbc), virtual desktop infrastructure (vdi), web of mobile systemen. De access control tiers zijn er dan verantwoordelijk voor dat dit device ook geen ander access profile kan gebruiken. De network access control tier dient zorg te dragen dat alleen trusted devices toegang krijgen tot het remote access en closed company network, bijvoorbeeld op basis van een geldig digitaal machine-certificaat. Verder dient de system access control tier zorg te dragen voor data isolatie. Bijvoorbeeld middels het sandboxen van web access, secure containerization en application wrapping in het kader van mobile access, network zoning toe te passen op client-server-applicaties, zodat deze niet direct toegankelijk zijn via het internet of open bedrijfsnetwerk, en virtualisatie op basis van centralized computing systemen als sbc en vdi.
Door de access architectuur op deze manier in te richten kan de oneigenlijke eis ten aanzien van dlp in het kader van byod vervallen.
Cloud
Een kenmerk van cloud-services is dat deze autonoom zijn ontworpen omtrent de elementen anywhere, anytime, anyhow. In de meeste gevallen is er binnen de cloud-service geen mogelijkheid om hieraan grenzen te stellen en is het ook niet mogelijk om het te koppelen aan security-services die ieraan beperkingen kunnen stellen. Er is vooral veelal behoefte om het risico omtrent het anyhow element te controleren. Het gevolg is dat men deze tekortkoming aan controle mogelijkheden dan toeschrijft aan dlp-technologie. Een oplossing hiervoor ligt echter ook veeleer voor de hand te zoeken in de access architectuur.
De enige koppeling die cloud-services veelal met andere systemen ondersteunen is in het kader van access management, bijvoorbeeld op basis van security assertion markup language (saml). Indien deze koppeling juist wordt gebruikt kan men hiermee ook de veelgevraagde eis invullen dat data afkomstig uit hoog geclassificeerde cloud-services niet op een untrusted device terecht komt. De access management-oplossing dient dan niet uitsluitend de gebruiker, eventueel sterk, te authentiseren, maar ook het device op basis van een digitaal certificaat of met behulp van network access control. Dit maakt het mogelijk om uitsluitend trusted users vanaf trusted devices toe te laten tot de betreffende cloud-service.
Met dlp kan men aanvullend beheersen dat uitsluitend data van classificatie niveaus in cloud-services wordt opgeslagen, waarvoor deze toereikend is bevonden. Dit op basis van informatie en applicatie-classificatie-schema en hieraan gerelateerde eisen.
Tenslotte zijn er nog enkele aandachtpunten om in het achterhoofd te houden bij het maken van cloud keuzes en dlp. Onthoud dat public cloud meer dlp-uitdagingen kent dan private cloud. Verder neemt dlp-complexiteit toe naarmate men in het kader van cloud verschuift op de as van SaaS, PaaS, naar IaaS. In principe nadert men dan de situatie dat de dlp-oplossing zelf en diens ondersteunende infrastructuur, zoals web gateways en mail relay servers, naar de cloud wordt uitbesteed. Het verdient überhaupt aanbeveling om kritisch te kijken of men security-services, die nauw verbonden zijn met bedrijfsprocessen, waaronder ik identity and access management en dlp schaal, naar de cloud wil uitbesteden.
