Steeds meer bedrijven lopen het risico dat de gegevens van hun klanten op straat komen te liggen. Bedrijven wapenen zich hiertegen door hun bedrijfsprocessen te laten voldoen aan (inter)nationale wet- en regelgeving (compliancy). Maar compliant zijn betekent nog niet 100 procent veiligheid. Dit artikel betoogt dat een tester een toegevoegde waarde levert aan zowel de compliancy als de security van een bedrijf.
De laatste jaren staan de media vol met berichten over bedrijven die gehackt zijn en waarbij bedrijfskritische informatie en/of klantgegevens in de openbaarheid zijn gebracht. Hierdoor hebben deze bedrijven, naast economische schade, ook reputatieschade geleden. Immers, bestaande klanten gaan weg en nieuwe klanten blijven weg omdat ze hun (persoonlijke) data niet (meer) veilig achten bij de getroffen bedrijven. Om klanten toch te behouden, geven bedrijven aan dat ze compliant zijn.
Maar wat betekent nu compliant? Een bedrijf dat compliant is, wil zeggen dat dit bedrijf zich houdt aan regel-en wetgeving. Dat dit wel erg algemeen is mag duidelijk zijn, daarom staat er ook meestal bij aan welke wet-en regelgeving dit bedrijf zich houdt.
In de financiële dagbladen staat er vaak dat een beursgenoteerd bedrijf compliant is aan de U.S. Sarbanes-Oxley Act (SOX). Compliant zijn kan ook zeggen dat een bedrijf zich houdt aan de richtlijnen van de industrie waartoe het behoort. Dit is bijvoorbeeld het geval bij bedrijven compliant aan de PCIDSS: Payment Card Industry Data Security Standard. Deze bedrijven moeten zich houden aan de opgestelde industrierichtlijnen voor kaarthouder-informatie van onder andere betaal- en creditcards.
Maar is onze data wel 100 procent veilig bij een bedrijf dat compliant is aan alle benodigde wet- en regelgeving? Nee!
Waarom niet? Omdat compliant zijn alleen wil zeggen dat het bedrijf voldoet aan bepaalde wetten en regels op het moment van toetsen van compliancy. Dit kan betekenen dat op een gegeven moment aan bepaalde richtlijnen is voldaan, bijvoorbeeld het up to date houden van de firewall op het bedrijfsnetwerk. Maar de meeste wetten en regels zijn al achterhaald als ze in werking worden gesteld. Timing van compliancy-toetsing is hier dus essentieel.
Het verschil met security is dat security een veel grotere bandbreedte heeft dan compliancy. Security geldt ook voor zaken die buiten de gestelde regel- en wetgeving vallen. Dit komt omdat de wet- en regelgeving zich vaak slechts richt op één domein, bijvoorbeeld privacy of financiële verantwoording. Om hierop alleen de security in te richten is dwaas, omdat er altijd het risico bestaat dat kwaadwillenden via een ander domein (bijvoorbeeld financieel beheer) in het betreffende domein privacy kunnen komen. Daarom is hierbij een goed uitgevoerde risico-analyse van alle bedrijfsprocessen cruciaal. Hiervoor wordt vaak de hulp ingeroepen van een it-auditafdeling.
Testers worden vergeten
Maar wie wordt hier vaak vergeten? De testers! Testers zijn met name geschikt om de security van bedrijfsprocessen te toetsen op kwaliteit. Beroepsmatig zijn zij bezig bedrijfsprocessen partieel, geheel of tezamen te testen of deze kwalitatief goed zijn en er geen bevindingen naar voren komen. Dit betekent dat het team van testers knowhow moeten hebben van de bedrijfsprocessen. Niet alleen van de geldende regels, maar ook van de onderlinge verbanden en verschillen.
Een goed testteam (in- of extern) moet dus naast systeemkennis, ook functionele en security-kennis hebben en deze kennis optimaal kunnen gebruiken. Daarnaast weet een goed testteam hoe het de risico-analyse kwantitatief kan verwoorden in grafieken en tabellen, zodat het bedrijfsmanagement hier haar security-strategie op aan kan passen. Tevens kan het testteam via een goed ingerichte (automatische) regressietest onderzoeken of een veranderd bedrijfsproces (naar aanleiding van een compliancy-regel) andere bedrijfsprocessen heeft beïnvloedt en dus ook wellicht de beveiliging.
Compliant zijn betekent dus nog niet dat een bedrijfsproces veilig is voor het hele bedrijf en de informatie van haar klanten. Bekwame testers zijn daarom van toegevoegde waarde voor het juist inschatten en testen van de risico's die alle bedrijfsprocessen doorlopen en niet alleen het bedrijfsproces waarvoor de compliancy-wet- en regelgeving geldt.
Andersom werkt het vaak wel. Als je veilig bent, dan hoef je je meestal geen zorgen te maken om compliancy.
Er wordt hier gespeeld met de begrippen compliancy en security alsof dit twee zeer wezenlijk verschillende begrippen zijn die elkaar bijten. Volgens mij bijt de een de ander niet. Mee eens, compliant betekent nog niet 100% veilig. Maar, bestaat dit dan, 100% veilig? Wil je dat uberhaupt bereiken? Wegen de kosten op tegen de risico’s? Als beveiliging uiteindelijk hygiene is, dus bijv:
1 we ruimen consequent de boel (oude accounts);
2 we patchen consequent tegen nieuwe exploits;
3 we kijken consequent de logfiles na op rare gebeurtenissen;
4 we testen alle changes voor in gebruikname;
5 we doen eens in de zoveel tijd een vulnerability scan;
6 we testen….
…en een compliancy framework schrijft deze maatregelen allemaal voor, dan dient compliancy toch het groter goed: een betere hygiene en daarmee een hogere beveiliging van de applicatie?
Het uitvoeren van bepaalde tests is een intergraal onderdeel van een compliancy framework. Zeker SOx vereist Opzet, Bestaan en Werking en gaat ervan uit dat een groot aantal testen worden uitgevoerd. Testen die het hele fiscale jaar omhelsen.
Marcel,
je geeft precies het antwoord waar ik op gewacht heb.
Compliant wil zeker niet zeggen 100% veilig.
Het ging er mij om de security en auditexperts te triggeren op dit artikel te reageren om de discussie ‘100% compliant, 100@ veilig?’ aan te gaan en hierbij testers te betrekken omdat deze groep professionals zijn in risico-analyse en het toetsen van kwaliteit.
Het is aan de ‘klant’ van de tester om te beoordelen of de kosten opwegen tegen de risico’s die mede door de tester zijn getest en beschreven.
Het was niet mijn bedoeling compliancy en security voor te doen als zaken die elkaar bijten. Maar eerlijk gezegd, dit haal ik ook niet uit mijn artikel.
Compliancy dient zeker het grotere goed: een hogere applicatie-beveiliging en compliancy frameworks zullen altijd flexibel moeten zijn om zich aan te passen aan de veranderlijkheid van de processen die de applicatie bedreigen.
Testers zijn hierbij nodig om het compliancy-framework te onderzoeken of het nog werkt zoals het zou moeten.
Trowens ,wel opvallend dat je het in je voorbeeld over hygiene het hebt over het consequent zijn, hier heb ik een andere mening over.