Elektronisk pengeoverførsel

Inspireret af artiklen ”Preventing EFT Fraud” i Information Systems Control Journal, volume 4, 2003 og de erfaringer vi har gjort ved ”it-beholdningseftersyn” hos vores kunder, vil vi i denne artikel redegøre for de forhold vi ofte støder på ved revision af elektronisk pengeoverførsel. Vi vil på udvalgte områder beskrive risici og hvordan de i praksis er eller kan reduceres. Desuden vil vi give eksempler på hvilke kontroller der kan etableres. Endelig vil vi komme med forslag til hvordan de enkelte områder kan revideres.

Målgruppe

Artiklen henvender sig mest til in- og eksterne revisorer, men da emnet grundlæggende handler om ”almindelig” it-sikkerhed kan den også være relevant for andre, der arbejder med it-sikkerhed eller har det som deres ansvarsområde.

Afgrænsning

Vi vil ikke behandle specifikke systemer, da der findes mange på markedet og hver leverandør tilbyder forskellig funktionalitet. Bevæggrundene for besvigelser vil ikke blive gennemgået - de kan være mange og falder ikke indenfor rammerne af denne artikel.

Processen

I det efterfølgende har vi kort redegjort for processen omkring elektronisk pengeoverførsel. Den beskrevne proces er så generel, at der ikke skelnes mellem de forskellige typer af pengeoverførsler der findes i dag (f.eks. betaling af kreditorer eller overførsel af løn). Da integration til øvrige systemer kan være forskellig fra virksomhed til virksomhed, kan processen have forskelligt startpunkt. Vores erfaringer viser dog, at langt de fleste virksomheder i dag starter ved punkt 1. Typisk vil det være mindre virksomheder, hvor antallet af elektroniske pengeoverførsler er beskedent, der starter ved punkt 3.

1. Fra fødesystem dannes en fil der indeholder oplysninger om pengeoverførsler
2. Opbevaring/flytning af fil med oplysninger om pengeoverførsler
3. Etablering af forbindelse til leverandørens system (via modem eller internet)
4. Indlæsning og kontrol/bekræftelse af oplysninger

Processen 1-4 varetages typisk af en eller flere medarbejdere, vi vil kalde ”indlægger”.

5. Etablering af forbindelse til leverandørens system
6. Kontrol og godkendelse af de indtastede/indlæste oplysninger

Denne sidste del af processen varetages typisk af en eller flere medarbejdere, vi vil kalde ”godkender”.

Vi forudsætter i denne artikel, at ovenstående opgaver er fordelt på to personer.

De enkelte delprocesser

Med udgangspunkt i processen vil vi for hver delproces redegøre for:

• Væsentlige risici i og omkring delprocesserne
• Hvordan de eventuelt kan reduceres
• Hvilke hensigtsmæssig kontroller der kan etableres (både manuelle og system)
• Hvordan de ovenstående punkter kan revideres

Der kan være flere af de nævnte forhold, som kan påvirke såvel hele som dele af processen, eksempelvis er der en manuel kontrol, der afdækker samtlige de risici, der er forbundet med elektronisk pengeoverførsel (mere om den senere - hav tålmodighed!). Vi har derfor valgt at strukturer beskrivelsen således, at de enkelte forhold beskrives, hvor vi har fundet det mest relevant i forhold til processen.

Top

1. Dannelse af fil
Da data i filen med oplysninger om pengeoverførslerne grundlæggende afhænger af kontrollerne i fødesystemet vil det være alt for omfattende, at redegøre for samtlige risici, kontroller der kan etableres og revisionshandlinger i denne artikel. Vi vil derfor begrænse os til, blot at nævne nogle helt grundlæggende forhold, som vi revidere ved vores ”it-likvideftersyn”, nemlig adgangskontroller (bruger ID og password) og funktionsadskillelse (hvem har adgang til hvad i fødesystemet). Omkring adgangskontrollen er relevante forhold (og der hvor vi erfaringsmæssigt ser problemer) eksempelvis manglende password eller manglende skift af samme, da dette ofte ikke er understøttet af fødesystemerne. Funktionsadskillelse kan være en udfordring med mange facetter. På dette område ser vi ofte, at der er sket en opdeling i adgangen, men at alt for mange brugere har adgang til hele fødesystemet. Vi retter derfor vores revision mod, hvem der har adgang til stamdata (kontonummer), og hvem der har ”superbruger” adgang.

2. Opbevaring/flytning af fil
Når filen med oplysninger om pengeoverførsler er dannet, skal den opbevares, indtil den kan indlæses. Der er adskillige muligheder for placering. Vi ser hovedsagligt 3 opbevaringssteder: netværksdrev, lokal harddisk eller diskette. Uanset hvilket medie der benyttes, er der risiko for, at uautoriserede brugere læser og/eller manipulere filen og f.eks. ændre beløb eller kontonumre. I langt de fleste tilfælde er der tale om en ASCII fil (tekstformat), der kan redigeres med almindelige tekstbehandlings- eller regenarkssystemer. Uanset hvilken opbevaring der er valgt, øges risikoen for manipulation jo længere tid der går inden filen indlæses i betalingssystemet. Denne risiko reduceres ved, ganske enkelt, at foretage punkt 1 til 5 i en lang, ubrudt arbejdsgang.

Hvis filen opbevares i et bibliotek på et netværksdrev kan risikoen for manipulation reduceres ved at begrænse adgangen til biblioteket til præcist de brugere, der har et arbejdsbetinget behov for det. En yderligere sikring kan være at kryptere filen. Denne løsning vil begrænse adgangen til de brugere der kender password til filen og dermed udelukke eksempelvis netværksadministratorer, der generelt har adgang til alt. Dette er dog nok ikke en praktisk løsning, idet krypteringen skal fjernes, før filen kan indlæses, og vi har ikke har set denne mulighed anvendt i praksis.

Uanset om filen opbevares på et netværksdrev eller på den lokale harddisk, er der risiko for at personer med fysisk adgang til Pc’en via denne kan opnå adgang til filen. En måde at reducere denne risiko er blandt andet ved at benytte en passwordbeskyttet pauseskærm. Det er vores erfaring, at pauseskærmen skal slå til automatisk for at være effektiv, da brugerne typisk ”glemmer” at gøre det selv.

Kontrollerne på dette område retter sig mod at danne ”kontroltal” der kan be- eller afkræfte at filen er blevet manipuleret. Det er nemlig muligt at lave diverse totaler der vil ændre sig hvis der er foretaget ændringer i filen. Eksempler er :

• Sumtotal, der kan bruges til at kontrollere ændringer i beløb
• Sum af antal pengeoverførsler, der kan bruges til at kontrollere om der er indføjet eller fjernet linier med oplysninger
• Nonsens total på kontonumre, der kan bruges til at kontrollere om der er sket ændringer i kontonumre

Endvidere kan man overveje at notere tidspunkt for dannelse af filen og foretage en kontrol af dette, før filen indlæses. Det er nemlig ganske besværligt, at ændre i filen uden at ændre det dato- og tidsstempel, som filen automatisk får, når den ændres.

Revisionshandlinger, der kan afdække denne risici, er kontrol af hvilke brugere, der har adgang til biblioteket på netværksdrevet, og hvilke rettigheder de har (læse/skrive). For at få fat i en liste eller oversigt kan det være nødvendigt at få fat i en netværksadministrator. Endelig kan det undersøges om filen er krypteret og beskyttet med kodeord.

Top

3. Etablering af forbindelse til leverandørens system (indlægger)
Denne del af processen går ganske enkelt ud på at ”indlæggeren” skaber forbindelse til det system, oplysningerne om pengeoverførselen skal indlæses i. Vi vil ikke gå i dybden med den fysiske forbindelse, der kan ske via såvel modem som internet. Vi ser oftest, at forbindelsen sker via internettet og risici m.v. er en disciplin helt for sig selv, som vi ikke vil komme ind på her, men det bør så vidt muligt revideres om virksomhedens forbindelse til internettet er beskyttet og sikret på behørig vis.

Det er i leverandørens betalingssystem, at verifikation af brugeren sker. Risikoen relatere sig til de klassiske problemer omkring fortrolighed af brugernes password. Brugeren identificere sig typisk overfor leverandørens system ved at benytte bruger ID og password, men i enkelte tilfælde er dette suppleret med et token. Risikoen reduceres i nogen grad af systemkrav til længde og sammensætning af password, men vi har ofte konstateret, at langt hovedparten af systemerne ikke understøtter tvunget skift af password! Brugerne får i nogle tilfælde besked om, at password er for gammelt, men kan sagtens opnå adgang uden at foretage udskiftning af dette.

Kontroller på dette område er vanskelige at etablere og undersøge efterlevelsen af. Et bud kunne være, at brugerne på en liste periodisk kvittere for at password er skiftet. Det er dog ganske vanskeligt at bekræfte at det rent faktisk er sket. En anden mulighed er, at bede systemleverandøren om at nulstille brugerens password. Begge er muligheder, men ingen af dem er ideelle.

Revision på adgangskontrollerne kan bestå i undersøgelse af, om hver bruger har egen unikke bruger ID. Dette kan f.eks. ske ved kontrol af fuldmagter eller lister fra leverandøren. I enkelte tilfælde er der muligt at se direkte i systemet hvem der er oprettet som bruger. Hvorvidt kravene til skift er efterlevet, kan ofte kun lade sig gøre at revidere ved at spørge brugerne direkte, hvornår de senest har skiftet password.

4. Indlæsning og kontrol/bekræftelse af oplysninger
Oplysningerne om pengeoverførslerne skal i denne delproces afleveres til leverandøren. Det sker oftest på én af to måder. Enten via direkte indtastning i systemet med udgangspunkt i grundbilag eller oversigt dannet i fødesystemet eller via indlæsning af den fil, der blev dannet under punkt 1.

Her er der risiko for fejl i indtastning/indlæsning. Denne risiko er typisk reduceret via systemkontrol i leverandørens system, eksempelvis kontrol af det indtastede/indlæste kontonummers længde og opbygning. Såfremt der er fejl i disse vil leverandørens system afvise indtastning/indlæsning. Der er dog fortsat risiko for, at fejl der ikke systemmæssigt kan kontrolleres slipper igennem. Her ligger der en opdagende kontrol i den del af processen, der ligger hos godkenderen, og den vil derfor ikke blive beskrevet her, men under punkt 6.

Revisionsmæssigt er der ikke så meget at stille op i denne del af processen. Man kan gøre sig bekendt med de systemkontroller leverandøren har bygget ind i sit system og danne sig en mening om effektiviteten af denne, men det er svært at ændre noget ved.

5. Etablering af forbindelse til leverandørens system (godkender)
Samme delproces som for indlæggeren. Se beskrivelsen i punkt 3.

Top

6. Kontrol af de indtastede/indlæste oplysninger
Risikoen her er selvfølgelig om godkenderen, der skal kontrollere og godkende pengeoverførslen, ikke opdager beviste eller ubeviste fejl. Reduktion af denne risiko basere sig alene på opdagende kontroller.

Vi har valgt at opdele kontrollerne i manuelle og systembaserede.

Manuelle kontroller

Det kan lade sig gøre, at foretage fuldstændigheds kontrol af alle elektroniske pengeoverførsler. Kontrollen skal for at være fuldstændig og dækkende ske ved at ”godkenderen” kontrollere hver enkelt postering i systemet til grundbilaget. Der bør som minimum ske kontrol af beløb og kontonummer. Dette er en omfattende og tidskrævende kontrol, men den eneste måde hvormed virksomheden kan sikre sig fuldstændigt mod fejl og besvigelser.

Der skal dog ikke mange elektroniske pengeoverførsler til før den ovenfor anførte kontrol bliver for omfattende og ressourcekrævende. Alternativet er stikprøvekontrol, men her er risikoen for at beviste eller ubeviste fejl ikke opdages selvfølgelig større. Kontrollen er bedst hvis den sker til grundbilag, men godkenderen kan vælge at få en liste med pengeoverførsler fra fødesystemet og foretage kontrol til indtastede/indlæste data op imod denne. Jo tættere på kilden, des bedre.

Kontrollen bør ske ”inde i” leverandørens system, da der kan være manipuleret med udskrifter.

Disse kontroller kan suppleres med en opfølgende kontrol ved f.eks. at gennemgå kvitteringslister fra leverandøren og sammenligne denne med de registrerede oplysninger i fødesystemet.

Revision af disse kontroller basere sig i stor udstrækning på kvittering for at kontrollen er udført. Ikke verdens bedste revisionsbevis, men umiddelbart det bedste der kan lede sig gøre.

Systembaserede kontroller

De systembaserede kontroller kan være et nødvendigt og fornuftigt supplement til stikprøvekontrollen beskrevet ovenfor.

Her kan godkenderen benytte de kontroltotaler som vi har beskrevet under kontrollerne i punkt 2. Endvidere kan godkenderen tilrettelægge kontroller ved brug af analyser. Da filen med oplysningerne om pengeoverførslerne (som beskrevet under punkt 2) ofte er i tekstformat, kan den indlæses i eksempelvis et regnearksprogram. Her kan der foretages en række forskellige analytiske handlinger. Herunder eksempelvis eftersøgning af flere pengeoverførsler til samme kontonummer (særlig relevant ifm. løn), ens beløb eller meget store eller små beløb, pengeoverførsler til udenlandske konti m.v., m.v. Kun fantasien sætter grænsen. For at denne kontrol bliver effektiv skal godkenderen ind i leverandørens system og se de aktuelle oplysninger på de pengeoverførsler, der på baggrund af analysen bliver udvalgt til kontrol.

Top

Afslutning

Der er mange risici forbundet med elektronisk pengeoverførsel. Ikke desto mindre er det vores opfattelse, at det er et noget overset område. Der er typisk meget god sikring af kontantkassen (den er låst inde og afstemmes jævnligt m.v.) og andre let omsættelige aktiver. Alligevel må vi erfaringsmæssigt konstatere, at den helt grundlæggende sikring af de elektroniske pengeoverførsler har det meget dårligt. Egentligt underligt når men tænker på hvor relativt let det er at flytte store summer elektronisk. Vi håber derfor at ovenstående gennemgang kan give inspiation til en bedre sikring af elektroniske pengeoverførsler