Säkerhetsblogg

Logghanteringssystem – varför och hur?

Att implementera ett logghanteringssystem för ett företag är ofta väldigt svårt. Det kan ofta bero på otydliga projektmål och bristande grunder att utgå ifrån.

Det finns två huvudsakliga logghanteringssystem:

  • Information Management System (IMS)
  • Event Management System

Målen för de två respektive systemen skiljer sig betydligt

Ett Information Management System är en åtkomstlösning för att kunna generera, samla in, analysera och lagra loggfiler så att man kan säkerställa deras konfidentialitet, integritet och tillgänglighet. En loggfil innehåller en identifiering som är unik för en person, ett tidslag och kommandot eller sökningen som gjorts.

Ett Event Management System syftar till att hitta information för att lättare upptäcka säkerhetsincidenter inom en stor mängd data genom att använda källdata från IDS/IPS, loggar från nätverksutrustning eller -system. Det innebär att man använder datamining-sökningar med korrelationsmekanismer för att upptäcka mönster som brukar associeras med skadliga program och/eller eventuella attacker.

Rent tekniskt kan de två systemen ha saker gemensamt, men det är ändå bra att ta itu med dem i två olika projekt och sedan återanvända gemensamma komponenter, såsom tolkning och insamling av loggar osv.

I det här inlägget kommer jag fokusera på Information Management System och belysa de steg som behövs för att lyckas.

Ett klassiskt misstag många gör är att tro att en logghanteringslösning hänger på installationen och konfigurationen av en mjukvara, snarare än att jobba utifrån att uppnå de slutliga målen för projektet.

Ett Information Management System har två huvudsyften:

  • Efterlevnad av interna policyer och/eller externa regelverk (i vårt fall PCI DSS, men det kan även vara t ex SOX, BRP.)
  • Behovet av att ha databevis som skydd mot eventuella bedrägerier gällande kunduppgifter som gjorts av anställd eller tredje part.

Lösning som ska implementeras är tätt sammankopplad med en tydlig definition av målen.

Fas ett: Kontoöversyn och rensning

En bra utgångspunkt är om företaget redan har implementerat en lösning för identitets- och åtkomsthantering (IAM). Om så inte är fallet blir det nödvändigt att lägga till en fas för att gå igenom konton och filtrera. En förutsättning för ett framgångsrikt genomförande av ett IMS är att alla användar-ID är kopplade till en unik person. Även konton för applikationer måste vara kopplade till en anställd. När det finns ’privileged accounts’ ska man inte tillåta direkt tillgång till systemen med dem. Användarna ska tvingas identifiera sig med sitt personliga användarnamn först.

Fas två: Loggproduktion

När loggar inte finns i systemet måste man tydligt definiera hur de kommer att genereras. Det är inte ett trivialt problem, eftersom det för det mesta kräver att man gör det på system som finns i produktion och som inte är framtagna för att ta hänsyn till logghantering. Den bästa lösningen är en som inte kommer att ha en inverkan på själva systemet eller på affärsapplikationerna som systemet stöder.

Jag vill inte gå in i detalj och utvärdera hur generering av loggar påverkar system, men det är nog bra att nämna åtminstone två kategorier av grundläggande operativsystem:

  • Windows
  • Unix/Linux

Med Windows måste vi ta itu med ett operativsystem som har dåliga spårningsmöjligheter att utgå ifrån. Det sparar informationen i binär form och har det är inte lätt att spåra aktiviteter relaterade till åtkomst genom att logga in någon annanstans. I det här fallet är lösningen ofta en installation av produkter som tillhandahåller en konsol för att generera rapporter med tillgång till systemet och objekt i filsystemet. En applikation som registrerar externa sessioner på mål plattformen, kan vara i en videofil, stöder vanligtvis den här typen av lösning.

Unix/Linux har mycket färre problem. Lösningen kan då vara mindre invasiv, som t ex ett skalprogram som skriver alla kommandon i en fil, inuti en SSH-session.

Tredje fasen: Insamling och skydd

För insamling av loggfiler, när de är lokalt genererade, finns det två grundläggande sätt:

  • push mode: skickar loggfilen från servern till det centrala arkivet när sessionen stängs
  • pull mode: överföringen av loggfilen är centralstyrd

Fördelen med pull mode är att det är lättare att managera, men push mode ger bättre garantier gällande filens integritet.

För att säkerställa loggfilernas integritet och för att förhindra att de systemgenererade loggfilerna inte ändras efter att de skapats, finns det olika lösningar som följer samma princip: Så fort loggfilen tagits bort från källsystemet måste man:

  • beräkna string hash
  • skriva tidsstämpeln med en centraliserad och synkroniserad tidsserver (identifikation med timme, minut, sekund, dag, månad och år) som sedan markerar hashen och samtidigt räknar ut den digitala signaturen

Efter det är lagring av de tre enheterna loggfilen, string hash och tidsstämpel möjlig. De två sista gör det möjligt att kontrollera autenticiteten av den lagrade loggfilen. Naturligtvis är det inte tillräckligt för att producera en loggfil i ett domstolssammanhang, men det är mer än tillräckligt för PCI DSS-efterlevnad.

  • 24 Solutions AB
  • Smedjegatan 2C
  • SE-13154 Nacka, Sweden
  • +46 (0)8 535 24 100
  • info@24solutions.com