Security by design: introductie

Geschreven door Rob Dekkers

Apps worden zodanig ontwikkeld, dat ze de eindgebruiker in voldoende mate en zonder fouten ondersteunen, conform de zogenaamde functionele eisen. Daarnaast wordt er ook ontwikkelinspanning geleverd om te voldoen aan niet-functionele eisen, zoals data-integriteit, robuustheid, betrouwbaarheid, snelheid.

We kunnen er niet meer omheen om tijdens de ontwikkeling ook aandacht te schenken aan veiligheidsaspecten. Immers niemand wil graag zien dat zijn of haar klantgegevens openbaar worden. Helaas kunnen we iedere dag weer lezen dat er een poging is gedaan om in te breken in applicaties, apps worden gegijzeld of dat de data inmiddels al ‘op straat’ ligt. Naast materiële is ook de immateriële schade groot.

In een aantal blogs zullen wij diverse belangrijke veiligheidsaspecten van een Mendix-app uitlichten en wijzen op mogelijke kwetsbaarheden en suggesties aandragen hoe hiermee om te gaan. Wij hopen hiermee bij te dragen aan de bewustwording van de noodzaak van “security by design” bij het ontwikkelen van Mendix-apps.

Wat is veilig

De belangrijkste veiligheidseisen of -doelen, in de literatuur de CIA-triad genoemd, zijn:

Confidentiality
Gebruikers (natuurlijke personen, maar ook andere systemen) mogen alleen toegang krijgen tot informatie waarvoor zij zijn geautoriseerd.
Integrity
Gebruikers mogen alleen informatie wijzigen (inclusief toevoegen en verwijderen) waarvoor zij zijn geautoriseerd en volgens de regels die daarvoor gelden (business rules).
Availability
De functionaliteit blijft beschikbaar, zelfs als er aanvallen worden uitgevoerd. Een zogenaamde Denial of Service (DoS) moet uitblijven.

Daaraan wordt vaak nog toegevoegd:

Accountability (non-repudiation)
Er kan bewijs worden geleverd dat gebruikers bepaalde acties hebben uitgevoerd, ondanks dat gebruikers dat zouden kunnen ontkennen.

Om aan deze eisen te voldoen zijn er ondersteunende mechanismen nodig. De meest bekende zijn:

Identity & Authentication
De identiteit van een gebruiker moet kunnen worden bepaald. De gebruiker zal zijn identiteit moeten bewijzen. Inloggen is een vorm van authentication.
Authorization
Er moet kunnen worden bepaald wat een (geïdentificeerde) gebruiker mag doen, mag lezen en wijzigen, alvorens dat de gebruiker de actie ook kan uitvoeren of informatie kan benaderen. Authentication in combinatie met authorization is van essentieel belang voor Confidentiality en Integrity.
Auditing (logging)
Vastlegging van activiteiten van gebruikers. Dit is van belang voor Accountability, maar ook om aanvallen te detecteren en te ondersteunen bij het herstellen van een aanval.

Er zijn meer mechanismen, zoals beheersbaar gebruik van resources en backup/restoreprocedure, maar die laten we nu buiten beschouwing.

Een Mendix app kan “veilig” worden genoemd, indien die goed voldoet aan de veiligheidseisen.

Risico-analyse

Een standaard onderdeel van het specificeren en ontwerpen van een applicatie is het uitvoeren van een risico-analyse. Dat klinkt misschien zwaar (en in sommige organisaties is het een heel formeel proces), maar je zult je bewust moeten zijn van de mogelijke risico’s en gevolgen van inbreuk op de veiligheidseisen. Dit zal per situatie moeten worden vastgesteld. Elke applicatie is anders, verwerkt andere informatie en heeft een ander afbreukrisico bij uitval. Een balans moet worden gemaakt tussen het beoogde veiligheidsniveau en de kosten van ontwikkeling en handhaving ervan. Veiligheid is niet gratis, daar moet je serieus werk van maken.

De informatie die door de applicatie verwerkt wordt, kan persoonlijke, privacygevoelige, gegevens bevatten. Er worden allerlei juridische eisen gesteld waaraan de verwerking, transparantie, toestemmingsplicht, archivering, verwijdering en beveiliging moet voldoen (AVG, GDPR). Dit kan zelfs landafhankelijk zijn en ook de locatie van opslag kan van belang zijn. Sommige informatie is soms zelfs verboden om te verwerken (bijvoorbeeld kent BSN hele strikte eisen). Een algemene regel is om persoonlijke informatie die niet relevant is voor het correct functioneren van de bedrijfsprocessen niet vast te leggen. Heb je de voornaam of het geslacht van personen echt nodig?

De gebruikerspopulatie zal worden beschouwd. Hierin zijn groepen te onderkennen met verschillend risicoprofiel. Wie heeft er toegang en wat mogen die zien en doen? Een afdeling van interne gebruikers heeft een ander profiel dan een groep anonieme gebruikers. Buitenstaanders willen we buiten de deur houden. Buitenstaanders, maar ook gebruikers kunnen bewust inbreuk maken op de integriteit van de applicatie (hacken).

Ook is er vaak communicatie tussen verschillende systemen of applicaties. Webservices zijn beschikbaar gemaakt voor gebruik door andere applicaties en zijn dan vaak publiek beschikbaar. Hoe zwaar moeten die beveiligd worden?

Wat is het afbreukrisico, als de beveiliging van de applicatie wordt doorbroken of wanneer er een storing optreedt waardoor de applicatie tijdelijk niet bruikbaar is? Een ondersteunende applicatie kent andere nadelige gevolgen dan een applicatie in een primair proces. Sommige aanvallen kunnen desastreuze gevolgen hebben voor de bedrijfsvoering.

Platformbeveiliging door Mendix

Als een Mendix-app via internet bereikbaar is; dat is het geval als de app in de Mendixcloud gedeployed is (dit geldt voor de meeste Mendix-apps), dan blijkt uit de praktijk dat daar dagelijks scans naar kwetsbaarheden op uitgevoerd worden. Dit is goed zichtbaar in de logs, waar hele reeksen aan 404-fouten (resource not found) voorkomen. Je ziet dat getracht wordt bestanden op te halen met namen als /etc/passwd, phpinfo.php en .htaccess. En recentelijk door de gevonden kwetsbaarheden in log4J staan er plotseling opvallend veel meldingen als ${j${main:\\k5:-Nd}i${spring:k5:-:}ldap://${sys:user.name} in de logs.

Er wordt dus actief gezocht naar de kwetsbaarheden van het Mendixplatform door onbekenden. Het is daarom zaak om de ‘deur’ goed dicht te houden, want een inbraak is niet prettig. Deze scans op kwetsbaarheden kunnen natuurlijk ook te goeder trouw plaatsvinden in het geval van ethical hacking en searchbots van searchengines waar de app is aangemeld.

Mendix doet er alles aan om de infrastructuur en het platform te beveiligen tegen aanvallen. Als onderdeel van Siemens heeft Mendix toegang tot de expertise van een zeer gespecialiseerd cybersecuritylab. Mogelijk heeft u al eens een email ontvangen over een door Siemens gevonden kwetsbaarheid in een module uit de appstore.

De container van een Mendix app beschermd standaard tegen een aantal infrastructurele kwetsbaarheden (waarover later meer), maar de verantwoordelijkheid van de ontwikkelde Mendix-apps ligt bij de ontwikkelaars ervan. Deze moeten er zelf voor zorgen dat de Mendix-apps voldoende beveiligd worden. Veiligheid is niet automatisch in een Mendix-app geregeld en kost het nodige denk- en ontwikkelwerk.

In het volgende blog Security by design: architectuur Mendix zal worden ingegaan op de architectuur van een Mendix-app en de daaruit af te leiden trust boundary.