Change- en releasemanagement  | Een stappenplan om continuïteit te verbeteren

We weten het, we vallen nogal in herhaling wanneer we het hebben over de impact van de menselijke factor binnen informatiebeveiliging en IT-security. De mens is een risico dat niet vergeten mag worden maar tegelijkertijd lastig is om te beveiligen. Probeer maar eens een medewerker achter een firewall te plakken. Dat gaat niet. Achter het behang is ongeveer net zo lastig overigens.

Een medewerker kan opzettelijk of onopzettelijk ervoor zorgen dat er iets grandioos misgaat binnen de organisatie op het gebied van informatiebeveiliging. Dagelijks zien we dat de gevolgen hiervan niet mals zijn. Om ervoor te zorgen dat deze scenario’s zoveel mogelijk beperkt blijven is het hebben van een sterk change- en release management van groot belang.

Wanneer er bijvoorbeeld nieuwe software wordt gemaakt, of bestaande software wordt geüpdatet, wordt dit vaak gedaan door een medewerker. De kans bestaat dan simpelweg dat hier fouten in zitten. Dit kan zijn in de vorm van een technische fout (bug) maar ook fouten die gemaakt worden tijdens de implementatie van de nieuwe software. Om dit proces soepel te laten verlopen hebben wij een aantal stappen opgesteld die u kunt gebruiken om dergelijke fouten, hopelijk, te voorkomen.

Het begint bij changemanagement

De eerste drie stappen hebben te maken met changemanagement. Het begint natuurlijk allemaal bij het goed ontwerpen en bouwen van het product. De software. Dit betekent dat alle code door meerdere personen moet worden bekeken, gecontroleerd en getest. Dit gebeurt in een zogenaamde ontwikkelomgeving. Pas als de code volledig is gecontroleerd en veilig is bevonden door meerdere partijen, kan deze door naar de testomgeving.

Nu dat de software is aangekomen in de testomgeving wordt deze (als het goed is) volledig getest op de processen. Zowel op de verwachte processen (happy flow) als ook de onverwachte processen (unhappy flow). Ook hier geldt weer dat volledigheid van de test van groot belang is. Daarom wordt er gebruik gemaakt van een combinatie van testcripts die geautomatiseerd de boel testen én van handmatig testen. De techniek komt een heel eind maar is nog niet zo ver dat het echt kan denken als een kritisch mens. Gelukkig maar.

Zodra de software met vlag en wimpel is geslaagd komt het terecht in de acceptatieomgeving. Dit is als het ware een werkkopie van de productieomgeving maar dan zonder AVG gerelateerde informatie. Hier kunnen vervolgens tests worden uitgevoerd met betrekking tot het wekelijks gebruik (performance / workload etc). Vergelijkbaar met de testomgeving wordt ook hier weer gebruik gemaakt van scripts en van handmatig testen.

Het is tijd voor de release! Toch..?

Nu dat gedeelte gedaan is, is het tijd voor releasemanagement. Dit is de fase die ervoor moet zorgen dat de grondig geteste software probleemloos naar de productieomgeving wordt gezet. Dit kan, afhankelijk van het betreffende systeem of software, een complexe stap zijn. Vaak moeten hiervoor veel stappen in een specifieke volgorde worden uitgevoerd waarbij er geen ruimte voor fouten is. Daarom dient ook dit proces goed ontwikkeld en getest te worden voordat de wijziging (update) werkelijk naar de productieomgeving kan worden gezet. Wordt er toch een fout gemaakt? Dan kan het zomaar zo zijn dat het volledige systeem instort. Als dat het geval is, is er nog een laatste stap die we moeten benoemen. De zogenaamde Roll Back.

Deze laatste actie is een maatregel die je liever niet neemt maar waarvan je wel blij bent dat hij er is. Het is een geautomatiseerd proces waarbij de zojuist mislukte change weer terugzet kan worden. Alle stappen worden dus ongedaan gemaakt en het kan opnieuw geprobeerd worden.

Het lijkt misschien een onnodig groot en langzaam proces, maar dat is nou juist het ding. Veel organisaties vinden dat ze geen tijd en / of geld hebben om dit allemaal in te richten. Het gevolg is dat ze nieuwe software e.d. zomaar gaan gebruiken. De gevolgen zijn duidelijk. Hoe vaak lezen we wel niet over ransomware-aanvallen dankzij een kwetsbaarheid in nieuwe software? Te vaak.

Wat levert change- en releasemanagement  op?

Change en releasemanagement kent velen voordelen. Bijvoorbeeld de productiviteit van de werknemers. Zij zijn dankzij een sterk ingericht release management veel minder tijd kwijt aan administratieve taken en hoeven zich niet druk te maken om versiebeheer en planning. Dit alles komt de systeemintegriteit ten goede. De risico’s op systeemonderbrekingen worden gecontroleerd en geminimaliseerd. Dit heeft naast minder verstoringen ook een kostenbesparing op bijvoorbeeld support tot gevolg. Je kunt immers bouwen op een stevig en goed gecontroleerd systeem. Het voegt dus absoluut een zekere mate van continuïteit en zekerheid toe voor de gebruiker.

Als er wordt gekozen voor geautomatiseerde processen, bijvoorbeeld via CICD (Continious improvement Continious Deployment) is er nog een groot voordeel dat benadrukt moet worden. Veranderingen kunnen dankzij deze automatisering namelijk veel vaker plaatsvinden. Dit stelt medewerkers in staat om zich meer te kunnen focussen op het ontwikkelen van nieuwe functionaliteiten en/of het oplossen van bugs, in plaats van het constant handmatig moeten testen.

Ben je na het lezen van dit artikel benieuwd geworden hoe wij uw organisatie kunnen voorzien van, onder andere, een onoverwinnelijk change- en release management? Neem dan vooral contact op met één van onze Beschermheren of dames. Wij helpen je graag verder.