Wat wordt onderzocht bij een IT security audit?

Eerst de scope: wat willen we eigenlijk weten?

“Doe maar een security audit” is nog geen goede onderzoeksvraag.

Vooraf wil ik weten:

• welke processen kritisch zijn;
• welke systemen daarbij horen;
• welke gegevens belangrijk zijn;
• welke leveranciers een grote rol spelen;
• waar bestuur, directie of IT nu onzeker over is;
• welk besluit na de audit genomen moet kunnen worden.

Een audit voor een organisatie die vrijwel alle IT heeft uitbesteed krijgt bijvoorbeeld vanzelf veel aandacht voor leveranciers, toegang, contracten en assurance.

Bij een organisatie met eigen infrastructuur kan de technische inrichting juist zwaarder wegen.

De scope volgt dus uit de organisatie, niet uit een standaardlijst.

Governance: wie stuurt en wie beslist?

Cybersecurity is nooit alleen een technisch onderwerp.

Ik kijk daarom ook naar de bestuurlijke inrichting.

Bijvoorbeeld:

• wie eigenaar is van digitale risico's;
• welke rol bestuur/directie heeft;
• welke verantwoordelijkheden bij IT liggen;
• wie risico's mag accepteren;
• hoe ernstige afwijkingen worden geëscaleerd;
• hoe informatiebeveiliging wordt besproken;
• welke informatie richting management of toezicht gaat.

Voor bestuur en directie is vooral relevant of risico's bestuurbaar zijn.

Een technisch probleem wordt pas bestuurbaar wanneer duidelijk is:

• wat de impact kan zijn;
• wie eigenaar is;
• welke maatregel nodig is;
• welke termijn realistisch is;
• welk restrisico daarna overblijft.

Identiteiten en toegangsrechten

Toegang is vrijwel altijd een belangrijk auditonderwerp.

Ik kijk bijvoorbeeld naar:

• hoe accounts worden aangemaakt;
• hoe rechten veranderen bij functiewijziging;
• hoe snel accounts worden beëindigd;
• multi-factor authenticatie;
• beheeraccounts;
• verhoogde rechten;
• serviceaccounts;
• toegang door leveranciers;
• periodieke toegangsreviews.

Daarbij wil ik niet alleen een procedure zien.

Als in het beleid staat dat vertrokken medewerkers direct worden afgesloten, wil ik bijvoorbeeld ook kunnen zien dat dit de afgelopen periode daadwerkelijk zo is gebeurd.

Dat verschil tussen afspraak en werking is in audits belangrijk.

Systemen, endpoints en technische inrichting

Vervolgens komt uiteraard ook de techniek aan bod.

Afhankelijk van de scope kan ik kijken naar:

• laptops en endpoints;
• servers;
• cloudomgevingen;
• netwerksegmentatie;
• firewalls;
• beheerinterfaces;
• beveiligingsinstellingen;
• patchmanagement;
• versleuteling;
• externe toegang;
• beheer op afstand.

De centrale vraag is steeds:

is de inrichting passend voor het risico, en kan de organisatie aantonen dat deze inrichting structureel wordt beheerd?

Een goed beveiligingsproduct helpt, maar lost weinig op wanneer het verkeerd is ingesteld of maar een deel van de omgeving afdekt.

Patch- en kwetsbaarhedenbeheer

Vrijwel iedere organisatie heeft kwetsbaarheden.

Dat is op zichzelf niet bijzonder.

Ik wil vooral weten hoe de organisatie ermee omgaat.

Vragen die ik dan stel zijn bijvoorbeeld:

• welke systemen worden gescand;
• hoe vaak;
• wie kritieke bevindingen beoordeelt;
• welke oplostermijnen gelden;
• hoe uitzonderingen worden vastgelegd;
• wat gebeurt als een leverancier niet tijdig kan patchen;
• welke kwetsbaarheden al langere tijd openstaan.

Voor een IT-manager is dit vaak bekend terrein.

Voor bestuur of directie vertaal ik het liever naar:

hebben we zicht op kwetsbaarheden die onze kritieke dienstverlening kunnen raken, en worden die aantoonbaar tijdig opgevolgd?

Logging, monitoring en detectie

Preventie kan nooit ieder incident voorkomen.

Daarom kijk ik ook naar de vraag of een organisatie afwijkend gedrag überhaupt ziet.

Bijvoorbeeld:

• welke systemen logging leveren;
• welke gebeurtenissen worden gemonitord;
• wie meldingen beoordeelt;
• wat buiten kantooruren gebeurt;
• hoe lang logs beschikbaar blijven;
• welke meldingen tot escalatie leiden;
• of incidenten achteraf onderzocht kunnen worden.

Een dashboard met veel meldingen geeft nog geen zekerheid.

Ik wil weten welke meldingen ertoe doen en of iemand er daadwerkelijk iets mee doet.

Back-up, herstel en continuïteit

Bij back-up kijk ik vrijwel altijd verder dan “de back-up draait”.

De interessantere vraag is:

kun je ook terug?

Ik kijk bijvoorbeeld naar:

• welke gegevens en systemen worden geback-upt;
• hoe vaak;
• waar back-ups worden opgeslagen;
• wie ze kan wijzigen of verwijderen;
• hoe ransomwarebestendig de inrichting is;
• wanneer voor het laatst een restore is uitgevoerd;
• hoe lang herstel werkelijk duurt;
• welke leveranciers nodig zijn om een kritisch proces weer op gang te krijgen.

Voor bestuur en directie is vooral de koppeling met continuïteit van belang.

Een groene back-upstatus is mooi. Aantoonbaar herstelvermogen geeft veel meer zekerheid.

Incident response: wat gebeurt er als het toch misgaat?

Ook goede beveiliging kent incidenten.

Daarom onderzoek ik of de organisatie weet wat zij dan moet doen.

Denk aan:

• incident response plan;
• rollen en verantwoordelijkheden;
• bereikbaarheid;
• escalatie;
• betrokkenheid van bestuur/directie;
• communicatie;
• juridische en privacyaspecten;
• forensisch onderzoek;
• herstel;
• contact met leveranciers;
• uitgevoerde oefeningen.

Een plan dat nooit is geoefend, blijft een aanname.

Ik vind een simpele scenario-oefening daarom vaak waardevoller dan nog een extra pagina in het incidenthandboek.

Leveranciers en ketenafhankelijkheden

Veel organisaties hebben hun IT grotendeels uitbesteed.

Dat verandert de werkzaamheden. De afhankelijkheid blijft.

Ik kijk dan bijvoorbeeld naar:

• welke leveranciers kritisch zijn;
• welke systemen zij beheren;
• welke gegevens zij verwerken;
• welke toegang zij hebben;
• welke beveiligingsafspraken zijn gemaakt;
• welke assurance beschikbaar is;
• hoe incidenten worden gemeld;
• welke herstelafspraken bestaan;
• welke onderaannemers worden gebruikt;
• wat gebeurt bij langdurige uitval.

Een leverancier kan technisch veel goed geregeld hebben.

De auditvraag is ook of de organisatie zelf voldoende zicht en regie houdt.

Medewerkers en dagelijkse uitvoering

Beveiliging zit ook in gewone werkprocessen.

Daarom kijk ik bijvoorbeeld naar:

• onboarding;
• uitdiensttreding;
• omgaan met gevoelige informatie;
• awareness;
• phishingmeldingen;
• change management;
• functiescheiding;
• escalatie van afwijkingen;
• incidentmeldingen.

Ik ben daarbij minder geïnteresseerd in de vraag of iemand ooit een e-learning heeft gevolgd.

Interessanter is of medewerkers weten wat van hen wordt verwacht en of de organisatie afwijkingen herkent en opvolgt.

Welk bewijs gebruik je tijdens een audit?

Een audit draait voor een belangrijk deel om aantoonbaarheid.

Afhankelijk van de scope gebruik ik bijvoorbeeld:

• beleidsdocumenten;
• configuraties;
• gebruikersoverzichten;
• accountreviews;
• logging;
• patchrapportages;
• kwetsbaarhedenrapportages;
• back-up- en restoreverslagen;
• incidentregistraties;
• leverancierscontracten;
• assurance-rapportages;
• tickets;
• managementrapportages;
• notulen;
• uitgevoerde controles.

Daarbij gebruik ik graag drie simpele begrippen:

Opzet

Is de maatregel logisch en passend ontworpen?

Bestaan

Is de maatregel daadwerkelijk ingevoerd?

Werking

Functioneert de maatregel in de praktijk zoals bedoeld?

Neem multi-factor authenticatie.

Op papier kan staan dat MFA verplicht is. Dan wil ik ook kunnen zien:

• voor welke accounts MFA geldt;
• hoe dat technisch is afgedwongen;
• welke uitzonderingen bestaan;
• wie die uitzonderingen heeft goedgekeurd.

Dat geeft veel meer zekerheid dan alleen een beleidsregel.

Hoe vertaal je technische bevindingen naar bestuurlijke risico's?

Een auditrapport moet bruikbaar zijn voor verschillende lezers.

De IT-manager heeft technische details nodig.

Een bestuurder wil vooral weten:

• wat is het risico;
• welk proces kan geraakt worden;
• hoe groot kan de impact zijn;
• hoe goed wordt het risico nu beheerst;
• welke maatregel heeft prioriteit;
• wie is eigenaar;
• welk besluit is nodig.

Die vertaling vind ik essentieel.

Een kritieke kwetsbaarheid in een testserver is misschien minder belangrijk dan een middelzware bevinding in een systeem waar de hele dienstverlening van afhangt.

De context bepaalt de prioriteit.

Wat levert een goede audit op?

Ik vind een audit geslaagd wanneer de organisatie na afloop beter kan beslissen.

De uitkomst moet daarom ten minste duidelijk maken:

• waar de organisatie aantoonbaar sterk staat;
• welke risico's onvoldoende worden beheerst;
• waar bewijs ontbreekt;
• welke verbeteringen snel kunnen;
• welke structurele maatregelen nodig zijn;
• wie eigenaar moet worden;
• welke punten bestuur of directie zelf moeten besluiten.

Bij Kynexis vertaal ik dat naar een samenhangend en geprioriteerd beeld, zodat IT én management ermee verder kunnen.

Wanneer is een audit niet de juiste vorm?

Niet iedere vraag vraagt om een brede audit.

Wil je vooral weten waar je globaal staat, dan kan een nulmeting logischer zijn.

Wil je één technische omgeving verdiepend bekijken, dan past een assessment vaak beter.

Wil je specifiek weten of een aanvaller een systeem kan binnendringen, dan kom je eerder bij een penetratietest.

Daar hebben we aparte keuzehulpen voor.

[Interne link: /cybersecurity-audit-pentest-kwetsbaarheidsscan/ zodra aanwezig]

Mijn uitgangspunt bij een IT security audit

Ik wil na een audit geen dik rapport afleveren waar de organisatie vervolgens zelf betekenis aan moet geven.

De uitkomst moet juist duidelijk maken:

wat werkt, wat weten we nog onvoldoende, welk risico zit daarachter en wat verdient als eerste aandacht?

Dat is voor mij het verschil tussen controleren en werkelijk inzicht geven.

Zelf alvast voorbereiden?

Gebruik dan ook de Cybersecurity audit checklist: welke onderdelen controleer je?

Wil je onafhankelijk laten onderzoeken hoe technische en organisatorische beveiligingsmaatregelen in de praktijk werken? Bekijk dan de Cyber Security Audit van Kynexis.