Hoe u DORA-resistentietests kunt plannen met behulp van AI

Overzicht

U leert hoe u een testprogramma voor digitale operationele weerbaarheid ontwerpt en implementeert dat voldoet aan DORA-artikelen 24-27 met behulp van AI. Deze gids behandelt het algemene testprogramma (kwetsbaarheidsbeoordelingen, penetratietesten, op scenario's gebaseerde testen), geavanceerde Threat-Led Penetration Testing (TLPT) vereisten, testomvang en -frequentie, het rapporteren van resultaten aan uw leidinggevend orgaan, en het integreren van testen met uw ICT-risicobeheerkader, met specifieke ISMS Copilot-prompts voor het genereren van elk onderdeel.

Voor wie dit is

Deze gids is bedoeld voor:

• CISO's en securitymanagers die verantwoordelijk zijn voor het ontwerpen van en toezien op programma's voor resistentietests

• IT-risicomanagers die testresultaten integreren in ICT-risicobeoordelingen

• Coördinatoren van penetratietesten die interne en externe testactiviteiten beheren

• Compliance officers die ervoor zorgen dat testprogramma's voldoen aan de verwachtingen van de toezichthouder

• Consultants die financiële entiteiten helpen bij de voorbereiding op TLPT of algemene resistentietests

Voordat u begint

U heeft nodig:

• Een ISMS Copilot-account (gratis proefperiode beschikbaar)

• Uw ICT-risicobeheerkader en ICT-inventaris uit Hoe u een DORA ICT-risicobeheerkader bouwt met behulp van AI

• Uw incidentclassificatie- en responsprocedures uit Hoe u DORA-incidentrapportage implementeert met behulp van AI

• Inzicht in uw huidige testactiviteiten (kwetsbaarheidsscans, penetratietesten, DR-tests)

• Kennis over of uw entiteit door uw bevoegde autoriteit is aangewezen voor TLPT

• Budgettaire machtiging voor externe testdiensten (met name voor TLPT)

De DORA-vereisten voor resistentietests begrijpen

Artikelsgewijze uitsplitsing

DORA Hoofdstuk IV (artikelen 24-27) stelt een gestructureerde aanpak vast voor het testen van de digitale operationele weerbaarheid:

Artikel

Titel

Belangrijkste vereisten

Toepasbaarheid

Art 24

Algemene vereisten voor het testen van de digitale operationele weerbaarheid

Testprogramma opzetten als onderdeel van ICT-risicobeheer, risicogebaseerde aanpak

Alle financiële entiteiten (proportioneel)

Art 25

Testen van ICT-tools en -systemen

Specifieke testtypes: kwetsbaarheidsbeoordelingen, penetratietesten, scenario-gebaseerde testen, compatibiliteitstesten, prestatietesten, broncode-evaluaties

Alle financiële entiteiten (proportioneel)

Art 26

Geavanceerd testen via TLPT

Threat-led penetration testing op basis van het TIBER-EU-kader, elke 3 jaar

Alleen aangewezen entiteiten

Art 27

Vereisten voor testers

Kwalificaties, onafhankelijkheid en standaarden voor testers (intern en extern)

Alle entiteiten die testen uitvoeren

Algemeen testen vs. TLPT

Het begrijpen van het onderscheid tussen algemeen testen en TLPT is cruciaal voor de afbakening van uw programma:

Aspect

Algemeen testen (Art 24-25)

TLPT (Art 26-27)

Belangrijkste verschil

Wie

Alle financiële entiteiten

Alleen aangewezen entiteiten

Bevoegde autoriteit wijst TLPT-entiteiten aan

Frequentie

Risicogebaseerd; kritieke systemen ten minste jaarlijks

Ten minste elke 3 jaar

TLPT is minder frequent maar veel intensiever

Scope

Alle ICT-systemen (proportioneel)

Kritieke en belangrijke functies, live productiesystemen

TLPT test live systemen, niet alleen testomgevingen

Methodologie

Divers (scans, pen-tests, scenario-tests)

TIBER-EU-kader, gebaseerd op threat intelligence

TLPT simuleert tactieken van echte aanvallers

Testers

Intern of extern (met onafhankelijkheidseisen)

Externe testers verplicht (met beperkte uitzonderingen)

TLPT vereist een gecertificeerd extern red team

Rapportage

Intern (bestuur, ICT-risicofunctie)

Aan bevoegde autoriteit, met verklaring

TLPT-resultaten gaan naar de toezichthouder

Stap 1: Ontwerp uw algemene testprogramma (artikelen 24-25)

Kader voor het testprogramma

Artikel 24 vereist een testprogramma dat integraal deel uitmaakt van uw ICT-risicobeheerkader, een risicogebaseerde aanpak volgt en proportioneel is aan de omvang en het risicoprofiel van uw entiteit.

1. Open uw DORA-werkruimte in ISMS Copilot

2. Genereer het document voor het testprogramma:

   "Maak een programma voor het testen van digitale operationele weerbaarheid voor een [type entiteit] dat voldoet aan DORA-artikelen 24-25. Neem op: doel en doelstellingen van het programma, governance (toezicht door leidinggevend orgaan, programma-eigenaar, rollen en verantwoordelijkheden), risicogebaseerde aanpak van testplanning (hoe risico's bepalen wat en hoe vaak wordt getest), testomvang (gekoppeld aan ICT-inventaris en kritieke/belangrijke functies), uit te voeren testtypes (kwetsbaarheidsbeoordelingen, netwerkbeveiligingstesten, penetratietesten, scenario-gebaseerde testen, compatibiliteitstesten, prestatietesten, broncode-evaluaties, open-source softwaretesten, end-to-end testen), testfrequentie per criticaliteit van activa en testtype, vereisten voor interne vs externe testers, onafhankelijkheidseisen per artikel 27, rapportage van resultaten en communicatie met het leidinggevend orgaan, proces voor het bijhouden van remediëring, integratie met updates van het ICT-risicobeheerkader, sjabloon voor de jaarlijkse testkalender, en budget- en middelenplanning. Pas proportionaliteit toe voor een [omvang entiteit] organisatie."

3. Definieer de risicogebaseerde testmethodologie:

   "Maak een risicogebaseerde testmethodologie voor DORA-resistentietests. Definieer hoe we bepalen: welke systemen en functies we testen (gebaseerd op criticaliteit van ICT-activa, zakelijke impact, dreigingslandschap, eerdere incidenten), welk type test we toepassen (kwetsbaarheidsscan vs penetratietest vs scenario-gebaseerde test), testdiepte en -intensiteit (basis, standaard, geavanceerd), testfrequentie (per kwartaal, halfjaarlijks, jaarlijks) en testprioriteit wanneer middelen beperkt zijn. Verstrek een testprioriteitsmatrix die de criticaliteit van activa en het dreigingsniveau koppelt aan het testtype en de frequentie. Geef voorbeelden voor een [type entiteit]."

Testtypes en hun toepassing

Artikel 25 specificeert meerdere testtypes. Gebruik ISMS Copilot om gedetailleerde plannen voor elk type te ontwikkelen:

1. Programma voor kwetsbaarheidsbeoordeling:

   "Maak een programma voor kwetsbaarheidsbeoordeling voor naleving van DORA Artikel 25. Neem op: scanomvang (alle ICT-activa per criticaliteitsniveau), scantools en -methodologie, scanfrequentie (minstens driemaandelijks voor kritieke activa, maandelijks aanbevolen), kwetsbaarheidsclassificatie afgestemd op CVSS-scores, tijdlijnen voor remediëring per ernst (kritiek: 48 uur, hoog: 7 dagen, gemiddeld: 30 dagen, laag: 90 dagen), proces voor uitzonderingsbeheer voor kwetsbaarheden die niet onmiddellijk kunnen worden verholpen, rapportageformat (technisch rapport en managementsamenvatting), methodologie voor trendanalyse en integratie met patchbeheerprocedures. Verstrek een workflow voor kwetsbaarheidsbeheer."

2. Programma voor penetratietesten:

   "Maak een programma voor penetratietesten voor naleving van DORA Artikel 25. Neem op: testomvang (externe perimeter, intern netwerk, webapplicaties, mobiele applicaties, API-beveiliging, social engineering), testfrequentie (minstens jaarlijks voor kritieke systemen, vaker voor gebieden met een hoog risico), testmethodologie (OWASP, PTES of gelijkwaardig), sjabloon voor rules of engagement (omvang, timing, escalatie, verboden acties), vereisten voor kwalificatie van testers volgens DORA Artikel 27 (onafhankelijkheid, deskundigheid, verzekering), pre-test procedures (autorisatie, bevestiging omvang, communicatie), rapportagevereisten (managementsamenvatting, technische bevindingen, risicoclassificaties, aanbevelingen voor remediëring), post-test procedures (verificatie van remediëring, hertesten) en rapportageformat voor het leidinggevend orgaan. Verstrek een voorbeeld van een rules of engagement-sjabloon."

3. Programma voor scenario-gebaseerde testen:

   "Ontwerp een scenario-gebaseerd resistentietestprogramma voor DORA Artikel 25. Maak testscenario's voor: ransomware-aanval op kernbank-/betalingssystemen, uitval van een grote cloudprovider die kritieke diensten beïnvloedt, DDoS-aanval tijdens piekperiodes van transacties, insider-dreiging die gevoelige gegevens in gevaar brengt, supply chain-aanval via een kritieke externe ICT-provider, gelijktijdige uitval van primaire en back-upsystemen, verlies van cruciaal ICT-personeel tijdens een incident, datalek met regelgevende gevolgen waarbij klantmelding vereist is. Definieer voor elk scenario: testdoelstellingen, omvang en betrokken systemen, scenarioverhaal en tijdlijn van injecties, succescriteria, deelnemers en rollen, testuitvoeringsprocedures, verwachte resultaten, evaluatiecriteria en rapportagesjabloon. Neem zowel tabletop- als gesimuleerde oefenformaten op."

Stap 2: Stel vereisten vast voor testers (artikel 27)

Onafhankelijkheid en kwalificaties van testers

Artikel 27 stelt vereisten vast voor testers die resistentietests uitvoeren. Deze gelden voor zowel interne als externe testers:

"Maak een beleid voor testervereisten en -kwalificaties voor DORA Artikel 27. Behandel: interne testers (onafhankelijkheid van de geteste gebieden, relevante certificeringen zoals OSCP/CREST/GPEN, behoud van bekwaamheid, rotatievereisten), externe testers (professionele certificeringen en accreditaties, relevante ervaring in testen in de financiële sector, beroepsaansprakelijkheidsverzekering, verificatie van onafhankelijkheid, referentiecontrole), beheer van belangenverstrengeling, screening van testers en veiligheidsprocedures, geheimhoudings- en vertrouwelijkheidseisen, en evaluatiecriteria voor de prestaties van testers. Verstrek een kwalificatiechecklist voor zowel interne als externe testers, en een voorbeeld van een werkomschrijving (statement of work) voor externe testopdrachten."

Stap 3: Plan voor TLPT (artikelen 26-27)

TLPT-vereisten begrijpen

Threat-Led Penetration Testing (TLPT) onder DORA is gebaseerd op het TIBER-EU-kader en vormt de meest intensieve testvereiste. Zelfs als u niet bent aangewezen voor TLPT, is het begrijpen van de vereisten waardevol voor de voorbereiding.

1. Beoordeel de toepasbaarheid van TLPT:

   "Beoordeel of onze [type entiteit] met [omvang, systemisch belang, ICT-risicoprofiel] waarschijnlijk zal worden aangewezen voor DORA TLPT onder Artikel 26. Denk aan: ons systemisch belang in de financiële sector, de criticaliteit van de diensten die we leveren, ons ICT-risicoprofiel en -complexiteit, criteria voor aanwijzing door de bevoegde autoriteit uit gepubliceerde richtlijnen. Indien waarschijnlijk aangewezen, verstrek een TLPT-gereedheidsbeoordeling en een voorbereidingstijdlijn. Indien onwaarschijnlijk, beveel voorbereidende maatregelen aan die we desondanks zouden moeten nemen."

2. Genereer het TLPT-kader:

   "Maak een voorbereidings- en uitvoeringskader voor TLPT voor DORA Artikel 26, afgestemd op de TIBER-EU-methodologie. Neem op: Fase 1 - Voorbereiding: definitie van de omvang (kritieke en belangrijke functies om te testen op live productiesystemen), betrokkenheid en melding aan de bevoegde autoriteit, selectie van de threat intelligence-provider, selectie van de red team-provider, vorming van het white team (intern team dat op de hoogte is van de test), goedkeuringen voor interne governance. Fase 2 - Threat Intelligence: threat intelligence-rapport (gerichte analyse van het dreigingslandschap), dreigingsscenario's gebaseerd op huidige actoren en technieken, analyse van het aanvalsoppervlak en beoordeling van dreigingsscenario's door de bevoegde autoriteit. Fase 3 - Red Team Testing: inzet van het red team (gesimuleerde aanvallen op live productiesystemen), uitvoering van de test gedurende [typische duur: 8-12 weken], gecontroleerd testen met veiligheidsmechanismen, purple team-activiteiten (indien overeengekomen) en documentatie van bevindingen. Fase 4 - Afronding: red team-rapport met bevindingen en bewijs, beoordeling van de respons van het blue team, ontwikkeling van een remediëringsplan, briefing van het leidinggevend orgaan, proces voor verklaring van de bevoegde autoriteit. Verstrek schattingen voor de tijdlijn en middelen per fase."

Selectie van TLPT-providers

TLPT vereist zowel een threat intelligence-provider als een red team-provider. Gebruik ISMS Copilot om selectiecriteria te ontwikkelen:

"Maak een selectiekader voor TLPT-providers voor DORA Artikel 26-27. Voor de Threat Intelligence Provider: vereiste kwalificaties (sectorspecifieke financiële dreigingsexpertise, erkende certificeringen), evaluatiecriteria (kwaliteit van eerdere dreigingsrapporten, begrip van dreigingen in de EU-financiële sector, gegevensbronnen en verzamelmogelijkheden) en selectiechecklist. Voor de Red Team Provider: vereiste kwalificaties (CREST, CBEST of gelijkwaardige accreditatie, ervaring met TIBER-EU testen, ervaring in de financiële sector), evaluatiecriteria (technische mogelijkheden, methodologie, teamsamenstelling, veiligheidshistorie), verificatie van onafhankelijkheid (geen huidige adviesrelatie met de entiteit), verzekeringsvereisten en selectiechecklist. Verstrek een RFP-sjabloon voor beide type providers."

TLPT-scoping

Een goede afbakening (scoping) is cruciaal voor een succesvolle TLPT. Gebruik ISMS Copilot om de testomvang te definiëren:

"Help ons bij het definiëren van de scope voor onze DORA TLPT-oefening. Onze kritieke en belangrijke functies zijn onder meer: [lijst functies]. Identificeer voor elke kritieke functie: de ondersteunende ICT-systemen en infrastructuur die in scope moeten zijn, gegevensstromen en integraties die aanvalspaden zouden kunnen zijn, externe ICT-providers die de functie ondersteunen (en of zij moeten worden opgenomen in het testen volgens artikel 26(3)), potentiële aanvalsoppervlakken (extern, intern, fysiek, social engineering) en systemen die expliciet moeten worden uitgesloten om veiligheidsredenen. Stel een TLPT-scopedocument op dat geschikt is voor beoordeling door de bevoegde autoriteit."

Stap 4: Rapportage van resultaten en tracking van remediëring

Testresultaten rapporteren aan het management

DORA vereist dat testresultaten worden gerapporteerd aan het leidinggevend orgaan en worden gebruikt om het ICT-risicobeheerkader bij te werken:

1. Genereer sjablonen voor rapportage van testresultaten:

   "Maak een rapportagesjabloon voor resistentietestresultaten voor rapportage aan het leidinggevend orgaan onder DORA Artikel 24. Neem op: managementsamenvatting (totale weerbaarheid, belangrijkste bevindingen, trendvergelijking), samenvatting van de uitvoering van het testprogramma (uitgevoerde tests, scope, timing), bevindingen per ernst (kritiek, hoog, gemiddeld, laag) met context over de zakelijke impact, vergelijking met vorige testcycli (verbetering of verslechtering), status van remediëring voor eerder geïdentificeerde kwetsbaarheden, nieuwe aanbevelingen voor remediëring met risicogebaseerde prioritering, beoordeling van de effectiviteit van het testprogramma, budget- en middelenverbruik en aanbevelingen voor aanpassingen aan het testprogramma. Het rapport moet geschikt zijn voor niet-technische bestuursleden, terwijl er voldoende detail behouden blijft voor risicotoezicht."

2. Maak TLPT-verlaringsdocumentatie:

   "Maak een TLPT-verklaringpakket voor indiening bij onze bevoegde autoriteit onder DORA Artikel 26(6). Neem op: TLPT-samenvattingsrapport (scope, methodologie, tijdlijn), geanonimiseerde red team-bevindingen (kritiek en hoge ernst), remediëringsplan met tijdlijn en status, erkenning en goedkeuring door het leidinggevend orgaan, organisatorische geleerde lessen en eventuele verzoeken om wederzijdse erkenning met andere bevoegde autoriteiten. Volg de formatrichtlijnen van [bevoegde autoriteit] en het TIBER-EU-kader."

Tracking van remediëring

Testen is alleen waardevol als bevindingen leiden tot verbeteringen. Zorg voor een robuuste tracking van remediëring:

"Maak een procedure voor het bijhouden van de remediëring van resistentietests voor DORA-compliance. Neem op: hoe bevindingen worden vertaald naar acties voor remediëring, prioriteringsmethodologie (kritiek: verhelpen binnen 30 dagen, hoog: 60 dagen, gemiddeld: 90 dagen, laag: volgende testcyclus), toewijzing van de eigenaar van de remediëring en verantwoordelijkheid, voortgangsbewaking en escalatie voor achterstallige remediëringen, verificatietests (bevestigen dat oplossingen effectief zijn), uitzonderingsproces voor bevindingen die niet kunnen worden verholpen (compenserende maatregelen, risicoacceptatie met goedkeuring van het leidinggevend orgaan), integratie met het ICT-risicoregister (bijwerken van risicobeoordelingen op basis van testbevindingen) en rapportagefrequentie aan het leidinggevend orgaan. Verstrek een sjabloon voor een register voor het bijhouden van remediëring."

Stap 5: Integreer testen met uw ICT-risicobeheerkader

Resultaten invoeren in risicobeheer

DORA vereist dat testresultaten uw ICT-risicobeheerkader informeren en bijwerken. Gebruik ISMS Copilot om deze integratie te formaliseren:

"Definieer hoe resistentietestresultaten integreren met ons DORA ICT-risicobeheerkader. Neem op: hoe testbevindingen het ICT-risicoregister bijwerken (nieuwe risico's geïdentificeerd, risicoclassificaties aangepast, effectiviteit van beheersmaatregelen opnieuw beoordeeld), hoe testresultaten de jaarlijkse beoordeling van het ICT-risicobeheerkader onder Artikel 6(5) informeren, hoe TLPT-resultaten onze ICT-risicostrategie en risicobereidheid beïnvloeden, hoe scenario-gebaseerde testresultaten onze bedrijfscontinuïteits- en herstelplannen bijwerken, hoe trends in kwetsbaarheidsbeoordelingen onze beschermings- en preventiemaatregelen onder Artikel 9 informeren en hoe resultaten van incidentsimulaties onze procedures voor incidentclassificatie en -rapportage valideren of uitdagen. Verstrek een processtroom die de feedbackloop tussen testen en risicobeheer laat zien."

Continue verbetering van het testen

Uw testprogramma zelf moet evolueren op basis van resultaten en veranderende dreigingen:

"Maak een jaarlijks evaluatieproces voor het testprogramma voor DORA-compliance. De evaluatie moet beoordelen: testdekking (hebben we alle kritieke systemen en functies getest zoals gepland?), testeffectiviteit (hebben tests echte kwetsbaarheden geïdentificeerd? hoe verhouden bevindingen zich tot werkelijke incidenten?), testefficiëntie (gebruiken we middelen effectief? zijn er overlappende of redundante tests?), veranderingen in het dreigingslandschap (weerspiegelen onze testscenario's de huidige dreigingen?), nieuwe systemen of diensten toegevoegd sinds de laatste evaluatie (zijn ze opgenomen in de testomvang?), feedback van toezichthouders of richtlijnen over testverwachtingen, en aanbevolen aanpassingen van het programma voor de volgende cyclus. Stel een evaluatierapport-sjabloon op voor het jaarlijkse testprogramma ter goedkeuring door het leidinggevend orgaan."

Stap 6: Beheer testlogistiek en governance

Testkalender en coördinatie

Stel een gestructureerde jaarlijkse testkalender op om ervoor te zorgen dat alle testactiviteiten worden gepland, gefinancierd en gecoördineerd:

"Maak een jaarlijkse resistentietestkalender voor onze [type entiteit]. Breng alle vereiste testactiviteiten over het jaar in kaart: kwetsbaarheidsscans (elk kwartaal voor kritieke activa, maandelijks voor internetgerichte activa), penetratietesten (jaarlijks extern, jaarlijks intern, jaarlijkse applicatie), scenario-gebaseerde oefeningen (halfjaarlijkse tabletop, jaarlijkse simulatie), bedrijfscontinuïteitstesten (jaarlijkse failover, jaarlijks herstel van back-ups) en TLPT-voorbereidingsactiviteiten (indien van toepassing). Neem op: benodigde middelen voor elke activiteit, coördinatievereisten (change freeze windows, betrokkenheid van business units), afhankelijkheden tussen testactiviteiten, budgettoewijzing per kwartaal en mijlpalen voor rapportage aan het leidinggevend orgaan. Formatteer als een kalenderweergave met een Gantt-chart-structuur."

Testen bij externe ICT-providers

Artikel 26(3) behandelt testen waarbij externe ICT-dienstverleners betrokken zijn. Coördineer de testvereisten met uw leveranciers:

"Maak procedures voor het coördineren van resistentietests met externe ICT-providers onder DORA. Neem op: contractuele vereisten voor deelname van providers aan testen (link naar artikel 28 contractclausules), procedures voor melding en coördinatie met providers, testen van gedeelde verantwoordelijkheid (wat wij testen vs. wat de provider test), omgaan met weigering van de provider om deel te nemen aan testen, alternatieve testaanpakken wanneer direct testen van de provider niet mogelijk is (synthetisch testen, door de provider verstrekte testrapporten), TLPT waarbij systemen van externe providers betrokken zijn (artikel 26(3) regelingen voor gebundelde testen) en bewijsverzameling van testactiviteiten van de provider. Behandel scenario's voor cloudproviders, managed service providers en providers van kritieke infrastructuur."

Volgende stappen

U heeft nu een uitgebreid programma voor het testen van digitale operationele weerbaarheid:

• Kader voor het testprogramma met risicogebaseerde methodologie

• Gedetailleerde plannen voor kwetsbaarheidsbeoordelingen, penetratietesten en op scenario's gebaseerde testen

• Vereisten voor kwalificatie en onafhankelijkheid van testers

• Voorbereidingskader voor TLPT (indien aangewezen of waarschijnlijk aangewezen)

• Rapportagesjablonen voor het leidinggevend orgaan en de bevoegde autoriteit

• Procedures voor het bijhouden van remediëring

• Integratie met het ICT-risicobeheerkader

Ga verder met de laatste gids in deze DORA-serie:

• Hoe u DORA-risico's van externe ICT-aanbieders beheert met AI -- Zorg ervoor dat uw externe providers zijn opgenomen in uw testprogramma en dat contracten uw testverplichtingen ondersteunen

Voor de basisinstallatie, zie Hoe u aan de slag gaat met DORA-implementatie met behulp van AI. Voor het ICT-risicokader, zie Hoe u een DORA ICT-risicobeheerkader bouwt met behulp van AI. Voor integratie van incidentrapportage, zie Hoe u DORA-incidentrapportage implementeert met behulp van AI.

Voor kant-en-klare prompts, zie de DORA Compliance Prompt Library. Raadpleeg voor het volledige overzicht van de regelgeving de DORA Compliance Guide for Financial Entities.

Hulp krijgen

Voor extra ondersteuning bij het plannen van uw resistentietestprogramma:

• Vraag het aan ISMS Copilot: Gebruik uw DORA-werkruimte om testscenario's te genereren die specifiek zijn voor uw type entiteit en ICT-omgeving

• Upload bestaande testrapporten: Krijg een gap-analyse door eerdere penetratietest- of kwetsbaarheidsbeoordelingsrapporten te uploaden voor vergelijking met DORA-vereisten

• TLPT-voorbereiding: Gebruik ISMS Copilot om uw TLPT-scopedocument en selectiecriteria voor providers te ontwikkelen voordat u contact opneemt met uw bevoegde autoriteit

• Valideer outputs: Controleer alle testplannen tegen DORA-artikelen 24-27, relevante RTS en het TIBER-EU-kader vóór goedkeuring door het leidinggevend orgaan