Risico’s met compliance en CI/CD

De compliance eisen verschillen per norm of wetgeving. Denk bijvoorbeeld aan de NEN 7510 specifiek voor de zorg. De kwaliteit van dienstverlening in deze sector is soms zelf van levensbelang. Naast het borgen van de kwaliteit, vereist de norm NEN 7510 dat de informatiebeveiligingsmaatregelen op een zo’n manier is ingericht dat het controleerbaar is en adequaat. Of de PCI-DSS (Payment Card Industry Data Security Standard) voor organisaties die gegevens van kaarthouders opslaan en verwerken. Het doel van de PCI-DSS is om gegevens te beschermen, fraude beperken en het risico op een datalek te verkleinen.

Voor deze normen moet er een proces komen die bestaat uit het ontwikkelen, onderhouden, evalueren en continu verbeteren van een set maatregelen om te garanderen dat de gegevensverwerking betrouwbaar is. Men moet kunnen aantonen dat informatie is beschermd tegen onrechtmatige toegang en bewerking ervan, dat eventuele gevolgen van security incidenten worden beperkt en dat de continuïteit van de informatie(voorziening) is geborgd.

Hoe controleer je nu of deze compliance eisen worden gehaald? Dat kan je meten met de properties van een systeem, deze te valideren aan een set van beperkingen en de resultaten te valideren en vast te leggen. Wat verstaan we hieronder?

• Properties: een objectief te meten onderdeel van een systeem.
• Meting: een test die een eigenschap van het systeem meet.
• Bewijs: de gemeten waarde. Dit kunnen cijfers zijn, of een waar of onwaar.
• Beperkingen: grenzen waarbinnen een property aan moet voldoen om compliant te zijn.
• Validatie: vergelijking van het bewijs van een specifieke beperking, waaruit blijkt dat het systeem overeenkomst met een specifieke eis.

Een voorbeeld zou kunnen zijn om uit de de webapplicatie (meting) een lijst met open poorten op te stellen (bewijs) en te valideren dat alleen bepaalde poorten of een max aantal poorten open staat (beperking).

Een complexer voorbeeld zou kunnen zijn om een container te scannen (meting) aan de hand van een lijst met bekende en veel voorkomende kwetsbaarheden (CVE’s) om te zien of de container hier kwetsbaar voor is (bewijs) en te valideren dat er geen CVE’s zijn die niet als bekende risico’s zijn geaccepteerd (beperking).

Uitdagingen met compliance en audits in het CI/CD proces

Door de groei van microservices en de adoptie van de DevOps methodiek is het handmatig nalopen van compliance en risicoblootstelling niet schaalbaar.

Met de snelheid van development lopen compliance auditors tegen de volgende uitdagingen aan:

1. Met continuous delivery kunnen organisaties duizenden changes per week doorvoeren. Dit tempo is niet bij te houden voor compliance officers.
2. Het controleren van policies is niet schaalbaar uit te voeren, zeker als er talloze microservices en pipelines zijn.
3. Compliance officers houden het beleid in documenten bij. Elke aanpassing in het beleid op organisatorisch niveau maakt het moeilijk voor hen om de wijzigingen in een bestaand proces in realtime door te voeren vanwege de overvloed aan documentatie.
4. Elke keer als het beleid niet wordt nageleefd of er onbedoelde fouten gebeuren, zoals een onbevoegd persoon die een wijziging of applicatie implementeert tijdens piekuren, kan er schade toegebracht worden aan de bedrijfsresultaten.

Risico’s bij handmatige compliance checks

De handmatige checks zijn misschien wel de meest simpele vorm van het compliance proces. De compliance officer definieert de lijst van eisen. Het development team vult de checklist van deze eisen in en levert deze in ter controle. Bij goedkeuring kan het DevOps team dan de features uitrollen. Dit proces wordt steeds bewerkelijker als het vaker moet gebeuren en in meer details als er steeds meer en sneller features worden uitgerold.

Vertragingen

Niet alleen het volume, maar ook de onregelmatigheid wanneer releases gedaan worden brengt complexiteit met zich mee. De lijst met eisen wordt groter en complexer, wat vraagt om meer tijd en moeite van zowel het development team als het compliance team. Als het compliance proces niet efficiënt is kan het de vertragende factor zijn hoe snel development kan uitrollen en business value kan leveren.

Schaduw IT

Als het compliance team overbelast raakt en de lijn van teams die wachten op goedkeuring groeit, dan bestaat de kans op “schaduw IT”. DevOps team kunnen dan de compliance ondermijnen of zelf vermijden wat gecompromitteerde ontwerp- en architectuur beslissingen oplevert.

Hoe moet je risico’s bepalen?

Een ander punt in het compliance proces is hoe betrouwbaar het proces zelf is. Welke vragen moet je stellen om de risico’s in het proces te bepalen? Als een developer toegang heeft tot de infrastructuur, zou een developer dan kunnen inloggen en ongewenste veranderingen aan de code doorvoeren op zo’n manier dat het niet zichtbaar is in de Source Code Management of in audit logs? Hoe kan je dit wel controleren?

Het begrijpen van de mogelijke risico’s zorgt ervoor dat je als organisaties de juiste stappen onderneemt om risico’s te mitigeren. Misschien kan dat zijn om een zero trust model te implementeren of security vanaf het begin bij development te betrekken.

Compliance gaat niet automatisch

Compliance in het DevOps proces is niet automatisch in orde. Bewust zijn van de risico’s zijn van de risico’s is de eerste stap, daarna moet gekeken worden hoe deze risico’s te mitigeren. Om mee te gaan met de snelheid van het DevOps proces kan automatisering een uitkomst bieden om zo compliance checks na te lopen.

Gelukkig zijn er mogelijkheden om compliance officers en auditors tevreden te stellen, zoals:

• Maak pipeline runtime policies om verschillende software-release parameters en implementatievoorwaarden te controleren voordat een pipeline wordt uitgevoerd.
• Definieer een pipeline policy management voor de principes voor het maken, wijzigen en verwijderen van een pipeline.
• Bepaal een enkel, uniforme manier om te kijken naar andere parameters zoals de applicatie, status, start- en eindtijd van uitvoering, enzovoorts.
• Consolideer de resultaten van verschillende pipelines om te controleren of bepaalde policies zijn aangeroepen bij de uitvoering van specifieke pipelines zodat je ervoor kunt zorgen dat DevOps-proces veilig verloopt en aan alle compliancy eisen voldoet.

Het zijn niet de makkelijkste zaken om te implementeren, maar wij kunnen je wel adviseren in dit proces. Dit doen we met DevOps on Demand. Of je nu voor een klein project, of een groot traject ondersteuning nodig hebt, wij staan voor je klaar.

Dev(sec)Ops ondersteuning nodig? DevOps on demand van Cyso versnelt jouw software development lifecycle.

De DevOps methode wordt door steeds meer organisaties ingezet om sneller en veiliger software te ontwikkelen. Ben jij op zoek naar Dev(Sec)Ops ondersteuning of advies voor jouw project? Neem dan contact op met Cyso.