CWE-classificatie: de encyclopedie van softwarezwakheden
Stel je een naslagwerk voor waarin elke mogelijke bouwfout die een architect kan maken een eigen nummer en beschrijving krijgt: 'fout 79, vergeten een brandtrap te plaatsen' of 'fout 89, verkeerde staalkwaliteit gebruikt in een draagbalk'. Iedereen die met bouwveiligheid bezig is, kan dan met hetzelfde nummer verwijzen naar precies hetzelfde probleem. Zoiets bestaat ook voor software, en dat heet CWE: Common Weakness Enumeration, oftewel een gemeenschappelijke opsomming van zwakheden.
CWE is geen lijst van concrete, ontdekte lekken in specifieke programma's, maar een classificatiesysteem van de soorten fouten die tot kwetsbaarheden kunnen leiden. Elke categorie krijgt een uniek nummer, zoals CWE-79 voor een bepaald type webfout of CWE-89 voor een fout in databasecommando's. Beveiligingsonderzoekers, softwarebouwers en geautomatiseerde scantools gebruiken deze nummers als gedeelde taal, zodat ze het altijd over hetzelfde onderliggende probleem hebben, ook al gaat het om compleet verschillende programma's.
Wat is het precies?
CWE is in essentie een grote, gestructureerde catalogus. Elk item in die catalogus beschrijft een type zwakte in software of hardware: een patroon van fouten dat, als het misgaat, kan leiden tot een beveiligingsprobleem. De catalogus is hiërarchisch opgebouwd: brede categorieën zoals 'fouten in invoervalidatie' vertakken zich naar specifiekere subtypen.
Elk zwaktetype heeft een vast identificatienummer met het voorvoegsel CWE, gevolgd door een cijfer. Enkele bekende voorbeelden: CWE-79 beschrijft Cross-Site Scripting (een fout waarbij een website onbedoeld kwaadaardige code van een aanvaller uitvoert in de browser van een bezoeker), CWE-89 beschrijft SQL Injection (waarbij een aanvaller via een invoerveld schadelijke databasecommando's kan laten uitvoeren), CWE-120 gaat over Buffer Overflow (een programma schrijft meer gegevens in een geheugenruimte dan daar past, met crashes of erger als gevolg), CWE-352 beschrijft Cross-Site Request Forgery (een aanvaller laat een ingelogde gebruiker ongewild een actie uitvoeren) en CWE-798 gaat over hardcoded credentials, oftewel wachtwoorden of sleutels die vast in de broncode staan geschreven.
Het is belangrijk om CWE niet te verwarren met twee andere bekende afkortingen uit de beveiligingswereld. CVE (Common Vulnerabilities and Exposures) is een lijst van specifieke, daadwerkelijk gevonden kwetsbaarheden in specifieke software, bijvoorbeeld een lek in versie 2.3 van een bepaald programma. Zo'n CVE-vermelding verwijst vaak terug naar een of meer CWE-nummers om aan te geven om wat voor type fout het gaat. CVSS (Common Vulnerability Scoring System) is weer iets anders: dat is een puntensysteem dat aangeeft hoe ernstig een specifiek lek is, los van het type fout. Kort gezegd: CWE zegt wát voor fout het is, CVE zegt wáár die specifieke fout is gevonden, en CVSS zegt hoe erg die specifieke vondst is.
Wat wil men ermee bereiken?
Het belangrijkste doel van CWE is het scheppen van een gemeenschappelijke taal. Voordat zulke classificaties bestonden, beschreef iedere onderzoeker, elk bedrijf en elke tool kwetsbaarheden op zijn eigen manier, wat vergelijken en samenwerken lastig maakte. Met een vast nummer voor 'SQL Injection' weten een ontwikkelaar in Nederland en een onderzoeker in Japan meteen dat ze het over hetzelfde probleem hebben.
Daarnaast is CWE bedoeld als bouwsteen voor geautomatiseerde gereedschappen. Zogeheten statische-analysetools scannen broncode op bekende foutpatronen en koppelen hun bevindingen aan CWE-nummers, zodat ontwikkelaars direct weten met welk type risico ze te maken hebben en hoe ernstig dat doorgaans is. Ook helpt de classificatie organisaties om risico's te prioriteren: als blijkt dat een bepaald zwaktetype in de praktijk vaak tot ernstige incidenten leidt, kunnen bedrijven hun ontwikkelaars gericht trainen om juist dát type fout te vermijden. Dat sluit aan bij het bredere streven naar 'secure by design': software zo bouwen dat bekende foutpatronen van meet af aan worden voorkomen, in plaats van pas achteraf te repareren.
Voorbeelden uit de praktijk
CWE is geen abstract idee, maar wordt op verschillende plekken in de dagelijkse beveiligingspraktijk toegepast.
Een bekend voorbeeld is de jaarlijkse CWE Top 25 Most Dangerous Software Weaknesses, een lijst die MITRE in samenwerking met de Amerikaanse cyberbeveiligingsdienst CISA publiceert. Deze lijst wordt samengesteld op basis van een analyse van duizenden daadwerkelijk geregistreerde kwetsbaarheden (CVE's) uit het voorgaande jaar, en laat zien welke typen fouten in de praktijk het vaakst voorkomen en het meeste risico opleveren. De lijst wordt sindsdien met enige regelmaat bijgewerkt, zodat de volgorde verschuift naarmate aanvalspatronen en softwarelandschap veranderen.
Ook in de National Vulnerability Database (NVD), de Amerikaanse overheidsdatabase van CVE-kwetsbaarheden die door NIST wordt beheerd, krijgt vrijwel elke geregistreerde kwetsbaarheid een of meer CWE-labels mee. Zo kun je in die database niet alleen zien dát een lek bestaat, maar ook tot welke bredere foutfamilie het behoort.
Verder gebruiken commerciële tools voor statische codeanalyse (zogeheten SAST-tools, Static Application Security Testing) CWE-nummers om hun bevindingen te labelen, zodat ontwikkelteams meteen weten met welk type probleem ze te maken hebben. Ook de bekende OWASP Top 10, een veelgebruikte lijst van de belangrijkste risico's voor webapplicaties, verwijst voor veel van haar categorieën naar onderliggende CWE-nummers, wat de twee classificaties met elkaar verbindt. Tot slot duiken CWE-verwijzingen ook op in compliance- en auditcontexten, waarbij organisaties moeten aantonen dat ze bepaalde bekende zwaktetypen structureel aanpakken.
Hoe ver is de techniek?
CWE is geen nieuw fenomeen: het initiatief gaat terug tot ongeveer 2006, toen MITRE begon met het opzetten van een gestructureerde catalogus van softwarezwakheden, voortbouwend op eerdere, kleinere classificatiepogingen. Sindsdien is de catalogus voortdurend uitgebreid en verfijnd, met periodieke versie-updates waarin nieuwe zwaktetypen worden toegevoegd of bestaande beschrijvingen worden aangescherpt.
De ontwikkeling is dus geen kwestie van een doorbraaktechnologie die op enig moment 'af' is, maar eerder een doorlopend onderhoudsproces, vergelijkbaar met het bijwerken van een woordenboek. Dat brengt ook bekende knelpunten met zich mee. Sommige categorieën overlappen inhoudelijk, waardoor het classificeren van een concrete fout soms een kwestie van interpretatie is: verschillende analisten kunnen dezelfde fout aan net iets andere CWE-nummers koppelen. Ook is CWE, net als CVE, sterk afhankelijk van Amerikaanse overheidsfinanciering via CISA, wat de continuïteit op de lange termijn gevoelig maakt voor beleidskeuzes in de Verenigde Staten. Bovendien is het gebruik van CWE nergens wettelijk verplicht: het is een vrijwillige industriestandaard die zijn waarde vooral ontleent aan brede acceptatie, niet aan regelgeving.
Wie werken eraan?
De catalogus wordt beheerd door de MITRE Corporation, een Amerikaanse non-profitorganisatie die ook de bekende CVE-database onderhoudt. MITRE voert dit werk uit onder financiering en toezicht van CISA (de Cybersecurity and Infrastructure Security Agency), een onderdeel van het Amerikaanse ministerie van Homeland Security.
Hoewel MITRE de formele beheerder is, komt de inhoud grotendeels tot stand in samenwerking met een bredere gemeenschap van beveiligingsonderzoekers, softwarebedrijven en academische instellingen wereldwijd, die meedenken over nieuwe zwaktetypen en bestaande beschrijvingen aanscherpen. Deze gemeenschap overlapt sterk met het netwerk van zogeheten CVE Numbering Authorities (CNA's): organisaties die bevoegd zijn om nieuwe CVE-kwetsbaarheden te registreren en die daarbij vaak ook CWE-classificaties toekennen. Zo vormen CWE, CVE en de bijbehorende instanties samen een onderling verweven ecosysteem rondom het in kaart brengen van softwarekwetsbaarheden.