MB CYBERWORKS · TECHNISCH ARTIKEL

Informatiebeveiliging: de fundamenten die ik leerde (ISO 27001 en 27002)

Voordat ik met tools, firewalls of pentesting aan de slag ging, wilde ik eerst snappen waaróm je iets beveiligt en wát je precies beschermt. Daarom begon ik met de basis van informatiebeveiliging, aan de hand van het boek Basiskennis informatiebeveiliging op basis van ISO 27001 en ISO 27002 en de opleiding Cyber Security voor Beginners, als voorbereiding op mijn EXIN Information Security Foundation-examen.

In dit artikel zet ik die fundamenten op een rij: de kernbegrippen, hoe je naar risico’s kijkt, hoe beleid en techniek samenkomen, en hoe ik het toepas op mijn eigen server. Het is generieke theorie, maar het is wel de laag waarop al het andere rust. Ook nu ik me richt op Azure en identity security kom ik deze principes elke dag weer tegen. Hoe die stap verliep, beschrijf ik in mijn cybersecurity-leerpad van pentesting naar Azure en Entra ID.

In dit artikel

De CIA-driehoek: waar het echt om draait

Informatiebeveiliging rust op drie pijlers, vaak samengevat als de CIA-driehoek.

  • Vertrouwelijkheid: alleen bevoegde personen hebben toegang tot informatie. Denk aan klantgegevens die niet zomaar door iedereen ingezien mogen worden.
  • Integriteit: informatie is correct en volledig, en kan niet ongemerkt gewijzigd worden.
  • Beschikbaarheid: informatie is er op het moment dat je het nodig hebt.

Die drie werken samen. Een document dat onbeheerd op een printer blijft liggen, is beschikbaar voor iedereen die erbij kan, en daarmee komt de vertrouwelijkheid in gevaar. Het laat meteen zien dat beveiliging niet alleen techniek is, maar ook gedrag en inrichting.

Een belangrijk onderscheid daarbij is dat tussen data en informatie. Data zijn ruwe feiten, zoals een getal of een tijdstip. Pas in een context worden het betekenisvolle gegevens. Dat onderscheid helpt om de waarde van informatie in te schatten. Beschermen moet je trouwens allebei: ook ruwe data zoals persoonsgegevens, sleutelmateriaal of logbestanden verdienen bescherming.

Dreiging, kwetsbaarheid en risico

Om keuzes te kunnen maken, moet je eerst de begrippen scherp hebben.

  • Een dreiging is een gebeurtenis die schade kan veroorzaken.
  • Een kwetsbaarheid is een zwakke plek in een systeem, proces of gedrag.
  • Een risico ontstaat als een dreiging een kwetsbaarheid kan misbruiken, gewogen naar de kans dat het gebeurt en de impact ervan.

Een concreet voorbeeld: een databaseserver waarop beveiligingspatches niet worden toegepast. De ontbrekende patch is de kwetsbaarheid, een aanvaller die daarop binnenkomt is de dreiging, en samen vormen ze het risico. De oorzaak van zo’n incident is dus de kwetsbaarheid, niet de impact.

Voor elk risico kun je vier richtingen kiezen: vermijden, beperken (mitigeren), overdragen (bijvoorbeeld via een verzekering of leverancier) of bewust accepteren. Welke je kiest, hangt af van de waarde van de informatie en de kosten van de maatregel. Risicobeheer is uiteindelijk het maken van onderbouwde keuzes, niet het najagen van honderd procent veiligheid.

Beleid en de PDCA-cyclus

Techniek zonder beleid is los zand. Een goed informatiebeveiligingsbeleid begint bij het management, wordt duidelijk gecommuniceerd en legt vast wie waarvoor verantwoordelijk is en wat er moet gebeuren bij incidenten.

Het sterke eraan is dat het een doorlopend proces is, geen eenmalig document. Dat ritme vat je samen met de PDCA-cyclus:

  • Plan: doelen stellen en maatregelen kiezen op basis van een risicoanalyse.
  • Do: het beleid en de maatregelen invoeren.
  • Check: toetsen of ze werken en worden nageleefd.
  • Act: verbeteren op basis van evaluaties, incidenten en nieuwe dreigingen.

Zo wordt beleid een levend kader dat meebeweegt met een veranderende omgeving. Bij het bepalen van de waarde van gegevens gaat het trouwens niet om de inhoud zelf, maar om de gevolgen als die gegevens wegvallen: kunnen de processen door, en is er een back-up? Dat onderscheid tussen directe schade (verlies van apparatuur of data) en indirecte schade (reputatie, juridische claims) helpt om de juiste prioriteiten te stellen.

Rollen, verantwoordelijkheden en toegangscontrole

Informatiebeveiliging is een gedeelde taak, maar niet iedereen heeft dezelfde rol. Drie komen steeds terug:

  • de eigenaar, verantwoordelijk voor een informatieobject zoals een klantenbestand;
  • de beheerder, die de technische kant regelt, bijvoorbeeld de toegang;
  • de gebruiker, die de informatie nodig heeft voor zijn werk.

Door die rollen te scheiden voorkom je dat één persoon te veel macht of toegang krijgt. Toegangscontrole regelt vervolgens wie bij welke systemen en gegevens mag. Het uitgangspunt is simpel: alleen wie de informatie echt nodig heeft, krijgt toegang.

Er zijn verschillende modellen:

  • DAC (Discretionary Access Control): de eigenaar van de data bepaalt zelf wie toegang krijgt.
  • MAC (Mandatory Access Control): toegang wordt centraal via vaste regels bepaald.
  • RBAC (Role-Based Access Control): je krijgt toegang op basis van je rol in de organisatie.

In de praktijk zie je vooral RBAC, omdat het schaalbaar en overzichtelijk is. In een zorginstelling mag een arts medische dossiers inzien en aanpassen, terwijl een administratief medewerker alleen NAW-gegevens beheert. Iedereen krijgt automatisch de juiste rechten, niet meer en niet minder.

Dat principe van minimale rechten komt later terug in de cloud, al is het goed om twee dingen uit elkaar te houden. In Azure bepaalt RBAC wélke acties een identiteit op resources mag uitvoeren. Conditional Access bepaalt iets anders, namelijk onder welke voorwaarden iemand toegang krijgt, bijvoorbeeld met verplichte MFA of alleen vanaf een vertrouwd apparaat. Ze vullen elkaar aan, maar doen niet hetzelfde.

Organisatorische en fysieke maatregelen

Niet elke maatregel is digitaal. Een groot deel van de risico’s in een kantooromgeving is juist fysiek of gedragsmatig. Printopdrachten die onbeheerd blijven liggen, een scherm dat niet vergrendeld wordt, of een bezoeker die ongemerkt een ruimte binnenloopt: stuk voor stuk lekken die geen hacker nodig hebben.

De oplossingen liggen in een combinatie van techniek en afspraken. Follow-me printing, toegangspassen, een clean-desk-aanpak en duidelijke gedragsregels horen er net zo goed bij als firewalls. Ook continuïteit valt hieronder: redundantie in systemen, een server die automatisch overneemt bij uitval, en personeel dat elkaars taken kan overnemen. Techniek en organisatie versterken elkaar, of ze verzwakken elkaar.

Technische maatregelen

Dit is het hart van de uitvoering. De belangrijkste lagen die ik heb leren kennen:

Toegang en authenticatie. Sterke, unieke wachtwoorden per dienst, bij voorkeur beheerd met een wachtwoordmanager, aangevuld met tweefactorauthenticatie. Die extra laag verkleint het risico op misbruik aanzienlijk.

Schadelijke software herkennen. Een virus verspreidt zich via besmette bestanden, een worm doet dat zelfstandig over het netwerk, een trojaans paard verbergt zich in iets legitiems, spyware verzamelt stiekem gegevens, en een rootkit probeert zijn aanwezigheid te verbergen. Tegen deze dreigingen helpen virusscanners, firewalls, gedragsanalyse en netwerksegmentatie, mits alles up-to-date blijft.

Netwerk en segmentatie. Routers, switches en firewalls hebben elk hun eigen risico’s. Gescheiden VLAN’s, toegangscontrole op netwerkapparatuur en versleutelde verbindingen beperken de schade als er toch iets misgaat. Het Zero Trust-model trekt dit door: vertrouw niet standaard op een gebruiker of apparaat, ook niet binnen je eigen netwerk.

Cryptografie en sleutelbeheer. Bij symmetrische encryptie gebruik je één geheime sleutel voor versleutelen en ontsleutelen. Bij asymmetrische encryptie werk je met een sleutelpaar: een publieke sleutel die je mag delen, en een privésleutel die geheim moet blijven. PKI koppelt via certificaten en een Certificate Authority een publieke sleutel aan een identiteit. Geheime en privésleutels horen goed beschermd en bij voorkeur regelmatig vervangen te worden. Raakt een privésleutel gecompromitteerd, dan vervang je de sleutel en trek je het bijbehorende certificaat in. Of een certificaat nog geldig is, controleert een client via een CRL of via OCSP. TLS is het bekendste voorbeeld: je browser controleert of het certificaat geldig is en of de certificaatketen naar een vertrouwde Certificate Authority leidt.

Logging en monitoring. Als er iets misgaat, is een logbestand vaak het eerste spoor. Goede logging beantwoordt wat, wanneer, waar, wie en waarvandaan. Gecentraliseerd in een SIEM herken je patronen van misbruik eerder, zoals inlogpogingen buiten werktijd.

Privacy en back-up. Bij pseudonimisering vervang je direct identificerende gegevens door een pseudoniem, terwijl je de aanvullende informatie waarmee je iemand alsnog kunt herleiden apart en beveiligd bewaart. Let wel: pseudonieme gegevens blijven persoonsgegevens onder de AVG. En de 3-2-1-regel blijft het uitgangspunt voor back-ups: drie kopieën, op twee verschillende media, waarvan één op een externe locatie. Brand, ransomware of een technische fout raken zelden alle drie tegelijk.

Incidenten en continuïteit

Niet elke storing is een beveiligingsincident. Een haperende netwerkprinter waarbij geen gegevens weglekken, is dat niet. Een medewerker die toegang krijgt tot een bestand dat niet voor hem bedoeld is, is dat wél, want dan is de vertrouwelijkheid geschonden. Een incident raakt dus altijd de vertrouwelijkheid, integriteit of beschikbaarheid van informatie.

Voor de aanpak leun ik op het NIST Cybersecurity Framework. In versie 2.0 bestaat dat uit zes functies. Het zijn geen vaste stappen die je één voor één afloopt, maar doorlopende functies om risico’s te beheersen:

  • Govern: de verantwoordelijkheden, het beleid en de risicostrategie vastleggen en bewaken.
  • Identify: weten welke assets je hebt en waar de risico’s liggen.
  • Protect: maatregelen nemen om incidenten te voorkomen.
  • Detect: afwijkingen tijdig opmerken.
  • Respond: snel reageren om schade te beperken.
  • Recover: terug naar normaal, en leren van wat er gebeurde.

Govern is in versie 2.0 toegevoegd en zet governance, beleid en verantwoordelijkheden centraal, als paraplu boven de andere vijf.

Daarnaast hoort er een Business Continuity Plan te zijn: een plan dat beschrijft hoe de organisatie na een calamiteit blijft functioneren. Dat gaat verder dan ICT. Toen in een voorbeeld back-uptapes smolten bij een brand, bleek hoe belangrijk het is om kopieën op een andere locatie te bewaren. Techniek, procedures en fysieke keuzes komen hier samen.

De menselijke factor: social engineering

Veel incidenten ontstaan niet door een technisch lek alleen, maar door een samenspel van mens, techniek en organisatie. Social engineering speelt daarop in met psychologische trucs om mensen informatie te ontfutselen. In een oefencasus deed iemand zich voor als hotelreceptioniste en vroeg naar creditcardgegevens, zogenaamd om een fout te herstellen. De aanpak was herkenbaar: eerst informatie verzamelen door observatie, dan vertrouwen en urgentie creëren, en ten slotte autoriteit misbruiken.

Daar helpt geen enkele firewall tegen. Wat wel helpt, is bewustwording en het principe van verificatie: vertrouw een telefoontje of e-mail nooit blind, maar controleer of de afzender legitiem is. Medewerkers zijn geen zwakke schakel die je moet wantrouwen, maar een belangrijke verdedigingslinie die je met awareness versterkt.

Uitbesteding en de cloud

Informatiebeveiliging houdt niet op bij je eigen organisatie. Steeds vaker worden diensten uitbesteed aan hosting- of cloudleveranciers. De belangrijkste les daarbij: uitbesteden betekent niet dat je de verantwoordelijkheid kwijt bent. Onder de AVG houdt de verwerkingsverantwoordelijke zijn eigen verplichtingen en blijft hij aanspreekbaar op de verwerking, terwijl de verwerker daarnaast eigen wettelijke plichten heeft. Een leverancier is dus niet automatisch van verantwoordelijkheid ontslagen. Wie waarvoor verantwoordelijk is, leg je vast in een verwerkersovereenkomst.

Daarnaast maak je heldere, meetbare afspraken over het serviceniveau, in een Service Level Agreement (SLA) waarin ook staat wat er gebeurt bij contractbreuk. Vage gedragscodes bieden geen harde garantie. Die aandacht moet door de hele keten lopen, want ook de onderaannemers van je leverancier kunnen bij kritieke onderdelen.

Bij clouddiensten staan gegevens vaak buiten je eigen omgeving, soms buiten de EU. Normen en rapporten helpen om te toetsen of een leverancier voldoet aan erkende eisen, al is het goed om ze uit elkaar te houden. ISO/IEC 27017 en 27018 zijn richtlijnen (codes of practice) voor respectievelijk cloudbeveiliging en de bescherming van persoonsgegevens in de cloud; een organisatie laat zich certificeren tegen ISO 27001 en kan die richtlijnen in de audit meenemen. SOC 2 is geen certificering, maar een assurance-rapport over de beheersmaatregelen van een dienstverlener. Let bij beide altijd op de scope en de periode die onderzocht is, want het blijft een momentopname.

Hoe ik dit in de praktijk breng

De theorie werd pas echt concreet op mijn eigen server, de Privacyhub. Die draait onder meer WireGuard, Pi-hole, Nextcloud en Fail2Ban. Dankzij deze basis snap ik beter welke configuraties invloed hebben op beschikbaarheid, hoe ik toegangscontrole inricht met een VPN en Fail2Ban, en hoe ik logs gebruik als audittrail. Ik pas er ook bepaalde Zero Trust-principes toe, zoals expliciete verificatie en minimale rechten. Een VPN en segmentatie maken van mijn omgeving nog geen volledige Zero Trust-architectuur, maar de principes erachter pas ik wel bewust toe. Mijn TLS-configuratie kon ik direct koppelen aan wat ik over certificaten en sleutelbeheer had geleerd.

Diezelfde principes, identiteit, minimale rechten, logging en gelaagde verdediging, vormen nu de brug naar waar ik me op richt: beveiliging in Microsoft Azure en Entra ID. De namen van de diensten verschillen, maar de vragen zijn hetzelfde. Wie mag wat, hoe weet je het als iets misgaat, en hoe houd je het beheersbaar?

Tot slot

Dit zijn de fundamenten waarop ik ben gaan bouwen. Ze hebben me geholpen het ISFS-examen te halen, maar belangrijker is dat ik ze nog steeds gebruik, van mijn eigen server tot mijn verdieping in de cloud. Goede beveiliging is zelden één oplossing. Het is een combinatie van beleid, techniek en gedrag die elkaar versterkt.

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *