Perfecte securitybeleidsregels bestaan niet omdat ze moeilijk te schrijven zijn, maar omdat ze de werkelijkheid slecht weergeven. Er zit een groot verschil tussen beleid dat op papier staat en beleid dat ook echt afdwingbaar is.
De meeste beleidsregels zijn niet gemaakt om stand te houden in het snel veranderende landschap waarin we ons bevinden. Ze worden met de beste bedoelingen opgesteld maar vallen uit elkaar zodra ze zijn geschreven voor “ideale” situaties en perfecte scenario’s.
Waarom goed beleid in de praktijk faalt
Toen ik nog sysadmin was en verantwoordelijk voor patchbeheer trapte ik precies in deze val. Ik had iets ingevoerd wat een heldere regel leek: alle kritieke patches moeten binnen 30 dagen na release zijn uitgerold. Het was een duidelijke maatstaf, eenvoudig te meten en bovenal sloot het aan op de regelgeving en compliance-eisen waaraan we moesten voldoen.
Op papier was het prima en precies hoe goede beveiliging eruit hoort te zien. Of toch niet? In de praktijk viel het namelijk vrijwel meteen uit elkaar.
Omdat ik ook deel uitmaakte van het team dat patches op onze endpoints en servers moest volgen en installeren, had ik zonder het te beseffen al mijn vrije tijd opgeslokt. Tegen de tijd dat ik had vastgesteld wat wanneer gepatcht moest worden, het binnen IT had getest (wij waren altijd de proefkonijnen), onderhoudsvensters had ingepland voor de rest van de organisatie en de patches daadwerkelijk had uitgerold waren er al bijna 30 dagen voorbij. Daarna begon de cyclus opnieuw. Er bleef geen tijd over om iets anders te doen dan patches babysitten.
En alsof dat nog niet genoeg was: we lieten een penetratietest uitvoeren en de bevindingen daaruit weken flink af van die uit onze kwetsbaarhedenscans. De pentesters drongen erop aan hun bevindingen op te lossen maar een deel had niet het label “Kritiek”. Die risicovolle bevindingen bleven dus nog een tijd liggen nadat de kritieke bevindingen waren verholpen.
Dit was geen gebrek aan goede bedoelingen. Het was niet verkeerd om tijdig te willen patchen. Het beleid faalde omdat het geen rekening hield met de daadwerkelijke omgeving, het echte risico voor de organisatie of met concurrerende prioriteiten. Precies hier loopt het bij de meeste securitybeleidsregels spaak. Ze zijn ontworpen voor perfecte omstandigheden die in echte IT-omgevingen niet bestaan en ze bevatten vaak geen echte risicogebaseerde afwegingen. Uiteindelijk wordt zulk beleid niet gevolgd; het wordt omzeild of simpelweg genegeerd.
Het zijn niet alleen zelfbedachte beleidsregels die in deze val lopen. Zelfs breed geaccepteerde industriestandaarden kunnen tekortschieten wanneer ze worden toegepast zonder begrip van de specifieke situatie van uw organisatie en omgeving.
Wanneer een “industriestandaard” niet langer nuttig is
Industriestandaarden bestaan om goede redenen. Ze zijn gebaseerd op lessen uit beveiligingsincidenten en datalekken en vertegenwoordigen de gezamenlijke expertise van securityprofessionals. Ze bieden een basislijn die voor de meeste organisaties meestal werkt. Het probleem is dat “de meeste organisaties meestal” nog altijd veel ruimte voor falen overlaat.
Een IT-team bij een productiebedrijf ondervond dat aan den lijve toen het besloot de Windows-servers te verharden met CIS Level 1-benchmarks. CIS Benchmarks zijn uitstekende vertrekpunten. Ze worden breed gerespecteerd, regelmatig bijgewerkt en aanbevolen door auditors en securityprofessionals. Dat was niet het probleem.
Het probleem was de aanname dat ze consequent op elk systeem in hun omgeving konden worden toegepast. Alleen zijn de besturingssystemen op hun productievloer geen typische eindgebruikerssystemen. Ze hebben een specifiek doel en specifieke eisen die afwijken van bijvoorbeeld een omgeving als de financiële administratie.
De benchmarks schakelden diverse verouderde protocollen en services uit waarvan hun vijftien jaar oude industriële apparatuur afhankelijk was om met de server te communiceren. Daardoor lag de productie het grootste deel van de dag stil (6 uur) terwijl ze koortsachtig de wijzigingen terugdraaiden. De financiële impact was aanzienlijk. Niet zodanig dat het bedrijf omviel maar het zorgde voor flink wat zorgen en chaos binnen de IT- en productieteams.
Het toepassen van CIS-benchmarks was niet de verkeerde aanpak. Ze zijn ontworpen voor moderne IT-omgevingen met actuele besturingssystemen en bijgewerkte apparatuur. Maar ze zijn een startpunt en niet elke instelling in de benchmark is per se ideaal voor een operationele technologieomgeving waarin upgraden veel lastiger is en uitvaltijd ernstige financiële gevolgen kan hebben.
Hier kan het blind volgen van “industriestandaarden” u schaden. Deze benchmarks zijn gebouwd op aannames over uw omgeving, uw middelen en uw bedrijfsvoering. Wanneer die aannames niet overeenkomen met uw werkelijke omgeving – omdat u legacysystemen draait, in een gespecialiseerde sector actief bent of met andere beperkingen werkt waar de benchmarks geen rekening mee houden – kan het blind volgen van beste praktijken meer problemen veroorzaken dan het oplost.
Benchmarks zijn een nuttig hulpmiddel en u zou ze moeten gebruiken. Maar te vaak wordt in beleid het gebruik van deze benchmarks verplicht gesteld om een compliance-vinkje te zetten, zonder eerst de specifieke eisen van uw omgeving te doorgronden.
Beleid ontwerpen dat in de praktijk werkt
Nadat mijn oorspronkelijke patchbeleid van 30 dagen was mislukt, hebben mijn team en ik het opnieuw ingericht rond uitkomsten in plaats van termijnen. Ons nieuwe beleid was gericht op risico. Er waren veel aanvullingen maar deze maakt het punt waarschijnlijk het duidelijkst:
“Kritieke kwetsbaarheden in assets die aan het internet zijn blootgesteld en waarvan actieve exploitatie is aangetoond, moeten binnen 72 uur worden gemitigeerd. Kritieke kwetsbaarheden waarvoor proof-of-concept-code beschikbaar is, moeten binnen 7 dagen worden gepatcht. Mitigatie kan bestaan uit patchen, compenserende maatregelen of tijdelijke isolatie van een service. Alle acties en uitzonderingen moeten worden gedocumenteerd met risicoacceptatie door de CISO.”
De echte verandering zat niet alleen in de termijnen. We stelden prioriteiten voor kwetsbaarheden en patches op basis van de daadwerkelijke blootstelling: of systemen aan het internet waren blootgesteld of er exploits in omloop waren en welke data die systemen raakten.
Minstens zo belangrijk: we begrepen dat zicht op de omgeving cruciaal is voor IT. We rolden geautomatiseerde kwetsbaarhedenscans uit die rechtstreeks werden doorgevoerd in ons dashboard voor patchbeheer. Zodra systemen buiten compliance vielen en kritieke patches misten, wisten we het meteen. We konden onze cijfers in de loop van de tijd volgen om te zien hoe goed (of slecht) we presteerden en waar we ons moesten verbeteren.
We erkenden ook dat patchen binnen de termijn soms niet mogelijk was, om uiteenlopende redenen. In die gevallen hadden we compenserende maatregelen nodig, documentatie en een akkoord van het management.
Bij het beleid rond de CIS Benchmarks was de les vergelijkbaar maar het IT-team benaderde het vanuit een andere hoek. Ze lieten de benchmarks niet volledig los en schrapten ze ook niet uit hun beleid. In plaats daarvan pasten ze het beleid aan zodat voor elk systeemtype in de organisatie een CIS-verhardingsbeoordeling verplicht werd, om vast te stellen welke benchmarks productiecomponenten wel of niet zouden verstoren. Het IT-team documenteerde welke benchmarks op welk systeemtype van toepassing waren, welke in strijd waren met de eisen voor dat systeemtype en welke compenserende maatregelen werden ingezet. De productiesystemen kregen hun eigen verhardingsbasislijn, eindgebruikerssystemen de hunne en servers eveneens.
Hoe nu verder
Zoals we weten is vrijwel niets in IT en security ideaal. Innovatie en technologische vooruitgang zullen security altijd voorblijven.
Onze taak als IT- en securityprofessionals is om het maximale te halen uit wat we tot onze beschikking hebben: systemen, processen en beleid ontwerpen die veilig genoeg zijn zodat gebruikers, afdelingen en bedrijfsfuncties zo veilig mogelijk kunnen werken zonder die werkzaamheden al te zeer te belemmeren.
We moeten accepteren dat perfecte beveiliging niet bestaat en begrijpen dat beleid dat perfectie eist zal falen.
Security werkt het best wanneer het onderdeel is van hoe IT elke dag werkt, niet iets wat er achteraf aan is vastgeplakt. Security werkt het best wanneer het de meest efficiënte en vanzelfsprekende optie is. Wanneer het zo min mogelijk in de weg zit.
Als uw team moet kiezen tussen het werk afkrijgen of een securitybeleid volgen, kiest het elke keer voor het werk afkrijgen. Ontwerp uw beleid zo dat die twee dezelfde keuze zijn.
