De beste hacker is een softwareontwikkelaar

25-11-2020 om 10:47 uur Charlotte BlogNieuws
"Bij kwetsbare functionaliteit moet de security bijna net zo strak zijn als bij een nuclear missile launch"
Op 4 november jl. was NXTApps-manager Rohald Boer te gast bij de vierde aflevering van de DETECT2020 Security Talks van Motiv. Hij sprak daar met andere securityspecialisten over onderwerpen als Security by design, DevSecOps, Living off the Land-aanvallen, en: het bakken van de beste pannenkoeken.

“Security by design, dat wil toch zeggen: per scrumteam heb je een fulltime security dude”?”

Gastheer Rens de Jong valt meteen met de deur in huis tijdens het DETECT2020 interview met Rohald Boer. Maar nee, dat is niet de beste aanpak volgens Rohald. “Alle developers in het scrumteam moeten kennis hebben van cybersecurity. Het werkt wel goed om één persoon met affiniteit met security de lead te laten nemen. De kennis actief naar het team te laten brengen. Maar iedereen in het team moet ermee bezig zijn. En we zorgen natuurlijk voor onderlinge controle en kennisdeling: wij hebben een architect die werkt in het ene team, en reviews doet op de globale architectuur in het andere team. En vice versa.”

 

Een goede pannenkoek begint met goede ingrediënten

Boer licht toe. Security by design betekent niet: eerst software bouwen, daarna pas security-aspecten er omheen vouwen. Security by design neem je vanaf het allereerste idee mee. En in elke fase van het bouwen. Als je een pannenkoek gaat bakken, begin je ook met de juiste ingrediënten, met het goede beslag. Bij het bouwen van software kun je je niet meer permitteren om een lange weg naar beheer te hebben. Met allerlei checkboxjes en een enorme transitielijst, voordat de software naar de beheerafdeling kan. Dat zag je vaak gebeuren bij de watervalmethode. Het moet nu sneller en vloeibaarder naar de productieomgeving kunnen.

Alle betrokkenen moeten zich tegelijkertijd blijven realiseren dat 100% security niet bestaat. Boer: “Als je denkt als een softwareontwikkelaar, kun je zeggen: ik heb alles volgens ‘Security by design’ gebouwd, dus mijn applicatie is 100% veilig. Maar je kunt beter denken als een securityspecialist, en ervan uitgaan dat perfectie niet bestaat. Wat doe je dan? Werken volgens ‘defense in depth’; meerdere van elkaar onafhankelijke lagen aanbrengen in je applicatie. Zodat de impact van een hack nooit heel groot kan zijn.”

 

Omwille van security én beheer: keep it simple

Een mooie leidraad bij het bouwen van veilige software vindt Rohald de OWASP security principles. Hij ziet als het belangrijkste uitgangspunt: hou het simpel. Maak je software niet onnodig complex. Niet alleen omwille van de security, maar ook omwille van de onderhoudbaarheid van de applicatie. Hoe complexer je code, hoe complexer het beheer. Een applicatie is altijd een levend ding; in de loop der tijd komen er  functionaliteiten bij, sluipen er bugs in. Dergelijke kwetsbaarheden merk je eerder op in een goed en simpel opgebouwde applicatie.

 

Snel verbeteren met slimme tools

Hoe controleer je of je software te complex is, of wordt? Boer: “Tegenwoordig heb je daar veel tools voor. Tools die het testproces kunnen verbeteren en automatiseren, of voor je packages en containers. Maar ook tools die je een cijfer kunnen geven voor de complexiteit van je code. En je aanbevelingen geven op basis van dat cijfer. Vanuit de operations-kant kan dat ook, als je bijvoorbeeld een RASP [Runtime Application Self Protection] inzet. Zo’n RASP kan een ontwikkelteam zelfs een waarschuwing geven: let op, hier gaat mogelijk iets mis. Het team wordt zo gevoed met gerichte kennis en inzichten. En doet het de volgende keer anders.”

Maar is dat niet riskant, de inzet van externe tools? Hoe weet je zeker dat die wel veilig zijn? Rohald is voorstander van tools, maar zegt erbij: wees kritisch. Vertrouw ze niet zomaar. “Wat wij in de scrumteams bijvoorbeeld doen: in een testopstelling bewust een aantal vulnerabilities zaaien. En dan kijken of de tools die vulnerabilities eruit halen. Als iets niet gesignaleerd wordt, hoe ga je er dan op handelen? Het blijft een samenspel tussen developers en tools. Daarom zou ik ook willen stellen: de beste hacker is een softwareontwikkelaar. “

 

Succesvolle samenwerking NXTApps – Motiv SOC

“Dat is ook de reden dat we vanuit NXTApps steeds intensiever gaan samenwerken met de SOC-analisten van Motiv. We kunnen enorm veel van elkaar leren en elkaar versterken op dit punt.” Tafelheer Bastiaan Bakker van Motiv beaamt dit: “Vanuit het SOC hebben we van de NXTApps-developers geleerd op het vlak van agile en scrum. De productiviteit bij het SOC schoot omhoog. We hebben nu een soort DevOps-fabriek bij het SOC, van waaruit we continu nieuwe functionaliteit aanbieden aan de product owner.”

 

Developers, ga niet het wiel uitvinden

Boer gaat terug naar de OWASP principles. Specifiek naar het eerste punt: ‘minimize the attack surface area’. Oftewel: het terugbrengen van het aantal punten in software waar een hacker zou kunnen binnenkomen. “Bij het bouwen van software denk je vanaf het begin na over de architectuur. En over de vraag: welke onderdelen maak ik beschikbaar voor welke gebruikersgroep?”

“Best practice daarbij is: gebruik maken van bestaande, bewezen technologie. Ga niet voor alles zelf het wiel uitvinden. Zoek en beoordeel bestaande libraries en functionaliteiten. Zet eventueel een dependency checker in. En maak gebruik van standaardcontroles in je OS (Operating System) patches. In die OS-patches zitten vaak ook tips en adviezen: ‘hey, dit stukje code is outdated, er zitten kwetsbaarheden in; update je code base.’”

Dat is dus eigenlijk het weer even opkloppen van je beslag, zo merkt Bastiaan Bakker op. Als we nog even bij de pannenkoek-metafoor mogen blijven.

 

DevOps versus DevSecOps

Een ingezonden vraag van een kijker gaat over DevOps en DevSecOps: is dat fundamenteel verschillend? Rohald Boer vertelt dat DevSecOps betekent: security in de gehele DevOps-cyclus. Gartner heeft hiervan een mooie plaat, die laat zien dat je met DevSecOps security checks doet door de gehele keten. Dat kan via code analytics, geautomatiseerd testen, het signen van je software, in operation runtime application security protection, maar ook op de behavior-kant van de applicatie… genoeg mogelijkheden.

 

 

OWASP principles in de praktijk

Gastheer Rens de Jong wil weten bij welke punten uit de OWASP-lijst Rohald praktijkvoorbeelden heeft. Boer vertelt: “Het ‘principle of least privilege’ heeft NXTApps succesvol toegepast tijdens het bouwen van een cryptografische opslag store voor een klant. Dat principe zegt: maak het vier ogen-principe verplicht, bij bepaalde handelingen in de software. Je kunt de technologie dan zo instellen dat de ene beheerder de bewerking klaarzet, en dat de andere beheerder moet inloggen en accorderen. Gebeurt dit niet, dan gaat het hele feest niet door. Je hebt dus twee ingelogde beheerders nodig om een bepaalde kwetsbare functie door te voeren.”

“Tijdens het bouwen van de cryptografische store voor die klant, hadden we tijdens een security analyse al gezien dat een van de meest kwetsbare procedures was: het terugzetten van een restore. Daarom hebben we hier dat principe van ‘least privilege’ toegepast. Voor het uitvoeren van een restore, moesten twee beheerders gelijktijdig zijn ingelogd. Met multifactor authentication (MFA). Ze moesten daarnaast de beschikking hebben over zogenaamde operator cards. Pas als aan al die voorwaarden was voldaan, kon de restore-knop geactiveerd worden.”

“Mooi voorbeeld. Bijna een nuclear missile launch”, grapt Bastiaan Bakker. Bijna wel! En let dus ook op, waarschuwt Boer meteen: “Een dergelijk niveau wil je absoluut niet bij alle functionaliteiten instellen. Dan zou het te complex worden. Maar zo’n elementaire functie als deze wil je echt onder controle hebben. En dan is dit principe een goed uitgangspunt.”

 

De impact van security: 30 patiëntendossiers op straat, versus 30.000 dossiers

Naast het vier ogen-principe, kun je in deze context ook denken aan een slim rechten en rollen-systeem. ‘Wie mag wat’ in de software. Vaak krijgen gebruikers toegang tot een deel van de software, op basis van hun functie of rol in het bedrijf. Maar, zo merkt Boer op, je kunt medewerkers ook autoriseren op object- of recordniveau. Dat is bijvoorbeeld slim om te doen bij applicaties als EPD’s (elektronisch patiëntendossier). NXTApps heeft dergelijke systemen gebouwd voor een grote klant in de zorg.

Bastiaan Bakker weet: in een ziekenhuis hebben gemiddeld 100 medewerkers toegang tot een patiëntendossier. Best veel. En is dat wel nodig? Rohald Boer: “Toegang wordt vaak ingeregeld vanuit gebruiksgemak. Als iemand iets moet overnemen, is het handig als ie er direct bij kan. Maar als je de software zo ontwerpt, dat je iemand bij vervanging heel eenvoudig toegang kan geven, dan is dit niet nodig. Dan hoef je niet zoveel autorisaties te geven op voorhand.”

“Je kunt de toegang limiteren tot de dossiers waar een medewerker behandelend specialist voor is. Als diegene nieuwe dossiers toegewezen krijgt op record level, krijgt ie toegang. Raakt zijn account onverhoopt gecompromitteerd, dan liggen er misschien 30 patiëntendossiers op straat. In plaats van de 30.000 dossiers die in het systeem zitten.” Zo wordt het voordeel van een slim rollen- en rechtensysteem in software behoorlijk helder.

 

Encryptie versus snelheid en gebruiksvriendelijkheid

Dergelijke voorbeelden smaken naar meer. De gastheer wil weten: heeft NXTApps een app gebouwd die wij kunnen kennen? Boer: “mSafe is onze app voor het veilig uitwisselen van bestanden. Hier zie je dat de uitdaging ook is: vertrouw je eigen bronnen niet. In mSafe krijgt iedere klant zijn eigen sleutel. Dus al hun bestanden zijn encrypted met hun eigen sleutel. Zou een hacker er op de een of andere manier bij kunnen komen, dan hebben ze iets in handen wat encrypted is. Waardeloos.”

“En NXTApps en Motiv kunnen ook niet bij de bestanden komen?” “Nee, wij hebben niet de hoofdsleutel, dus dat kan niet.” Gastheer Rens de Jong wil weten wat de grootste uitdaging was voor het team, bij het bouwen van mSafe. Boer beschrijft een spanningsveld tussen encryptie en decryptie, versus performance en snelheid. “Encryptie en decryptie zijn nogal bewerkelijke processen. Je moet dat netjes in zo’n systeem krijgen. En het gebruiksvriendelijk houden. Daar zijn we met mSafe gelukkig in geslaagd.”

 

 

Onderschat het belang van goede logging niet

Een kijker wil weten in hoeverre Security by design kan helpen bij Living off the land-aanvallen. Rohald merkt op dat we het tijdens de security talks veel hebben gehad over preventieve en correctieve maatregelen, maar dat iets als goede logging ook enorm belangrijk is. Software moet logging bevatten die correct is, en voldoende informatie geeft voor bijvoorbeeld een SOC. De analisten van een SOC hebben rijke logging nodig om goed te kunnen zien wat er allemaal is gebeurd in een applicatie.

 

Vloeken in de security-kerk?

Is agile-scrum niet ‘vloeken in de security-kerk’, vraagt tafelgast Gunther Cleijn. Is de snelheid van scrum niet in strijd met de zorgvuldigheid die hoort bij security? Volgens Rohald Boer niet. MVP’s (minimum viable products) volgens scrum laten juist snel zien waar kwetsbaarheden zitten. “Deliver fast, fail fast, en zorg dat je het aanpast. Als je de software snel naar productie brengt en er wordt eenmaal iets geconstateerd, kun je het ook snel aanpassen. Vroeger moest je die nieuwe versie eerst stap voor stap door de releasestraat krijgen. Dan was je als bedrijf mogelijk een heel kwartaal kwetsbaar. Nu gaat dat veel sneller, met kleine versies met verbeteringen.”

“Als je het beslag aanpast… heb je steeds weer een nieuwe pannenkoek.” Zoiets ja, dankjewel Bastiaan. Na een talk over veilige software hebben we nu ineens allemaal honger.

 

 

 

Bekijk hier aflevering 4 van DETECT2020, met Rohald Boer van NXTApps

Bekijk hier het overzicht van alle DETECT2020-afleveringen op de site van Motiv

 

Charlotte

Mail Charlotte
BlogNieuws
Deel:

Meer weten over Security by Design?

Neem contact op met Rohald Boer
Telefoon 256x256  06 53 11 62 96  |  Mail 256x256  rohald.boer@nxtapps.nl

Stel ons een vraag