De gebrekkige ontwikkeling in de beveiliging van IT-systemen is geen techniek- of documentatieprobleem. In mijn ervaring zitten bedrijven in de knoop door de gevolgen van de menselijke conditie. Het is daarom de menselijke aanpak, en niet de bureaucratische, die ervoor gaat zorgen dat bedrijven hun assets beter kunnen beveiligen. Wat ons gaat helpen zijn simpelere, modulaire systemen en minder druk op techneuten.

Disclaimer

Niet elke manager is tegen verandering. Niet elke CISSP is een incompetente papieren tijgertjes-vouwer. Ik benoem alleen typische anti-patronen en frustraties vanuit het oogpunt van technisch personeel. Dit zijn geen verwijzingen naar specifieke personen of bedrijven. Wat ik hier probeer te schetsen is dat beveiligingsuitdagingen veel dieper liggen dan een gebrek aan technische vaardigheden of papierwerk.

Governance, Risk and Compliance dient veel goede doelen. Het is belangrijk dat we risico's inventariseren en procesmatig werken. Maar governance zou geen doel an sich moeten worden. Het dient als hulpmiddel om structuur aan te brengen. Of een richtlijn in zo'n hulpmiddel hout snijdt, verschilt per bedrijf, applicatie en context. Ik blijf voor de pragmatische aanpak waarin we kaders kunnen wijzigen als we vanuit expertise zien dat er een betere manier is.

Neem mijn visie vooral met een korreltje zout. Niemand weet hoe een veilige wereld eruitziet. Als er in jouw bedrijf een governance-tabelletje rondgaat, vul die dan gewoon in. Iemand hogerop heeft vast een eigen securityfilosofie. Help diegene om zijn of haar visie waar te maken en te verbeteren.

Het draait om beheersbaarheid

Computersystemen zijn onveilig door de wildgroei van IT-ontwikkeling. De wildgroei maakt systemen complexer, waardoor de beheersbaarheid afneemt. Een systeem wordt onbeheersbaar als de complexiteit sneller toeneemt dan de snelheid waarmee je het geheel kan versimpelen. Toch doen we weinig om technische inflatie tegen te gaan, en veel systemen zitten al geruime tijd tegen het maximum van wat een persoon kan overzien. Hoe ingewikkelder een systeem, hoe briljanter je moet zijn om er nog wat moois van te maken.

Met meer mensen kom je er niet

Wij van security zeggen dat er meer securitymensen nodig zijn. Maar met meer mensen bouw je niet automatisch beheersbaardere systemen. Het gaat om de verhouding tussen vaardigheid en de complexiteit van de uitdaging; zonder Michelangelo schilder je geen Sixtijnse Kapel. Je kan dure ZZP'ers tegen dat plafond gooien tot je een ons weegt, maar het wordt er niet mooier op. Erger nog, als er een Michelangelo tussen die schilders zit, zie je dat niet terug, omdat vakmanschap verwatert in het werk van de middenmoot.

De uitdagingen zijn organisatorisch

De meeste uitdagingen in het wegwerken van onveiligheden zijn niet technisch maar organisatorisch. Verantwoordelijkheid en aansprakelijkheid worden in de bedrijfswereld doorgegeven als een hete aardappel. Iemand die poogt verantwoordelijkheid te concretiseren wordt afgescheept, rondgestuurd of eruit gewerkt, omdat concrete verantwoordelijkheid de baanzekerheid van anderen in gevaar brengt. De gedeelde belangen maken het bedrijf zelforganiserend; het ontwikkelt een immuunsysteem tegen verandering. Mensen met talent, gezonde levenslust en passie raken overspannen, terwijl de droeftoeters die graag uren uitzitten in meetings, vriendjespolitiek in de hand werken of het baasje moeten spelen, floreren in dit milieu.

Geld kost geen moeite

Dat je geld investeert in computerbeveiliging betekent niet dat je moeite hebt gedaan om iets te beveiligen. Als je 10k hebt betaald zodat een pentester je kan vertellen dat er wachtwoorden op shares staan, is dit goed te verkopen aan management. Er is immers 10k geïnvesteerd met een high-risk kwetsbaarheid als gevolg ("ROI"). Maar deze kwetsbaarheden waren al lang bekend onder het personeel. Nu gaat een beheerder dat ene wachtwoord op die ene share verwijderen omdat er geen buy-in is voor een structurele aanpak. De structurele uitdagingen die moeite kosten worden vaak volledig compliant onder het tapijt geveegd.

Pentesten gaat je niet helpen

Door het ophemelen van pentesten wordt de impact ervan overschat. Pentesters zien maar een klein deel van de infrastructuur en moeten het doen met de requirements in scope. Alleen het bedrijf zelf kan met asset management en Threat Modeling naar wijsheid risico-gebaseerde aanvalsscenario's ontwikkelen.

Een pentest voegt ook weinig toe als je de resultaten niet laat leven. Binnen governance worden kwetsbaarheden als statische incidenten gekaderd met een lineaire oplossing. Er is weinig speling om de diepgewortelde root-causes te achterhalen. En het moet uiteraard een technisch issue zijn. Het is zeldzaam dat een kwetsbaarheid uit een pentestrapport op het bord van een manager terechtkomt.

Governance is geen oplossing

De CISSP'en en andere CISA/CISM/AFK'en van team governance hebben de taal van GRC leren spreken, maar zijn daarmee niet meteen technisch expert. Ze leren holle best practices en abstracte beveiligingsconcepten. Deze practices kunnen averechts werken als je ze verkeerd toepast. Helaas leert niet elke GRC'er de nederigheid om de implementatie van beveiligingswerk aan de technische experts over te laten, en sommigen zetten zich graag neer als autoriteit op het gebied van technische beveiliging.

Het is typisch voor de GRC-fanaat om te pogen orde te scheppen met militant governance-werk. Onder het mom van schaalbaarheid stampen ze een 'security baseline' in elkaar, alsof alle applicaties uit hetzelfde hout zijn gesneden. Vaak wordt dit een ellenlange tabel met onduidelijke requirements en willekeurige best practices. Vervolgens kijken ze raar op als niemand dat ding invult, en men is graag blind voor de verslechterde security-ervaring van de teams.

Een governance-implementatie kan negatieve gevolgen hebben. ISO-27001 bewijst dat een bedrijf risico's administratief kan verwerken, maar dat maakt je niet aantoonbaar veiliger. Risico-acceptatie wordt al snel gebruikt als loophole. De risico's worden vaak weggemoffeld in een risicoregister dat alleen wordt afgestoft als een auditor langskomt. Verder heb ik op de werkvloer vaak genoeg gezien dat risico's niet worden uitgesproken uit angst voor een eindeloze spiraal van meetings en administratief werk.

Ontwikkelaars willen wel

De meeste DevOps-teams die ik spreek leveren uitstekend werk en staan volledig open voor securitykennis, maar ze krijgen geen tijd om kritisch te kijken naar de systemen die ze bouwen. Er is al te weinig tijd om het normale ontwikkelwerk af te ronden. Dit komt niet door het ontwikkelwerk zelf, maar door de rompslomp eromheen. Meetings over meetings, slecht onderhouden applicaties die opeens in hun beheer komen, vastgeroeste infra die hun workflow bemoeilijkt, etc, etc. En dat met stapels tech debt op de backlog. Omdat het teams onduidelijk is wat ze nou eigenlijk maken, krijgen architecten - als ze er überhaupt bij worden betrokken - technische details niet in kaart.

Sommige securityguru's verkopen goedkope trucjes om beveiligingskennis in de teams te krijgen. Een middagje OWASP-training hier of een security-awareness sessie daar en klaar is Kees. Of neem de "Security Champion". Als er echt tijd was vrijgemaakt voor kennisdeling, was iedereen een kampioen. En als je niet oppast, benadeel je de positie van deze Champion als van haar wordt verwacht dat zij de spreekbuis van hogerop wordt.

Winnende voorbeelden

Hieronder beschrijf ik twee bedrijven (non-fictie) die het opvallend goed deden. De rode draad van succes zit hem in het vertrouwen van technisch personeel en het beperken van afhankelijkheden.

Bij een logistieke leverancier vond ik twee beheerders die moeiteloos de infrastructuur voor 50.000 medewerkers beheerden. Management had ze volledige controle gegeven om from scratch een moderne infrastructuur te bouwen. Simpliciteit en controle waren de ontwerpprincipes. Met moderne orchestration tools beheerden ze alles vanuit een enkele, netjes gestructureerde code repo met infra-as-code. Centraal in het ontwerp lag een steevaste regel richting management: producten die niet integreren met moderne oplossingen komen er niet in. Zo blijft alle infrastructuur as-code en beheersbaar. De kwetsbaarheid die ik vond tijdens de pentest was binnen een uur opgelost.

Een andere organisatie had geen securitypersoneel maar een ontzettend strak beveiligingspostuur. Hun kernteam van 3-5 beheerders werkt er al zo'n twintig jaar. In die twintig jaar hebben ze stapsgewijs verbeteringen doorgevoerd. Wat opviel was dat ze het zelfvertrouwen hebben om kennis en vaardigheden van pentesters over te nemen. Nadat ze een dure infra-scan hadden laten doen, hebben ze gewoon dezelfde tool gekocht. Nu scannen ze wekelijks hun eigen infrastructuur voor een fractie van de kosten. De cloud-hype heeft ze ook niet gek gemaakt; alles draait op eigen hardware. Hierdoor houden ze de controle en blijven afhankelijkheden beperkt.

Dicht bij je systeem staan

Wat is het waard om dicht bij je systeem te staan? De verborgen kosten van afhankelijkheden worden vaak onderschat. Een grootschalig voorbeeld is natuurlijk het euvel rond afhankelijkheden van Amerikaanse leveranciers. Zo had Amazon laatst de prijzen van GPU-gebaseerde diensten met 15% verhoogd. Als je infrastructuur afhankelijk is van AWS, ben je daar mooi klaar mee.

Een modulair ontwerp wint

De uitdaging van managers en ontwikkelaars is het aanbrengen van abstractielagen om de complexiteit van bedrijven en applicaties beheersbaar te houden. Ontwikkelaars herstructureren hun code via een proces genaamd refactoring, precies zoals een bedrijf regelmatig moet herstructureren. Het applicatielandschap en het organigram zijn continu in ontwikkeling. Een winnende strategie voor beiden is het onderhouden van een modulair ontwerp, zodat de modules gelijk blijven na herstructurering. In een bedrijf is dit bijvoorbeeld "de financiële afdeling".

Geef een kleine club competent personeel de vrijheid om losse modules van je bedrijf uitstekend in te richten. De Unix-filosofie voor applicaties is "Make each program do one thing well". In software engineering passen ze een soortgelijk principe toe op elke abstractielaag. We kunnen deze engineering-principes ook toepassen in de bedrijfswereld. Als jij duidelijk kan maken wat je van een module in je bedrijf verwacht en je goede mensen de vrijheid geeft, bouwen ze een component die precies doet wat die moet doen.

Je kan ook doorslaan in het aanbrengen van abstractielagen. Als je een microservice voor file uploads te abstract maakt, gaan teams hun eigen file upload services bouwen, wanneer het generieke component niet werkt voor hun use-case. De abstractielagen dienen daarom zo te zijn gekaderd dat zij op hun beurt ook weer precies doen wat ze moeten doen. Als je de microservices-route wilt nemen, en je wilt een file upload service maken, dien je deze zo in te richten dat het werkt voor alle file upload services die nodig zijn.

Met duidelijke modulaire kaders zijn per module de beveiligingseigenschappen in kaart te brengen. Voor overlappende eigenschappen kunnen dan checklists worden gebouwd. Voorbeelden zijn een CI/CD-pipeline die door meerdere teams wordt gebruikt, of dat teams een vaste manier hebben voor het bouwen van API's. Maar laat er speling zijn. Systemen zijn continu in ontwikkeling, dus checklists zijn meer nice-to-have suggesties dan een vervanging voor een up-to-date dreigingsmodel. Als een item echt in een checklist past, kan je de check waarschijnlijk wegautomatiseren.

Het fundament van technische beveiliging

Het fundament van technische beveiliging is Threat Modeling. Je kijkt wat je hebt, wat er mis kan gaan, en wat je ertegen kan doen. Als je teams hier geen tijd voor geeft, race je te snel door de design-fase en eindig je met een krakkemikkige fundatie. Uit het bespreken van zo'n dreigingsmodel volgt ook logischerwijs het belang van in-depth security, monitoring en overzicht.

Focus op inventarisatie van asset-specifieke issues in plaats van statische risico-analyse. Houd de securitybaseline en de ISRA'tjes zo simpel mogelijk, want deze tools zijn slechts indicatief. Het echte werk zit hem in de details.

Meer tijd en vertrouwen

Leg minder druk op ontwikkelteams. Geef ze regelmatig een weekje om tech debt weg te werken en te refactoren. Door structuur en overzicht worden kwetsbaarheden duidelijk en beheersbaar. Het kan ook geen kwaad om per use-case of sprint te onderzoeken of er geen kwetsbaarheden worden geïntroduceerd (Threat Modeling).

Neem zoveel mogelijk kennis over van pentesters, en geef teams de ademruimte om de kennis in hun systeem te krijgen. Dat zou de hele reden van de pentestacquisitie moeten zijn. Goede pentesters ondersteunen ontwikkelaars en borgen kennisoverdracht.

Vraag in vertrouwen rond naar kwetsbaarheden zonder er meteen incidenten van te maken. De meeste structurele kwetsbaarheden vind ik tijdens het intakegesprek. Je hebt geen pentester nodig om je te vertellen dat servers outdated zijn, dat wachtwoorden via Confluence worden gedeeld of dat de JWT-key op al je microservices hetzelfde is. Dat je Active Directory vol zit met verouderde accounts en Domain Admins van externe bedrijven. Etc, etc. Als je in vertrouwen rondvraagt, vind je genoeg structurele kwetsbaarheden waar je moeite voor kan doen.

Ontwikkel rustiger aan

De belangrijkste tip is: maak het niet allemaal zo complex. De veiligste systemen zijn overzichtelijk en beheersbaar. Als we minder hard van stapel lopen, kunnen we elkaar misschien de ruimte geven om beheersbare, veilige systemen te ontwikkelen.