Governance van MFA-moeheid en push-bombingaanvallen

De pushmelding van 02:13 die een bestuursvraag werd

Om 02:13 ontvangt een senior financieel beheerder een mobiele melding: “Aanmelding goedkeuren?” Ze is half in slaap, gaat ervan uit dat het om een time-out van een in de cloud gehost financieel platform gaat en tikt op goedkeuren.

Om 02:19 bevindt de aanvaller zich binnen de identiteitsprovider. Om 02:31 probeert hij toegang te krijgen tot een salarisexport, een geprivilegieerde cloudconsole en een gedeelde mailbox die wordt gebruikt voor leveranciersbetalingen. Om 03:05 ziet het SOC herhaalde MFA-prompts, een ongebruikelijke geografische locatie, een succesvolle goedkeuring en een nieuwe sessie vanaf een onbeheerd apparaat.

Het gesprek die ochtend is herkenbaar:

• “Maar we hadden toch MFA?”
• “Waarom heeft de gebruiker dit goedgekeurd?”
• “Hebben we de details van de MFA-challenge gelogd?”
• “Is dit een datalek in verband met persoonsgegevens?”
• “Hebben we rapportageverplichtingen binnen 24 uur of 72 uur?”
• “Zal onze ISO 27001:2022-auditor dit als een falen van de beheersmaatregel behandelen?”
• “Raakt dit NIS2, DORA, GDPR, klantcontracten of cyberverzekering?”

Dit is het governancehiaat achter MFA-moeheid en push-bombing. Aanvallers breken geen cryptografie. Zij putten menselijke besluitvorming uit, misbruiken zwak authenticatieontwerp en zoeken naar ongemonitorde uitzonderingen. Het falen van de beheersmaatregel is zelden “MFA niet ingeschakeld”. Meestal gaat het om een keten van zwakke identiteitsassurance, risicovol ontwerp van pushgoedkeuringen, ontbrekende nummermatching, onduidelijke regels voor geprivilegieerde toegang, onvoldoende authenticatielogging, gebrekkige alerttriage, onvoldoende getrainde gebruikers en het ontbreken van gedocumenteerd bewijs dat de organisatie de zwakte heeft beoordeeld en gecorrigeerd.

Voor CISO’s, compliancemanagers, auditors en proceseigenaren moet MFA-moeheid worden behandeld als een ISMS-bewijsvraagstuk, niet alleen als een instelling in de identiteitsprovider. De aanpak combineert ISO 27001:2022-risicobehandeling, ISO/IEC 27002:2022-beheersmaatregelen, beleidsverplichtingen, gebruikersbewustzijn, incidentrespons, leveranciersgovernance en mappings over meerdere kaders voor NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019.

MFA-moeheid is een assurance-falen, geen gebruikersprobleem

MFA-moeheid, ook push-bombing of prompt-bombing genoemd, doet zich voor wanneer een aanvaller met een geldig wachtwoord herhaaldelijk MFA-goedkeuringsverzoeken activeert totdat de gebruiker er één accepteert. Soms voegt de aanvaller social engineering toe, zoals een valse helpdeskoproep, een bericht met de claim “we testen uw account”, of een verzoek om een aanmelding goed te keuren om meldingen te stoppen.

Het operationele risico is dat organisaties vaak alle vormen van MFA als gelijkwaardig behandelen. Dat zijn ze niet.

Een eenvoudige pushmelding met “goedkeuren of weigeren” is zwakker dan nummermatching, phishing-resistente FIDO2-beveiligingssleutels, certificaatgebaseerde authenticatie of voorwaardelijke toegang die onmogelijke reizen en onbeheerde apparaten blokkeert. MFA faalt ook wanneer bypass-uitzonderingen niet zijn gedocumenteerd, serviceaccounts interactief zijn, verouderde protocollen open blijven staan of toegang met een hoog risico geen sterkere authenticatie vereist.

In de Zenith Blueprint: roadmap in 30 stappen voor auditors plaatst Clarysec veilige authenticatie in de fase Controls in Action, stap 19: technische beheersmaatregelen I. De guidance is direct:

Authenticatie is de eerste en meest kritieke verdedigingslinie tussen een dreigingsactor en uw systemen, gegevens en diensten. Als authenticatie zwak is, kan al het andere, encryptie, monitoring, segmentatie, worden omzeild.

Dezelfde Zenith Blueprint behandelt ook ISO/IEC 27002:2022-beheersmaatregel 5.17 in stap 22:

Als identiteit de vraag is: “Wie bent u?”, dan is authenticatie het bewijs. Beheersmaatregel 5.17 is waar theorie vertrouwen wordt. Deze vereist dat authenticatie-informatie gedurende de volledige levenscyclus veilig wordt beheerd, zodat de methoden en inloggegevens waarmee identiteit wordt geverifieerd niet zelf de zwakste schakel worden.

Die twee uitspraken verklaren waarom push-bombing in het risicoregister thuishoort. Encryptie helpt niet als de aanvaller een goedgekeurde gebruiker wordt. Netwerksegmentatie helpt minder wanneer geprivilegieerde cloudtoegang via een vermoeide prompt wordt goedgekeurd. Monitoring werkt alleen wanneer authenticatiegebeurtenissen voldoende gedetailleerd worden gelogd en tijdig worden beoordeeld.

Een volwassen risicoverklaring moet expliciet zijn:

Hier wordt ISO 27001:2022 relevant. De norm vereist context, belanghebbenden, leiderschap, risicobeoordeling, behandelplanning, operationele beheersing, monitoring, interne audit, directiebeoordeling en voortdurende verbetering. MFA-moeheid raakt ze allemaal.

Het ISO 27001:2022-cluster van beheersmaatregelen dat auditors zullen toetsen

ISO 27001:2022 biedt de structuur van het managementsysteem. ISO/IEC 27002:2022 biedt implementatierichtlijnen voor beheersmaatregelen. Voor MFA-moeheid en push-bombing richten auditors zich doorgaans op een cluster in plaats van op één afzonderlijke beheersmaatregel.

Clarysec’s Zenith Controls: The Cross-Compliance Guide mapt ISO/IEC 27002:2022-beheersmaatregel 8.5 Secure authentication naar ondersteunende beheersmaatregelen zoals 5.17 Authentication information, 8.2 Privileged access rights, 8.16 Monitoring activities, 5.24 Information security incident management planning and preparation en 5.34 Privacy and protection of PII. Deze koppeling is belangrijk omdat een screenshot met “MFA ingeschakeld” niet voldoende is. Auditors willen bewijs dat authenticatie risicogebaseerd is ontworpen, gemonitord, beoordeeld en verbeterd.

Een verdedigbaar bewijspakket moet het volgende bevatten:

1. Risicobeoordeling waarin push-bombing en social engineering van MFA-prompts zijn geïdentificeerd.
2. Authenticatiestandaard die toegestane MFA-methoden per systeemkritikaliteit definieert.
3. Beleid voor geprivilegieerde toegang dat sterkere authenticatie vereist voor beheerderstoegang en toegang op afstand.
4. Configuratie-export van de identiteitsprovider met nummermatching, promptlimieten, voorwaardelijke toegang en geblokkeerde legacy-authenticatie.
5. Logboeken met geslaagde en mislukte MFA-gebeurtenissen, geweigerde prompts, onmogelijke reizen en apparaatcontext.
6. Alertregels voor herhaalde MFA-prompts, herhaalde faalgevallen en ongebruikelijke succesvolle goedkeuring.
7. Incidentresponsregistraties voor authenticatiegerelateerde alerts.
8. Bewustwordingstrainingsmateriaal waarin gebruikers wordt geïnstrueerd onverwachte prompts niet goed te keuren.
9. Toegangsrechtenbeoordelingen voor geprivilegieerde systemen en systemen met hoge impact.
10. Uitzonderingenregister met vervaldatums, goedkeuringen door risico-eigenaren en compenserende beheersmaatregelen.

Beleid maakt van “keur onverwachte prompts niet goed” auditbewijs

Veel organisaties zeggen tegen gebruikers dat zij verdachte prompts niet moeten goedkeuren. Dat advies is nuttig, maar niet genoeg voor ISO 27001:2022-certificering, NIS2-toezicht, DORA-weerbaarheid, GDPR-verantwoordingsplicht, klant-due diligence of cyberverzekering.

Het eerste beleidsanker is P38 Beleid inzake beveiligde communicatie en multifactorauthenticatie (MFA). Het behandelt de menselijke factor rechtstreeks:

Gebruikersbewustzijn: gebruikers moeten training krijgen om veilige van onveilige communicatiekanalen te onderscheiden. De training moet het juiste gebruik van multifactorauthenticatie (MFA) omvatten, bijvoorbeeld het niet goedkeuren van onverwachte aanmeldprompts, en veilige communicatiepraktijken, bijvoorbeeld het verifiëren van links voor videovergaderingen en het niet bespreken van vertrouwelijke onderwerpen via onbeveiligde lijnen.

Dit maakt van MFA-moeheid een trainingsverplichting, geen schuldvraag. Het stelt de CISO in staat aan te tonen dat prompt-bombing is opgenomen in onboarding, opfristraining, rolgebaseerde training en briefings voor geprivilegieerde gebruikers.

Hetzelfde P38 Beleid inzake beveiligde communicatie en multifactorauthenticatie (MFA) creëert ook een monitoringverplichting:

Informatiebeveiliging moet authenticatielogboeken continu monitoren op pogingen tot aanmelding met één factor of afwijkende MFA-faalgevallen. Logboeken van beveiligde communicatiesystemen moeten, waar van toepassing, worden gemonitord op pogingen tot ongeautoriseerde toegang of configuratiewijzigingen.

Voor mkb-organisaties legt P11S Beleid inzake beheer van gebruikersaccounts en privileges - mkb een praktische baseline vast:

Multifactorauthenticatie (MFA) moet, waar technisch haalbaar, worden ingeschakeld voor beheerdersaccounts of gevoelige systemen.

De frase “waar technisch haalbaar” mag nooit een achterdeur worden. Als een systeem sterke MFA niet ondersteunt, moet de uitzondering worden geregistreerd met een eigenaar, vervaldatum, compenserende beheersmaatregelen, monitoring en een migratieplan. Grotere organisaties kunnen dezelfde verwachting afstemmen op P11 Beleid inzake beheer van gebruikersaccounts en privileges en vervolgens toetsen of beleid en operationele werkelijkheid overeenkomen.

Detectiebewijs komt uit P22S Beleid voor logging en monitoring - mkb, dat logging van authenticatiegebeurtenissen vereist:

Authenticatielogboeken: geslaagde en mislukte aanmeldpogingen, sessieduur, MFA-gebruik

Het vereist ook een onmiddellijke beoordeling van authenticatiesignalen met hoog risico:

Onmiddellijke beoordeling na detectie van alerts met hoge ernst, bijvoorbeeld malware, mislukte multifactorauthenticatie (MFA), herhaalde mislukte aanmeldingen

Bewustwording moet mee-evolueren met dreigingen. Informatiebeveiligingsbewustzijns- en opleidingsbeleid - mkb ondersteunt die cyclus:

Onderwerpen moeten opkomende dreigingen, bijvoorbeeld phishing, relevante beleidswijzigingen en interne incidenttrends omvatten.

Wanneer het SOC pogingen tot MFA-moeheid detecteert, moet die intelligence worden gebruikt voor gebruikerswaarschuwingen, helpdeskscripts, tabletop-oefeningen en actualisaties van trainingsmateriaal.

Een beheerst maatregelenpakket voor MFA-moeheid

Stel dat uw organisatie een cloudidentiteitsprovider, een SaaS-CRM, een financieel platform, een VPN en een aanbieder van beheerde beveiligingsdiensten gebruikt. Het doel is MFA-moeheid te beheersen met de Zenith Blueprint, de beleidsbibliotheek en de cross-compliance guide Zenith Controls van Clarysec.

Begin met stap 19 in de Zenith Blueprint, die teams opdraagt authenticatievereisten per systeem te definiëren en waarschuwt dat authenticatie uitsluitend met een wachtwoord moet worden vermeden voor beheerdersaccounts, cloudconsoles, tools voor toegang op afstand en systemen die vanaf internet bereikbaar zijn. Pas vervolgens de praktische beoordelingsactiviteit toe:

Beoordeel uw MFA-uitrol: identificeer hiaten en plan hoe deze worden gesloten. Valideer dat serviceaccounts waar mogelijk niet-interactief zijn, sterke inloggegevens hebben en zijn gedocumenteerd. Bevestig dat er op geen enkel systeem of in geen enkele applicatie standaardinloggegevens zijn achtergebleven.

Zet die guidance om in een operationeel pakket aan beheersmaatregelen.

Stap 1: classificeer systemen op authenticatierisico

Stap 2: verwijder pushgedrag met hoog risico

Schakel basis-pushgoedkeuring uit voor beheerdersaccounts en accounts met hoge impact. Gebruik waar mogelijk phishing-resistente authenticators. Waar pushmeldingen blijven bestaan, dwing nummermatching, applicatiecontext, geografische context, apparaatbinding en promptfrequentielimieten af. Blokkeer legacy-authenticatie en vereis herauthenticatie voor risicovolle sessies.

Stap 3: definieer alertregels voor MFA-moeheid

Een praktische SIEM-regel moet activeren wanneer één of meer van deze patronen binnen een kort tijdsvenster optreden:

• Drie of meer MFA-pushprompts voor één gebruiker.
• Twee geweigerde prompts gevolgd door één goedgekeurde prompt.
• MFA-goedkeuring vanaf een nieuwe geografische locatie of een onbeheerd apparaat.
• MFA-prompt na een signaal van password spraying of credential stuffing.
• MFA-goedkeuring voor geprivilegieerde toegang buiten normale werktijden.
• Nieuwe authenticatorregistratie kort na mislukte aanmeldpogingen.

De alert moet een incidentticket aanmaken, het SOC of de beveiligingsverantwoordelijke informeren en indammingsstappen verplicht stellen: sessie opschorten, refresh tokens intrekken, wachtwoordreset vereisen, apparaat verifiëren, gebruiker interviewen, toegang tijdens de sessie beoordelen en classificeren of er impact op persoonsgegevens of een kritieke dienst is ontstaan.

Stap 4: koppel privacy- en incidentregistraties

Als het account toegang kan krijgen tot persoonsgegevens, pas dan het Beleid inzake PII-beveiliging en toegangscontrole toe. Dit vereist sterke authenticatie voordat toegang tot persoonsgegevens met hoge impact wordt ingeschakeld:

[Beide] De verantwoordelijke voor informatiebeveiliging MOET sterke authenticatie vereisen voor geprivilegieerde, externe, administratieve toegang of toegang met hoge impact tot persoonsgegevens voordat dergelijke toegang wordt ingeschakeld en de vereiste in REG12 vastleggen.

Het vereist ook dat de scope van logging wordt gedefinieerd:

[Beide] De systeemeigenaar / applicatie-eigenaar MOET de scope van logging van persoonsgegevens voor authenticatiegebeurtenissen, toegangsgebeurtenissen, geprivilegieerde acties, PII-exportactiviteit en wezenlijke configuratiewijzigingen in REG12 definiëren vóór productiegebruik of een wezenlijke wijziging.

Wanneer monitoring wijst op ongeautoriseerde toegang tot persoonsgegevens, ontstaat een verplichting tot incidentregistratie:

[Voorwaardelijk] De Incident Response Coordinator MOET binnen één werkdag een REG10-registratie openen of koppelen wanneer monitoring wijst op vermoedelijke ongeautoriseerde toegang tot persoonsgegevens, vermoedelijke verstrekking van persoonsgegevens, vermoedelijke wijziging van persoonsgegevens of vermoedelijk verlies van beschikbaarheid van persoonsgegevens.

De privacy-escalatie wordt afgerond door het Beleid inzake incidenten en datalekbeheer voor PII:

[Voorwaardelijk] De Privacy Lead / PIMS Manager MOET toepasselijke wettelijke, sectorale, financiële-sector-, cyberbeveiligings-, contractuele, klant- en dienstontvangergerelateerde rapportagetriggers voor elk incident met hoge impact met betrekking tot persoonsgegevens beoordelen en de uitkomst van de toepasselijkheid vastleggen in REG01, REG08 en REG10.

Dit maakt van een MFA-alert auditgereed bewijs over beveiliging, privacy en compliance heen.

NIS2, DORA en GDPR: één incident, verschillende vragen

MFA-moeheid is een nuttige stresstest over meerdere compliancekaders, omdat het governance, cyberhygiëne, toegangsbeveiliging, incidentdetectie, leverancierstoegang en datalekmelding raakt.

NIS2: verantwoordingsplicht van het management en cyberhygiëne

NIS2 is van toepassing op veel essentiële en belangrijke entiteiten, afhankelijk van sector, omvang en aanwijzing door de lidstaat. Article 20 legt verantwoordingsplicht bij leidinggevende organen om maatregelen voor cyberbeveiligingsrisicobeheer goed te keuren, toezicht te houden op de implementatie en training te ontvangen. Article 21 vereist passende technische, operationele en organisatorische maatregelen, waaronder incidentafhandeling, cyberhygiëne, beveiliging van de toeleveringsketen, toegangscontrole, beheer van bedrijfsmiddelen, training en multifactorauthenticatie of continue authenticatie waar passend. Article 23 introduceert gefaseerde incidentrapportageverplichtingen voor significante incidenten, waaronder een vroegtijdige waarschuwing binnen 24 uur nadat men kennis heeft gekregen en incidentmelding binnen 72 uur.

Een push-bombingincident wordt daardoor een bestuursvraag: was MFA veilig ontworpen of alleen maar ingeschakeld?

DORA: authenticatie als digitale operationele weerbaarheid

Voor financiële entiteiten die onder DORA vallen, is DORA van toepassing vanaf 17 januari 2025. DORA verwacht ICT-risicobeheer, detectie, respons, herstel, incidentrapportage, testen van digitale operationele weerbaarheid en risicobeheer voor derde aanbieders van ICT-diensten.

DORA Article 9 behandelt bescherming en preventie, waaronder toegangscontrole en authenticatiemaatregelen. Article 10 behandelt detectie van afwijkende activiteit. Article 17 vereist een proces voor het beheer van ICT-gerelateerde incidenten. In een DORA-context moet bewijs over MFA-moeheid aantonen dat getroffen ICT-activa zijn geïdentificeerd, monitoring afwijkend gedrag heeft gedetecteerd, het incident op impactcriteria is geclassificeerd, waar vereist naar senior management is geëscaleerd en geleerde lessen zijn teruggekoppeld naar het ICT-risicokader.

GDPR: beveiliging van de verwerking en verantwoordingsplicht

GDPR Article 5(1)(f) vereist integriteit en vertrouwelijkheid. Article 5(2) vereist verantwoordingsplicht. Article 32 vereist beveiliging passend bij het risico. Article 4 definieert een inbreuk in verband met persoonsgegevens als een inbreuk op de beveiliging die leidt tot onopzettelijke of onrechtmatige vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of ongeoorloofde toegang tot persoonsgegevens.

Als een incident met MFA-moeheid persoonsgegevens raakt, is de bewijsvraag eenvoudig: kan de organisatie passende authenticatiebeheersmaatregelen, monitoring, incidentrespons en datalekbeoordeling aantonen?

Crosswalk voor ISO, NIST CSF 2.0, COBIT 2019 en auditbewijs

NIST CSF 2.0 is nuttig omdat het MFA-governance vertaalt naar uitkomsten voor GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND en RECOVER.

COBIT 2019 voegt governancehelderheid toe. Een COBIT-georiënteerde auditor kan kijken naar DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security en MEA03 Managed compliance with external requirements. De focus ligt niet op de MFA-leverancier. Het gaat erom of authenticatie bedrijfsdoelstellingen ondersteunt, of toegangsrechten worden beheerst, of monitoring effectief is en of management betekenisvolle assurance ontvangt.

Een geconsolideerde mapping helpt complianceteams gefragmenteerde bewijsverzoeken te voorkomen:

Waar auditors en toezichthouders om zullen vragen

Een sterk programma voor MFA-moeheid moet meerdere auditstijlen kunnen doorstaan. De cross-compliance guide Zenith Controls van Clarysec laat zien hoe ISO/IEC 27002:2022-beheersmaatregelen worden getoetst binnen ISO-, NIST-, COBIT- en ISACA-methodologieën.

Een zwak programma zegt: “We hebben de gebruiker gevraagd en het wachtwoord gereset.” Een beheerst programma levert een SIEM-alert, incidentticket, registratie van sessie-intrekking, bewijs van wachtwoordreset, beoordeling van MFA-factoren, analyse van toegangslogboeken, PII-beoordeling, evaluatie van rapportagetriggers, oorzakenverklaring, corrigerende maatregelen en input voor de directiebeoordeling op.

Een actieplan van 30 dagen voor governance van MFA-moeheid

Het doel is niet perfectie binnen 30 dagen. Het doel is zichtbaarheid, eigenaarschap en bewijs.

Week 1: identificeren en scope bepalen

• Maak een lijst van alle identiteitsproviders, VPN’s, cloudconsoles, SaaS-platformen en tools voor geprivilegieerde toegang.
• Identificeer systemen met persoonsgegevens, financiële gegevens, productietoegang of functies met impact op dienstverlening.
• Exporteer huidige MFA-methoden en uitzonderingen.
• Identificeer externe accounts en leveranciersaccounts.
• Voeg MFA-moeheid en push-bombing toe aan het risicoregister.
• Wijs een risico-eigenaar en een behandelingseigenaar aan.

Week 2: authenticatie hardenen

• Schakel legacy-authenticatie uit.
• Vereis waar haalbaar phishing-resistente MFA voor beheerders.
• Schakel nummermatching en applicatiecontext in voor push-MFA.
• Pas voorwaardelijke toegang toe voor locatie, apparaatcompliance en onmogelijke reizen.
• Beperk herhaalde pushprompts.
• Vereis herauthenticatie voor acties met hoog risico.
• Maak serviceaccounts waar mogelijk niet-interactief.
• Documenteer uitzonderingen met vervaldatum en compenserende beheersmaatregelen.

Week 3: monitoren en oefenen

• Zorg dat authenticatielogboeken succes, falen, sessieduur en MFA-gebruik vastleggen.
• Maak alertregels voor herhaalde prompts, geweigerde prompts gevolgd door goedkeuring, registratie van nieuwe apparaten en ongebruikelijke locatie.
• Test alerts met een gecontroleerde simulatie.
• Valideer het aanmaken en escaleren van incidenttickets.
• Train gebruikers met een korte oefening rond “onverwachte MFA-prompt”.
• Actualiseer helpdeskscripts om social engineering tijdens wachtwoordresets en herinschrijving van MFA te voorkomen.

Week 4: bewijs en directiebeoordeling

• Sla configuratie-exporten en screenshots op.
• Leg uitkomsten van toegangsrechtenbeoordelingen vast.
• Koppel voltooiing van training aan geprivilegieerde gebruikers.
• Beoordeel incidenten en bijna-incidenten.
• Werk de Verklaring van Toepasselijkheid en het behandelplan bij.
• Presenteer restrisico en metrieken aan het management.
• Plan steekproeven voor de interne audit.

Maak MFA-moeheid auditeerbaar voordat het meldingsplichtig wordt

MFA-moeheid herinnert eraan dat beveiligingsmaatregelen vaak falen op de raakvlakken: tussen identiteit en monitoring, tussen beleid en training, tussen leveranciers en interne toegang, tussen incidentrespons en privacyrapportage.

Organisaties die dit goed beheersen, zetten niet simpelweg “MFA aan”. Zij besturen authenticatie als een levenscyclus, monitoren deze als dreigingssignaal, trainen gebruikers als onderdeel van de beheersmaatregel en bewaren bewijs als onderdeel van het ISMS.

Clarysec brengt drie assets samen:

• De Zenith Blueprint: roadmap in 30 stappen voor auditors, met name stap 19 voor veilige authenticatie, stap 22 voor authenticatie-informatie en stap 16 voor door personeel gedreven incidentmelding.
• Clarysec-beleidssjablonen, waaronder P38 Beleid inzake beveiligde communicatie en multifactorauthenticatie (MFA), P22S Beleid voor logging en monitoring - mkb, P11S Beleid inzake beheer van gebruikersaccounts en privileges - mkb, Informatiebeveiligingsbewustzijns- en opleidingsbeleid - mkb, Beleid inzake PII-beveiliging en toegangscontrole en Beleid inzake incidenten en datalekbeheer voor PII.
• Zenith Controls: The Cross-Compliance Guide, die ISO/IEC 27002:2022-beheersmaatregelen 5.17, 8.5, 8.15 en 8.16 mapt naar ondersteunende beheersmaatregelen, ISO-auditverwachtingen, GDPR, NIS2, DORA, NIST en COBIT.

Als u CISO, compliancemanager, auditor of proceseigenaar bent, voer dan een eendaagse beoordeling van bewijs voor MFA-moeheid uit. Haal uw MFA-configuratie, authenticatielogboeken, lijst met geprivilegieerde toegang, lijst met leverancierstoegang, incidentdraaiboek, trainingsmateriaal en uitzonderingenregister op. Als die artefacten geen samenhangend verhaal vertellen, kan Clarysec u helpen het pakket aan beheersmaatregelen op te bouwen voordat een aanvaller, auditor of toezichthouder erom vraagt.

Verken de Zenith Blueprint, beoordeel Zenith Controls of plan een Clarysec-discoverycall om MFA-moeheid om te zetten van een verrassing op bestuursniveau naar een verdedigbaar, auditeerbaar authenticatieprogramma.