Wat als niet álle securitylekken zijn te dichten?

Als security-bewuste ontwikkelaar is het bijdragen aan een legacy software-ontwikkelingsproject hetzelfde als het erven van een oud huis. Een oud huis met ontbrekende dakpannen, druppelende badkamerkranen, een voordeur die niet goed sluit, een hal die je moet opknappen en waar zorgwekkende scheuren in de fundering zitten. Je weet dan niet zo goed waar te beginnen.

De securityproblemen van applicaties kunnen net zo vervelend en divers zijn. Ze hebben bijvoorbeeld verouderde afhankelijkheden van oudere versies van softwarebibliotheken. Ze kunnen verkeerd geconfigureerd zijn met gebruik van onveilige protocollen. Ze zouden ook opensource-componenten met bekende kwetsbaarheden kunnen gebruiken, zoals de recent ontdekte CVE-2021-44228, oftewel log4j.

Als we de vergelijking doortrekken, zijn afgeschreven afhankelijkheden te vergelijken met een kapot dak. Als het aanpakken ervan wordt uitgesteld, kan een klein probleem al snel veel groter worden. Het gebruik van onveilige protocollen is te vergelijken met een kapot deurslot; beide zijn gemakkelijke ingangen voor indringers. De gebarsten funderingen zijn vergelijkbaar met kwetsbare opensource-bibliotheken: op elk moment kan een complete ramp uitbreken, of dat nu is doordat een kwaadwillende mijn applicatie aanvalt of doordat een storm mijn huis omver werpt.

Met zo’n lange lijst van problemen is het, in beide gevallen, moeilijk om prioriteiten te stellen van wat we als eerste moeten repareren. Alleen al het aantal problemen kan tot verlamming leiden, of ontwikkelaars (van zowel codes als huizen) ertoe aanzetten de hele zaak af te breken en opnieuw te beginnen.

Inspanning vs. impact

Een eenvoudig systeem om acties te prioriteren, kan een krachtig hulpmiddel zijn. Triage, oftewel het stellen van prioriteiten tussen de taken en veranderingen die nodig zijn om de security van een applicatie te verbeteren, is een effectieve manier om je taken te categoriseren. Je kan dan allereerst beginnen met het toekennen van een score aan de hoeveelheid impact die een oplossing heeft, die vaak samenhangt met de ernst van een kwetsbaarheid. Ernstige kwetsbaarheden die actief worden uitgebuit, zouden dan hoog scoren. Kwetsbaarheden die meer een kwestie van hygiëne zijn, scoren laag.

Geef naast deze scores ook een score voor de hoeveelheid moeite die het kost om het probleem op te lossen. Vervanging van een groot stuk functionaliteit heeft uiteraard een hoge score, terwijl vervanging van een afhankelijkheid voor een andere, bijgewerkte versie sneller zou zijn opgelost, en dus een lagere score heeft.

Op dit punt zal je lijst met taken binnen de volgende vier categorieën vallen:

• Taken met een hoge impact, maar die niet veel inspanning vergen. Die zouden je eerste prioriteit moeten zijn: dit zijn de laaghangende vruchten die een groot verschil maken voor de security van de applicatie, zonder veel tijd te kosten;
• Dan komen de taken die een grote impact hebben, maar ook een aanzienlijke hoeveelheid inspanning vereisen. Dit zijn je volgende grote projecten die je gestaag moet aanpakken zodra de easy wins zijn voltooid;
• Taken met een lage impact en een lage inspanning. Deze moeten onderaan op de takenlijst staan: werk ze af tussen grotere taken of wanneer je op iets anders wacht;
• Taken die veel inspanning vergen, maar weinig impact hebben. Deze komen nog verder onderaan de lijst. Misschien kun je bij deze taken beter overwegen om een alternatieve aanpak te vinden om de benodigde inspanning te verminderen.

De twee dimensies impact en inspanning zijn misschien voldoende om taken te prioriteren. Echter, met langere lijsten of misschien een eerste securitycontrole van een bestaande applicatie, kan dit nog steeds erg lange lijsten opleveren. Hier komt een derde dimensie goed van pas: waardoor jouw triagekaart verandert in een kubusvormig model, waarin je prioriteiten zijn gecategoriseerd. Maar in plaats van te denken in 3D, zal een eenvoudig scorings-algoritme meestal meer helpen.

Derde dimensie: exploiteerbaarheid

De derde dimensie kan exploiteerbaarheid zijn. Een toepassing kan uitzonderlijke kwetsbaarheden bevatten. Er zijn bijvoorbeeld lang bestaande problemen met bijna elk besturingssysteem en elke programmeertaal, en voorbeelden van randgevallen met veel gangbare opensource–bibliotheken. Als er echter niet aan alle voorwaarden is voldaan om deze kwetsbaarheden uit te buiten, vermindert dat de urgentie om de kwetsbaarheid te verhelpen.

Als een kwetsbaarheid bijvoorbeeld op geen enkele manier zichtbaar is voor een aanvaller, of als een kwetsbaar commando niet wordt gebruikt binnen een project, dan wordt de urgentie van een oplossing kleiner. De kwetsbaarheden moeten op een gegeven moment nog steeds worden verholpen. De omstandigheden kunnen veranderen en een kwetsbaarheid die nu niet kan worden misbruikt, kan dat in de toekomst wel worden. Maar deze toegevoegde lens geeft duidelijkheid over de taken die prioriteit hebben.

Deze derde dimensie moet helpen om kwetsbaarheden te sorteren, ongeacht hoe slordig het lopende project ook is. Het biedt een solide aanpak om elke kwetsbaarheid op de juiste plaats te zetten in de lange lijst van taken die mogelijk moeten worden uitgevoerd.

Vooral wanneer de takenlijst lang is, zal je hulp nodig hebben. Aangezien elk element van automatisering organisaties wapent om op systematische wijze bedreigingen te bestrijden, is automatisering de sleutel tot een effectievere uitvoering van taken op je triagekaart.

Triage is een essentiële eerste en doorlopende stap. Het combineren van deze methodes en dev-first tools zal de triage, de initiële hardening, en de doorlopende applicatie-security verbeteren.

(Auteur Daniel Berman is product marketing director bij Snyk.)