Vroeger konden we ons bij in-huis IT nog permitteren om de security er achteraf aan te plakken. Daar hadden we onze eigen mensen voor.
Dat kan nu niet meer.
Cloud en ander vormen van uitbesteden maken dat we veel nauwkeuriger en vroeger om moeten gaan met security.
Hier is het typische verhaal van een organisatie die volwassen wordt in het beheersen van IT risico’s.
In stap 1 worden applicaties ingezet zonder over de beveiliging na te denken. Dat ging vroeger verbazingwekkend lang goed. Maar dat was vroeger. Dan ontstaan de eerste incidenten, of blijkt compliance plotseling van belang.
Dan gaan we over naar stap 2: timmer alles dicht. Dat blijkt best lastig te zijn. Databases die voor alle ontwikkelaars open staan moeten ineens beveiligd worden. Alleen, als je zo maar wat access control regels op de servers zet kan dat de productie flink verstoren. Dan moeten er dus dure ‘data access monitor’ tools aangeschaft worden, met de bijbehorende consultants. Bovendien is het dweilen met de kraan open, want elke dag produceren de ontwikkelaars weer nieuwe lekken.
Met een beetje geluk komt dan het inzicht dat het probleem meer stroomopwaarts moet worden aangepakt.
In stap 3 wordt elke project en elke change vooraf beoordeeld op een strikt normenkader voor beveiliging. Alle ‘controls’ moeten aanwezig zijn en worden afgetekend door de security officer. Dit is een taak waar IT architecten zich ook met veel genoegen op storten. Eindelijk weer een manier om die “wildgroei” in de business onder controle te krijgen.
Maar ook deze aanpak heeft zo zijn beperkingen. Kort samengevat zijn die: duur, traag en niet altijd gepast. In de techniek zijn de kosten van het laatste restje risico afdichting niet altijd in verhouding tot de mogelijke gevolgschade, of tot de effectiviteit van alternatieve inzet van middelen. Hoeveel sloten wil je op de voordeur als de achterdeur wijd open staat?
Dan komen er externe partijen (bijvoorbeeld cloud providers) die zich niet in alles aan je normenkader houden en ook andere manieren van werken hebben. En die zouden wel eens effectiever kunnen zijn.
Een voorbeeld: je normenkader kan zeggen dat er een patch proces voor operating systems in productie moet zijn. Maar in een secure devops omgeving wordt een verouderde server instance in productie niet gepatched, maar gewoon afgeschoten, waarna de load balancer vanzelf een vers gepatchte instance opstart.
En dan krijgen we stap 4, waarin we zien dat we risico gedreven moeten werken, in plaats van maatregel gedreven. En natuurlijk is dat best lastig, want nu moeten we gaan nadenken en overleggen, in plaats van lijstjes met best practices afvinken.
We moeten gaan bedenken of onze eigen wijze van werken beter is dan die van een externe partij, en of we het de moeite waard vinden om onze manier af te dwingen, terwijl een andere manier in die situatie misschien wel net zo goed is. Dan pas worden we ‘cloud ready’.
Deze column verscheen eerder in TITM magazine