Red-teaming

Betalingssvindel som scenarie: når målet er en forretningsproces

Betalingssvindel som scenarie: når målet er en forretningsproces

En falsk betalingsanmodning kræver ingen avanceret adgang til systemerne; den kræver, at en kæde af mennesker og kontroller giver efter på det forkerte tidspunkt. Et scenarie om betalingssvindel hviler derfor på et andet spørgsmål end et scenarie, der handler om netværk og systemer: ikke hvor langt holdet kommer ind i netværket, men om forretningsprocessen omkring betalinger og ændrede kontooplysninger holder, når nogen udgiver sig for at være en, processen stoler på.

Svaret på titlens spørgsmål er, at scenariet er relevant, når betalinger er en af organisationens kronjuveler, og når I er parate til at lade økonomifunktionen indgå i øvelsen på samme vilkår som IT. Det kræver en tydelig grænse for, hvad der må ske med rigtige penge, og det kræver, at procesejeren er med i planlægningen, uden at forsvaret afsløres.

Hvad scenariet faktisk afprøver

MITRE ATT&CK beskriver økonomisk tyveri som en teknik under taktikken Impact og nævner, at modstandere kan udgive sig for at være en betroet part for at få et offer til at sende penge til en konto, modstanderen kontrollerer. For CISO’en er pointen ikke teknikken, men målet: angrebet slutter i en forretningshandling, ikke i et system.

Det flytter fokus fra teknisk forsvar til samspillet mellem kontroller. Scenariet kan belyse:

  • Godkendelsesflowet · om to-personers godkendelse og beløbsgrænser virker, når anmodningen ser ud til at komme fra ledelsen.
  • Stamdata · hvordan en ændring af en leverandørs kontooplysninger modtages, kontrolleres og registreres.
  • Bekræftelse ad anden kanal · om medarbejderne bruger en kendt kontakt, når en anmodning er usædvanlig.
  • Melding og eskalering · om en mistanke når frem til sikkerhedsfunktionen, og hvor hurtigt.
  • Overvågning · om de digitale spor omkring anmodningen bliver set af forsvaret.

Læg mærke til, at to forsvar er i spil på samme tid. Økonomifunktionen ser en anmodning, der enten passer eller ikke passer ind i den daglige forretning. Sikkerhedsfunktionen ser måske usædvanlig aktivitet på en konto eller en henvendelse fra en afsender, der ikke plejer at skrive. Ingen af dem ser hele billedet alene. Et af de mest brugbare resultater af scenariet er derfor et svar på, om de to forsvar taler sammen, og om en medarbejder i bogholderiet ved, hvor en mistanke skal hen.

Flaget skal ligge før pengene flytter sig

Det vigtigste valg i planlægningen er, hvor scenariet slutter. Ingen rigtig betaling må gennemføres, og ingen rigtig bankkonto må ændres. Flaget skal derfor placeres på et punkt, hvor det er bevist, at processen ville have givet efter, men før noget forlader organisationen.

Eksempler på sådanne flag kan være en betaling, der er oprettet og godkendt i systemet til en aftalt testmodtager, men stoppes af white team før afsendelse, eller en ændring af en fiktiv leverandørs kontonummer, som white team har oprettet til formålet. Flaget aftales skriftligt, og den, der kan stoppe en betaling i sidste øjeblik, skal være kendt og tilgængelig i hele perioden. → Målet for øvelsen

Hvem skal give tilladelse

Et betalingsscenarie berører flere end IT. Ud over den almindelige godkendelse af øvelsen skal mindst disse forhold være afklaret:

  • Økonomidirektøren eller den, der ejer processen · accepterer, at processen afprøves, og udpeger en kontaktperson i white team, der ikke selv godkender betalinger.
  • Banken · skal ikke nødvendigvis orienteres, men I skal vide, hvad der sker, hvis en betaling alligevel når banken, og hvordan den kaldes tilbage.
  • Direktionen · hvis scenariet bruger direktørens navn eller rolle, skal godkendelsen placeres et sted, der ikke afslører øvelsen. → Direktion og bestyrelse som mål
  • Juridisk funktion · vurderer, om der er forhold omkring regnskab, revision eller indberetning, som øvelsen kan komme i berøring med.

Brug ikke rigtige leverandørers navne uden at have overvejet, hvad det betyder for relationen, hvis en medarbejder kontakter leverandøren. Fiktive leverandører eller aftalte samarbejdspartnere er tryggere.

Mennesker i økonomifunktionen

Medarbejderne i bogholderi, kreditor og løn er ikke nødvendigvis forberedt på at være en del af en sikkerhedsøvelse. De har ikke selv sagt ja, og de risikerer at føle sig udstillet, hvis de lod en anmodning passere.

Gør det klart fra start, at fund skrives om arbejdsgange og kontroller, ikke om den enkelte medarbejder. Aftal med HR, hvordan medarbejderne debriefes, og sørg for, at den, der stoppede anmodningen, også bliver set. En medarbejder, der ringede tilbage og spurgte, har gjort præcis det, processen kræver, og det skal fremgå af rapporten. → Medarbejderhensyn

Timing og forretningens rytme

En betalingsproces har travle og stille perioder. Et scenarie, der lægges midt i en måneds- eller årsafslutning, afprøver noget andet end et scenarie en almindelig onsdag, og det kan også belaste økonomifunktionen på et uheldigt tidspunkt. Beslut bevidst, hvilket af de to spørgsmål I vil have svar på, og lad white team have mandat til at udskyde scenariet, hvis forretningen kræver det. Notér det valgte tidspunkt i rapporten, så resultatet kan læses i den rette sammenhæng.

Tænk også på, at en anmodning, der afvises, kan blive gentaget af en rigtig modstander. Hvis økonomifunktionen bliver opmærksom og spreder en advarsel, er det et godt resultat. White team skal blot have en plan for, hvordan advarslen håndteres, uden at hele øvelsen afsløres. → Kommunikationsplan

Det skal I lade være med

  • At lade en rigtig betaling gå igennem · flaget skal ligge før pengene flytter sig.
  • At bruge rigtige leverandørers identitet uden overvejelse · det kan skade relationer, I ikke selv ejer.
  • At lade godkenderen af betalinger sidde i white team · så afprøves en kontrol, der kender svaret.
  • At glemme banken som mulig modtager · aftal, hvordan en fejlagtig betaling kaldes tilbage.
  • At skrive fund om navngivne medarbejdere · fundet handler om processen.
  • At måle kun på, om holdet kom igennem · meldinger og eskalering er lige så vigtige resultater.

Hvad kan og ikke kan konkluderes

Scenariet kan vise, om godkendelse, stamdatakontrol og bekræftelse ad anden kanal holdt over for én bestemt henvendelse på ét bestemt tidspunkt, og om mistanken nåede frem til forsvaret. Det kan ikke vise, at processen er sikker mod alle varianter af svindel, og et vellykket forsøg siger intet om den enkelte medarbejders dømmekraft. Et mislykket forsøg er heller ikke en garanti; det kan skyldes timing eller held. Resultatet bør derfor læses som en vurdering af kontrollernes samspil og føre til ændringer i processen, ikke til et skærpet tilsyn med enkeltpersoner. → Fra social engineering-fund til bedre processer

Tjekliste før scenariet

  • ☐ Er flaget placeret, så ingen rigtig betaling eller kontoændring kan gennemføres?
  • ☐ Har procesejeren accepteret afprøvningen og udpeget en kontaktperson uden godkenderrolle?
  • ☐ Ved white team, hvordan en betaling stoppes eller kaldes tilbage?
  • ☐ Er der taget stilling til brug af ledelsens og leverandørers navne?
  • ☐ Er HR og debriefing af økonomifunktionen aftalt?
  • ☐ Er scenariets tidspunkt valgt i forhold til forretningens rytme?

Kilder

  • MITRE ATT&CK, Financial Theft (T1657): økonomisk tyveri som teknik under taktikken Impact, herunder at en modstander udgiver sig for at være en betroet part for at få penge overført.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om red teaming

Læs også: Debriefing af medarbejdere · Datatyveri som scenarie · Detail og e-handel

→ Kontakt · Tlf. 70 13 63 23 · Red teaming hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Overvejer I en red team‑øvelse?

Fortæl kort, hvad øvelsen skal give svar på, og hvornår ledelsen skal have resultatet. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.