Betere business door IT-auditors en DevOps samen te brengen (met liefde)

Ik snap het wel. Auditors zoals ik worden vaak gezien als de spelbrekers die de schwung en de lol van DevOps komen verstoren. Immers: als teams van engineers ongedwongen samen aan een product kunnen werken, dan gaan ze van sprint naar sprint in een flow van automatisering. Waarom zouden ze dat onderbreken om formulieren in te vullen en veiligheidschecks te automatiseren? Waarom zouden ze willen dat een of andere externe auditor ineens langs komt waaien om te vragen naar bonnetjes, letterlijk en figuurlijk? Dus ja, het is voor de DevOps-club altijd moeilijk geweest om een auditor te zien als iemand die het hele team juist kan helpen bij het bereiken van zijn doelstelling: waarde leveren.

Toch hoeven mission-critical audits en DevOps niet op gespannen voet te staan. Sterker nog: een goede IT-auditor hoort engineeringprojecten juist te ondersteunen en niet te vertragen. Het uiteindelijke doel van de audit is immers om de kwaliteit van hun processen en resultaten te verbeteren.

Een beter leven?

Als bij auditors en DevOps de neuzen niet dezelfde kant op staan, dan komt dat in grote mate door de klassieke indeling met drie defensieve linies. Daarbij is er een strikte scheiding van machten tussen de afdelingen die gaan over de business; veiligheid en risico; en auditen. En dan heb je dus niet het hele systeem aan één tafel – iets waar Schuberg Philis juist altijd sterk voor pleit als een cruciale voorwaarde voor het voldoen aan de multidisciplinaire eisen van mission-critical IT, die meerdere afdelingen raken. In plaats daarvan krijg je experts die elk in hun eigen silo werken en die, zoals ik al eerder schreef, elkaars taal niet spreken.

Voor DevOps heb je een ander soort controle nodig dan gebruikelijk. Dat is de conclusie uit meerdere onderzoeken en white papers, waaronder het meest recente en invloedrijke raamwerk voor Control Objectives for Information and Related Technologies (COBIT), gepubliceerd door ISACA, de Information Systems Audit and Control Association. In 2018 heeft de DevOps-gemeenschap zelf ook al geprobeerd een nieuwe weg in te slaan met de invoering van de DevOps Risk and Controls Matrix. Die matrix werd toen met een kwinkslag geïntroduceerd in een “liefdesbrief van DevOps aan auditors”. Daarin staat een enorm hart afgebeeld, en de belofte om het leven beter te maken. De brief opent als een valentijnskaart met de woorden “Dear auditor” in wit cursief – dat is schattig natuurlijk, maar het geeft ook duidelijk aan dat er nog wat te verbeteren valt aan de innige banden tussen beide groepen.

De matrix was een startpunt en bevat een aantal goede punten. Maar helaas zien we vier jaar later in het algemeen nog geen grote verbeteringen in onze omgang met DevOps-engineers. Beide disciplines gaan nog steeds onwennig met elkaar om; we moeten elkaar leren vertrouwen.

Een brug slaan tussen twee werelden

Toch heb ik, na tien jaar ervaring in het auditen van softwareontwikkelingsprojecten, wel degelijk gezien dat het mogelijk is om de polarisatie tussen deze twee groepen te verzachten en de afstand in hun relatie te overbruggen. Eén stap in die richting zette ik al in het rapport DevOps and Agile in control, geschreven als antwoord op het gebrek aan controleraamwerken specifiek voor DevOps. Dat rapport is opgesteld in samenwerking met NOREA, de Nederlandse beroepsvereniging van IT-auditors, waar ik voorzitter ben van de werkgroep DevOps & Softwareontwikkeling.

Het rapport beschrijft een controleraamwerk om te conceptualiseren hoe de belangrijkste IT-risico’s bij de principes van Agile en DevOps beperkt kunnen worden. Dit raamwerk is gebaseerd op mijn ervaring bij Schuberg Philis en op interviews met engineers, IT-managers en projectmanagers die ik in mijn werk ben tegengekomen. Het NOREA-rapport werkt als een soort handboek met concrete aanbevelingen voor auditors zoals ik, en ik stel me voor dat soortgelijke richtlijnen voor DevOps ook goed zouden kunnen werken.

Het huidige controleraamwerk omvat 15 voorgestelde controlepunten. Ons advies aan teams is om waar dan ook in het raamwerk te starten, steeds kijkend naar de relevante behoeften en risicogebieden. Waar ze ook beginnen, het doel is om de veiligheid en voorspelbaarheid te verbeteren door het implementeren van de controlepunten. Hieronder staat een indruk van verschillende aandachtsgebieden voor deze controlepunten, met daarbij verbeterpunten die ik vaak ben tegengekomen.

1. Meerdere controlepunten zijn ingesteld om het werk van auditors te versoepelen en dus het hele DevOps-project te versnellen. De focus ligt hier op de werkwijze van het DevOps-team. We zien nog steeds vaak dat teams hun manier van werken meerdere keren per jaar aanpassen zonder enige documentatie. Dan houden engineers soms oude richtlijnen aan, of een mix van oude en nieuwe afspraken. En dat heeft een negatieve invloed op de slagvaardigheid én de kwaliteit van het team.
2. Om de werelden van auditors en DevOps dichter bij elkaar te brengen, zouden auditors afscheid moeten kunnen nemen van een perspectief dat helemaal gedicteerd wordt door beleid, procedures en bewijs in de vorm van documentatie. Een goede manier om de afstand te overbruggen kan zijn om het principe van “alles is code” te onderstrepen, met een gecentraliseerd versiecontrolesysteem. Ook een geautomatiseerde uitrolpijplijn kan veel bieden, omdat die niet alleen sterk geautomatiseerd is maar ook sequentieel – en auditors houden van sequentieel werken.
3. Om de beide werelden effectief bij elkaar te brengen, zullen teams hun omgeving echt beter moeten documenteren. We komen maar zelden een goed gedocumenteerd DevOps-team tegen, en daardoor lopen we vaak tegen dezelfde vragen op. Welke applicaties of software horen bij de scope? Door welke ruitrolpijplijn worden ze beheerd? Welke oplossingen, afkomstig van derden of elders, worden in deze pijplijnen gebruikt? Worden de pijplijnen ook via het versiecontrolesysteem beheerd? Hoe zijn deze pijplijnen in de loop van het jaar onderhouden en aangepast? Zijn de productteams of afzonderlijke platformteams verantwoordelijk voor de pijplijnen?
4. Als de teams hun werkwijze en de uitrolpijplijnen eenmaal hebben gedocumenteerd, gaan we kijken of de implementatie en configuratie goed uitgevoerd zijn. We vragen dan: voorziet elke pijplijn in een vereiste die door het team is vastgelegd? Hoe wordt de toegang en autorisatie voor deze belangrijke configuratie-instellingen ingeregeld? En, van levensbelang: hebben we het gevoel dat er een team is dat hier in control is?
5. DevOps-teams staan bekend om hun hoge niveau van automatisering. Toch moeten we weten: heeft het team een teststrategie aangepast? Horen daar ook veiligheidstests bij? Wat zijn de verschillen tussen de uiteenlopende oplossingen en diensten die ze ontwikkelen? Zijn er voor elke soort test ook doelstellingen vastgelegd en als relevant bestempeld? Bijvoorbeeld: worden er testbereikdoelen gemeten? Zonder de antwoorden op zulke vragen wordt het voor ons heel lastig om een goed gefundeerde mening te geven over de kwaliteit van de testpraktijken van de teams.
6. De meeste DevOps-teams zijn het gewend om met peer review te werken. Maar auditors kunnen vaak niet zien welke checks de peer reviewer uitvoert. Daarom zou het geweldig zijn als reviewers vastleggen welke tests ze tegenkomen, wat het vastgestelde testbereik was, of dat tegemoetkomt aan de eisen voor kwaliteit en veiligheid voor de oplossing of dienst, en of er geen kritieke bevindingen openstonden.
7. Een andere kenmerkende eigenschap van DevOps-teams is hun onafhankelijkheid. Dat is prima, maar het is van essentieel belang om de eindgebruiker en de business van de organisatie goed in het proces te betrekken – niet alleen voor de vereisten-fase, maar ook voor de acceptatie van veranderingen en voor de uitrol. Daarom willen we weten: heeft het team afspraken gemaakt over de betrokkenheid van deze partijen bij de goedkeuring van het testen en de uitrol? Past dat bij het relevante risicoprofiel voor de oplossing of dienst? Worden de activiteiten van deze spelers ook gedocumenteerd?

De business staat centraal

Bij Schuberg Philis zorgen we ervoor dat de drie defensieve linies niet primair gezien worden als aparte lijnen, maar als een verbonden cirkel van prioriteiten die elkaar wederzijds versterken. Dat betekent dat de experts voor de business, veiligheid en auditen allemaal vanaf dag één betrokken zijn bij een project. Ze dragen elk kun eigen deskundigheid en vaardigheden bij en ze ondersteunen en sparren met elkaar zodat ze als collectief de beste fit-for-purpose oplossing ontwikkelen. Op die manier werkt elke defensieve linie aan een beter begrip van het probleem en werken ze samen om de optimale verdediging tot stand te brengen.

Zo zijn het niet alleen de businessstakeholders die kijken naar de waardecreatie van de oplossing. Het hele team, inclusief auditors, houdt de toegevoegde waarde voor de business steeds in het vizier. In deze context wordt softwareontwikkeling steeds efficiënter. Engineers kunnen hun werk omarmen zonder de last van manuele processen of het invullen van onnodige documentatie, en zonder bij elk project of jaar weer vanaf nul te moeten beginnen. Zo kan een goed geauditeerde, sterk geautomatiseerde omgeving het proces van softwareontwikkeling versnellen.

Dus, lieve DevOps, we willen jullie liefde graag beantwoorden. Weet dat onze controlepunten jullie DevOps en Agile benaderingen kunnen versterken én daarbij de veiligheid van elke uitrol kunnen verbeteren. Betrek ons in een vroeg stadium bij het proces en wij zorgen ervoor dat jullie projecten een vliegende start krijgen en altijd vaart blijven houden. Onze rol als auditors is niet om jullie werk fast and furious te maken, maar wel om ervoor te zorgen dat elk detail klopt. Samen kunnen we dan van iedere rit een succes maken – op topsnelheid.