Auteurs: Yorick Koster ● yorick.koster@securify.nl & Gerben de la Rambelje ● gerben.delarambelje@gmail.com
Afgelopen 9 juli was het voor mij de tweede keer op rij dat ik een ‘security testen’ workshop gaf op de Summerschool bij Testnet. Een voorstelrondje bij de deelnemers van de workshop met de vraag of zij in hun dagelijkse werkzaamheden te maken hadden met security testen gaf mij de bevestiging dat security nog steeds niet op de agenda staat bij veel organisaties. Eigenlijk is dit heel vreemd. Als je je realiseert welke enorme financiële en andere (imago, maatschappelijke) risico’s er kleven aan het niet testen van security, dan wordt de noodzaak duidelijk om security een vast onderdeel te maken van de kwaliteitszorg in IT-projecten en onderhoud van applicaties.
De importantie van security
Security is nog nooit zo belangrijk geweest als nu. Steeds meer bedrijven vertrouwen hun gevoelige informatie toe aan geautomatiseerde systemen. Denk maar eens aan de risico’s die ontstaan als er geen autorisaties bepaald worden en iedereen zomaar alle vertrouwelijke gegevens kan bekijken en/of bewerken. Ook de ernstige gevolgen die ontstaan als hackers bij vertrouwelijke informatie kunnen komen, zijn vaak niet te overzien. Security en beveiligingslekken zijn dan ook aan de orde van de dag en steeds vaker in het nieuws. Bedrijven lopen schade op en verliezen veel belangrijke data doordat applicaties openstaan voor de buitenwereld.
Helaas is het testen van security bij veel ontwikkeltrajecten nog steeds een ondergeschoven kindje. Doorgaans wordt een securitytester helemaal aan het einde van een ontwikkeltraject ‘ingevlogen’. Al het programmeerwerk is afgerond en de release is beschikbaar in een representatieve acceptatieomgeving, klaar voor de penetratietest (pentest). In veel gevallen is de pentest het eerste moment waarop beveiliging in beeld komt en heeft het geen of onvoldoende onderdeel uitgemaakt van het hele ontwikkeltraject. Dit vergroot de kans op beveiligingsproblemen aanzienlijk. Het resultaat is een dik rapport vol bevindingen. Elke tester weet dat wanneer problemen eerder worden geconstateerd, het goedkoper is om deze te verhelpen. Toch zien we in de securitytestwereld helaas nog weinig veranderen. Nog steeds worden pentesten vaak pas op het allerlaatste moment uitgevoerd. In de ‘kreukelzone’ van een project.
Wat zijn zoal de securityrisico’s?
Voor mij dus de uitdaging om via de workshop een aantal security issues de revue te laten passeren. Ik heb een aantal security issues behandeld uit de OWASP (Open Web Application Security Project) top tien. De OWASP werkt aan een lijst met de tien grootste beveiligingsrisico’s voor webapplicaties. De eerste top-10 verscheen in 2003 en is bedoeld om bewustzijn over het belang van webapplicatiebeveiliging te verhogen. Aangezien het veld zich ontwikkelt, moet ook de lijst worden bijgewerkt. Voor dit artikel pak ik de twee securityrisico’s van OWASP eruit, die tijdens de workshop zijn behandeld met het testen van de ‘sbank webapplicatie’:
Note: probeer nooit zaken uit als je geen toestemming hebt om dat te doen. En dus zeker niet op internet, want dat kan strafbaar zijn.
- Gebroken Authenticatie en sessie management
Authenticatie is het proces waarin een gebruiker zich (bijvoorbeeld) bekend dient te maken met behulp van een gebruikersnaam en wachtwoord. Authenticatie- en sessiebeheer zijn vaak niet goed beschermd, waardoor hackers de kans krijgen om deze gegevens te misbruiken. De volgende instructiefilm laat zien wat er kan gebeuren als gebruikers niet via een beveiligde ‘https’ sessie zijn ingelogd: https://www.youtube.com/watch?v=5ZLmRMLo6HI - SQL-Injectie
Een SQL-injectie (of SQLi) is een methode om een op SQL-gebaseerde database via internet te kraken. De hacker test in zo’n geval vooraf of de database van de website vatbaar is voor een SQL-injectie door verschillende query’s via zijn browser op de database los te laten. Als de hacker beet heeft (en de database dus kwetsbaar is), kan de hacker uiteindelijk de backend database in zijn geheel overnemen. De volgende instructiefilms geven een aantal voorbeelden van SQL-injectie:
Voor meer beeldend materiaal over security verwijs ik naar de volgende site, die veel informatie bevat:
Security is belangrijk, maar hoe start ik?
Beste manier om met security aan de slag te gaan als organisatie, is door de volgende vragen te stellen:
- Security, wat houdt het in, hoe start ik? En hoe kom ik in control?
- Hoe krijg ik meer grip op mijn risico’s en hoe verbeter ik de sturing op security? Hoe blijf ik in control?
- Hoe weet ik zeker dat de getroffen maatregelen voldoende zijn om ellende te voorkomen? Ben ik wel in control?
Ga je als organisatie aan de slag met security, dan is het belangrijk dat dit zo vroeg mogelijk binnen een project onder de aandacht komt. Agile omgevingen zijn ideaal om ‘security testen’ te implementeren. Ook de securitytester moet onderdeel zijn van het team!
Om het kennisniveau van de medewerkers over security op korte termijn op te schroeven, kun je denken aan de volgende punten:
- Volg de een cursus ‘Certified Ethical Hacker’ (CEH), ‘Offensive Security Certified Professional’ (OCSP). Ook SANS heeft een aantal goede trainingen:
http://pen-testing.sans.org/training/courses
- Ga zelf aan de slag met de boekenserie ‘Hacking Exposed’. Ook het boek ‘The Web Application Hacker’s Handbook’ kan ik erg aanbevelen.
- Loop mee met een ervaren specialist
- OWASP heeft recent ook versie 4.0 van haar ‘Testing Guide’ uitgebracht: https://www.owasp.org/images/1/19/OTGv4.pdf
Implementatie Security in de organisatie
Het afgelopen jaar heb ik meegelopen met verschillende Agile ontwikkelteams om ervaring op te doen hoe de implementatie van security nou echt werkt. Uit mijn ervaring blijkt dat er al een onderscheidende bijdrage kan worden behaald, door ongeveer één dag per week aanwezig te zijn. Door Pokersessies bij te wonen worden beveiligingslekken al vroeg gesignaleerd en kunnen tips en hints aan de ontwikkelaars worden meegegeven. Korte tussentijdse code-reviews, het gebruik van ‘security userstories’ en een nauwe samenwerking met het team zijn bepalende factoren voor een succesvolle aanpak.
Voor het integreren van security binnen Agile-projecten, voer ik doorgaans de volgende stappen uit:
- Review van de Sprint-backlog; welke stories komen er aan die interessant zijn vanuit beveiligingsperspectief;
- Bijwonen van pokersessies; verhoogt zichtbaarheid security testers & betrokkenheid van het team;
- Maak securitytaken aan in stories die relevant zijn vanuit beveiligingsperspectief;
- Code-review, handmatige securitytesten; beoordeel resultaten van securitytools, zoals statische codescanners.
Microsoft heeft een document waarin beschreven staat hoe je security kan integreren binnen Agile:
Het is wel belangrijk dat je een werkwijze implementeert, die het beste werkt voor een organisatie. De volgende presentatie is daarom ook erg informatief:
- https://www.owasp.org/images/f/f9/Real_World_Agile_SDLC_-_Chris_Eng%2BRyan_OBoyle.pdf
- https://www.youtube.com/watch?v=X0YzSq8gkeA
Tot slot
Het was voor mij weer uitdagend om een workshop te geven bij Testnet om op die manier security onder de aandacht te kunnen brengen. Ik hoop dat ik met dit schrijven van dit artikel duidelijk heb kunnen maken wat de noodzaak is om hiermee aan de gang te gaan. Wellicht bent u geïnspireerd om dit ook echt te gaan doen.
Veel succes,
Yorick Koster