Applicatiebeveiliging moet in de haarvaten van de organisatie zitten

Abonneer je gratis op Techzine!

Bij applicatiebeveiliging hoor je niet als eerste te denken aan pentesten, securitytesten, monitoring en patching. In plaats daarvan moet iedereen, van operations tot development teams, op één lijn zitten. Wat wordt er verwacht rondom applicatiebeveiliging, wat is het beleid en hoe voeren we het uit? Het moet in de haarvaten van de organisatie zitten.

We gingen in gesprek met Martin Knobloch, Application Security Strategist bij Micro Focus. Knobloch legt in duidelijke taal uit dat er nog veel misgaat op het gebied van applicatiebeveiliging. Detecteren en patchen worden vandaag de dag vaak gezien als de betekenis van applicatiebeveiliging. Dat lost echter niks op, het verlaagt enkel tijdelijk het risico.

Volgens Knobloch moeten organisaties meer doen dan dat. Uiteindelijk is de enige goede manier het voorkomen van securityproblemen. Al geeft Knobloch toe dat dit niet heel eenvoudig is.

Lees ook: De juiste securitystrategie? ‘Apps en data allebei topprioriteit’

Hoe krijgen bedrijven hun applicatiebeveiliging wel op orde?

Knobloch komt in zijn rol bij Micro Focus bij veel bedrijven over de vloer, waar hij ze helpt met het ontwikkelen van een applicatiebeveiligingsstrategie. Hij spreekt bedrijven van verschillende formaten, met ook verschillende oplossingen voor applicatiebeveiliging.

Knobloch komt bedrijven tegen die security op verschillende manieren proberen toe te passen. Zo kiest het ene bedrijf ervoor om securitytools aan te schaffen voor ontwikkelaars, terwijl een ander bedrijf een 75 pagina’s dik securitybeleid heeft opgesteld waar ontwikkelaars zich aan moeten houden. Dan zijn er ook nog bedrijven die de oplossing denken te hebben gevonden in zero-trust. Daarbij wordt operations gedicteerd hoe het netwerk en toegang tot applicaties moet worden dichtgetimmerd.

Het zijn allemaal pogingen om tot betere security te komen, maar niet altijd even goed doordacht. Maken de ontwikkelaars ook gebruik van de aangeschafte securitytools? Hebben ze de 75 pagina’s securitybeleid überhaupt gelezen? En is zero-trust wel haalbaar, kan je je afvragen. In een enterprise organisatie met 1000 applicaties is het namelijk zo goed als onmogelijk

Volgens Knobloch hebben grote organisaties te maken met meerdere afdelingen die allemaal nodig zijn om applicatiebeveiliging goed uit te voeren. Dat is een grote uitdaging. Er is communicatie en samenwerking nodig tussen teams die eigenlijk niet met elkaar praten of elkaars taal spreken. Een echte cultuurclash.

Verschillende culturen

Knobloch houdt een helder betoog over hokjes en culturen binnen de IT-sector. Veel vooroordelen zijn in dit geval nou eenmaal waar. Veel ontwikkelaars zijn introvert en op zichzelf. Binnen de wereld van ontwikkelaars heb je ook verschillende groepen met hun eigen cultuur. Je hebt Java-ontwikkelaars, .NET-ontwikkelaars, open source-ontwikkelaars die zich meer op het web richten en een opkomende Python-stroming gericht op data science. Deze ontwikkelaars richten zich over het algemeen vooral op hun eigen programmeertaal en content en communiceren vooral binnen hun eigen community en groep. Communicatie met andere groepen is vaak beperkt, ze bestaan vaak naast elkaar in grote organisaties.

Op managementniveau en door securityspecialisten worden ze vaak in hetzelfde hokje geplaatst, en wil men beleid en methodiek opleggen, maar dat werkt dus niet. Communicatie en vooral samenwerking zijn enorm belangrijk.   

“Developers zijn introvert en focussen op hun eigen context, zodra management of securitybeleid of methodiek gaat opleggen ontstaat er een cultuur clash”

Duidelijk beleid, heldere communicatie en verschuivende verantwoordelijkheden

Zoals in zoveel situaties is ook bij applicatiebeveiliging heldere communicatie noodzakelijk. Het beleid moet vooral kort en duidelijk zijn, want wie wil nu tientallen pagina’s lezen over wat hij wel en niet mag. Daarnaast moet applicatiebeveiliging direct bij de ontwikkeling al goed worden toegepast.

Wat men niet mag vergeten is dat ontwikkelaars nooit geleerd hebben hoe ze security moeten toepassen. Ontwikkelaars willen goede code schrijven, maar ze hebben op het vlak van security goede begeleiding nodig. Daar staan de securityexperts min of meer lijnrecht tegenover. Zij weten alles van beveiligen, maar niets van programmeren. Wel vinden ze hun werk enorm belangrijk en willen nogal snel de schuld bij de ontwikkelaars neerleggen.

De eerste stap kan zijn om binnen elk ontwikkelteam iemand de verantwoordelijkheid te geven over het ontwikkelen en beheren van uitgebreide automated testing routines. Op die manier kunnen geautomatiseerde tests direct na het ontwikkelen van een module of feature testen of het ook goed werkt en veilig is. Zo niet, dan kan het direct terug naar het bordje van de ontwikkelaar die het heeft opgeleverd. Op die manier leert de ontwikkelaar van zijn fouten en gaat die sneller betere code schrijven. Het is daarbij van belang niet enkel de fouten aan te wijzen, maar er ook ruimte is voor training om fouten te voorkomen en van elkaar te leren.

Het belangrijkste is, zo stelt Knobloch, dat de verantwoordelijke voor de automated testing ook onderdeel is van het development team dat de features bouwt. Dan zorg je er namelijk voor dat de betrokkenheid ook aanwezig is. Dit is wat anders dan de huidige handelswijze van sommige bedrijven, waarbij een apart team zich puur bezighoudt met automated testing. Met zo’n team creëer je een nieuwe groep met een eigen cultuur die botst met de ontwikkelaars. Ontwikkelaars zien dat aparte team als een blok aan het been, een obstakel dat ze moeten omzeilen, in plaats van onderdeel van het team en het ontwikkelproces.

Zodra automated testing onderdeel is van elk ontwikkelteam, verschuift ook de verantwoordelijkheid voor application security richting deze teams. Dat is niet geheel onbelangrijk, want als men ergens voor verantwoordelijk is, gaat normaliter de kwaliteit omhoog.

Tip: 7 noodzakelijke veranderingen voor IT Service Management (ITSM)

Op hoger niveau moet het ook anders

“Een securityspecialist die niet kan programmeren een beleid laten schrijven en opleggen aan developers gaat echt niet werken.”, aldus Knobloch. Wat je volgens Knobloch nodig hebt zijn security champions: een ontwikkelaar die snapt wat erbij komt kijken, security aware is en onderdeel van het development team. De security champion kan helpen bij het beleid en dit vertalen richting de automated security pipelines. Als je de problemen van ontwikkelaars kan identificeren en securityoplossingen kan aandragen, krijg je meer waardering en respect dan wanneer je zaken gaat opleggen.

De security champion is een belangrijke schakel in de communicatie tussen security en de ontwikkelteams. De security champions zijn op hun beurt vaak ook weer georganiseerd in squads, tribes of guilds. Zij komen bij elkaar om bijvoorbeeld het beleid te bespreken en te verbeteren of mogelijke trends door te nemen die recent zijn waargenomen. Denk aan het bespreken wat de vulnerability trends zijn, welke libraries er geüpdatet zijn of worden en welke problemen daaruit volgen of kunnen volgen. Op die manier kan je veel eerder een securityprobleem over de teams identificeren en structureel oplossen. Het zorgt ervoor dat security top-of-mind blijft. HR speelt hierbij een actieve rol, door security champions de mogelijkheden voor relevante training en tijd voor het samenkomen te geven.

Bij veel organisaties waar Knobloch over de vloer komt, begint hij over het Open Web Application Security Project (OWASP) Software Assurance Maturity Model (SAMM). SAMM helpt bedrijven de volwassenheid met betrekking tot software zekerheid in kaart te brengen, op het gebied van beleid, ontwerp, implementatie, verificatie en operatie. Hierdoor kunnen aandachtspunten worden geïdentificeerd en verholpen.

Knobloch gelooft in Agile en DevOps, maar zorg dat je overzicht houdt

Bij een gesprek over applicatiebeveiliging kan je ook niet heen om het ontwikkelen zelf. Er zijn enorm veel methodes waarmee organisaties software ontwikkelen. Agile, CI/CD en DevOps voeren momenteel de boventoon. Knobloch: “CI/CD is goed voor automation, DevOps draait om response en Agile draait om het proces om de delivery te versnellen. Uiteindelijk zorgt dit voor veel versimpeling.” In de basis is dit prima, stelt Knobloch, want in de securitywereld geldt dat alles wat vandaag veilig is morgen onveilig kan zijn. Als je daar snel (en wellicht simpel) op kan reageren met een korte development cycle is dat erg prettig.

Wel ziet Knobloch de trend dat bedrijven hierin een beetje doorslaan, door zaken te ver te willen versimpelen. Zo gebruiken steeds meer bedrijven een microservice-architectuur, waarbij ze zoveel mogelijk processen als een aparte service willen ontwikkelen. Het is steeds vaker een doel om meer en meer losse services te gebruiken. Als je zaken namelijk te ver versimpelt en te veel services creëert, raak je het overzicht kwijt. Als je geen overzicht meer hebt hoe processen lopen en welke services er allemaal zijn gebruikt in een proces, dan is het oplossen van een beveiligingsprobleem ineens een gigantische uitdaging. Kom er dan maar eens achter in welke service het beveiligingsprobleem zit.

Hoe begin je met applicatiebeveiliging?

Om je organisatie en ontwikkelaars meer security-aware te maken en applicatiebeveiliging meer aandacht te geven kan je beginnen met iets simpels als een basiscursus. Knobloch stelt dat een basiscursus application security voor elke organisatie geschikt is. Mensen zijn nooit te oud om te leren, ze steken er altijd iets van op. Ander bijkomend voordeel is dat het onderwerp hierdoor ook meer besproken wordt binnen de organisatie. Het kan het startpunt zijn van nieuw beleid, meer aandacht en meer samenwerking om veiliger applicaties te ontwikkelen.

Vervolgens kan een stap worden gezet om binnen ontwikkelteams een security champion te werven. Hiermee krijgt het securitybeleid ook een gezicht en kan de verantwoordelijkheid verschuiven richting deze ontwikkelteams.

Uiteindelijk is het zaak om iedereen het nut van applicatiebeveiliging in te laten zien. Zodat de organisatie als geheel hetzelfde doel heeft en dat applicatiebeveiliging bij de bron wordt toegepast. Dus niet enkel door te focussen op monitoren en testen als de applicatie al in productie draait. Applicatiebeveiliging moet in de haarvaten van de organisatie en ontwikkelproces zitten.

Tip: Software testen: niemand twijfelt aan nut, toch gebeurt het te weinig