av Mattias Fagerlund
Separation of Duties definieras av Wikipedia som;
“Separation of duties (SoD) is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers.”
Här tänker jag försöka beskriva hur ett SIEM system kan användas för att säkerställa att SoD efterföljs.
SIEM (System Information and Event Management) är mer än bara logghantering, logghantering i sin enklaste bemärkelse handlar om att samla in loggar och att göra uppslagningar mot dessa, vad som kallas Forensics. Utöver detta kan man tänka sig lite enklare rapporter. Ett SIEM system går betydligt längre än så, vilket kommer behandlas i senare blogginlägg, men nedan beskrivs användningen av tekniker som inte normalt finns tillgängliga i enklare logghanteringssystem.
Ett exempel på SoD är att samma användare inte skall ha rätt att utfärda en betalning och att attestera densamma. Då kan man lätt utföra bedrägliga utbetalningar – betalningar till sig själv t.ex. Självklart kan användare använda någon annans inloggningsuppgifter för att utföra bedrägliga transaktioner, det löser inte SoD (även om ett SIEM system kan vara till stor hjälp även i sådana situationer).
Det här knyter också in i “compliance”, vilket är svårt att översätta till svenska, men om man är compliant med ett regelverk så följer man reglerna i regelverket. Dessa regelverk kan vara lagar, förordningar, branschorganisationsregler eller förhållningsregler som fastslagits av företagets ledning. Exempel på dessa är PCI-DSS, SOX etc.
Man vill givetvis att det inte skall gå att bryta mot sina compliance-regler, så får det vara bra så. Men det kan vara svårt, orimligt dyrt eller orimligt begränsande att uppnå. Då vill man givetvis att när någon bryter mot en complianceregel så skall det stoppas aktivt. Detta kan också vara svårt, eftersom man inte nödvändigtvis har sådan kontroll över de bakomliggande system som är inblandade i processen. För att inte tala om att det kan vara svårt eller orimligt dyrt. Då vill man givetvis att ett larm istället skall genereras så att man genast får veta när någon bryter mot compliance regler. Detta kan vi uppnå, i någon mån, förutsatt att den information vi behöver finns i våra loggfiler!
Tänk er en mer komplex situation, där regeln säger att handling A på system X och handling B på system Y får aldrig utföras av samma person. Dessa två system kanske inte alls är sammankopplade, så de kan inte aktivt stoppa hanteringen! Hur löser vi detta, hur blir vi compliant?
Vanligen så använder man ett IAM (Identity and Access Management) system, där roller skapas och utdelas så att samma person aldrig har behörighet som gör att de kan bryta mot compliancereglerna. Detta går inte alltid att uppnå av olika anledningar, men säg att det går. Är vi färdiga då?
Men tyvärr så är compliance bara första steget, som Ulf kan intyga, hur överlever man en revision? Hur dokumenterar vi att vi faktiskt är compliant? Hur bevisar vi att dokumentationen är komplett? Man kan tänka sig en skala från att inte ha en aning om man är compliant till att i varje given sekund veta om man är det eller inte, till att ha system som reagerar aktivt eller larmar när man bryter mot dessa regler.
Så, vad göra?
Nästa blogg jag skriver kommer handla om hur man med hjälp av ett SIEM system kan få hjälp med dessa frågeställningar. Sedan får vi hoppas att Ulf (it-revisor och loggproffs) tycker att bevisningen duger och att rapporterna är tillfredsställande, annars blir det till att börja om…