Security-testen binnen de “gouden driehoek”

| (Security-)tester aan het woord: Kaan Dolgun

Security-testen binnen de “gouden driehoek”
In de wereld van de zakelijke en financiële dienstverlening die steeds sneller verandert, staat het belang en de tevredenheid van (en de service naar) de klant meer en meer centraal. Omdat dit ook steeds meer wordt verwacht door consumenten zelf, zullen deze bedrijven en organisaties, die voor hun dienstverlening grotendeels afhankelijk zijn van IT, in toenemende mate voor de uitdaging staan om een goede balans te vinden tussen de kwaliteitsattributen: Security, Usability en Functionality.

sec

 

 

 

 

 

 

 

 

Security: Door allerlei afhankelijkheden in de digitale wereld blijft het een uitdaging om je web/app/onderliggende infrastructuur en data veilig te houden. De klant verwacht een veilige, gebruiksvriendelijke en functionele omgeving voor het opslaan en teruglezen van persoonlijke (vaak gevoelige) gegevens.

Functionality: Veranderende gebruikersverwachtingen en wetgeving kunnen andere (zwaardere) eisen stellen aan het onderliggende applicatielandschap en de infrastructuur voor verschillende soorten data.

Usability: Met een steeds sneller wordend internet en gebruikerseisen die hierin meegaan, zullen steeds meer organisaties uit de financiële sector (bank/verzekering/pensioen) een 24-uursbeschikbaarheid van actuele informatie willen leveren.

Jongleren met security
Een organisatie met een complexe IT-infrastructuur heeft soms meer dan 500 bedrijfsapplicaties. De CEO, CFO, CTO, CISO, CIO en CSO hebben elk een ander zorgpunt waarop geanticipeerd moet worden vanuit hun eigen project: het verlies van data, de continuïteit van bedrijfsprocessen, mogelijke uitval van productieomgevingen. De nadruk wordt vaak toch nog gelegd op functionality, waardoor “complexe” security maatregelen zoals Hybride wachtwoorden, periodieke password resets, security tokens te verwijderen, niet worden genomen door de business, die vaak vooral kijkt of de omgeving easy to use is.
De aandacht voor functionality is vanuit business oogpunt niet onbegrijpelijk, maar als je een tijdje meedraait in de wereld van het testen, kom je er achter dat de kwaliteitsattributen usability en security evenveel aandacht nodig hebben aan het begin van het traject. Immers, hoeveel functionaliteiten er ook bedacht worden, zolang de functionality “kwetsbaar” blijft voor lekken zal het herstellen van deze kwetsbaarheden veel geld kosten, substantieel meer dan wanneer requirements worden meegenomen aan het begin van het traject.
Bedrijven worden ook nog wel eens verleid door third parties die Secure by Design beloven in de software die zij leveren. Zij garanderen in feite dat zij rekening houden met security in hun Software Development Life Cycle (SDLC). Hier kun je op vertrouwen, maar zelf ben ik er voorstander van om altijd te toetsen of het gedrag van de applicatie daadwerkelijk voldoet aan de eisen van de klant op zijn eigen platform. Zeker nu het melden van datalekken juridisch ook verplicht is geworden. Werk je met testdata, dan is het van groot belang dat data met klantgegevens automatisch worden geanonimiseerd ten behoeve van jouw pilot/prototype/keten.

Invloed van de tester?
Mijn ervaring is dat je als testconsultant weinig formele invloed hebt op de mate waarin security op de agenda staat, tenzij het gaat om een kleine klus waarbij er niet van verschillende partijen(cloud) goedkeuring gevraagd hoeft te worden. De verantwoordelijkheid voor security testen - ook wel pentesten – ligt bij grote projecten bij de security officer (die vaak minimaal een CISSP certificaat op zak heeft). Deze huurt een externe security tester in – je wil namelijk niet je eigen vlees keuren – en stemt met deze externe tester(s) af welke datacomponenten wel of niet toegankelijk zijn (je wil namelijk ook niet dat een externe partij bij alle klantdata kan). De security officer krijgt dan een rapport met security bevindingen waarop een risico analyse wordt losgelaten (kans x impact). Dit wordt gedeeld met het projectteam en de bevoegde manager zorgt ervoor dat de bevindingen op de agenda komen.
De intentie is dat deze bevindingen worden opgelost, maar dit gebeurt lang niet altijd. Er komt soms namelijk veel kijken bij het oplossen van een “interne” bevinding. Het gaat dan bijvoorbeeld niet slechts over het patchen van één oude Apache server, maar meteen over 200 exemplaren. Dat kost tijd en geld en dit past vaak niet in het krappe budget van een project waarbij de business hamert op een snelle time-to-market. Als de impact dan ook nog laag wordt ingeschat, laat de implementatie van de oplossing vaak op zich wachten. In mijn ogen is dat niet altijd de juiste afweging. Elke kwetsbaarheid kan leiden tot grote incidenten op de middellange termijn.
Bedrijven zijn wat betreft security nog steeds (te) vaak gericht op aanvallen van buitenaf, al zie ik wel een trend naar meer aandacht voor security-risico's van binnen naar buiten. Ik vind de toenemende discussie over de bevindingen binnen de onderliggende infrastructuur van bedrijven dan ook erg interessant. Misschien speelt de veranderende arbeidsmarkt hierbij een aanjagende rol: veel tijdelijke contracten, kortom veel mensen over de vloer waarvan je niet weet of ze er over een drie maanden nog zitten. Interne security maatregelen kunnen zijn: Geen toegang tot externe email, providers en clouddiensten, USB-controle op je laptop, data encryptie op bestandsniveau, etc.

Certified Ethical Hacker
Vanuit mijn persoonlijke interesse in security heb ik zelf de training Certified Ethical Hacker gevolgd en afgerond met een certificering. Het leuke aan zo'n training is dat elke cursist een andere achtergrond heeft; Risk managers, Security officers, testers en mensen die gewoon meer willen weten over ethisch hacken. In mijn hoedanigheid als tester vond ik het erg nuttig dat de focus vooral lag op de praktijk. Je leert hoe je een virus kunt maken, hoe je kan sniffen op een netwerk, Wi-Fi netwerken kunt kraken, hoe je een DDOS-aanval kunt voorbereiden, maar ook hoe je hiertegen preventieve maatregelen kunt nemen om het risico te minimaliseren. Binnen de training wordt ook de OWASP Top-10 behandeld, met daarin de meest voorkomende security kwetsbaarheden.

OWASP Top 10 - 2013

A1 - SQL injection

A2 - Broken Authentication and Session Management

A3 - Cross-Site Scripting (XSS)

A4 - Insecure Direct Object References

A5 - Security Misconfiguration

A6 - Sensitive Data Exposure

A7 - Missing Function Level Access Control

A8 - Cross-Site Request Forgery (CSRF)

A9 - Using Known Vulnerable Components

A10 - Unvalidated Redirects and Forwards

Ik beweeg mijzelf binnen de “gouden driehoek” van attributen meer in de richting van Security. Zo heb ik twee langdurige opdrachten kunnen doen waarbij ik mijzelf bezig mocht houden met Identity and Access Management (IAM) en Web Application Security. IAM zorgt er uiteindelijk voor dat autorisatie aanvragen door middel van extra goedkeuringen, periodieke attestaties en herbeoordelingen in control zijn – en blijven. Daar wordt een organisatie namelijk blij van, in control zijn. Of dat je als organisatie de licentiekosten blijft doorbetalen.
Tijdens mijn opdracht voor Web Application Security heb ik voor de uitvoer van verschillende testgevallen gebruik gemaakt van verschillende soorten tooling: HP Webinspect, Burp Suite, Acunetix, Owasp Zap, Nmap en de overige tools voor penetration testing.

Neem de regie
Security zal de komende jaren steeds belangrijker worden in het kader van Big data en voorspellende analyses, waarbij er steeds meer data verzameld, opgeslagen en verwerkt wordt in verschillende systemen en applicaties. Met name in de financiële wereld waarin de privacy en betrouwbaarheid van gegevens even belangrijk zijn als de beschikbaarheid en het gebruikersgemak, zullen dienstverleners en instanties steeds vaker op zoek moeten naar de “gouden snede”, een goede balans tussen security, usability en functionality. Er is in deze beweging behoefte aan flexibele testers die hun meerwaarde kunnen laten zien door kennis te hebben van verschillende (lees meerdere) kwaliteitsattributen om een goede testafweging te kunnen maken.
Zodra ik ergens binnenkom, kijk ik altijd naar mogelijke security aspecten. Deze probeer ik op de agenda te krijgen – en als het even kan ook zelf uit te voeren. Als security laag op de prioriteitenladder staat binnen een project, moet je het als tester soms gewoon erbij doen.