REVISIONSRAPPORT. Intern kontroll och säkerhet vid elektronisk handläggning av leverantörsfakturor. Arvika kommun. September 2005.

Transkript

1 REVISIONSRAPPORT Intern kontroll och säkerhet vid elektronisk handläggning av leverantörsfakturor Arvika kommun September 2005 Rolf Aronsson (1)

2 Innehållsförteckning 1. Sammanfattning av synpunkter Bakgrund och uppdrag Kartläggning och översiktlig analys av rutinen Economa Faktura översiktlig beskrivning Fakturahantering, scanning och bokföring Rutin för kontroller vid hantering av scannade fakturor i system Economa Kontrollmiljö och kontrollaktiviteter Ankomstregistrering och manuell registrering med inskanning Avstämning och kontroller vid integration med bokföring och utbetalning Reglemente för kontroll av verifikationer Beslutsattestanter Mottagningsattest Rutin för fakturagranskning Styrning av åtkomst Policy och riktlinjer...11 (2)

3 1. Sammanfattning av synpunkter I vår granskning har vi konstaterat att kontrollmiljön och genomförda kontrollaktiviteter till stora delar fungerar relativt bra. Vi har dock funnit några områden som vi anser bör förbättras och/eller förtydligas för att ytterligare förbättra den intern kontrollen vid användning av systemen: Rutinen för fakturagranskning vid förvaltningarna är väsentlig för att uppnå en god intern kontroll vid hantering av fakturor. Vi har noterat att omfattningen och kvaliteten på inlämnad dokumentation till ekonomienheten över genomförda granskningar varierar. Bl.a. har vi noterat att vissa förvaltningar inte dokumenterar vilka fakturor som har granskats, vilket vi anser är en viktig del i dokumentationen. Vi rekommenderar att ekonomiavdelningen i samverkan med större förvaltningar ser över nuvarande rutin. Begreppen risk och väsentlighet bör få en mer uttalad roll i bedömningen av olika kontrollaktiviteter. Kraven på hur förvaltningarna skall dokumentera genomförda granskningar måste också förtydligas. Ekonomiavdelningens roll i analysen av inlämnad dokumentation bör också tydliggöras. Kontroller av att mottagningsattesten och beslutattesten inte görs av samma person sker i liten omfattning för närvarande. Mottagningsattesten är en viktig funktion för att uppnå en bra intern kontroll vid köp av varor och tjänster. Vid översyn av nuvarande rutin för fakturagranskning bör man utifrån en riskbedömning överväga om det finns anledning att utöka nuvarande kontroller av att mottagningsattesten och beslutsattesten inte görs av samma person. Bedömningen skall alltid utgå från begreppen risk och väsentlighet. Kommunstyrelsen har under augusti 2005 fasställt en policy för IT-säkerheten. Policyn skall konkretiseras i IT-säkerhetsinstruktionerna, Förvaltning, Drift och Användare samt i Systemsäkerhetsplaner för väsentliga system. Arbetet med att ta fram instruktioner och systemsäkerhetsplaner måste prioriteras för att få en tydlig och dokumenterad samt fastställd säkerhetsnivå för användning av systemen. Det är också viktigt att tydliggöra roller och ansvar för hur arbetet med att ta fram instruktioenr och planer skall bedrivas. D.v.s arbetsfördelningen mellan IT-enheten och verksamheterna samt utsedda systemansvariga. (3)

4 Som exempel på instruktioner/riktlinjer kan nämnas säkerhetsnivå vid hantering av identiteter och lösenord. I ekonomisystemet Devis finns i dag inga krav lösenord etc., vilket innebär att säkerhetsnivån är mycket låg. Vi anser att användare av ett system (oavsett behörighetsnivå) alltid skall ha personliga identiteter med krav på lösenord, bl.a. av den anledningen att användare som har använt systemet säkert genom säkerhetsloggar skall kunna identifieras i efterhand. Finns inga krav på lösenord är det svårt att i efterhand hävda att viss användare har använt systemet. I det prioriterade arbetet med instruktioner och riktlinjer bör man på ansvarig nivå fastställa vilken säkerhetsnivå som skall gälla i ekonomisystemet. Andra exempel på behov av riktlinjer/föreskrifter är dokumenterad rutiner för registrering och avregistrering av användare, beslut och kvittering av identiteter, riktlinjer för skydd av datorrum, arbetsstationer m.m. Ett annat viktigt område är loggning och behandlingshistorik. I system Economa Faktura finns behandlingshistorik, men det finns inga riktlinjer för uppföljning och kontroll av loggar och behandlingshistorik. Loggning och uppföljning av olika händelser har stor betydelse för kontroll av säkerheten i olika avseende och är dessutom en grundförutsättning för att skapa god intern kontroll genom planenliga uppföljningar och kontroller. Det finns därför anledning att vid utarbetande av IT-säkerhetsinstruktioner och systemsäkerhetsplaner ta fram riktlinjer/föreskrifter för när, hur, var loggning och uppföljning skall ske. Detta gäller både säkerhetshändelser i inloggningsserverar vid IT-enheten och behandlingshistorik i Economa och Devis. 2. Bakgrund och uppdrag En mycket stor del av kommunens utbetalningar sker utifrån inkommande fakturor som underlag. Kommunen har under 2004 infört rutiner för skanning av inkommande fakturor.därmed skapas elektroniska dokument för handläggning och utbetalning av leverantörsfakturor. Syftet med granskningen är granska säkerheten i rutinen samt om den interna kontrollen är tillfredsställande. (4)

5 Revisionsfråga: Är kontrollmiljö och kontrollaktiviteter i systemet tillräckliga för att garantera hög säkerhet vid elektronisk handläggning och utbetalning av leverantörsfakturor? Vi utgår från COSO-modellen i genomförandet. Modellen identifierar fem ömsesidigt beroende komponenter som tillsammans omfattar intern kontroll: Kontrollmiljö, riskanalys, kontrollaktiviteter, information och kommunikation, tillsyn och efterlevnad. Vi utgår också i tillämpliga delar från standard för Ledningssystem för informationssäkerhet (LIS) som definierar detaljerade krav på sekretess, riktighet, tillgänglighet och spårbarhet. 3. Kartläggning och översiktlig analys av rutinen 3.1 Economa Faktura översiktlig beskrivning Systemet är en Webbaserad applikation utvecklat för den nya generationens flödesorienterade IT-stöd som styrs av den enskilde användarens unika behov, dennes arbetssätt och roll i en organisation. Economa Faktura innehåller ett arbetsflöde (workflow) som kan hantera alla fakturatyper, såväl elktroniska som papperafakturor, med samma rutiner och gränssnittför kontering och attest. Stöd finns också för automatiserade lösningar för kontering och attest för inköpsfakturor eller abonnemangsfakturor. Fakturorna kan tas in i systemet på följande sätt Manuell registrering utan inscanning (traditionell fakturahantering) Manuell registrering med inscanning. Import av teckentolkad faktura. Elektroniska fakturor från leverantörer (för avstämning mot order eller orderlösa). Elektroniska förfakturor (och förberett för självfakturor) från inleveransmodul. Vår granskning omfattar enbart fakturor som hanteras genom Manuell registrering med inscanning, som är den modul som används för närvarande. Det pågår försök med Elektroniska fakturor från leverantörer med leverantören Telia. (5)

6 3.2 Fakturahantering, scanning och bokföring Nedan beskrivs rutinen för hantering av inkommande fakturor, ankomstregistrering, skanning och överföring till system Economa Faktura samt överföring till Devis ekonomisystem för bokföring och utbetalning. Ankomststämpling Faktura Skanning av fakturabild med viss komplettering Fakturor lagras I buntar I ver.nrordning (bunt x-y Systemet skapar integrationsfil och dokumentation System Economa Faktura Avstämningslista över skapade integrationfiler. Se avsnitt 4.2 Devis leverantörsreskontra Utbetalningsrutin Databas I System Economa Fil lev.poster flyttas manuellt, därefter överförs bok.föringsfi len automatiskt Utbetalningsfilen skapas manuellt. Se avsnitt 4.2 (6)

7 3.3 Rutin för kontroller vid hantering av scannade fakturor i system Economa Här beskrivs kontrollmiljö etc. vid hantering av skannade fakturor. System Economa E-post till motagningattestör eller annan handläggare Mottagningsattest och kontering OBS! Mottagninsattest kan göras av samma person som beslutsattesterar. Bokföring och utbetalning Bokföringsfil skapas och integreras till Devis av kassafunktionen samt utbetalningsfil, skapas I Devis.. Beslutsattest - fakturan stängs Kassan gör utanordning - OBS! Ingen manuell kontroll av mottagninsattest görs! (7)

8 4. Kontrollmiljö och kontrollaktiviteter 4.1 Ankomstregistrering och manuell registrering med inskanning Endast fakturor som inkommer från förvaltningarna med internpost ankomststämplas. För övrigt sker ankomstregistrering samtidigt som fakturorna scannas in i sytemet, vilket normalt sker samma dag som fakturorna ankommer med posten. Efter scanning av fakturorna sker manuell registrering av ett antal uppgifter, bl.a. fakturanummer, verifikationsnummer, buntnummerbuntnummer, fakturamottagare, belopp, mervärdeskatt m.m. Fakturorna lagras och stäms av buntvis. Efter registrering så levererar systemet en buntlista. Totalsumman kontrolleras manuellt genom kontrollräkning. Vad vi kan finna säkerställer nuvarande rutin att kontrollaktiviteterna är tillräckliga. 4.2 Avstämning och kontroller vid integration med bokföring och utbetalning Integration mellan system Economa (Ftb) och Devis sker normalt varje arbetsdag. I systemet skapas bokförings- och leverantörsfil. En kvitenslista (Skapa integrationsfiler) skrivs ut från systemet som underlag för senare kontroll mot integreringen med Devis. De filer som skapats i Economa (Ftb) flyttas till en särskild katalog i Devis (Devis INT-katalog). Därefter läser man in fakturafilen till leverantörsreskontran i Devis genom komandot Import bet.poster. En särskild kvittenslista över inlästa betalningsuppdrag skrivs ut från Devis för kontroll över att alla poster är rätt inlästa. Denna kontrolleras mot tidigare framtagen kvitenslista i Economa både vad gäller antal poster och totalbelopp. Systemet medger också olika möjligheter till analyser över integrerade poster. Sista steget är att skapa betalningsfiler i Economa genom komandot Skapa bet.uppdrag. Summorna skall stämma med leverantörsreskontran i Devis. Vid avsändande av betalningsfil till postgiro och bankgiro via systemet decapus så bekräftas detta genom ett e-postmeddelande som bekräftar filnamn, mottagarkonto, delbelopp och totalbelopp. I kassan sker sedan också kontroll mot kvittenser som kommer från postrespektive bankgirot. I detta sammanhang finns rutiner för hantering av felaktiga utbetalningar. Denna har vi inte granskat närmare. I vår översiktliga genomgång av rutinerna som är dokumenterade för integration med bokföring och utbetalning har vi inte funnit anledning till ytterligare kommentarer, utan kontrollmiljön synes fungera. 4.3 Reglemente för kontroll av verifikationer Reglemente för kontroll av verifikationer har antagits av kommunfullmäktige. Rutinen med elektroniska attester infördes under (8)

9 I reglementet finns följande skrivning: Attest får sker med hjälp av IT-stöd. Om attest skall utföras med IT-stöd ska det finnas en av kommunstyrelsen fastställd rutin för tilldelning av behörighet, införande av systemförändringar och dokumentation av utförda kontroller. När det gäller krav på dokumentation av utförda kontroller så är detta fastlagt i rutinen för fakturagranskning, vilken beskrivs under avsnitt 4.6 i rapporten. Övriga rutiner är inte fastställda eller tydligt dokumenterade i dag. Detta är områden som måste prioriteras i säkerhetsinstruktioner och systemsäkerhetsplaner. Se också skrivningar under avsnitt í rapporten. 4.4 Beslutsattestanter I system Economa så knyts beslutsattestanten till ansvarsnivå. I ekonomisystemet Devis så knyts beslutsattestanten även till mer detaljerade verksamhetsnivåer. Möjlighet finns också att knyta beslutsattestanter till enskilda projekt. Vid kontering och beslutsattest i Economa så görs automatiskt kontroll mot ekonomisystemet Devis, vilket innebär att attesten inte godkänns om verksamhetsnivån inte är rätt. 4.5 Mottagningsattest I nuvarande programvara finns ingen automatisk spärr att det inte är samma person som utför beslutsattest och mottagningsattest. Kontrollen måste därför ske manuellt. Några generella manuella kontroller sker enligt uppgift inte i dag. Enligt rutinen för fakturagranskning (se avsnitt 4.6 nedan) så skall förvaltningarna själva genomföra stickprovsmässiga kontroller. I Reglemente för kontroll av verifikationer som är fastställt av kommunstyrelsen i januari 2005 så står följande: Mottagningsattesten gäller köp av varor samt köp av tjänster. Attestanten intygar att kommunen tillgodogjorts det som beställt. Mottagningsattestanten och beslutattestanten skall ej vara samma person. Mottagningsattesten är en viktig funktion för att uppnå en bra intern kontroll vid köp av varor och tjänster. Vid översyn av nuvarande rutin för fakturagranskning (se avsnitt 4.6) bör man utifrån en riskbedömning överväga om det finns anledning att utöka nuvarande kontroller av att mottagningsattesten och beslutsattesten inte görs av samma person. Bedömningen skall alltid utgå från begreppen risk och väsentlighet. 4.6 Rutin för fakturagranskning Enligt Reglemente för kontroll av fakturor så skall kompletterande stickprovskontroller göras varje månad. Vid dessa kontroller skall samtliga uppgifter på verifikationen kontrolleras. Varje nämnd ansvarar för sin kontroll. Statistik skall föras över kontrollen och insändas till ekonomiavdelningen. (9)

10 Om fel hittas vid granskningen skall rättelse ske i efterhand. Vid felaktigheter bör berörda personer kontaktas. Om attester missköts skall förvaltningschef/kommunchef kontaktas. Ekonomiavdelningen har tagit fram en särskild rutin för fakturagranskning i efterhand. Granskningen består av två delar, en del där samtliga uppgifter på alla framsökta fakturor granskas (stickprovskontroll) och en del där samtliga fakturor inom ett visst slag på förvaltningen granskas. Varje nämnd/förvaltning ansvarar för sin kontroll. Statistik skall föras över genomförda kontroller och en kopia skall skickas till ekonomiavdelningen varje månad. Rutinen infördes under 2004, men har enligt uppgift i huvudsak börjat att fungera under första halvåret Vi har noterat att det finns en viss eftersläpning i tiden när det gäller inlämnad dokumentation över genomförda kontroller. Omfattningen och kvaliteten på inlämnad dokumentation varierar. Bl.a. har vi noterat att vissa förvaltningar inte dokumenterar vilka fakturor som har granskats, vilket vi anser är en viktig del i dokumentationen. Vi rekommenderar att ekonomiavdelningen i samverkan med större förvaltningar ser över nuvarande rutin. Begreppen risk och väsentlighet bör få en mer uttalad roll i bedömningen av olika kontrollaktiviteter. Kraven på hur förvaltningarna skall dokumentera genomförda granskningar måste också förtydligas. Ekonomiavdelningens roll i analysen av inlämnad dokumentation bör också tydliggöras. Se också skrivningar under avsnittet 4.5 Mottagningsattest. 4.7 Styrning av åtkomst Eftersom säkerheten vid elektronisk hantering, attestering m.m. är avhängigt hur behörigheterna är skyddade så har vi översiktligt granskat och diskuterat hur behörighetskontroller och loggning fungerar. Eftersom det fysiska skyddet blir alltmer utvecklat så flyttas fokus alltmer mot den logiska säkerheten, d.v.s. åtkomstskydd av information i nätverk, program och databaser. I detta sammanhang är det därför viktigt att ha ett väl utbyggt behörighetskontrollsystem. Den hierarkiska uppbyggnaden kan beskrivas på följande sätt: (10)

11 Uppbyggnad av behörighetskontrollsystem Behörighetskontrollsystem Identifiering Å tkom stk ontroll Loggning T illgån g till funktioner T illgån g till lagrad e d ata Datain tegritet U tnyttjande Spårbarhet Begreppsförklaringar se fotnot Policy och riktlinjer I augusti 2005 fastställde kommunstyrelsen en policy för IT-säkerheten. IT-säkerhetspolicyn är en del i organisationens IT-verksamhet och redovisar ledningens viljeinriktning och stöd för IT-säkerhetsarbetet och syftar till att klarlägga: Mål för IT-säkerhetsarbetet. Organisation, ansvar och roller inom IT-säkerhetsarbetet. Riktlinjer för områden av särskild betydelse. 1 Identifiering sker genom uppgivande av identitet samt att systemet verifierar äktheten. Åtkomstkontrollen skall styra tillgången till ett systems samtliga resurser, som omfattar både data, program, skrivare, kommunikationsmöjligheter m m. Loggning omfattar både säkerhetshändelser (ex vis åtkomstförsök med felaktigt lösenord) och s k behandlingshistorik (vem har gjort vad, när och hur) i enskilda system. Dataintegritet definieras som informationssystemets förmåga att förhindra att lagrade data förvanskas genom bl a kontroll av riktighet, signering samt möjlighet att återskapa varje version av informationen (11)

12 Policyn skall konkretiseras i IT-säkerhetsinstruktionerna, Förvaltning, Drift och Användare samt i Systemsäkerhetsplaner för väsentliga system. IT-säkerhetspolicyn har tydligt angivit mål, organisation, roller och ansvar samt kraven på dokumenterade rutiner och riktlinjer. Vi beskriver för övrigt inte innehållet i policyn, utan konstaterar att i dag saknas IT-säkerhetsinstruktioner och systemsäkerhetsplaner för både system för elektronisk faktura, Economa Faktura och för ekonomisystemet Devis. Arbetet med att ta fram instruktioner och systemsäkerhetsplaner måste prioriteras för att få en tydlig och dokumenterad samt fastställd säkerhetsnivå för användning av systemen. Det är också viktigt att tydliggöra roller och ansvar för hur arbetet med att ta fram instruktioenr och planer skall bedrivas. D.v.s arbetsfördelningen mellan IT-enheten och verksamheterna samt utsedda systemansvariga. Som exempel på instruktioner/riktlinjer kan nämnas säkerhetsnivå vid hantering av identiteter och lösenord. Här har vi bl.a. noterat följande: 1. I ekonomisystemet Devis finns i dag inga krav lösenord etc., vilket innebär att säkerhetsnivån är mycket låg. Motivet till detta är att flertalet användare endast har s.k. tittarbehörighet och därmed inte kan påverka innehållet i ekonomisystemet. Det finns dock enligt uppgift cirka 10 personer med mycket högre behörighet och som kan registrera uppgifter samt administrera systemet. Vi anser att användare av ett system (oavsett behörighetsnivå) alltid skall ha personliga identiteter med krav på lösenord, bl.a. av den anledningen att användare som har använt systemet säkert genom säkerhetsloggar skall kunna identifieras i efterhand. Finns inga krav på lösenord är det svårt att i efterhand hävda att viss användare har använt systemet. I det prioriterade arbetet med instruktioner och riktlinjer bör man på ansvarig nivå fastställa vilken säkerhetsnivå som skall gälla i ekonomisystemet. 2. I systemet för hantering av elektronisk faktura har vi noterat att lösenordens längd skall vara minst 5 tecken och skall bytas efter 30 dagar. Antalet påloggningsförsök innan utspärrning är satt till 5. Några formatkrav på lösenorden finns inte. Vi rekommenderar att man vid utarbetande av instruktioner och riktlinjer höjer säkerhetsnivån bl.a. genom att man minskar påloggningsförsök till 3 gånger, vilket är en normal standard i de flesta system i dag. Dessutom bör man aktivera funktionen för att ett lösenord alltid skall innehålla både alfabetiska och numeriska tecken. (12)

13 Andra exempel på behov av riktlinjer/föreskrifter är dokumenterade rutiner för registrering och avregistrering av användare, beslut och kvittering av identiteter, riktlinjer för skydd av datorrum, arbetsstationer m.m. Ett annat viktigt område är loggning och behandlingshistorik. I system Ekonoma Faktura finns behandlingshistorik, men det finns inga riktlinjer för uppföljning och kontroll av loggar och behandlingshistorik. Loggning och uppföljning av olika händelser har stor betydelse för kontroll av säkerheten i olika avseende och är dessutom en grundförutsättning för att skapa god intern kontroll genom planenliga uppföljningar och kontroller. Det finns därför anledning att vid utarbetande av ITsäkerhetsinstruktioner och systemsäkerhetsplaner ta fram riktlinjer/föreskrifter för när, hur, var loggning och uppföljning skall ske. Detta gäller både säkerhetshändelser i inloggningsserverar vid IT-enheten och behandlingshistorik i Economa och Devis. Som exempel på frågor kan noteras: 1) Hur länge 2 och på vilket media 3 skall loggfiler (behandlingshistorik) sparas? 2) Vilka kontrollmål gäller, d.v.s. av vilken anledning sparas uppgifterna? 3) Organisation för uppföljning och kontroll? 4) Vilka krav på selektiv loggning (terminal, användare, register m.m.) skall finnas? 5) Vilka krav skall finnas på program för rapportuttag? Ovanstående synpunkter skall ses som exempel på kriterier för att höja skyddsnivån vid åtkomst. Någon egentlig granskning av IT-säkerheten har inte gjorts. 2 Om inte lagstiftningen ställer högre krav bör loggade uppgifter sparas i två år. 3 Vid lagring av loggar på exempelvis tapekassetter är det viktigt att också förvara dessa med utgångspunkt från den sekretess som gäller. (13)