Om maar met de deur in huis te vallen, dit artikel is niet om met de vinger te wijzen. In tegendeel, het dient als een trigger voor de lezers. Lezers die denken: 'Dat doen toch wij al', prima alleen maar goed. Het gaat om de groep lezers die denkt 'moeten we hier toch maar eens naar kijken'; opdrachtgevers die overwegen om hier over navraag te doen bij hun leverancier en leveranciers die besluiten de opdrachtgever hier over te adviseren.
Bij software ontwikkeling ligt de focus vaak op de functionaliteit. Er wordt een 'use case' opgesteld en op basis van de gevraagde functionaliteit word bepaald hoeveel werk het is en wordt het ontwerp gemaakt. Er worden testplannen opgesteld en test scenario’s doorlopen om te toetsen of alles goed geïmplementeerd is. Er is dan ook geen twijfel mogelijk dat de vereiste functionaliteit van een systeem makkelijk te toetsen is.
Applicatiebeveiliging wordt meestal minder uitgebreid beschreven en is een onderschat onderdeel tijdens de ontwerpfase van de software. Met name bij webapplicaties is dit belangrijk . Uiteraard worden in de functionele specificaties beveiligingsaspecten beschreven. Er is wel degelijk een beveiligd gedeelde van de website, en de gebruiker dient natuurlijk wel in te loggen. En we kennen allemaal de termen 'SQL Injection', 'Cross Side Scripting' en 'Never Trust Your Input'. Maar hoe zit het met de beveiliging van de data tijdens transport, en de opslag van gegevens in het datacenter? Maar ook onderwerpen waar we niet zo één, twee, drie aan denken zoals het veranderen van de standaard cookie naam van een login token, of het feit dat de token bij ASP.Net niet gebonden is aan de gebruikerssessie.
Veel systemen draaien al jaren in een datacenter en functioneren zonder problemen. De architectuur is continue in beweging. Verouderde applicaties worden vernieuwd, nieuwe applicaties geïmplementeerd, hardware wordt vervangen, et cetera. Tot het moment komt dat er binnen een bepaalde sector een beveiligingslek wordt gevonden en dit in de media komt. Dan gaan bedrijven en instellingen nadenken over beveiligingsaspecten en laten een security-audit uitvoeren. Hieruit komen regelmatig verborgen beveiligingsproblemen naar voren die niet eerder gevonden zijn, of waar niet eerder over na is gedacht. Logischerwijs komen deze bevindingen bij de leveranciers terecht met de vraag hoe dit heeft kunnen voorkomen in de software en waarom deze bevindingen nu pas aan het licht komen. Maar heeft de klant de software niet geaccepteerd? En heeft de kant de software zelf ook niet getoetst tegen de gevraagde functionaliteit? Het antwoord daarop is natuurlijk dat je als leverancier veilige software moet leveren en uiteraard streven die hier ook naar.
Software belandt vaak op een bestaande architectuur waarbij beveiligingsrichtlijnen al gedefinieerd zijn. Firewalls worden gebruikt om toegang tot de applicatie te beperken. Een gelaagde infrastructuur zorgt ervoor dat de data en backend services gescheiden zijn van de publieke servers door loadbalancers en nog meer firewalls. Beveiligingsimplementaties hebben vaak impact op de ontwikkeltijd van de software, maar ook op de benodigde testtijd. En dan is er nog de benodigde hardware. Encryptie van data kost rekenkracht en daarvoor moet wel voldoende hardware beschikbaar zijn. Dit betekent dat de kosten omhoog gaan. En zijn er natuurlijk meerdere manieren om een beveiligingseis te implementeren. Een voorbeeld hiervan is gebruik maken van de “secure” property van een cookie. Deze forceert dat een cookie alleen over https wordt verzonden en dus alleen bij geëncrypte verzoeken over de lijn gaat. De setting wordt echter niet door oudere browsers ondersteund en als de omgeving alleen maar via https te benaderen is dan is dit probleem niet aan de orde.
Ik denk dat de beveiliging van software en de infrastructuur waar het op uitgerold wordt, soms onderschat wordt en dat er meer aandacht moet worden gegeven aan het opstellen van beveiligingseisen van de software. En hiermee bedoel ik dus niet het gekozen autorisatiemodel of de manier waarop gebruikers zich aanmelden bij het systeem. Ik wil met dit artikel bewustzijn creëren met betrekking tot de beveiliging van de software of de gehele oplossing. Hierbij moeten beveiligingsexperts vanuit de opdrachtgever samen met de leverancier meer aandacht schenken aan de beveiliging. De opdrachtgever moet duidelijk aangeven wat de eisen zijn en wat de huidige architectuur al aan beveiligingsaspecten heeft. De leverancier moet in zijn rol de opdrachtgever adviseren over de mogelijkheden en advies uitbrengen voor de beste oplossingen van de probleemstellingen.
Als laatste wil ik nog een tip meegeven. Iedereen zou eens een kijkje moeten nemen op de website van The Open Web Application Security Project (OWASP). Dit is een goede bron van informatie voor het toetsen van de applicatiebeveiliging. Ze zijn gefocust op applicatiebeveiligingen en hebben een overzicht van de meest voorkomende beveiligingsaspecten en de manier waarop dit kan worden voorkomen. Interessant om mee te beginnen is de OWASP Top 10 for 2010 die de tien meest voorkomende beveiligingsproblemen beschrijft.
Duidelijk en overzichtelijk verhaal…
Duidelijk verhaal. Zeker gezien alle recente incidenten in het nieuws. Het is mijn ervaring dat beveiliging in het algemeen wel belangrijk wordt gevonden, maar dat het toch altijd een sluitpost is. Als deadlines onder druk komen of als er sprake is van kosten overschrijdingen, dan wordt er vaak op dit onderwerp als eerste gekort. Veel bedrijven worstelen ook met het vinden van de juiste balans tussen kosten vs risico’s. Ik ben erg benieuwd naar jullie ervaringen en tips over dit onderwerp.