(Blog) Moderne cloud native-applicaties en de DevSecOps-cultuur zorgen voor een nieuwe reeks uitdagen als het gaat om het meten van security; een onderwerp dat altijd al lastig is geweest.
Van oudsher werd security gemeten op een regelmatige maar periodieke manier. De snelheid waarmee veranderingen plaatsvinden in cloud-native organisaties die DevSecOps en/of CI/CD hebben geïmplementeerd is echter meedogenloos. Doordat er meerdere implementaties op één dag worden uitgevoerd, moet de kijk op het meten van security drastisch veranderd worden. Je kunt niet elke x-aantal dagen een securitytest uitvoeren en verwachten dat dit waardevolle informatie geeft.
Misleidende metrics
Meetmethodes die worden gebruikt om security te meten, zijn bovendien soms misleidend. Het aantal onopgeloste kwetsbaarheden in applicaties lijkt een objectieve maatstaf, maar toch is dit niet altijd het geval. Stel, een team rapporteert 400 kwetsbaarheden in hun applicatie, terwijl een ander team er maar 20 meldt. Je zou denken dat het qua security beter gesteld is bij de applicatie van het team dat minder kwetsbaarheden rapporteert, maar dat hoeft niet zo te zijn. Wellicht is de andere applicatie wel veiliger, maar het team veel zorgvuldiger in het melden van kwetsbaarheden.
Een tweede moeilijkheid is dat niet alle kwetsbaarheden gelijkwaardig zijn. Zo kan het zijn dat de 400 kwetsbaarheden die waren gevonden door team 1 er niet voor zorgen dat criminelen toegang krijgen tot privégegevens, terwijl de 20 die zijn gerapporteerd door het andere team een bedrijf in grote problemen kan brengen. Voor bedrijven is het daarom belangrijk om te bepalen wat ernstige en minder ernstige kwetsbaarheden zijn en hier een weging in mee te nemen.
Een andere behulpzame metric is de tijd die nodig is om kwetsbaarheden op te lossen. Maar ook hier moet je voorzichtig mee zijn. Sommige kwetsbaarheden zijn vrij snel op te lossen, maar anderen vragen om veel meer werk. Bijvoorbeeld als je een feature opnieuw moet ontwerpen om een oplossing te creëren die niet afhankelijk is van een bepaalde bibliotheek. Dus terwijl de ene developer 20 kwetsbaarheden oplost in een ochtend, is de ander een hele ochtend bezig met maar één, maar deze developer moest veel harder en creatiever werken dan de eerste. Het is daarom belangrijk om het volledige verhaal te horen en de context te begrijpen.
Kortom, het meten van security moet een continu proces zijn, omdat de periodieke meetmomenten al snel niet accuraat meer zijn. Ten tweede zijn eenvoudige metrics vaak misleidend. Een stijging of daling van een bepaalde metric kan zowel positief of negatief zijn, afhankelijk van gerelateerde metrics.
Tegelijkertijd moet het management een betrouwbaar en makkelijk te begrijpen inzicht krijgen in de veiligheid van hun applicaties. Hierdoor kunnen zij datagedreven beslissingen nemen, goede prestaties herkennen en begrijpen wanneer er meer geïnvesteerd moet worden.
Metingen werkelijkheid maken
Om het hoge tempo van moderne softwareontwikkeling aan te kunnen, moeten realtime datavisualisaties ‘snapshotscores’ vervangen. Teams moeten statistieken kunnen leveren en de relatie tussen die cijfers begrijpen: het aandeel van kwetsbaarheden op laag niveau heeft bijvoorbeeld invloed op het aandeel problemen op hoog niveau, en waarschijnlijk ook op het totale aantal. De securitymetingen van de organisatie zal al deze cijfers bevatten, samen met de gemiddelde tijd tot herstel, input van SAST- en DAST-tools, het aantal commits en andere bronnen.
De volgende stap is om de relaties tussen deze cijfers te begrijpen en om duplicaties te verwijderen: als je bijvoorbeeld al het aantal kwetsbaarheden op laag en hoog niveau hebt, dan voegt een afzonderlijke meting van het totale aantal kwetsbaarheden geen waarde toe. Het kan zelfs tot verwarring leiden.
Visualiseren van de flow
Probeer de relaties tussen cijfers te plotten met behulp van bijvoorbeeld causale diagrammen. Deze leggen niet de nadruk op een lineaire, eenzijdige oorzaak-en-gevolgsituatie, maar visualiseren de continue en dynamische aard van de informatie. In het geval van security statistieken moeten we laten zien hoe veranderingen in data-elementen elkaar zullen beïnvloeden. Ten tweede zijn causale diagrammen bedoeld om nooit af te zijn. Je kunt eenvoudig nieuwe nodes en loops toevoegen. Dit is ideaal omdat er in de loop van de tijd nieuwe data-elementen uit nieuwe cloud-native technologieën zullen ontstaan.
