Het is erg gemakkelijk gezegd tegen teams dat ze veilige software moeten opleveren veel moeilijker is de uitvoering van deze opdracht. Het opleveren van veilige software is in grote organisaties of organisaties die aan allerlei wet en regelgeving vallen soms een worsteling.
Teams in mijn omgeving zie ik ook worstelen met de vraag wat veilige software dan eigenlijk is. Als je streeft naar autonome teams zul je ze ook maximaal verantwoordelijk moeten maken voor de veiligheid van hun software en omgeving. Maar hoe kun je ze verantwoordelijk maken als je niet eens weet wat er allemaal speelt of als je niet weet hoe alle driecijferige afkortingen gerelateerd zijn aan elkaar. Ik maakte een eenvoudig overzicht van de meest belangrijke zaken.
Creating the software
Het maken van software is een proces waar veiligheid een cruciale rol speelt. Het 4-ogen principe voordat je code merged naar je master branch en Static Code Analysis gericht op secure code zijn twee belangrijke aspecten. Ik heb hierover diverse blogs geschreven (1.Drie belangrijke ingrediënten 2.Vijf reden voor Continuous Compliance)
Running the software and the environment
Als de software eenmaal in productie draait is het zaak dat je dit ook continu controleert. Een pentest gericht op je applicatie, database, middleware en infrastructuur kunnen je hier elk half jaar in ondersteunen. Continue je omgeving scannen met een vulnerability scanning geeft je inzicht in mogelijk zwakheden. (overigens moeten teams hier ook hun footprint proberen te minimaliseren, wat je niet gebruikt zet je uit).
Security Event Monitoring en Technical State Compliancy Monitoring zorgen ervoor dat je weet wie wat wijzigt en geen oneigenlijke wijzigingen worden doorgevoerd. De integriteit en betrouwbaarheid worden hierdoor gewaarborgd.