Executives Guide: Security Configuration

Met deze blog ga ik je helpen met het motiveren van ontwikkelaars om een applicatie veiliger te maken en waarom Security Configuratie (financieel) voordeliger en ook voor ontwikkelaars interessant is. Uiteraard wordt dit betoog onderbouwd met een uitleg van termen en onderwerpen die de revue zullen passeren.

Waarom (kennis van) Security Configuratie interessant is

De term Security Configuratie is eigenlijk heel gemakkelijk te ontleden. Het onderwerp omvat namelijk alle configuraties die aangepast kunnen worden om de beveiligingsgraad te verhogen. Deze configuraties liggen vaak al klaar om gebruikt te worden, maar dit wordt vaak door nalatigheid niet gedaan. Daarom is Security (Mis)configuratie dé oorzaak van een groot aantal kwetsbaarheden en hacks. Het onderwerp staat zelfs op plek vijf in de OWASP Top Ten; een standaard bewustwordingsdocument voor ontwikkelaars en beveiliging van webapplicaties. Security Configuratie betreft elk niveau in de soft-/hardware stack: netwerken, platformen, besturingssystemen, databases, code, virtuele machines/containers, etc.

"Security Configuratie is dé oorzaak van kwetsbaarheden en hacks."

We zien een aantal zaken vaak misgaan: ontbreken van beveiligingsupdates, gebruiken van standaard inloggegevens, geen of zwakke versleuteling, onbeschermde API’s of bestanden, onnodige openstaande poorten, onnodige geïnstalleerde software en processen met te veel rechten.

 

Manieren om Security Configuratie toe te passen

Bij het toepassen van Security Configuratie gaat het om het instellen van veilige configuraties in alle eerdergenoemde niveaus. Er zijn duidelijke verbeterpunten te omschrijven op het gebied van zowel processen als principes. Sommige van deze punten zijn misschien al goed geregeld, maar anderen dan weer niet. Wanneer er met een GAP-analysis is bepaald welke verbeteringen er gemaakt kunnen worden, dienen deze doorgevoerd te worden om de risico’s van een onveilige configuratie te mitigeren.

 

Processen

  • Volg een herhaalbaar hardeningsproces. Dit houdt in dat je een draaiboek hebt waarmee servers en applicaties veilig mee geconfigureerd kunnen worden. Dit geeft je controle over het proces waarmee je je applicaties veilig maakt en zorgt ervoor dat alles aan dezelfde standaard voldoet.
  • Configureer productie-, test- en ontwikkelomgevingen identiek aan elkaar. Hiermee kun je niet alleen problemen met de inrichting van de productieomgeving in een vroeg stadium ontdekken, maar verplicht je jezelf om al vanaf het begin security in te bouwen.
  • Verwijder onnodige functies en ongebruikte afhankelijkheden. Deze onderdelen leveren geen waarde en vormen alleen maar een beveiligingsrisico.
  • Stel een prioriteitssysteem in om updates tijdig te implementeren. Software updates bieden niet alleen nieuwe functionaliteit, maar nog veel belangrijker ook patches voor beveiligingslekken. Het doorvoeren van deze updates kan een grote impact hebben, daarom is het belangrijk om deze te prioriteren. Kritieke beveiligingslekken moeten meteen opgelost worden.
  • Gebruik een applicatie architectuur die een effectieve scheiding biedt tussen verschillende componenten. Denk hierbij bijvoorbeeld aan een microservices architectuur. Elke service kan dan zo veilig mogelijk geconfigureerd worden zonder dat het een ander component in de weg zit. Daarnaast maak je het een aanvaller moeilijker om vanuit een gehackte service terecht te komen in een volgend systeem.
  • Implementeer Security Configuratie in je DevOps proces. Het zijn namelijk beide doorlopende processen en sluiten goed op elkaar aan. In de afbeelding hieronder is te zien welke acties je bij welke DevOps stap kunt uitvoeren. Hiermee zorg je ervoor dat Security Configuratie onderdeel wordt van het dagelijkse werk.

Principes

  • Door het least privilege principe toe te passen, verleen je gebruikers (en systemen) alleen de toegang die ze nodig hebben. Door niet meer rechten toe te wijzen dan strikt noodzakelijk, verklein je de impact van een gehackt account. Je staat pas extra rechten toe wanneer deze nodig zijn en neemt ze daarna weer weg.
  • Met het defense in depth principe tref je meerdere lagen van maatregelen op security events: preventieve, detectieve en reactieve. Door op al deze lagen actief te zijn, verklein je de kans dat een kwade actor serieuze schade kan aanrichten.
  • Door middel van het trust nothing principe configureer je effectief begrenzingen, validatie, whitelisting en ‘ontsmetting’. Dit houdt in dat het duidelijk is welke omgeving vertrouwd is, in welke er extra maatregelen moeten worden getroffen, of data veilig gebruikt kan worden en of een aanvraag beantwoord moet worden.
  • Met economy of mechanism ontwerp je zo eenvoudig mogelijk (oftewel: KISS), is security een zo eenvoudig mogelijk mechanisme, zijn er makkelijke controles en bevestigingen en worden beproefde veilige oplossingen hergebruikt. Hiermee blijven kosten onder controle en wordt de kans op falen geminimaliseerd.
  • Door Fail Safe-standaarden te gebruiken, moeten standaardconfiguraties veilig zijn en wordt een systeem bij een mislukte beveiligde transactie teruggebracht in een secure state. Dit houdt in dat de kans op onveilige configuraties aanzienlijk verkleind wordt en dat veilige configuraties niet terugvallen in een onveilige staat.
  • Openheid van ontwerp: beveiliging mag niet afhangen van geheimhouding; vertrouw niet op security through obscurity; houd wachtwoorden en sleutels geheim versleuteld.
  • Door het ontwerp van je applicaties open te maken, hangt de beveiliging niet af van geheimhouding en word je verplicht om wachtwoorden en sleutels geheim te versleutelen.

 

Actiepunten

We hebben nu gezien dat er heel wat gedaan kan worden om de stand van Security Configuratie te verbeteren in een organisatie. Het is misschien nog wat onduidelijk of ongrijpbaar hoe je hier nu precies mee aan de slag kunt. Daarom heb ik hier een paar technische actiepunten op een rijtje gezet, die je mee kunt geven aan engineers.

 

Het optimaliseren en toepassen van Security Configuratie leidt tot kostenbesparingen en een hogere graad van cyberweerbaarheid. Wanneer de aanbevelingen en aanwijzingen een te grote stap blijken om te implementeren binnen je organisatie, kun je de specialisten van SALT Cybersecurity inschakelen. Leer meer over onze diensten.

Andere artikelen over dit onderwerp:

Het nut van een goede cybersecuritystrategie

Het is iets wat ons allemaal overviel, de inmiddels ruim bekende kwetsbaarheid in Log4j: Log4Shell. Als lezer zul je het waarschijnlijk ook al wel weer een beetje gehad hebben met alle nieuwssites die hierover rapporteren. Desondanks voel ik me verplicht om hier toch nog een artikel aan te wijden.

Het nut van een goede cybersecuritystrategie

Het is iets wat ons allemaal overviel, de inmiddels ruim bekende kwetsbaarheid in Log4j: Log4Shell. Als lezer zul je het waarschijnlijk ook al wel weer een beetje gehad hebben met alle nieuwssites die hierover rapporteren. Desondanks voel ik me verplicht om hier toch nog een artikel aan te wijden.

Package afhankelijkheden: de verborgen killer

Het gebruiken van externe packages in je applicaties om het leven makkelijker te maken is iets wat we allemaal doen, maar waar we vaak de gevaren niet goed van voor ogen hebben. Het grote voordeel van open source code uit de community zou moeten zijn dat we op het werk van anderen kunnen leunen én erop kunnen vertrouwen dat andere mensen de code op veiligheid controleren.

Package afhankelijkheden: de verborgen killer

Het gebruiken van externe packages in je applicaties om het leven makkelijker te maken is iets wat we allemaal doen, maar waar we vaak de gevaren niet goed van voor ogen hebben. Het grote voordeel van open source code uit de community zou moeten zijn dat we op het werk van anderen kunnen leunen én erop kunnen vertrouwen dat andere mensen de code op veiligheid controleren.

De gevaren van het blind vertrouwen van ontwikkelaars

Vorige week kwam naar buiten dat er weer eens een WordPress plug-in gigantische gaten in websites veroorzaakt. John Leyden (journalist voor The Daily Swig) schrijft hier het volgende over: “Kwetsbaarheden in OptinMonster, een plug-in voor e-mailmarketing voor WordPress, lieten meer dan een miljoen websites open voor misbruik, waarschuwen beveiligingsonderzoekers van Wordfence.” De plug-in laat aanvallers gevoelige informatie exporteren en kwaadaardige JavaScript toevoegen aan kwetsbare sites, naast andere exploits.

De gevaren van het blind vertrouwen van ontwikkelaars

Vorige week kwam naar buiten dat er weer eens een WordPress plug-in gigantische gaten in websites veroorzaakt. John Leyden (journalist voor The Daily Swig) schrijft hier het volgende over: “Kwetsbaarheden in OptinMonster, een plug-in voor e-mailmarketing voor WordPress, lieten meer dan een miljoen websites open voor misbruik, waarschuwen beveiligingsonderzoekers van Wordfence.” De plug-in laat aanvallers gevoelige informatie exporteren en kwaadaardige JavaScript toevoegen aan kwetsbare sites, naast andere exploits.

Andere artikelen in de Executives Guide serie:

Thomas van den Nieuwenhoff

Thomas van den Nieuwenhoff

Security Blogger voor SALT Cyber Security en student HBO-ICT Infrastructure Design & Security op Windesheim.