Alweer even geleden bezocht ik de Testnet avond over security testen.

Eelco Stofbergen trapte de avond af met de mededeling dat security testen eigenlijk ook functioneel testen is. Maak de PO er bewust van ook security requirements op te stellen. Zodra die requirements er zijn, test je functioneel of die requirements gehaald worden, ja dan wel nee. Daarbij is het van belang de PO te begeleiden om tot deze security requirements te komen. Dit kan o.a. door het opstellen van abuse cases, die voor te leggen aan de PO en af te stemmen wat het gewenste gedrag is in die situaties. Bij security testen geldt nog meer dan bij “gewoon” testen dat je alle risico’s alleen voorkomt als je alles test. Je moet dan vaak ook breder denken dan alleen technisch. Bijvoorbeeld ook aan de mensen die het product gaan gebruiken. Kunnen ze geen “foute” link aanklikken zonder dat ze dit doorhebben? Is een security-melding duidelijk genoeg? Passen ze wel de juiste controles toe bij een telefonisch verzoek?

Vroeger en nu

Vroeger hackten vooral script kiddies om stoer te doen. Inmiddels doen steeds meer professionele (overheids)hackers dit voor macht en geld. Heel belangrijk is dus je goed af te vragen vanuit welk oogpunt je test. Test je tegen hackers die willen slopen (ddos) of een voordeel halen, bijvoorbeeld een foutieve transactie uitvoeren.
Door vroeg te testen op security en door goed te monitoren, kun je handelen op dreigingen en niet alleen reageren na incidenten.

Code verification

Verificatie van je code middels tools is heel belangrijk. Iedereen maakt fouten, maar laat het nou niet dezelfde fouten zijn als die duizenden al maakten. Die merken code verificatie tools dus op.
Via deze link zie je de 25 meest gemaakte fouten in software. Een deel daarvan vind je middels code verification tools. Verder brengt de OWASP elke 4 jaar de OWASP top 10 uit met de 10 meest voorkomende security issues. Iedere 4 jaar klinkt misschien vreemd en traag. Waarom niet vaker? Echter vreemd genoeg verandert die lijst niet zo veel na 4 jaar. We maken nog steeds veel dezelfde fouten. Deze lijst is ook zeker goed te gebruiken als checklist. Bevat jouw applicatie geen issues uit die lijst?

Peter Rietveld over testen

Peter spreekt vooral vanuit een berg aan ervaring als pentester, maar ook veel breder als security tester. Zijn ervaring leert dat pentesten duur zijn, veel voorbereidings- en doorlooptijd vergen en daardoor in een agile omgeving beperkt inzetbaar. Erger is dat ze doorgaans wel wat vinden, maar dan veelal de dingen die ook al met handmatige testen gevonden waren. Bovendien vinden ze vaak ook een boel niet, dat met handmatige testen wel gevonden werd. Daarom is Peter geen pentester meer.

Type security issues

Security issues zijn grofweg in 3 groepen te verdelen:

1. Vulnerability: zwakte/kwetsbaarheid in een systeem wat mogelijk misbruikt wordt

2. 0day: een vulnerability die nog niet publiekelijk of bij de vendor bekend is

3. Sploit: een werkend stuk code waarmee een vulnerability misbruikt kan worden.

Sommige bedrijven zijn blij als je ze vulnerabilities meldt, anderen totaal niet en dreigen soms zelfs met een rechtszaak. Weer anderen negeren je bijna: kom maar terug als je een Sploit hebt, een Vulnerability interesseert ons niet zo. Echter zo’n Sploit schrijven, is vaak (heel) veel werk.

CVSS rating

Bekende security issues krijgen een zogenaamde CVSS rating (Common Vulnerability Scoring System) toegekend. Een getal tussen de 0 en 10, waarbij 10 een extreem “gevaarlijk” issue betekent. Deze rating wordt berekend aan de hand van een boel parameters. Een voorbeeld van hoe zo’n rating wordt verkregen vind je hier.

Indien je niet de meest recente versie (updates) van een software product gebruikt, check dan de bekende security issues en hun CVSS rating. Hoe hoger de rating, des te belangrijker wel te patchen of anderszins maatregelen te treffen zoals een firewall of bepaald functionaliteit uitschakelen.

Zoek en gij zult vinden…

Wat je niet zoekt, vind je niet. Kortom, zoek zo breed mogelijk.
Microsoft claimt dat hun code minder dan 0.5 fouten, per 1000 regels, bevatten. Chrome heeft er 0.06, per 1000 regels, en het industriegemiddelde ligt op 15-50 per 1000 regels code. Deze grote verschillen komen o.a. door een verschil in platform, IDE, compiler en taal. In alle software zitten dus nog fouten, ook in potentiële security issues met een hoge CVSS rating. Nu is het alleen nog aan jou om ze te vinden.