Flaws, bugs en vulnerabilities
Wanneer er in de media wordt gesproken over cybersecurity vliegen de termen zoals flaws, bugs, vulnerabilities en exploits je om de oren.
Het is belangrijk om te weten dat binnen de applicatiebeveiliging de termen flaws en bugs niet hetzelfde zijn. In deze blog lichten we de verschillen toe en geven we onze visie over hoe je flaws tijdig kan voorkomen.
Fouten in het ontwerp of (business)logica
Tijdens het bouwen van een applicatie kunnen er op meerdere vlakken zaken misgaan. Zo ook op het vlak van beveiliging.
Fouten met een beveiligingsrisco kunnen grofweg in twee groepen worden onderverdeeld: Fouten in het ontwerp of de (business)logica en fouten die er tijdens het programmeren insluipen. Bij de eerste groep wordt veelal gesproken over flaws en bij de tweede groep over bugs.
Flaws zijn vaak lastiger te corrigeren en vergen soms een ingrijpend redesign om het weer recht te trekken. Op het laatste moment tegen high-risk issues aanlopen die ook nog eens lastig blijken te verhelpen! Het schrikbeeld van menig projectmanager. En doodzonde want juist flaws zijn vaak in een vroeg stadium zichtbaar en kunnen eenvoudig voorkomen worden mits je er vroeg bij bent.
Bugs kunnen ook een grote impact hebben op de security, maar zijn vaak eenvoudig te verhelpen met kleine code wijzigingen.
Voordat we verder in zullen gaan op de risico’s van flaws, nog even een aantal voorbeelden van de verschillen.
Flaws?
Bouw je een nieuwe applicatie dan moet je continue goed blijven nadenken over security om onnodige risico’s te voorkomen.
Hoe ga je bijvoorbeeld je login of het transactiesysteem beveiligen met een One Time Password (OTP), hoe bedenk je de password-reset functie, hoe ga je om met sessies, welke aanpak hanteer je voor je centrale autorisatie laag, hoe versleutel je gegevens, wat wordt je strategie om OWASP Top 10 issues te voorkomen, etc.? Zo maar een paar voorbeelden van onderdelen waar we geregeld grote conceptuele fouten in tegenkomen.
Meestal ligt de oorzaak in het ontbreken van goed uitgedachte specificaties, waardoor de invulling wordt overgelaten aan de “dichterlijke vrijheid” van het ontwikkelteam. Wat uiteraard prima kan als de juiste kennis aanwezig is, maar dat blijkt helaas niet altijd het geval. Geen verrassing dus dat een slechte voorbereiding en gebrekkige specificaties de #1 oorzaken van flaws zijn.
Bugs?
Bugs daarentegen zijn vaak programmeerfoutjes die er tijdens de bouw insluipen. Denk aan het vergeten om een veld goed te valideren, het gebruiken van een onveilige methode, vergeten een cryptografische functie goed te initiëren, een verkeerde berekening, een vergeten autorisatiecheck, een stukje achtergebleven debug-code, etc. Allemaal zaken die zeker een grote impact kunnen hebben op de security, maar over het algemeen nog vrij eenvoudig en goedkoop zijn te herstellen.
De meeste high-risk issues blijken flaws!
De meeste high risk bevindingen uit onze onderzoeken blijken meer flaw dan bug te zijn. Dingen die niet goed zijn uitgedacht met vervelende gevolgen. Kortom, veel organisaties hebben nog steeds moeite met het voorkomen van flaws en het leggen van een goed securityfundament. Wat kun je doen om dit soort verrassingen te voorkomen?
Voorkom last-minute verrassingen
Door vroegtijdig aandacht te besteden aan security. Ik hoor je zuchten en denken, ja die open deur horen we al jaren, maar hoe dan? Zonder de hele Software Development Life Cycle (SDLC)-preek af te draaien (daar zijn inmiddels genoeg boeken over geschreven) staan voor mij persoonlijk de twee volgende praktische acties met stip op #1.
Security brainstorming
Deze tip is voor teams die op het punt staan een nieuwe applicatie of feature te bouwen. Organiseer een “security brainstormsessie” zodra je helder hebt wat je wilt gaan bouwen (functioneel ontwerp) en hoe je het wilt implementeren (frameworks, talen, platformen etc.). Niet te vroeg, maar ook zeker niet te laat doen dus.
Het doel van de sessie is om een lijst te maken van alle (technische) risico’s en aanvalsvectoren die van toepassing zijn op jouw applicatie en uiteraard ook de benodigde maatregelen om ze te voorkomen. Houdt het praktisch en sla niet door met allerlei formele methodes en hele boekwerken aan papier. Een simpele praktische tabel, bijvoorbeeld een excel-sheet, is meer dan voldoende.
Zo heb je met een paar uurtjes alle concrete security requirements inzichtelijk en kun je weken werk en een hoop (security) ellende achteraf besparen. Zorg dat het concreet genoeg is om mee te geven aan het bouwteam.
Het belangrijkste is dat je ervoor zorgt dat een ervaren software security engineer de sessie leidt. Heb je die niet intern, betrek deze dan van buiten. Dit hoeft echt niet veel te kosten en is de beste security investering die je kunt doen.
Bij Securify zijn we fan van de OWASP Application Security Verification Standard (ASVS). Deze lijst van standaard security requirements biedt ook een uitstekend startpunt om zelf aan de slag te gaan met het helder krijgen van je eigen security requirements. In een volgend blog zullen we dieper ingaan op hoe je een dergelijke sessie, bekend als threatmodeling in het vakjargon, aan kunt vliegen.
Werp een tussentijdse blik op de code
Ben je inmiddels lekker op weg met de bouw, voer dan een tussentijdse security code-review uit. Flaws zijn namelijk al vroeg te identificeren vanuit de code en des te vroeger je ze vangt, des te eenvoudiger er kan worden bijgestuurd.
Het ideale moment van een dergelijke tussentijdse check is zodra de (security) basis van je applicatie staat. Wat vaak al op 25-50% van je bouwtraject is! Voor een doorsnee applicatie is dat bijvoorbeeld zodra de volgende zaken (nagenoeg) gereed zijn: authenticatie en autorisatie, sessie management, afhandeling van gebruikersinvoer, een aantal frontend-schermen en de database interactie.
Verifieer dus vroegtijdig of er geen grote blunders in het fundament zitten en of er optimaal gebruik wordt gemaakt van de security features van gebruikte frameworks e.d.
Bij onderzoeken die wij achteraf uitvoeren blijkt helaas vaak dat de grootste lekken er al heel lang inzitten en met een simpele tussentijdse check al vroeg gevangen en (toen nog eenvoudig) verholpen hadden kunnen worden.
Houdt er rekening mee dat er voor deze check nog niet persé een werkende testomgeving nodig is. Wacht daar dus niet op! Een blik op de code is vaak al voldoende. En ook dit hoeft weer geen grote investering te zijn en zal zich ruim terugbetalen.
Flaws zijn automation proof!
Uiteraard kan tegenwoordig een blog over security niet worden afgesloten zonder het ook even over security automation te hebben.
Waar sommige type bugs goed gedetecteerd kunnen worden met een code scantool geldt dit helaas niet voor flaws. Net zoals een spell-checker de inhoud van deze blog niet snapt en jou niet kan vertellen of de volgorde van de alinea’s wel kloppen, het inhoudelijk wel deugd en of mogelijk belangrijke onderwerpen ontbreken. Want flaws worden juist vaak veroorzaakt door code die er niet is en er dus wel had moeten zijn. Flaws zijn dus compleet onzichtbaar voor je code analyse tool.
Meer over deze “automation gap” en onze ervaringen met Static Code Analysis (SCA) tools in een volgend blog.
In een notendop
Flaws zijn:
- ontwerpfouten die vaak in het begin van het project of bij nieuwe features optreden
- resulteren vaak in high risk issues
- zijn al vroeg zichtbaar en dan nog gemakkelijk te verhelpen
- voorkom flaws door vroegtijdige security brainstorms en tussentijdse code-reviews
- flaws zijn helaas “automation proof” (onzichtbaar voor geautomatiseerde code scan tools).
Happy flaw hunting!
~ David