Achtergrondartikel


Dennis de Leest van F5 Networks:

‘Ook aanbieders moeten gedrag veranderen’

Security-awarenessprogramma’s zijn vaak gericht op het veranderen van het gedrag van de werknemers. “Maar daar kunnen we niet de eindverantwoordelijkheid neerleggen”, vindt Dennis de Leest, Senior Field Systems Engineer bij F5 Networks. “Het is tijd voor een gedragsverandering bij de leveranciers van de producten en diensten.”

Als we Dennis de Leest spreken over het onderwerp ‘security awareness’ waarschuwt hij voor een ‘duale oproep’. Volgens de Senior Field Systems Engineer moet iedereen die met gevoelige gegevens omgaat een ‘natuurlijke achterdocht’ hebben. “Hacks zijn nooit uit te sluiten. Daarom is het belangrijk dat gebruikers zich er bewust van zijn welke gegevens ze waar achterlaten. Anders weet je niet welke gegevens bij een hack in verkeerde handen vallen en kun je slachtoffer worden van identiteitsfraude. Het stimuleren van beveiligingsbewustzijn bij de werknemers zal daarom altijd belangrijk blijven.”

Toch is dit volgens De Leest maar een deel van het verhaal. “De andere kant van de medaille is dat je een securityincident nooit in de schoenen van werknemers kunt schuiven, zeker niet als zij werken met systemen die inherent onveilig zijn geschreven. Ook bij de aanbieders van producten en diensten moet er daarom sprake zijn van een gedragsverandering.” En op dat gebied is er volgens De Leest veel werk aan de winkel. “Nog altijd maak je mee dat bij een password reset wachtwoorden in ‘plain text’ naar de gebruiker worden toegestuurd.”

Ethisch programmeren
Volgens De Leest worden applicaties nog te vaak ontwikkeld vanuit een functionaliteitsgedachte, en niet met security als uitgangspunt. Hij roept dan ook op tot wat hij noemt het ‘ethisch programmeren’ van zowel oude als nieuwe applicaties. “Een ontwikkelaar moet altijd de vraag stellen: draagt het stukje dat ik heb ontwikkeld bij aan een veilig geheel? In hoeverre heb ik zelf nagedacht over het securityaspect?”

“Dit houdt onder andere in dat de ontwikkelaar nadenkt over zaken als het gebruik van veilige protocollen, encryptie en inputvalidatie”, vervolgt De Leest. “Als jouw module ‘aware’ is van inputvalidatie, dan weet je dat een wachtwoord niet kan bestaan uit 400 tekens met een heleboel vreemde karakters die ook zijn te interpreteren als SQL-injectie of een aanval. Dat is iets waar je over na moet denken als je security direct wilt meenemen in de ontwikkeling van een applicatie."

Maar ook de ontwikkelaars dragen volgens De Leest niet de eindverantwoordelijkheid. “Er is een schone taak weggelegd voor degene die uiteindelijk de gehele applicatie als een werkend geheel moet opleveren. Die moet teruggaan naar de programmeurs met de vraag: wat heb jij binnen jouw specifieke module gedaan om de applicatie of het project ‘as a whole’ veiliger te maken? Zo zorg je ervoor dat de applicatie die je uitrolt inherent veilig is en dat je niet achteraf aanvullende beveiligingsmaatregelen als ‘doekjes voor het bloeden’ nodig hebt. Bij een van onze klanten heeft deze aanpak zelfs geleid tot security-awarenesstrainingen specifiek gericht op de programmeurs.”

Beveiliging blijft nodig
“Anno 2017 zijn er nog steeds oplossingen nodig omdat de producten en diensten die worden geleverd niet zijn ontwikkeld met security in het achterhoofd”, concludeert De Leest. “Dat moet in de basis veranderen, te beginnen bij een brede gedragsverandering. Als applicatieleverancier moet je er alles aan hebben gedaan om veilige producten en diensten te leveren.”

Wat volgens de Senior Field Systems Engineer niet wil zeggen dat beveiligingsmaatregelen overbodig worden. “Er blijven altijd goede redenen om je applicaties te beschermen met bijvoorbeeld een Web Application Firewall. Zoals gezegd zijn hacks nooit te voorkomen. Dan komt het aan op de tegenmaatregelen die je hebt getroffen.”

Ook moet De Leest bekennen dat het niet altijd mogelijk is om de security van een applicatie te optimaliseren. Zo kunnen er goede redenen zijn om applicaties die eigenlijk ‘niet kunnen’ vanuit commerciële overwegingen toch niet offline te halen. “Doordat we tussen de gebruiker en de applicatie in staan, kunnen we als F5 helpen om de securitypostuur van zo’n applicatie te verbeteren.”

“Onze oplossingen zijn geschikt om applicaties sneller en betrouwbaarder te maken, maar kunnen ook worden ingezet om veilig gebruik te maken van applicaties die dat in de kern niet zijn. Zo kunnen applicaties gebruikmaken van onveilige standaarden zoals SSL, terwijl wij met veilige standaarden richting de eindgebruikers communiceren.”

Tekst: Ferry Waterkamp

Dit artikel is afkomstig uit Motivator Magazine, najaar 2017. Deze editie verschijnt binnenkort. Vorige edities van Motivator Magazine teruglezen? Dan kan hier.

Verder lezen?

Log in en lees verder of maak hier uw persoonlijk profiel aan en ontvang als eerste het laatste securitynieuws. Speciaal voor u geselecteerd!

Dit veld is verplicht
Vul een geldige e-mailadres in
Dit veld is verplicht