Beheer

Security
Beveiliger

Beveiligingstests op e-dienstverlening

Een overzicht van testtypes die goed zicht geven op de kwaliteit van de bescherming van persoonsgegevens.

24 augustus 2016

IT-security prijkt al jaren boven aan de agenda van elke CIO en CSO. Daarbij komen webapplicaties steeds meer in de picture. Waar liggen op dit vlak de meest voorkomende kwetsbaarheden?

Uitvoeren van kwaadwillende code
SQL-injectie, remote code execution en code injection. Via deze zwakheden kan een hacker middels een aangepast verzoek malafide code uitvoeren binnen de webserver, besturingssysteem of database. Bijvoorbeeld om zijn rechten verhogen en zo controle te krijgen over de server en de informatie;

Onvoldoende toegangscontrole
Zwakheden in sessiemanagement, authenticatie en autorisatie kunnen leiden tot het overnemen van iemands gebruikers­omgeving in de webapplicatie. Vaak besteden ontwikkelaars veel aandacht aan de loginprocedure maar wordt de toegangscontroles na in gebruikname vergeten;

Gebruik van zwakke encryptiemethoden
Veel zwakheden in encryptieprotocollen zijn bekend, waaronder Heartbleed, POODLE en de DROWN-aanval. Voor misbruik is vaak toegang tot het netwerkverkeer tussen de bezoeker en de webserver vereist, maar mede door de brede inzetbaarheid van SSL, impact en bekendheid van de zwakheden is dit een categorie om rekening mee te houden;

Zwakheden in de IT-infrastructuur
Tijdens een penetratietest wordt de IT-infrastructuur vaak vergeten terwijl zwak patch management en gebruikersbeheer vaak de oorzaak van zwakheden zijn. Een veilige webapplicatie is alsnog eenvoudig te hacken als de onderliggende database kan worden benaderd. Niet alleen de server waarop de webapplicatie is geïnstalleerd speelt een rol, ook gerelateerde diensten zoals een centrale authenticatiesservice dienen onderdeel van het onderzoek te zijn.

Zwakheden die een social engineer faciliteren
Social engineering speelt in op het gedrag van de mens. Aanvallen als Cross-site Scripting (XSS) en Cross-Site Request Forgery (CSRF) maken het voor een hacker mogelijk scripting binnen de browser van het slachtoffer uit te voeren. Deze scripting kan mogelijk een gebruiker aanmaken of instellingen voor remote toegang wijzigen waardoor de hacker zich toegang tot het systeem kan verschaffen;

De bovenstaande aandachtspunten zijn niet uitputtend maar vormen een beeld van de meest voorkomende zwakheden. De Open Web Application Security Project (OWASP) heeft een top 10 gemaakt van de meest voorkomende zwakheden en benoemt daarnaast ook andere zwakheden met mogelijke maatregelen. Het SANS instituut heeft een vergelijkbare top 20 van kritieke controls uitgebracht die op de IT-infrastructuur is gericht. Deze frameworks worden vaak gebruikt als referentiekaders in rapportages.

Verschillende beveiligingsniveaus vereisen vaak ook andere tests en testmethodieken

Het vereiste beveiligingsniveau van de webapplicatie volgt uit een impact- en risicoanalyse. De verschillende beveiligingsniveaus vereisen vaak ook andere tests en testmethodieken. Welke typen technische beveiligingstests zijn er? Wat is het verschil en welke test is geschikt voor welke applicatie?

Test 1: Penetratietest

Een penetratietest dient om ongeautoriseerde toegang tot informatie te verkrijgen. Deze test wordt uitgevoerd vanuit het perspectief van een hacker en start met het inventariseren van systemen in scope, scannen op bekende zwakheden, verificatie van false-positives en het handmatig testen en eventueel uitbuiten van zwakheden. Het resultaat van een penetratietest bestaat uit een rapportage die inzicht geeft in de geconstateerde zwakheden met een risicobeschrijving en advies. Wanneer instanties een penetratietest laten uitvoeren is het goed om op de volgende punten mee te nemen:

Kwaliteit van de penetratietester
Door de toenemende vraag naar penetratietests is de veelzijdigheid van tests en organisaties die tests aanbieden toegenomen. Vergelijking van de aanbieders is lastig. Punten waarop men kan selecteren zijn: Certificeringen en ervaring van de testers, gebruikte testmethodologie, reputatie van de organisatie, kwaliteitsbeheersing in het team en de mate waarin de organisatie onderzoek verricht;

Scope van het onderzoek
Vaak wordt de scope van een onderzoek beperkt tot de webapplicatie terwijl de gerelateerde IT-infrastructuur even belangrijk is. Inventariseer voorafgaand aan een penetratietest alle afhankelijkheden en hun toegangspad om te bepalen of een systeem moet worden opgenomen in de scope;

Risico’s in perspectief van de organisatie
Penetratietesters zijn goed in het rapporteren van technische bevindingen, maar helder weergeven van bedrijfsrisico’s is vaak lasig voor ze. Laat de test daarom op locatie plaatsvinden zodat regelmatig kan worden overlegd over de bevindingen en hun impact op de bedrijfsvoering;

Beperken van de risico’s
Penetratietesten brengt altijd risico’s mee. Vaak wordt eerst beoordeeld welke servers cruciaal zijn voor de bedrijfsvoering en welke risico’s aanwezig zijn zodat testers daar rekening mee kunnen houden. Bij voorkeur vindt de test plaats op de acceptatie- of testomgeving en worden bevindingen gevalideerd op de productieomgeving. De configuratie van de IT-infrastructuur en applicatiecode op beide omgevingen moet wel gelijk zijn.

Een penetratietest is relatief goedkoop en biedt snel inzicht in de risico’s van de webapplicatie. Dit type test is echter niet allesomvattend en de kwaliteit van de test is moeilijk vast te stellen.

 

Test 2: Review van broncode

Een review van broncode geeft een beeld van risico’s en andere onvolkomenheden in de broncode. Zo’n review kan manueel en geautomatiseerd worden uitgevoerd. Een geautomatiseerde review is snel, levert vaak false-positives op en zal niet alle zwakheden herkennen. Vooral ’logische’ fouten herkent een geautomatiseerde review niet. Een handmatige review kost meer tijd, is duurder terwijl zwakheden in ingewikkelde patronen minder snel onderkend worden. Kortom, een combinatie van beide reviews is raadzaam!

Een combinatie van geautomatiseerde en handmatige reviews is raadzaam

Een aantal aandachtspunten voor review van broncode:

Stem secure coding guidelines af
De meest gebruikte programmeertalen hebben een zogenaamde ‘secure coding guideline’, een set van veilige programmeerstandaarden die door de leverancier wordt geadviseerd. Veel ontwikkelaars hebben een eigen secure coding binnen hun bedrijf die zij periodiek evalueren. Het is aan te raden een secure coding guideline als een baseline mee te nemen in de review van de broncode;

Integreer met de penetratietest
Een review van broncode staat de securityexpert toe ‘onder de motorkap’ van de applicatie te kijken terwijl een penetratietester alleen van buitenaf mag ‘schieten’ en niet altijd weet wat de uitwerking is. Wanneer beide onderzoeken worden gecombineerd verbetert dit risico-inventarisatie sterk en verkort mogelijk ook de doorlooptijd;

Laat ook de gecompileerde bestanden testen
Een aantal tools kan de uitvoerbare bestanden van een applicatie analyseren. Het is aan te raden deze vorm (dynamic) te combineren met de analyse van de broncode zelf (static).

Review van broncode (zeker in combinatie met penetratietesten) biedt veel zekerheid. De kosten zijn echter relatief hoog. Om effectief te zijn vergt deze combi een volwassen ontwikkelomgeving. Review van broncode is vooral geschikt voor webapplicaties met een bovengemiddeld risicoprofiel.

 

Test 3: Configuratie-analyse

Gedurende een configuratieanalyse wordt de inrichting van de IT-infrastructuur, databases en de webserver vergeleken met security good practices passend bij het risicoprofiel van de webapplicatie. Het doel van de analyse is risico’s te identificeren en adviezen ter verbetering aan te dragen. Verschillende instanties bieden security good practices in de vorm van een basisset aan vereisten. Voorbeelden van deze organisaties zijn NIST3 en CIS4. De volgende aandachtspunten zijn van toepassing op een configuratieanalyse:

Baselineselectie
Selecteer een baseline die op hoofdlijnen past bij het risicoprofiel van de organisatie (veel baselines hebben risiconiveaus). Een configuratieanalyse met een baseline die een te hoog beveiligingsniveau ambieert zal niet de toegevoegde waarde brengen die de klant verwacht;

Scope van het onderzoek
Evenals bij de penetratietest moet voor de configuratieanalyse de juiste scope worden gekozen. Voor een webserver betekent dit dat vaak het besturingssysteem, de database, de webserver en de authenticatieservice wordt opgenomen in de scope.

Configuratieanalyse biedt een hoge mate van zekerheid over de beveiliging van de IT-infrastructuur gerelateerd aan de webapplicatie. De kosten voor een configuratieanalyse zijn relatief laag en er is tooling om zelf een analyse uit te voeren. Deze analyse is geschikt voor webapplicaties vanaf een gemiddeld risicoprofiel.

 

Test 4: Red teaming

Red teaming test zowel de organisatorische (inclusief medewerkers), sociale als technische maatregelen van een organisatie. Vaak wordt een combinatie van de drie factoren gebruikt om een aanval snel en effectief te laten verlopen. De red-team-aanval kent de volgende aandachtspunten:

Keuze van scenario’s
Vaak worden bepaalde scenario’s, systemen of personen uitgesloten van de red teaming-test. Hoewel hier goede redenen voor kunnen zijn, liggen aan de uitsluiting vaak politieke redenen ten grondslag. Bijvoorbeeld omdat men al van zwakheden op de hoogte is;

“Red teaming geeft een realistisch beeld van de stand van ­zaken, omdat acties van hackers worden gehanteerd”

Heldere afspraken
Omdat red teaming ook het beveiligingsbewustzijn van medewerkers test, is het goed om heldere afspraken te maken en wederzijds een contactpersoon aan te wijzen die gedurende de oefening contact houden en de impact op de bedrijfsvoering monitoren.

Red teaming geeft een realistisch beeld van de stand van zaken omdat in feite de acties van hackers worden gehanteerd. Red teaming is echter duur, het aanbod is gering en de test is relatief risicovol. Er is een volwassenheidsniveau van de organisatie vereist om effectief te zijn. Red teaming is geschikt voor webapplicaties met een hoog risicoprofiel.

Conclusie

Om te voldoen aan de eisen van de toezichthouder zijn verwerkingsverantwoordelijke instanties gebaat bij de inzet van multidisciplinaire teams die invulling kunnen geven aan het testen van systemen. Aanbieders van diensten gericht op de privacywaarborging zullen daar gezamenlijk op in moeten springen.

Randvoorwaarde blijft dat de geboden oplossing aansluit bij de eisen vanuit het type gegevens dat wordt verwerkt en bij eventuele verzwarende factoren, zoals de hoeveelheid gegevens waar met toegang toe heeft en de mogelijke impact van een inbreuk op de privacy.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!