Auteur: Edward van Deursen ● evandeursen@sysqa.nl
Heb je de thema-avond Security op 7 december al in jouw agenda gezet?
Zelf merk ik dat veel testers security op een of andere manier uit de weg gaan. Men vindt dat men er onvoldoende van weet en dat het nogal technisch is. Dat laatste is in sommige gevallen waar terwijl het eerste over het algemeen erg meevalt. Tijdens onze presentatie wordt duidelijk dat je onbewust al veel securitytesten uitvoert. Op een of andere manier voert iedere tester wel testgevallen uit die een security kwaliteitskenmerk raakt. Met deze bewustwording kijken we verder naar het securitytesten.
Wat is BIR, BIG of BIWA?
Voor de overheid gelden diverse security normen zoals Baseline Informatiebeveiliging Rijksdienst (BIR) en Baseline Informatiebeveiliging Gemeenten (BIG). Beide zijn bijna identiek overigens. Het verschil zit vooral in de functionarissen die worden benoemd. In beide gevallen moeten ze hetzelfde doen, alleen hebben ze een andere naam binnen de rijksoverheid en gemeenten. Zo wordt in BIG gesproken over Chief Information Security Officer (CISO) terwijl in BIR over Beveiligingsambtenaar (BVA) en BVC (Beveiligingscoördinator) wordt gesproken. Lekker belangrijk, maar zo werkt dat nu eenmaal binnen de overheid.
BIWA is een baseline voor waterschappen die gebaseerd is op BIR en BIG. Ook hier dus minimale verschillen.
Waarom?
De overheidsinstanties zijn verplicht zich aan deze BIR/BIG/BIWA normen te houden. En eigenlijk moeten ook de ketenpartners en leveranciers aan de BIR voldoen om de (rijks)instanties aan de BIR te laten voldoen. Indien een organisatie goed beveiligd is, dan wordt door een hacker wel naar een andere weg gezocht om binnen te komen. De BIR is ook voor bedrijven een goed uitgangspunt, al is de onderliggende basis (ISO 27002:2005) ondertussen vervangen door een nieuwere variant.
En dan?
Er zijn mooie baselines opgesteld maar daarmee is de organisatie niet meteen veilig. Er moet het nodige gebeuren om de werkwijzen en genoemde normen om te zetten in effectieve maatregelen. Maatregelen die ook nog eens werkbaar zijn. Wij merken dat veel organisaties moeite hebben deze high-level normen om te zetten in goede maatregelen. Daarnaast merken we dat de normen niet worden gebruikt bij de reguliere testen. Security wordt als een los onderdeel gezien en bijvoorbeeld niet al tijdens ontwerp, bouw of functioneel testen meegenomen. Veelal wordt pas achteraf, vlak voor livegang, een pentest (penetratietest of hackerstest) gedaan. Pentesters vinden veelal andere fouten dan alleen fouten in de software. Vaak gaat het om misconfiguraties van netwerk en servers. En een pentest is nooit een veelomvattend vangnet… Het uitvoeren van een pentest alleen geeft schijnzekerheid.
Wat moeten wij als (functioneel) testers hier mee?
Maar wat kunnen wij testers nu eigenlijk met deze BIR, BIG of BIWA norm? Wat is hierin nu belangrijk voor een tester? Hoe kunnen we hieruit goede testgevallen opstellen? Ondanks dat de BIR veel over processen en procedures gaat, zijn er toch wel software-requirements en securitytesten aan te relateren. Er is een aantal securitytest frameworks die aanknopingspunten bieden. Een belangrijke is bijvoorbeeld de OWASP Testing Guide. We nemen voorbeelden die ook door testers zonder specifieke securityopleidingen kunnen worden uitgevoerd. Wij zijn van mening dat ook niet-securitytesters veel security issues kunnen vinden. Testers lopen al de hele applicatie door en als je vanuit de juiste (hackers)mindset naar een applicatie kijkt, zul je verbaasd staan hoeveel security issues er nog in een applicatie zitten…
Waar gaat de presentatie over?
Tijdens de meeting op 7 december gaan we in onze (duo)presentatie dieper op bovenstaande in. In het kort wordt de BIR/BIG/BIWA uitgelegd door een collega die dagelijks met de BIR-normen bezig is. Ze weet hoe je de BIR moet lezen en licht een aantal BIR-normen toe. We kijken naar de belangrijkste normen die voor iedere tester interessant zijn. De belangrijkste BIR-normen leggen we vervolgens tegen testen vanuit de OWASP Testing Guide aan. En gaan we met name op zoek naar een aantal generieke securitytestgevallen die niet in een (regressie)testset mogen ontbreken. Vervolgens kunnen jullie met de opgedane kennis zelf de set uitbreiden. We geven tips en voorbeelden waarmee je eerder de functionele security issues vindt. Op deze wijze wordt de basis gelegd voor veiligere software in de (nabije!) toekomst.
Tot 7 december!
NieuwsMagazine