De meeste programma’s voor applicatiebeveiliging kunnen vertellen wat ze vorig kwartaal hebben gedaan. Veel minder kunnen vertellen of het heeft gewerkt. De stream Measure and Improve van OWASP SAMM bestaat om dat gat te dichten.
Dit artikel is community-guidance voor de stream Measure and Improve in de practice Strategy and Metrics van SAMM. De bijbehorende OpenCRE-vermelding is Steer the secure software development program. De metrics hieronder gaan over softwareontwikkeling in R&D-teams. Operationele securitymetrics, zoals patchniveaus van productieservers of klikratio’s bij phishing, zijn een ander onderwerp.
Wat een goede metric is
Volgens SAMM meten deze metrics de effectiviteit en efficiëntie van uw programma voor applicatiebeveiliging. Houd dat in gedachten terwijl u de lijst opstelt. Elke metric moet het applicatiebeveiligingsteam iets vertellen wat het moet weten om zijn eigen doelen te halen. Een metric waar niemand iets mee doet, is overhead.
Elke metric moet bovendien:
- elke keer op dezelfde manier meetbaar zijn, zodat trends iets betekenen
- goedkoop genoeg zijn om te verzamelen, het liefst automatisch uit tools die u al gebruikt
- uitgedrukt worden als getal of percentage, met een duidelijke eenheid
Leg elke metric vast met naam, formule, eenheid, gegevensbron, meetfrequentie en eigenaar. Die ene regel documentatie voorkomt later de meeste discussies over de cijfers.
Drie categorieën: inspanning, resultaat en omgeving
Op volwassenheidsniveau 1 legt het securityteam metrics vast in alle drie de categorieën die SAMM onderscheidt: inspanning (effort), resultaat (result) en omgeving (environment). Het belangrijkste is begrijpen hoe inspannings- en omgevingsmetrics de resultaatmetrics beïnvloeden.
Dat verband neemt u ook mee naar het management. Bestuurders geven om resultaten, maar ze kunnen alleen in inspanning investeren. Als u kunt laten zien welke inspanning welke resultaten verbetert, zijn investeringsbeslissingen veel makkelijker te onderbouwen.
De kaart hieronder toont voorbeeldmetrics per categorie, met lijnen die laten zien hoe ze elkaar beïnvloeden. Gebruik hem als vertrekpunt en pas hem aan op de doelen van uw eigen programma.
Inspanningsmetrics
Inspanningsmetrics meten hoeveel werk er in securityactiviteiten gaat. Ze tellen vooral activiteiten die op zichzelf geen resultaat zijn, maar wel helpen om resultaten te bereiken.
Voorbeelden:
- aantal securitytrainingen, of het totale aantal trainingsuren
- aantal bezochte externe securityevenementen, zoals workshops, conferenties en communitybijeenkomsten
- aantal interne communicaties over security
- tijd besteed aan security code reviews
- aantal architectuurreviews met focus op security
- aantal threat modeling-sessies
- aantal penetratietests
- aantal reviewsessies voor securityeisen in functionele aanvragen
- aantal gesloten securitydefecten in uw issuetracker, zoals Jira
- aantal gesloten bevindingen in SCA-, SAST- en DAST-tools in een bepaalde periode
- budget besteed aan securitytools en licenties
- aantal uitgevoerde OWASP SAMM-assessments
Resultaatmetrics
Resultaatmetrics meten hoe effectief de securityinspanning is. Op volwassenheidsniveau 2 van deze stream kiest u de belangrijkste daarvan als kern-KPI’s van uw programma voor applicatiebeveiliging en stelt u er doelen voor.
Voorbeelden:
- dekking van securitytraining: getrainde mensen gedeeld door de mensen die getraind zouden moeten zijn
- securitybewustzijn: gemiddelde scores van quizzen of enquêtes na een training
- totaal aantal security champions
- dekking van security champions: teams of producten met ten minste één champion gedeeld door alle teams of producten
- instroom van securityincidenten: nieuwe incidenten in een bepaalde periode
- kosten per incident, in geld of persoonsdagen
- gemiddelde tijd tot een patch, of tot het sluiten van een incident
- tooldekking: applicaties of repositories die SCA, SAST en DAST scannen, gedeeld door de applicaties of repositories die gescand zouden moeten worden
- open SCA-bevindingen, of de totale risicoscore van afhankelijkheden van derden
- kritieke kwetsbaarheden in componenten van derden die ouder zijn dan 90 dagen
- open securitybevindingen uit SAST
- open securitydefecten in uw issuetracker
- serviceniveaus: gemiddelde tijd om securitydefecten en incidenten op te lossen, en de totale kosten daarvan in persoonsdagen
- dekking van SAMM-assessments: scopes met een recent assessment gedeeld door alle scopes
Omgevingsmetrics
Omgevingsmetrics beschrijven de context waarin het securitywerk plaatsvindt. Ze helpen u de omvang en complexiteit van het programma te begrijpen. Ze hoeven niet aan securitytools of activiteiten gekoppeld te zijn, maar u hebt ze nodig als input voor de resultaatmetrics, vooral als noemer van dekkingspercentages.
Voorbeelden:
- aantal scopes in de organisatie die u voor SAMM-assessments gebruikt
- totaal aantal producten of applicaties
- aantal producten of applicaties dat DAST zou moeten dekken
- aantal gebruikte componenten van derden
- totaal aantal ontwikkel-, QA- en operationsteams, en het aantal mensen daarin
- beschikbaar budget voor externe securityevenementen en training
- beschikbaar budget voor securitytools en licenties
- aantal security officers
Hoe de categorieën samenhangen
Een paar verbanden uit de kaart laten zien hoe dit in de praktijk werkt:
- Meer trainingsuren horen de trainingsdekking en de bewustzijnsscores te verhogen en het aantal security champions te laten groeien.
- Threat modeling-sessies, architectuurreviews en penetratietests horen de incidentinstroom, de kosten per incident en de tijd tot een patch te verlagen.
- Het sluiten van SCA-, SAST- en DAST-bevindingen verlaagt het aantal open bevindingen, zolang er niet sneller nieuwe bijkomen.
- Budget voor tools verhoogt de dekking van SCA, SAST en DAST, afgezet tegen het aantal applicaties uit uw omgevingsmetrics.
- Het uitvoeren van SAMM-assessments verhoogt de assessmentdekking, afgezet tegen het aantal scopes.
Als een resultaat niet beweegt terwijl de inspanning omhoog is gegaan, is dat een gesprek waard. Misschien richt de inspanning zich op het verkeerde, of is de omgeving sneller gegroeid dan het programma.
Metrics voor de voorbereiding op de CRA
Maakt u producten met digitale elementen voor de Europese markt, dan geeft de Cyber Resilience Act sommige resultaatmetrics een juridische lading. Deze zijn het waard om aan uw lijst toe te voegen:
- producten met een actuele SBOM gedeeld door alle producten binnen de scope
- producten met een vastgestelde en gepubliceerde ondersteuningsperiode
- mediane tijd om kritieke kwetsbaarheden in ondersteunde productversies op te lossen
- kritieke kwetsbaarheden in componenten van derden zonder oplossing of mitigatieplan
- producten die onder een gepubliceerd beleid voor coordinated vulnerability disclosure vallen
- tijd tussen het bekend worden van een actief uitgebuite kwetsbaarheid en de vroegtijdige waarschuwing binnen 24 uur, gemeten in oefeningen voordat u het echt nodig hebt
Onze CRA-gids voor het mkb legt de verplichtingen daarachter uit, en OWASP Dependency-Track kan een aantal van de SBOM-cijfers en cijfers over kwetsbaarheden van derden automatisch leveren.
Van metrics naar KPI’s
Het definiëren en vastleggen van uw Measure and Improve-metrics is de stap vóór volwassenheidsniveau 2, waarop u de KPI’s uit uw resultaatmetrics kiest en er doelen voor stelt. Begin klein. Vijf metrics die u elke maand betrouwbaar verzamelt, zijn meer waard dan dertig die u één keer verzamelt.
Wilt u een onafhankelijk beeld van waar uw programma staat? Ons SSDLC Maturity Assessment gebruikt OWASP SAMM om uw huidige werkwijze te scoren en een verbeterroadmap op te stellen.