De stille datalekken van low-code
Een datalek hoeft niet het gevolg te zijn van een sluwe hack of een kwetsbaarheid in de software. Met name bij low-codeplatforms, zoals Mendix of Salesforce, kan één verkeerde configuratie al genoeg zijn om gevoelige informatie openbaar te maken. ‘Bij ruim één op de tien onderzochte applicaties konden onbevoegden bij gegevens die niet voor hen was bestemd.’
De bevindingen komen van het Dutch Institute for Vulnerability Disclosure (DIVD), dat de problematiek recent tijdens een presentatie in het Tech Theater op Cybersec Netherlands toelichtte.
DIVD onderzocht vooral applicaties die met Mendix zijn gebouwd. In Nederland werden 1.460 Mendix-applicaties gevonden. Bij iets meer dan 150 daarvan stuurde DIVD een melding omdat de applicatie mogelijk gevoelige of kritieke informatie aan onbevoegden blootstelde.
Onder de radar
Het gaat niet om een formeel wetenschappelijk onderzoek, maar de cijfers geven volgens DIVD wel een indicatie van een breder probleem binnen low-code. Een verkeerde instelling, bijvoorbeeld een gastrol of te ruime standaardrechten, kan toegang geven tot gegevens die niet voor iedereen bedoeld zijn.
Technisch functioneert de applicatie dan zoals ontworpen; de beveiliging is alleen verkeerd geconfigureerd. ‘Securityteams weten vaak niet dat er applicaties zoals Mendix binnen hun omgeving bestaan’, aldus Jeroen Ellermeijer, hoofd Research & Development bij DIVD. Daardoor blijven deze toepassingen dus vaak onder de radar.
En Salesforce?
Het probleem beperkt zich niet tot Mendix. DIVD zag een vergelijkbaar fenomeen bij Salesforce, waar eveneens door configuratiefouten gegevens via de bedoelde functionaliteit toegankelijk kunnen worden. Voor Salesforce heeft DIVD nog een onderzoek lopen.
Low-codeplatforms worden vaak gepositioneerd als veilig by design. Maar tijdens de ontwikkeling en uitrol worden toegangsrechten en functionaliteiten regelmatig ruimer ingesteld. Bij de overgang naar productie moeten die instellingen daarom kritisch worden gecontroleerd. ‘Iemand moet de vinkjes nog goedzetten’, stelt Ellermeijer het eenvoudig.
Hoe beperk je het risico?
Ellermeijer raadt een aanpak aan op drie niveaus en verantwoordelijkheden.
Voor het blue team begint de aanpak met zichtbaarheid. ‘Breng alle low-code-applicaties binnen de organisatie in kaart en controleer vervolgens welke informatie zonder authenticatie toegankelijk is’, haalt Ellermeijer aan. ‘Test applicaties expliciet vanuit het perspectief van een anonieme gebruiker en monitor api-endpoints en runtime-verkeer op onverwachte toegang.’
Het red team, het tweede niveau, moet volgens hem gericht zoeken naar configuratiefouten, publiek toegankelijke functionaliteit en data die via de applicatie of api zonder de juiste autorisatie beschikbaar komt.
Voor ontwikkelaars ligt de nadruk ten slotte op toegangscontrole. ‘Valideer entity access en module roles, test de runtime-toegang vóór livegang en schakel anonieme toegang standaard uit.’
Welkom in de wereld van ICT, waar een vinkje er toe doet.
In programmeertaal ook, een boolean heeft betekenis.
Krachtige systemen noemt men dat, veel functionaleit in weinig code.
Aleen heb ieder voordeel zn nadeel..
Jack kan vermoeien waarom controles niet het antwoord zouden zijn.
Maar de auteur lijkt het toch daarin te zoeken.
Met een palet aan team ;-).
Weg met de DevSecOps en de T-shaped professionals met You built in you own it.
Haha, extra kleurrijke teams die op zoek gaan naar configuratiefouten in een systeem waar ze strategisch gekozen zelf te gast zijn.
Hele idee van lowcode was dat de business zelfstandig kon rondclicken (sorry, ik bedoelde business value toevoegen)
De vroegere grap van slimme mensen achter domme terminals of andersom.
Lijkt het probleem toch in OSI laag 8 te zitten waar het denken op low pitje gezet is.
Steeds weer mijn naam erbij halen begint inmiddels behoorlijk te vervelen.
Iedere volgende vermelding van mijn naam beschouw ik daarom als een verzoek aan de redactie van Computable om reacties onder een pseudoniem niet langer toe te staan.
Jack reageert op zijn naam maar mist het werkelijke fluitje van controle door te testen. De nar van Computable is anoniem maar daarom is de reactie niet slecht want de kleurrijke teams die geïnformeerd op zoek gaan naar wat hackers ongeïnformeerd ontdekken roept inderdaad vragen op over wat je nu uiteindelijk controleert. Het signaalwoord is: Olifantenpaadjes.
Want controleer je nu of het vinkje goed staat of test je ook welke route naar de data ontstaat zodra iemand zich niets van het aangelegde pad aantrekt? En waar staat die data eigenlijk en hoe is de toegang ertoe geregeld als ik buiten de applicatie omga?
Want hoe kouder de data, hoe groter het bewijsrisico. Juist omdat niemand ernaar kijkt kunnen context, toegangsrechten, metadata, controles en leesbaarheid ongemerkt verdwijnen. Bij hergebruik blijkt dan dat het bestand nog bestaat maar de chain of custody niet meer. Zie hier het probleem van een hallucinerende aanname dat er causaliteit zit tussen het signaalwoord en de casus.
Het toevoegen van business value met low code gaat inderdaad om een grap als ik kijk naar de data synthese met slechte data, de anonieme bron die wijst op het olifantenpaadje gaat vooral om de responsible disclosure. De spreekwoordelijke open deur die iedereen gebruikt als ik kijk naar het verwachtingsmanagement.
Het begrip olifantenpaadjes vind ik raak. Juist daarom is alleen testen voor mij niet voldoende.
Als we achteraf moeten ontdekken welke routes naar data bestaan, hebben we kennelijk de betekenisvolle toegangsbeslissingen niet expliciet in de architectuur vastgelegd.
Een controle kan een olifantenpaadje vinden. Een goede architectuur maakt vooraf duidelijk waarom een bepaalde actor, onder bepaalde omstandigheden, wel of geen toegang tot bepaalde informatie mag hebben — ongeacht de route.
Daar ligt voor mij het verschil tussen controle achteraf en betekenis als uitgangspunt van architectuur.
Ik had het niet over paadjes, maar over de paradoxen:
– krachtige systemen vs security
– eenduidige verantwoordelijkheid vs externe controle
– efficientie vs effectiviteit
– devsecops vs hier en daar een vinkje
– zero trust vs wendbaar in het rond clicken
– En goede architectuur vs zero clue van de citizen developer mag daar inderdaad bij.
De spreekwoordelijke sandbox die steeds meer op een echte gaat lijken.
Met een team blauwe mamas en rode papas, omdat IT geen kinderspel is.
Want voegen die kleuters nou business value of open deuren toe.
Hoe vaak hebben we nou gezegd om de deur achter je te sluiten !!!