Opzet, bestaan en werking bij informatiebeveiliging

Wat betekent opzet?

Opzet gaat over de vraag of de maatregel passend is ontworpen.

Voorbeeld:

De organisatie wil voorkomen dat onbevoegden toegang krijgen tot kritieke systemen.

De opzet kan dan bestaan uit:

• individuele accounts;
• multi-factor authenticatie;
• beperkte beheerrechten;
• periodieke toegangsreview;
• procedure bij uitdiensttreding.

De auditvraag is:

zou deze inrichting, als zij goed wordt uitgevoerd, het risico voldoende beheersen?

Wat betekent bestaan?

Bestaan betekent dat de ontworpen maatregel daadwerkelijk is ingevoerd.

Bij hetzelfde voorbeeld kijk je dan of:

• MFA technisch is geactiveerd;
• beheeraccounts bestaan;
• rechten zijn ingericht;
• reviewproces is gestart;
• offboardingprocedure wordt gebruikt.

Een beleidsdocument met “MFA is verplicht” bewijst het bestaan van MFA nog niet.

Daarvoor wil je de feitelijke inrichting zien.

Wat betekent werking?

Werking gaat een stap verder.

De maatregel bestaat, maar functioneert hij ook structureel?

Bijvoorbeeld:

• is MFA gedurende de onderzochte periode actief gebleven;
• zijn nieuwe accounts correct toegevoegd;
• zijn uitzonderingen beheerst;
• zijn kwartaalreviews werkelijk uitgevoerd;
• zijn gevonden afwijkingen opgelost;
• zijn vertrokken medewerkers tijdig afgesloten.

Daarmee verschuift de vraag van aanwezigheid naar betrouwbaarheid.

Waarom is dit onderscheid zo bruikbaar?

Omdat veel beveiligingsproblemen juist tussen deze drie lagen ontstaan.

Goede opzet, geen bestaan

De procedure is uitstekend beschreven, maar technisch nog niet ingevoerd.

Bestaan, beperkte werking

De kwetsbaarheidsscanner draait, maar niemand volgt de bevindingen tijdig op.

Werking zonder duidelijke opzet

Een ervaren beheerder doet verstandige controles, maar alles zit in zijn hoofd en niemand weet wat er gebeurt als hij vertrekt.

De drie begrippen maken zulke verschillen zichtbaar.

Voorbeeld: back-up en herstel

Opzet

Er is bepaald:

• welke systemen worden geback-upt;
• welke frequentie geldt;
• welke bewaartermijn nodig is;
• hoe back-ups worden beschermd;
• welke hersteltijden passen bij de bedrijfsvoering.

Bestaan

Je kunt zien dat:

• back-uptaken zijn ingericht;
• opslag bestaat;
• rechten zijn beperkt;
• meldingen worden gegenereerd.

Werking

Je kunt aantonen dat:

• taken structureel succesvol draaien;
• fouten worden opgevolgd;
• restore-tests plaatsvinden;
• herstel binnen de gewenste termijn lukt.

Voor bestuur/directie is vooral die laatste stap relevant.

Een groene back-upstatus zegt minder dan aantoonbaar herstelvermogen.

Voorbeeld: leveranciersbeheer

Opzet

Er is bepaald welke leveranciers kritisch zijn en welke eisen gelden.

Bestaan

Contracten, SLA's en beoordelingsprocessen zijn ingericht.

Werking

Leveranciers worden daadwerkelijk periodiek beoordeeld, assurance wordt gelezen, afwijkingen worden opgevolgd en risico's worden geactualiseerd.

Dat is het verschil tussen “we hebben leveranciersmanagement” en “we sturen aantoonbaar op leveranciersrisico”.

Voorbeeld: incident response

Opzet

Er is een incident response plan met rollen en escalatie.

Bestaan

Contactlijsten, draaiboeken en voorzieningen zijn beschikbaar.

Werking

De organisatie oefent, actualiseert contactgegevens, verwerkt lessen en weet tijdens een incident werkelijk wie beslist.

Wat betekent dit voor bestuur en directie?

Voor bestuur/directie maakt het onderscheid managementinformatie veel scherper.

Neem de uitspraak:

“Onze kritieke controls zijn op orde.”

Ik zou dan willen weten:

• bedoelen we dat ze zijn beschreven;
• technisch zijn ingevoerd;
• of aantoonbaar gedurende de tijd functioneren?

Dat zijn drie verschillende niveaus van zekerheid.

Een bruikbare bestuurlijke vraag

“Van welke belangrijke beveiligingsmaatregelen weten we alleen dat ze bestaan, en van welke hebben we ook aantoonbare werking?”

Dat levert vaak een interessanter gesprek op dan een dashboardscore.

Wat betekent dit voor de IT-manager?

Voor de IT-manager helpt het vooral om bewijs uit normale beheerprocessen te halen.

Denk aan:

• accountreviews;
• patchrapportages;
• vulnerability tickets;
• SIEM-alertopvolging;
• restore-tests;
• change logs;
• endpointstatus;
• leverancierstickets.

Dan ontstaat bewijs automatisch tijdens het werk.

Dat is veel efficiënter dan vlak voor een audit screenshots verzamelen.

Hoe toets je werking zonder bureaucratie?

Je hoeft niet ieder detail continu te controleren.

Begin risicogericht.

Stap 1

Selecteer de controls die het meest relevant zijn voor kritieke risico's.

Stap 2

Bepaal welk bewijs logisch is.

Stap 3

Leg vast wie de controle uitvoert.

Stap 4

Bepaal een passende frequentie.

Stap 5

Registreer afwijkingen en opvolging.

Dat kan voor de ene control maandelijks zijn en voor een andere jaarlijks.

Waar gaat het in de praktijk vaak mis?

De procedure wordt als bewijs gezien

Een procedure bewijst vooral de opzet.

Een screenshot wordt als structurele werking gezien

Een screenshot laat één moment zien.

De control heeft geen eigenaar

Dan is onduidelijk wie afwijkingen moet opvolgen.

Er is bewijs, maar niemand beoordeelt het

Een rapportage zonder opvolging is nog geen effectieve control.

Alles krijgt dezelfde controlefrequentie

Risico bepaalt hoe vaak je wilt toetsen.

Opzet, bestaan en werking in een audit

In een audit gebruik ik deze begrippen om bewijs te structureren.

Bijvoorbeeld:

Dat maakt een auditrapport ook voor management begrijpelijker.

Het verband met interne beheersing

Interne beheersing draait uiteindelijk om vertrouwen in de werking van maatregelen.

Daarom passen deze begrippen zo goed bij informatiebeveiliging.

Je kunt ermee voorkomen dat gesprekken blijven hangen in:

• beleid;
• tools;
• certificaten;
• plannen.

De kernvraag wordt:

welke risico's beheersen we, met welke maatregelen, en hoe weten we dat die maatregelen werken?

Dat is voor mij de essentie van aantoonbare informatiebeveiliging.

Wil je dit breder in de organisatie inrichten? Bekijk dan de Kynexis-dienst Interne beheersing informatiebeveiliging.