Praktisk implementation av ett säkerhetssystemAnders Strömberg SIEM

(1)

Praktisk implementation av ett säkerhetssystem Anders Strömberg

DT099G - Examensarbete 15 hp Main field of study: Datateknik Credits: 180hp

Semester/Year: VT 2020 Supervisor:

Examiner: Ulf Jennehag, ulf.jennehag@miun.se Course code: DT099G

Degree programme: Datateknik 180 hp

(2)

Abstract

In a large computer system or in a single personal computer, there are both internal and external threats to the system. For a seasoned user who knows what is important to monitor and which files are sensitive, it is possible to have control over the system. If, on the other hand, it is an inexperienced user or a larger system of several computers, networks, routers, switches and maybe services that are wholly or partly located on the Internet, it is very difficult to monitor the whole system. Where do infringement attempts occur? Did it just happen, or was it a couple of weeks ago? Are repeated login attempts by a specific user to be considered an intrusion? What has happened to the firewall and to the network? Who has queried the database? To monitor the whole system and get answers to these questions, you can use a SIEM system. It is designed to collect data, process and analyze it and present it in a way that is clear to the user. Today, there are SIEM systems on the market with parts of or complete solutions. Depending on what is needed or requested, the cost of these also varies. The report describes how the project is planned and goes through how a SIEM system is constructed and what parts are included. In the project, a SIEM system has been built up with some of the parts found in ready-made solutions today.

The focus has been on retrieving data and systematically storing them in a PostgreSQL database. With so many different modules that will interact and work together, most of the time and energy has been spent on the design part of the SIEM system. The programming code is made in Python and Node JS.

Nyckelord: SIEM-system, Python, Node JS

(3)

Sammanfattning

I ett stort datorsystem eller i en enskild persondator så finns det både interna och externa hot mot systemet. För en van användare som vet vad som är viktigt att övervaka och vilka filer som är känsliga är det möjligt att ha kontroll över systemet. Är det däremot en ovan användare eller ett större system av flera datorer, nätverk, routrar, switchar och kanske tjänster som helt eller delvis ligger ute på Internet så är det väldigt svårt att övervaka hela systemet. Var sker intrångsförsök? Hände det nyss, eller var det för ett par veckor sedan? Är upprepade inloggningsförsök från en specifik användare att betrakta som ett intrång? Vad har skett mot brandväggen och mot nätverket? Vem har ställt förfrågningar mot databasen? För att övervaka hela systemet och få svar på dessa frågor går det att använda ett SIEM-system. Ett sådant är uppbyggt för att in- hämta data, behandla och analyser den samt presentera den på ett för användaren överskådligt sätt. Det finns idag SIEM-system på marknaden med delar av eller helt färdiga lösningar. Beroende på vad som be- hövs eller efterfrågas så varierar också kostnaden för dessa. Rapporten beskriver hur projektet är planerat och går igenom hur ett SIEM-system är uppbyggt och vilka delar som ingår. I projektet har ett SIEM-system byggts upp med några av de delar som återfinns i färdiga lösningar idag. Fokus har lagts på inhämtning av data och att på ett systematiskt sätt lagra dessa i en PostgreSQL-databas. Med så många olika moduler som ska samspela och fungera tillsammans har den mesta tiden och energin lagts på konstruktionsdelen av SIEM-systemet. Programmering- en har skett i Python och Node JS.

Nyckelord: SIEM-system, Python, Node JS

(4)

Förord

Det här projektet hade inte varit möjligt att genomföra utan hjälp och vägledning av Esmond Buswijller, Weevil, därför vill jag framföra ett stort tack för all hjälp. Ett stort tack också till mina underbara student- kompisar Sandra Landin och Mattias Åhlander som har förgyllt exa- mensarbetstiden med sällskap, samtal och skratt. Slutligen vill jag också tacka min fru Andrea och min son Tobias för att de haft tålamod och stått ut med mig under hela studietiden.

(5)

Innehållsförteckning

Abstract...ii

Sammanfattning...iii

Förord...iv

Terminologi...vii

1 Inledning...1

1.1 Bakgrund...1

1.2 Övergripande syfte...2

1.3 Avgränsningar...2

1.4 Detaljerad problemformulering...2

1.5 Översikt...3

2 Teori...4

2.1 Övervakningssystem - SIEM...4

2.1.1 SIEM-system...4

2.1.2 Historia[4]...5

2.1.3 Uppbyggnad...6

2.1.4 SIEM-system på marknaden...7

McAfee...7

Exabeam...8

2.2 Raspberry Pi 3 Model B+...10

2.3 Syslog...11

2.4 Databas - PostgreSQL...11

2.5 Meddelandesystem - MQTT...12

MQTT Broker...12

2.6 Användargränssnitt - REST API...13

3 Metod...14

3.1 Notifier...15

3.2 Logreader...15

3.3 Database connector...16

3.4 Database...16

3.5 MQTT-broker...16

3.6 REST API...16

3.7 Hårdvaror...16

3.8 Testets utförande...17

4 Konstruktion...18

4.1 Loggfiler...18

4.2 Uppbyggnad - Notifier...19

4.3 Uppbyggnad - Logreader...20

4.4 Uppbyggnad - Database connector...20

4.5 Uppbyggnad - Database...21

(6)

4.7 Uppbyggnad - REST API...21

5 Resultat...22

6 Slutsatser...25

6.1 Svar på problemformulering...26

6.2 Samhälls- och etiska aspekter...27

Källförteckning...28

Bilaga A: Dokumentation av egenutvecklad programkod...31

Bilaga B: Dokumentation av databas och tabeller...32

(7)

Terminologi

Dessa förkortningar och termer förekommer i rapporten och är här sam- manställda tillsammans med deras förklaringar.

Förkortningar

ACK Acknowledge. Kvittering av korrekt överfört meddelande.

CRUD Create Read Update Delete

MQTT Message Queuing Telemetry Transport

REST API Represantational State Transfer Application Pro- gramming Interface

PostgreSQL,

Postgres En objekt-orienterad databas.

SaaS Software as a Service

SEM Security Event Management

SIM Security Information Management

SIEM Security Information and Event Management Syslog Ett protokoll för att skicka loggdata genom UDP

via port 514.

UEBA User and Entity Behaviour Analytics

(8)

1 Inledning

Användandet av ett Security Information and Event Management-system (SIEM-system) handlar om övervakning av säkerhetsinformation och hantering av säkerhetshändelser inom ett datorsystem. Det kan vara alltifrån en enskild dator till ett komplext system bestående av flera datorer och nätverk med både lokala resurser och molntjänster. Rapporten tittar översiktligt på några befintliga SIEM-system för att studera deras uppbyggnad och beståndsdelar. Därefter ligger fokus på uppbyggnaden av ett praktiskt tillämpbart system som är funktionellt. Systemet utvär- deras därefter från ett driftperspektiv och dess funktionella hantering av loggdataposter.

1.1 Bakgrund

Ett datorsystem kan vara utsatt för flera olika typer av hot och intrångs- försök. Det kan vara allt från rena bedrägerier till virusattacker eller nå- gon som otillåtet försöker koppla upp sig mot systemets resurser. Även fast en användare på ett mindre datorsystem har större möjlighet till en helhetsbild så är det fortfarande svårt att veta var, när och hur hot och intrångsförsök mot systemet sker eller har skett. Om du är säkerhetsad- ministratör på ett större datorsystem så är det näst intill omöjligt att manuellt övervaka alla delar och loggfiler som ingår i systemet. Det är här ett SIEM-system verkligen kommer till användning. I figur 1 nedan ser vi en övergripande skiss för ett SIEM-systems uppbyggnad[1].

Figur 1: Ingående SIEM-delar i ett datorsystem.

I princip kan man dela in systemet i tre olika huvuddelar. Insamling och övervakning av data från händelserapporter och loggfiler, sammanställ-

(9)

ning och analys av all tillgänglig data samt rapportering och framställ- ning av resultatet och de gjorda analyserna.

1.2 Övergripande syfte

Projektets övergripande syfte är att praktiskt bygga upp och skapa ett fungerande SIEM-system för att kunna implementera i ett befintligt datorsystem. Eftersom det är många moduler och delar som ska fungera i ett samverkande system blir det intressant att studera driftsäkerheten i ett sånt system. Körningar av hela systemet, alltså alla ingående moduler, kommer att ske och genom detta är tanken att identifiera fel och brister som dyker upp under tiden.

1.3 Avgränsningar

Projektet kommer inte att skapa ett komplett system med alla de be- ståndsdelar som finns i kommersiella SIEM-lösningar på marknaden.

Eftersom hela systemet kommer att finnas på en Raspberry Pi 3 som är en enkortsdator, så blir också utformningen och tillämpningen begrän- sad utifrån det. De datorsystem som övervakas inom det här projektet är loggfilerna från MQTT och från protokollet Syslog[2][3].

Rapporten beskriver de ingående delarna i systemet och hur de är upp- byggda och fungerar ihop.

1.4 Detaljerad problemformulering

Ett SIEM-system som går att införskaffa på marknaden är utformat och testkört under lång tid och utvecklat för att fungera i flera olika typer av operativsystem och datormiljöer. Det här projektet kommer att lägga fokus på att få systemet och dess moduler att fungera tillsammans.

Sammanlagt kommer tre körningar under normalbelastning och tre kör- ningar under högbelastning att utföras. Varje körning sker under 30 minuter. De faktorer som kommer att studeras närmare är driftsäkerheten och noggrannheten av de enskilda loggdataposterna. Kontroll av SIEM- systemet under körning och alla enskilda moduler, kommer också att ske under testkörningarna. Detta för att se om det blir några driftavbrott och om modulerna kan jobba tillsammans.

För att konkretisera så är det följande frågor som ska besvaras inom projektet:

(10)

• Vilka är nödvändiga delarna i ett SIEM-system?

• Hur driftsäkert det slutliga SIEM-systemet?

• Går det att lita på det som läses och loggas i SIEM-systemet?

1.5 Översikt

I rapportens kapitel 1 som är den inledande delen är det en genomgång i grova drag vilka förutsättningar som har gällt för projektet. I kapitel 2 kommer teoridelen som går igenom vad ett SIEM-system innebär och vilka övriga moduler som har ingått i projektet. Kapitel 3 visar på vilken metod som har använts och kapitel 4 är en detaljerad genomgång av alla ingående moduler. Resultatdelen kommer i kapitel 5 och sedan avslutas rapporten med kapitel 6 som är slutsatser. Det finns dessutom en käll- förteckning som kommer i slutet av rapporten. Allra sist i rapporten finns egenutvecklad programkod som är bifogad i form av Bilaga A.

(11)

2 Teori

I det här kapitlet förklaras hur ett SIEM-system fungerar, vilka delar som bör ingå och dess historia. Några system som finns på marknaden idag nämns och beskrivs. Därefter förklaras termer, begrepp, hård- och mjukvara som är viktiga för att förstå hur hela projektet är planerat och uppbyggt som ett komplett SIEM-system.

I den här delen följer också en beskrivning av den enkortsdator, Rasp- berry Pi 3 Model B+, som använts för att köra det här SIEM-systemet.

Teorikapitlet förklarar också vad Syslog är och vilken typ av databas PostgreSQL är. Dessutom följer en beskrivning av meddelandesystemet MQTT och vad ett REST API är.

2.1 Övervakningssystem - SIEM

Ett övervakningssystem ska hantera händelser och information på en dator eller i ett datorsystem. Det kan vara svårt som användare att veta var information om inloggningar, uppkopplingar mot portar och för- frågningar mot en databas går att hitta. Det kan också vara svårt att age- ra i realtid mot intrångsförsök när man inte vet var man kan hitta information om sådana händelser. För att användarna lättare ska kunna samla information om säkerhetsfrågor gällande ett datorsystem, så finns det övervakningssystem på marknaden. Många av dessa system arbetar enligt en modell som heter Security Information and Event Management (SIEM)[4]. En svensk översättning blir ungefär säkerhetsinformation och händelsehantering.

2.1.1 SIEM-system

I den här rapporten kommer den engelska förkortningen, SIEM använ- das. Men termen i sig bygger i sin tur på två andra metoder för system- säkerhet, nämligen Security Event Management (SEM) och Security In- formation Management (SIM). På svenska blir det hantering av säker- hetshändelser och säkerhetsinformation. SEM innebär att systemet var- nar för misstänkta händelser och aktiviteter på en dator eller i ett system. Det gör den genom att övervaka flera gränssnitt och kan därmed spåra händelser som sker. Ett SIM-system däremot fokuserar framför allt på innehållet i loggfiler. Den stora skillnaden mellan ett SEM- och ett

(12)

SIM-system är att den förstnämnda rapporterar händelser som sker i realtid och den senare analyserar loggade eller sparade händelser.

Det är inte skarpa gränser mellan SEM- och SIM-system utan det är bätt- re att använda sig av ett SIEM-system som kombinerar dessa två säker- hetssystem. Till exempel övervakning av loggfiler och vilka som har läs- och skrivrättigheter till dessa är ett område som lätt hamnar mellan sto- larna. När loggfilerna blir för stora brukar man använda sig av ett rul- lande loggschema

Det gör man för att veta hur och när systemet ska byta till en ny loggfil och också hur man ska döpa de gamla loggfilerna som komprimeras.

Det är ett område som tillhör SEM, hantering av säkerhetshändelser.

Men eftersom SIM, hantering av säkerhetsinformation, är det system som hanterar data som har loggats kan det också ligga under ett sådant system. Genom att integrera SEM och SIM till ett gemensamt system för hantering av säkerhetsfrågor (SIEM), så slipper man hantera gränsdrag- ningen av sådana frågor.

Idag finns det flera företag som jobbar inom IT (informationsteknologi) som har skapat egna system för säkerhetsinformation och händelsehan- tering. Det kan vara system som de har utvecklat för att distribuera och sälja till kunder, men också slutna system för större företag och myndig- heter.

2.1.2 Historia[4]

De första system som arbetade enligt SIEM-modellen dök upp under ti- diga 2000-talet. Det var lite revolutionerande eftersom de kombinerade både händelsehantering och säkerhetsinformation. Tidigare hade det varit uppdelat enligt SEM och SIM. Ett av problemen med de tidigaste mo- dellerna var möjligheten att utöka dessa till ett växande system, alltså skalbarhet. Det var besvärligt att hantera en stor mängd data. En be- gränsande faktor blev alla I/O-operationer (Eng. Input/Output). En annan undermålig egenskap var hur informationen sammanställdes och presenterades för användarna. De grafiska gränssnitten, om det överhu- vud taget fanns sådana, var inte speciellt användarvänliga.

Andra generationen av SIEM-modeller kom i början på 2010-talet. Nu hade systemet byggts ut och det gick att spara större mängder data på databaserna som inte längre behövde ligga centralt. Det behövdes bara fler servar som kunde hantera informationen. Användargränssnitten var

(13)

förbättrade och det gick dessutom att hämta historiska data på ett mycket bättre sätt än tidigare. Nu blev det emellertid problem för att det blev alldeles för stor mängd data att hantera. Tidigare var risken stor att all viktig data inte fanns tillgänglig. Nu var risken stor att viktig data ten- derade att försvinna i den väldiga mängd data som skulle hanteras.

I mitten på 2010-talet växte den tredje generationen av SIEM-modeller fram. Nu hade man insett att det var viktigt att inte bara samla in och spara all information. Det var egentligen själva analysen av det material som fanns tillgängligt som var det centrala. Man ville få in ett risktänk istället för ett vanligt alarmtänk. Var kan det dyka upp säkerhetsrisker, finns det ett beteende som är avvikande någonstans i systemet. Det in- fördes en teknik som kallas UEBA, User and Entity Behaviour Analytics.

2.1.3 Uppbyggnad

I stora drag är SIEM-modellen uppbyggd enligt fem olika steg.

• Insamlande av data

• Förtydligande av data

• Lagring av data

• Analys av samband

• Presentation

Den första och viktigaste delen är att inhämta data från de olika delarna i datorsystemet, som till exempel servrar, nätverksutrustning och brand- väggar. Det kan kompletteras med data från molnbaserade tjänster för att få ett heltäckande resultat. Nästa steg innan all data lagras blir att märka den med id-nummer, ursprung, tid, position och annan metadata. Efter det här steget så sparas datan till en databas. All data lagras i en databas oavsett om man har försett det med metadata eller inte. Dessa första steg är egentligen bara ett verktyg för att kunna analysera och behandla all data till information som är användbar. Det sista steget inne- bär att sammanställa och presentera all data på ett vettigt sätt för använ- daren

(14)

2.1.4 SIEM-system på marknaden

Internetsidan Solutions Review[5][6] presenterar en lista på 25 olika SI- EM-leverantörer med en kort översikt och lite detaljer för varje system.

Det finns allt ifrån kända varumärken som AT&T, IBM och McAfee till mindre kända varumärken. I den här rapporten redovisas två av dessa leverantörer och dessa system.

McAfee

McAfee[7] är ett av de ledande antivirus-företagen på marknaden och en av delarna som ingår är SIEM. Den är uppdelad på sex olika grenar vilka samlar in och analyserar data i olika faser, som också syns i tabell 1.

Tabell 1: Översikt av McAfee SIEM-system.

Översikt av McAfee SIEM

McAfee Advance correlation Engine

Användaren ställer in regler utifrån behov och två så kallade korrela- tions-sökmotorer letar enligt dessa regler efter hot och sätter riskpoäng som sedan analyseras.

McAfee Application Data Monitor

Dataövervakningen är applicerad på TCP/IP-modellens applikationsla- ger och söker där efter hot, bedrägerier, eventuella dataförluster enligt ett givet schema.

McAfee Enterprise Log Manager

Logghanteraren har en automatiserad övervakning av alla typer av loggtyper och jobbar tillsammans med McAfee Enterprise Security Ma- nager för att bättre kunna utföra sina analyser. Den standardiserar ock- så olika typer av loggfiler för att säkerställa att de sparas på ett liknande sätt.

McAfee Enterprise Log Search

Det är en sökmotor som är optimerad för att snabbt kunna hämta den informationen som användaren är intresserad av. Det går också att söka rådata från dessa loggfiler.

McAfee Enterprise Security Manager

Det här motsvarar hjärnan i McAfee SIEM-system. Här sammanställs och analyseras alla händelser och all information för att hitta attacker

(15)

mot och svagheter i datorsystemet.

McAfee Global Threat Intelligence (GTI) for ESM

Det här systemet arbetar i realtid för att upptäcka och rapportera hot mot systemet. McAfee hävdar att svarstiderna är reducerade till ett mi- nimum eftersom alla delar är hopbyggda till ett och samma säkerhets- system.

På figur 2 nedan ser vi en del av McAfees SIEM-system och hur de olika grenarna hänger ihop. Den stora figuren med blå ruta i är McAfee Enter- prise Security Manager. Det är den del som sammanställer och analyserar den data som kommer från dels McAfee Receiver och McAfee Enter- prise Log Manager samt det som kommer från McAfee Advance Corre- lation Engine, McAfee Database Monitor och McAfee Application Data Monitor.

Figur 2: Systemöversikt av McAfee Enterprise Security Manager

Exabeam

Ett av de företagen som renodlat arbetar med en typ av SIEM-produkt är Exabeam[8] och deras system är uppdelat på nio delar. De finns be- skrivna i tabell 2.

(16)

Tabell 2: Översikt av Exabeam SIEM-system.

Exabeam SIEM-system

Cloud Deployment Options

Det finns möjlighet att använda Software as a Service (SaaS) genom deras egna molntjänst eller genom större leverantörer som Amazon. SaaS innebär att leverantören kör hela mjukvaran genom en molntjänst istäl- let för att användaren ska installera det på sitt eget system[9].

Exabeam Advanced Analytics

Exabeam använder sig av User and Entity Behaviour Analytics (UEBA).

UEBA gör en modell av människors användarmönster inom ett system.

Det identifierar typiska och avvikande mönster och sammanställer dessa så att det går att få fram möjliga hot mot systemet.

Exabeam Cloud Connectors

Den här delen samlar in loggdata från mer än 40 olika molntjänster till olika delar i Exabeams system.

Exabeam Cloud Platform

Exabeam har ett helt system av olika molntjänster som assisterar i sitt SIEM-koncept.

Exabeam Data Lake

Det finns obegränsat med datalagring på ett säkert sätt i deras datacen- traler.

Exabeam Entity Analytics

Analysdelen använder sig bland annat av UEBA, (= User and Entity Be- haviour Analytics) för att identifiera mönster i användarnas beteende inom datorsystemet.

Exabeam Incident Responder

Sker det någonting inom systemet som är avvikande eller är beskrivet i reglerna som är uppsatta larmar och rapporterar den här modulen.

Exabeam SaaS Cloud SIEM

Fördelen med att lägga SIEM-systemet på en molntjänst gör att använ- darna inte behöver belasta det egna systemet.

Exabeam Threat Hunter

Ett användarvänligt system för att söka efter hot mot datorsystemet.

(17)

I figur 3 nedan ser vi hur Exabeams olika delar hänger ihop. Det är tre huvuddelar, Collect, Detect & Investigate och Respond.

Figur 3: Systemöversikt av McAfee Enterprise Security Manager

2.2 Raspberry Pi 3 Model B+

Raspberry Pi 3[10] räknas in under kategorin enkortsdatorer. I figur 4 nedan går det att se hur den är utformad. Den är ungefär 10 cm lång 5 cm bred, så den är lätt att bära med sig. Den dök upp på marknaden 2016 och har bland annat 1GB RAM och en 64 bitars CPU med fyra kär- nor. Den drivs med 5V/2,5A genom en strömomvandlare. Operativsys- temet för den dator som har använts till det här projektet är Raspbian, vilket idag kallas Raspberry Pi OS. Det är en Linux-variant som går ut- märkt att köra till exempel Python-skript på.

Figur 4: Raspberry Pi 3 Model B+ utan låda.

(18)

2.3 Syslog

Syslog står för ”System Logging Protocol” och används till enheter som routrar, switchar, brandväggar, Unix/Linux servrar och andra nätverk- senheter[2][3]. Syslog skickar sina meddelanden via UDP, alltså utan ACKnowledgement vilket gör att man inte med säkerhet kan säga att allt som skickas verkligen kommer fram. Syslogs meddelandeformat finns beskrivet i RFC 5424 och styr hur varje meddelande som skickas från respektive enhet ska se ut. Figur 5 nedan visar den lagerstruktur som Syslog-protokollet har.

Figur 5: Syslog-protokollets uppbyggnad.

Meddelandena som skickas med Syslog-protokollet går till en insamlare (Eng. collector). Det är en logging-server som kodar av informationen och sparar den till loggfiler. Det finns en maxgräns på 1024 bytes för storleken på dessa meddelanden.

2.4 Databas - PostgreSQL

PostgreSQL[11][12] är en databas gjord i öppen källkod och helt gratis att använda. Den brukar också benämnas endast Postgres och i den här rapporten används bägge benämningarna. Den är av typen Object-Rela- tional Database Management system (ORDBMS), vilket innebär att den fungerar som en traditionell relationsdatabas med en objekt-orienterad modell. Det betyder att det finns stöd för objekt, klasser och arv i såväl databasscheman som själva SQL-förfrågningarna

De datatyper som Postgres har till sitt förfogande är fler än i vanliga SQL-databaser eftersom det finns möjlighet att göra egna datatyper. Det finns också fördefinierat olika varianter av nätverksadresser, multidi- mensionella listor och geometriska datatyper.

(19)

I det här projektet har inte användningen av Postgres varit på en högre nivå så i själva verket hade det fungerat utmärkt att använda en vanlig SQL-databas.

2.5 Meddelandesystem - MQTT

Message Queuing Telemetry Transport (MQTT) är ett smidigt medde- landeprotokoll som är utvecklat för att användas mellan olika maskiner.

Det innebär att prenumeranter (Eng. subscribers) kan skriva upp sig på en ämneslista (Eng. thread) och ligga och lyssna efter uppdateringar på den ämneslistan. Uppdateringarna görs av skribenter (Eng. publishers).

Därför kallas ofta den här typen av protokoll för publish/subscribe-protokoll. Det utvecklades i slutet av 1990-talet för att övervaka oljeledning- ar via satellit.

För utveckling av programvaran i det här projektet har både en Mos- quitto MQTT Broker och Paho MQTT Python Client använts. Skillnaden mellan båda dessa system är att Paho MQTT Python Client går att implementera i ett Python-skript.

MQTT Broker

Det här systemet går att köra både under Windows och Linux operativsystem. Det går att köra lokalt med en broker eller via en Internetbase- rad broker. En MQTT-broker[13][14] är ungefär som en server. All trafik går genom brokern, så en skribent skickar ett meddelande och anger till vilket ämne det ska publiceras. Det meddelandet går till brokern som skickar vidare det meddelande till alla som har registrerat sig som prenumeranter på det ämnet. När en ny prenumerant skriver upp sig för att lyssna på ett ämne så noterar brokern det och finns med till prenume- ranten begär att få avsluta prenumerationen.

Figur 6: Principen för ett MQTT-system.

I figur 6 kan man se principen för hur ett MQTT-system med en central MQTT-broker fungerar.

(20)

2.6 Användargränssnitt - REST API

Att komma in på Postgres och göra förfrågningar mot databasen går ut- märkt via antingen ett grafiskt eller kommandobaserat användargräns- snitt. Men för att förenkla kommunikationen med databasen och de tabeller och poster som ligger där så kan man använda ett så kallat REST API, vilket betyder Representational State Transfer Application Pro- gramming Interface. REST-delen av den här termen innebär att servern inte sparar tidigare förfrågningar från en och samma samma klient. Den andra delen av termen REST API innebär att användarna får ett enklare gränssnitt mot databasen. Det blir dessutom ett gränssnitt som är obero- ende av vilket programspråk REST API-modulen är skriven i.

För att uppnå ett användarvänligt REST API vill man förse det med en så kallad full CRUD-funktionalitet (CRUD = Create Read Update Dele- te), det innebär att man kan skapa, läsa, uppdatera och ta bort poster från databasen genom gränssnittet. Det kan finnas skäl till att inte låta användarna ha full CRUD-funktionalitet. Om användarna har admini- stratörsrättigheter så bör det vara full CRUD-funktionalitet, men i annat fall är det lämpligt att begränsa till endast läsrättigheter.

(21)

3 Metod

Projektet innebär att praktiskt implementera ett SIEM-system i form av moduler, som relativt enkelt ska kunna användas i ett verkligt system.

Inom ramen för det här projektet innehåller SIEM-systemet dessa delar:

• Notifier

• Logreader

• Database connector

• Database

• MQTT-broker

• REST API

Programmeringskoden är skriven i Python 3.6.3 och Node.js 8.11.1 och finns återgiven som bilagor i slutet av rapporten.

Systemet kommer att testköras under sammanlagt sex tillfällen som va- rar i en halvtimme per körning. Tre tillfällen kommer att vara under normalbelastning och tre tillfällen under högbelastning. Det som kommer att studeras är om systemet kan köra utan avbrott under den tiden och att alla moduler fortsätter att arbeta som planerat.

För fallet att kontrollera körningarna under normalbelastning så blir testmodellen att göra en inloggning till PostgreSQL och ett utskick via MQTT under mättiden. Annars kommer hela systemet att stå helt orört under resterande tid. Vid körningar under högbelastning av testmodellen kommer det ske kontinuerligt arbete mot PostgreSQL och databasen samt återkommande utskick genom MQTT. Dessutom kommer det pa- rallellt att ske andra programkörningar under mätperioden för att belasta systemet mer än under normalbelastning.

Genom det här tillvägagångssättet så går det att se tillförlitligheten i ett praktiskt system. Eftersom det är flera delar i SIEM-systemet som ska köras samtidigt och samverka med varandra så är det svårt att få ett

(22)

studera funktionen i de olika delarna går det dessutom att identifiera brister och hitta områden som går att förbättra.

Här nedan beskrivs de olika ingående delarna i SIEM-systemet som ryms inom det här projektet och det går också att se de olika delarna i figur 7 nedan.

Figur 7: En skiss av projektets SIEM-system.

3.1 Notifier

Delen som kallas Notifier är ett Python-skript som använder en Python- modul som övervakar filhändelser i realtid i ett Linux-operativsystem[15][16]. Genom en så kallad regelfil går det att ställa in vilka mappar eller filer som ska övervakas. När datumstämpeln på någon av de övervakade objekten ändras skickar skriptet ett notifikation att nu har någon typ av ändring eller uppdatering skett.

3.2 Logreader

Logreader eller loggläsare på svenska är ett Python-skript som på en gi- ven signal ska gå in och läsa av nya tillkommande rader i olika loggfiler.

Det är en speciell loggläsare för varje typ av logg. De flesta loggfiler har ett liknande upplägg, men är ändå inte helt identiska med tanke på informationen som skrivs till dessa. Get går att ändra vilken typ av information som faktiskt skrivs till loggfilerna i konfigurationsfiler. Det är filer med olika inställningar för loggningen. Man kan till exempel ställa typ av information och till vilken loggfil man vill logga. Eftersom alla

(23)

loggfiler skiljer sig från varandra blev det också naturligt att utforma loggläsarna beroende på loggfilernas utseende.

3.3 Database connector

Databaskopplingen, som är skriven i Python, är ett gränssnitt för de olika skripten i systemet så att de kan kommunicera mot databasen. Alla förfrågningar sker via databaskopplingen som är den enda enheten som kan läsa och skriva till databasen vilket går att se i figur 7 ovan.

3.4 Database

Databasen är den enhet som lagrar alla poster från loggfilerna. Den är skapad i PostgreSQL 9.6. Det är loggläsaren som förser databaskopplingen med data över vad som ska sparas ner till databasen. Databasen består av en tabell för varje typ av loggdata som sparas ner. Vid utsök- ningar och förfrågningar mot databasen skickas svaren på dessa till da- tabaskopplaren som därefter distribuerar vidare den data som behövs.

3.5 MQTT-broker

MQTT-brokern i det här projektet är implementerad genom ett Python- skript. Brokern får sin information från skribenten och prenumeranterna. Skribenten i sin tur får all sin information från databaskopplingen efter att någon post har sparats till databasen. All data som sparas till databasen kommer inte att skickas till skribenten utan det kommer att ligga ett filter som bara släpper igenom vissa typer av data för publicering.

3.6 REST API

För att låta användarna ha tillgång till ett mer användarvänligt gräns- snitt så är det här SIEM-systemet också försett med ett REST API som är skrivet i Node.JS. REST API:et gör sökningar till databasen genom data- baskopplaren och får också sina svar genom den, vilket man kan se från figur 7 ovan.

3.7 Hårdvaror

Programkoden för projektet skrevs på en Raspberry Pi 3 Model B+ som hade operativsystemet Raspbian installerat. Idag kallas operativsystemet Raspberry Pi OS, men när det installerades på den Raspberry Pi som användes i projektet hette det Raspbian.

(24)

3.8 Testets utförande

Testerna i projektet skedde i form av 30-minuterskörningar av SIEM- systemet på Raspberry Pi. Det blev tre körningar under normal belastning och tre körningar under hög belastning. Inför varje testkörning kontrollerades vilka loggposter som var de senaste i databasens tabeller samt hur slutet på loggfilerna såg ut. Efter det startades körningen av systemet som fick gå under 30 minuter utan manuellt avbrott. Under körningen för normal belastning startades MQTT-broker om en gång.

Det var den enda externa momentet mot systemet. Under körningen med hög belastning gjordes flera omstarter av MQTT-broker och fler andra system var också på samtidigt, till exempel webbläsare och några texteditorer. Det var för att belasta systemet lite mer för att kunna se på- verkan på driftsäkerheten och antalet loggposter. När körningen hade avslutats öppnades syslog-filen för läsning. Antalet logghändelser under testkörningarna noterades. Från databastabellen postgresprimary skrevs och antalet loggposter upp under testkörningen. All data sam- manställdes sedan till tabell 3 i resultatkapitlet.

(25)

4 Konstruktion

Det här kapitlet beskriver hur SIEM-systemet i det här projektet är uppbyggt, vilka delar det består av och hur programkoden är skriven. Hela SIEM-systemet i det här projektet består av sammanlagt sex delar. Det är Notifier, Logreader, Database connector, Database, MQTT-broker och REST API.

4.1 Loggfiler

I ett datorsystem har operativsystemet flera olika sätt att kommunicera med de ingående delarna. Bland annat sker det genom interna kopp- lingar (Eng. buses), men det sker också genom att skicka meddelanden vid olika händelser. Då är protokollet Syslog ett viktigt verktyg. Det tar emot meddelanden från olika delar i nätverket som switchar, routrar, skrivare, brandvägg och så vidare. Därefter skrivs det till en loggfil som heter syslog rätt och slätt.

Några av problemen i ett datorsystem är att alla processer (den programkod som processorn exekverar) inte skickar sina meddelanden via syslog, eller att en del program har egna loggfiler som de skriver till. Till exempel så finns det på den Raspberry Pi som användes i projektet en loggfil för Ubuntu Kernel, kern.log, en loggfil för pakethanteraren, dp- kg.log, en loggfil för brandväggen, ufw.log och så vidare. Om allt skulle hamna i en och samma fil vore det lättare att samla ihop all data.

I Raspberry Pi 3 finns en systemresurs, Rsyslogd, förinstallerad[17]. Det är alltså den syslog-server som sköter meddelandehanteringen för alla syslog-meddelanden på det Linux-operativsystem som är installerat på Raspberry Pi 3. Det går att göra flera inställningar till det här systemet genom att gå in i konfigurationsfilen /etc/rsyslog.conf[18], bland annat hur formatet på dessa meddelanden ska se ut i loggfilen.

Inom det här projektet har fokus lagts på tre filer, syslog, mosquitto.log och postgresql-9.6-main.log. Anledningen till att just dessa loggfiler val- des ut är att till syslog skrivs väldigt mycket systeminformation regel- bundet. Det är lätt att i realtid upptäcka när något loggas till den här filen genom att gå in och läsa i slutet av syslog-filen för att se när ett nytt meddelande läggs till. Loggfilerna mosquitto.log och postgresql-9.6-

(26)

lämpligt att övervaka dessa filer för att kontrollera att dessa händelser kommer med i dessa loggfiler. Avgränsningen i det här projektet gjordes till dessa tre filer, men om man är intresserad av en utbyggnad är det lätt att övervaka fler loggfiler i ett senare skede. Man kan se loggfilernas utseende genom figur 8 nedan.

Loggmeddelande från loggfilen /var/log/syslog

2020-06-05T09:35:01.814708+02:00 raspberrypi CRON[1648]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

Loggmeddelande från loggfilen /var/log/mosquitto.log

2020-06-05T09:15:19.996477+02:00 raspberrypi mosquitto[484]: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.

Loggmeddelande från loggfilen /var/log/postgresql/postgresql-9.6-main.log

2020-06-04 16:47:58 CEST|[local]|postgres@postgres|604|LOG: statement: SELECT d.datname as "Name",

pg_catalog.pg_get_userbyid(d.datdba) as "Owner",

pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding", d.datcollate as "Collate",

d.datctype as "Ctype",

pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges"

FROM pg_catalog.pg_database d ORDER BY 1;

Figur 8: Exempel på loggposter från de olika loggfilerna.

De kolumner, eller den data som loggas i respektive loggfil är olika beroende på vilken fil som läses.

4.2 Uppbyggnad - Notifier

Det är delen Notifier som sköter övervakningen av de loggfiler som kontrolleras. Filen notifier.py (alla filer går att se i Bilaga A) använder en Python-modul som heter pyinotify. Med den går det att ställa in en så kallad övervakning av en hel mapp eller olika filer. Modulen kollar på mapparnas och filernas datumstämpel för att se olika filhändelser. Filer- na som övervakas anges i en lista, se figur 9 nedan.

watch_path_list = [

'/var/log/mosquitto/mosquitto.log', '/var/log/syslog'

]

# Exclude patterns from file

excl_file = os.path.join(os.getcwd(), 'exclude.lst') excl = pyinotify.ExcludeFilter(excl_file)

Figur 9: Kodavsnitt från filen notifier.py som visar vilka filer som ska övervakas.

Man kan se att de mappar som kollas är /var/log och /var/log/mosquitto vilket innebär att alla filer som ligger i dessa mappar kommer att över- vakas. I den förstnämnda mappen finns det ett 20-tal olika loggfiler, men

(27)

det är endast två av dessa filer som ska kontrolleras. Genom att skapa en exclude-list går det att bestämma vilka filer som inte ska kontrolleras.

Annars kommer Notifier att reagera varje gång det sker en filhändelse i någon av alla filer som ligger under dessa mappar.

De filhändelser som registreras är MODIFY, ACCESS, CLOSE_WRITE och CLOSE_NOWRITE. Det finns andra händelser förutom dessa som till exempel CREATE och DELETE som också kan vara intressanta att övervaka, men det är avgränsat till dessa filhändelser i det här projektet.

Filen eventhandler.py är kopplad till filen notifier.py och anropas när Notifier har upptäckt någon form av ändring på de filer som övervakas.

I den förstnämnda filen läses ett event som skickas med för att se vilken fil som har ändrats och därefter skickas ett MQTT-meddelande ut till de prenumeranter som är med på den listan. I steget efter anropas Databa- se connector som får ett meddelande om vilken fil som behöver läsas.

4.3 Uppbyggnad - Logreader

Om Notifier signalerar att en filhändelse har hänt med någon av de filer som övervakas så anropas Logreader. I och med att loggfilerna som övervakas skiljer sig lite grann från varandra så var det också nödvän- digt att använda en separat Logreader för respektive loggfil. Både syslog och mosquitto.log skriver varje logghändelse på precis en rad. ILogrea- der går in och läser den aktuella loggfilen vid en notifikation att en fil- händelse har ägt rum. Då läses den sista raden från loggfilen in som ett objekt och skickas därefter till modulen Database connector.

4.4 Uppbyggnad - Database connector

Databaskopplingen är navet i projektets SIEM-system. Det är den här modulen som läser till och från databasen. När det har kommit en ny loggpost till /var/log/syslog från Notifier så loggas den till en tabell i da- tabasen. I databasen finns det skapat en tabell för MQTT-, en för Post- greSQL och en för syslog-poster. I projektet är det dock bara logghän- delser från syslog-filen som också registreras till databasen. Database connector får också uppgifter från REST API-modulen när någon gör en request till IP-adressen. Genom Python-skript går det att i koden koppla upp mot databasen och genom den kör förfrågningar där. Python har en Postgres-modul som heter psycopg2 där man kan köra olika funktioner som bland annat läser från och skriver till databasen.

(28)

4.5 Uppbyggnad - Database

Databasen heter weevil_siem och är skapad med tre tabeller. Dessa he- ter msqttprimary, postgresprimary och syslogprimary. I Bilaga B finns en beskrivning av uppbyggnaden för tabellerna. En post i databasen skrivs bara när det har skett någon händelse i syslog-filen eller i mosquitto-loggfilen. Det går att göra förfrågningar mot databasen från REST API:et. Tabellerna i databasen skiljer sig lite från varandra vilket beror på de olika loggfilernas uppbyggnad. De viktigaste kolumnerna i tabel- len syslogprimary är timereported, hostname och message. Tabellen mqttprimary har endast tre kolumner. Databasen består av tre olika ta- beller men för projektet används endast tabellen för syslog-händelser.

4.6 Uppbyggnad - MQTT-broker

För att använda MQTT i ett Python-skript behöver man använda en mo- dul som heter paho. Då går det att ange på vilken IP-adress och port som MQTT-broker kör på. Det går att installera en broker lokalt på en vanlig dator eller så kan man använda sig av publika broker som ligger på Internet. I det här projektet ligger brokern på en publik adress, mqtt.eclipse.org . Filen MqttPublisher.py anropas från filen eventhand- ler.py och vid anropet skickas meddelande objekt med som senare följer med i själva MQTT-utskicket. Det som krävs för att nås av dessa meddelanden är att prenumeranterna har skrivit upp sig för att prenumerera på servicen.

4.7 Uppbyggnad - REST API

Den här modulen är den enda modulen som är skriven i Node.js vilket egentligen är JavaScript, men skriven för server-sidan istället för klient- sidan vilket är det vanliga. Det är en huvudfil som startar upp en server som är av typen Express-server. Det är ett enkelt server-ramverk som är gjord för webbapplikationer. Servern ligger lokalt på Raspberry Pi och lyssnar på port 3000 efter förfrågningar (Eng. request). När det kommer in en sådan från en webbläsare anropar servern Database connector som gör en databasförfrågan. När connector får svar från databasen skickar den i sin tur svar till Express-servern som kan visa resultatet på den webbläsare som har gjort den ursprungliga förfrågan.

(29)

5 Resultat

De testkörningar som genomfördes visade ett positivt resultat vad gäller driftsäkerheten av systemet. Alla sex körningar kunde ske utan avbrott och poster skrevs till databasen samt utskick till de MQTT-topics enligt planen. Notera att det var endast bevakning på händelser i loggfilen syslog under testkörningarna, vilket går att se i figur 10.

Figur 10: En skiss av projektets SIEM-system under testkörning.

En sammanställning av de testkörningar som gjordes finns i tabell 3.

Tabell 3: Sammanställning av testkörningar (30 minuter / körning).

Körning Belastning Driftstopp Syslog-poster Databas-poster

1 Normal 0 7 5

2 Normal 0 6 6

3 Normal 0 5 5

4 Hög 0 12 8

5 Hög 0 11 8

6 Hög 0 8 6

(30)

För loggningen av poster till syslog respektive till databasen är resultatet inte tillfredsställande. För att resultatet ska vara bra vill man se lika antal poster i syslog som har sparats ner till databasen.

Det är inte så många poster som loggas totalt under dessa körningar.

Det skiljer på antalet poster mellan syslog och databasen under alla kör- ningar. Utdrag från filen /var/log/syslog finns i tabell 4 med radnummer i filen som första post. Därefter kommer själva postens innehåll med tiden först.

Tabell 4: Utdrag ur syslog-filen loggat under körning 5.

9759 2020-06-07T17:33:18.397152+02:00 raspberrypi systemd[1]: Stopping Mosquitto MQTT v3.1/v3.1.1 Broker...

9760 2020-06-07T17:33:18.519355+02:00 raspberrypi systemd[1]: Stopped Mosquitto MQTT v3.1/v3.1.1 Broker.

9761 2020-06-07T17:33:18.526195+02:00 raspberrypi systemd[1]: Starting Mosquitto MQTT v3.1/v3.1.1 Broker...

9762 2020-06-07T17:33:18.545926+02:00 raspberrypi systemd[1]: Started Mosquitto MQTT v3.1/v3.1.1 Broker.

9763 2020-06-07T17:35:01.971871+02:00 raspberrypi CRON[8953]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

9766 2020-06-07T17:57:30.584208+02:00 raspberrypi systemd[1]: Stopping Mosquitto MQTT v3.1/v3.1.1 Broker...

9767 2020-06-07T17:57:30.703101+02:00 raspberrypi systemd[1]: Stopped Mosquitto MQTT v3.1/v3.1.1 Broker.

9768 2020-06-07T17:57:30.728623+02:00 raspberrypi systemd[1]: Starting Mosquitto MQTT v3.1/v3.1.1 Broker...

9769 2020-06-07T17:57:30.821281+02:00 raspberrypi systemd[1]: Started Mosquitto MQTT v3.1/v3.1.1 Broker.

I tabell 5 går det att se ett utdrag från databasens tabell syslogprimary och där är det första talet som ses vilket nummer posten har i tabellen.

Både tabell 4 och 5 innehåller endast de poster som har skrivits under den tiden som testkörning 5 ägde rum.

(31)

Tabell 5: Utdrag ur databasen sparat under körning 5.

81 | 2020-06-07 17:33:18.545926+02 | raspberrypi | systemd[1] | Started Mosquitto MQTT v3.1/v3.1.1 Broker.

83 | 2020-06-07 17:35:01.971871+02 | raspberrypi | CRON[8953] | (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

86 | 2020-06-07 17:57:30.728623+02 | raspberrypi | systemd[1] | Starting Mosquitto MQTT v3.1/v3.1.1 Broker…

Det går att se ungefär samma antal poster som skiljer mellan syslog-filen och tabellen syslogprimary från databasen för alla sex körningar.

(32)

6 Slutsatser

Under projektets gång har vissa av de målsättningar som fanns revide- rats. En grundtanke var att lyssna på syslog, brandvägg, routrar, switchar och andra nätverksenheter. När man utvecklar ett SIEM-system är det viktigt att inhämta data och information från så många olika käl- lor som möjligt. Alla nätverksenheter skriver inte direkt till syslog-filen.

Några enheter gör det, medan andra skriver till helt andra loggfiler. En annan grundtanke var att logga allting till en PostgreSQL-databas. Det som skrivs i syslog-filen loggas till databasen, men inte de logghändel- ser som skrivs till mosquitto- eller postgres-loggfilen. Med en lyssnare som Notifier uppstod problem eftersom den säger till varje gång de ob- serverande filerna ändras. Då kommer också Logreader att gå in och läsa de filerna för att sedan logga till databasen. När dessa poster loggas till databasen uppdateras i sin tur loggfilen för PostgreSQL, vilket återi- gen gör att Notifier triggar Logreader. På det här sättet fick provkör- ningarna i slutet av projektet mycket snabbt växande loggfiler som loggade och läste det som hade loggats själv. Det blev också ett liknande problem med MQTT eftersom den skulle skicka ut ett meddelande varje gång en post hade loggats i databasen. När det meddelande skickades ut loggades det samtidigt till loggfilen vilket också gjorde att Notifier berättade för Logreader att det hade skett en händelse i den filen. Återi- gen blev det snabbt växande poster i databasernas tabeller och i loggfilerna.

Det system som slutligen växte fram under det här projektet innebar att flera olika moduler behövde fungera tillsammans och i flera av Python- skripten är det andra moduler och skript som anropas. Det innebar att planeringen för upplägget av hela projektet var väldigt viktig. Testkör- ningarna visade att systemet klarar att köra oavbrutet även om det är i förenklad form jämfört med ursprungsplaneringen.

Några justeringar vid en tillbakablick på hela projektet är att observera flera filjusteringar än bara MODIFY, som det var i det här projektet, är nog bra att implementera. Till exempel är det intressant att se information om en ACCESS-händelse, eller CREATE. Vem har gjort det och när?

Det är absolut något att bygga ut systemet med. En annan aspekt att tän- ka på är att lägga observation på fler loggfiler än vad som är fallet nu.

Det är intressant att se till exempel filerna auth.log, ufw.log och

(33)

user.log. Så nästa steg borde vara att bygga ut systemet med observation och loggning till databasen av fler loggfiler än i det här projektet. En tredje justering, är att lägga på någon form av analys, av den data som loggas och sparas till databasen. Det är intressant, men kan nog samtidigt vara en resurskrävande uppgift i form av planering och programmering.

Resultatet från körningarna visar att SIEM-systemet inte sparar ner alla nya poster till databasen. Det är intressant att studera tabell 4 och 5 lite närmare för att försöka hitta troliga orsaker till diskrepansen. De poster som skiljer uppstår när det har skett en omstart av MQTT-daemon ge- nom Linux-kommandot sudo systemctl restart mosquitto.server . När det sker en omstart på MQTT-daemon, skickar den fyra meddelanden i snabb takt, Stopping, Stopped, Starting och Started. Det blir sammanlagt fyra poster i syslog-filen. Om man däremot ser på det som loggats till databasen så hittar man endast två poster och båda har dessutom samma tid. En förklaring kan vara att endast två signaler i snabb takt kommer fram till Notifier eftersom händelserna Stopping och Stopped samt Starting och Started enligt tidsangivelserna sker tätt inpå varandra. Där- emot är SIEM-systemet långsammare än syslog och hinner endast gå in och läsa sista raden i syslog-filen två gånger. När SIEM-systemet kommer in och läser första gången har syslog redan loggat sina fyra händel- ser. Det gör att SIEM-systemet endast läser en rad istället för fyra. Strax därpå kommer SIEM-systemet in för den andra Notifier-signalen och lä- ser på nytt den sista raden trots att inga nya poster har loggats. När hän- delserna som loggas till syslog inte inträffar för nära inpå varandra hinner systemet med att spara allt till databasen.

6.1 Svar på problemformulering

De frågor som skulle besvaras var vilka delar som är nödvändiga i ett SIEM-system, hur driftsäkert är det slutliga SIEM-systemet samt går det att lita på det systemet läser och loggar. För den första frågan visar un- dersökningen av kända SIEM-system på marknaden och körningarna av projektets system visar att åtminstone fem delar är nödvändiga. Det är insamling, förtydligande, lagring, analys och presentation. Den andra frågan besvaras genom testkörningarna där det går att se att driftsäker- heten är god. Projektets testkörningar var inte så omfattande så det är vanskligt att dra alltför långtgående slutsatser vad gäller driftsäkerhe- ten. Det hade varit önskvärt med fler tester och framförallt längre tester.

På den tredje frågan som skulle besvaras visar testkörningarna att det

(34)

me situationer då signaler inte nådde den modul som behövde under- rättas. Det förekom också dubbla poster i databasen av en och samma händelse. Ett mer omfattande testmaterial hade kunnat visa på fler brister och situationer som behöver ses över.

Slutsatsen av undersökningen blir att ett SIEM-system går bra att implementera och köra. Det behövs dock injusteringar för att kunna lita på att systemet får med alla värden som skrivs till loggfilerna. Dessutom be- hövs kontroller av de databasvärden som loggas för att undvika så kallade dubbelposter. Det är många olika delar som ska samverka i ett sånt här system. Inom ramen för det här projektarbetet fanns tyvärr inte möj- lighet att kolla närmare på någon form av analysalgoritm för att behandla all insamlad data. Det är att rekommendera inför framtida arbeten.

En slutsats av projektet är att det går att implementera ett enklare SIEM- system på en Raspberry Pi som också uppvisar en ändå helt okej tillför- litlighet vad gäller loggning och drift. Som så ofta visar det sig i efter- hand att ännu mer planering i startskedet av projektet förmodligen hade betalat sig i slutskedet av projektet.

6.2 Samhälls- och etiska aspekter

Personer som arbetar med större datorsystem har ett ansvar för att över- vaka intrångsförsök mot systemet. Det behöver också ha kunskap om många typer av säkerhetshot som datorsystemet kan bli utsatt för. Det är väldigt svårt att samordna om det är flera personer som är inblanda- de. Är det en eller två personer kan det istället bli svårt att övervaka allting. Eftersom mängden data som hanteras hela tiden blir större, blir det också en allt viktigare uppgift för en datoradministratör att hantera.Där- för är det viktigt att känna till vilka stödapplikationer som finns att till- gå. Det här rapporten kan hjälpa till att visa på vilka hjälpmedel som finns att tillgå, vare sig man vill använda en redan färdig produkt eller skapa sitt eget SIEM-system.

Under projektet har inget insamlande av data från personer eller känsli- ga datauppgifter hanterats. Därför är de etiska aspekterna av arbetet ringa och har inte beaktats.

(35)

Källförteckning

[1] comparitech, ”9 Best SIEM Tools of 2020: Vendors & Solutions Ranked”

https://www.comparitech.com/net-admin/siem-tools/

Publicerad 2020-04-14. Hämtad 2020-05-29.

[2] PC & Network DOWNLOADS, ”What is Syslog, including Linux and Windows Servers, Ports and more.”

https://www.pcwdld.com/what-is-syslog-including-servers-and- ports

[3] RAPID7 Blog, ”What is syslog?”

https://blog.rapid7.com/2017/05/24/what-is-syslog/

Publicerad 2017-05-24. Hämtad 2020-06-03 [4] Techerati, ”A brief history of SIEM”

https://techerati.com/features-hub/opinions/a-brief-history-of- siem/

Publicerad 2019-06-12. Hämtad 2020-05-28

[5] Computer Performance, ”Best SIEM tools & sofware for 2019”

https://www.computerperformance.co.uk/network-security/siem- tools-software/

Publicerad 2018-11-26. Hämtad 2020-05-25

[6] Solutions Review, ”Information Security. Security Information and Event Management Solutions Directory”

https://solutionsreview.com/security-information-event-

management/security-information-event-management-solution- directory-siem/

Hämtad 2020-05-29

[7] McAfee, ”Security Information and Event Management (SIEM)”

https://www.mcafee.com/enterprise/en-us/products/siem- products.html

Hämtad 2020-05-29

(36)

[8] exabeam, ”The Exabeam Security Management Platform”

https://www.exabeam.com/product/

Hämtad 2020-05-29

[9] Wikipedia, ”software as a service”

https://en.wikipedia.org/wiki/Software_as_a_service Publicerad 2020-05-28. Hämtad 2020-05-30

[10] The Raspberry Pi Foundation, ”Raspberry Pi 3 Model B+”

https://www.raspberrypi.org/products/raspberry-pi-3-model-b- plus/

Hämtad 2020-06-03

[11] John C. Worsley, Joshua D. Drake, Practical PostgreSQL. First Edi- tion. Sebastopol; CA, USA: O’Reilly & Associates, Inc., 2002 [12] Gregory Smith, PostgreSQL 9.0, High Performance. Birmingham,

UK: Packt Publishing Ltd., 2010

[13] Steve's Internet Guide, ”Mosquitto MQTT Broker”

http://www.steves-internet-guide.com/mosquitto-broker/

Hämtad 2020-05-31

[14] Steve’s Internet Guide, ”Mosquitto MQTT Broker”

http://www.steves-internet-guide.com/into-mqtt-python-client/

Hämtad 2020-05-31

[15] TecMint, ”Pyinotify - Monitor Filesystem changes in Real-Time in Linux”

https://www.tecmint.com/pyinotify-monitor-filesystem- directory-changes-in-linux/

[16] GitHub, ”seb-m/pyinotify Home”

https://github.com/seb-m/pyinotify/wiki Publicerad 2012-11-15. Hämtad 2020-06-01.

[17] man7.org, ”RSYSLOGD(8)”

https://www.man7.org/linux/man-pages/man8/rsyslogd.8.html Publicerad 2014-05-28. Hämtad 2020-06-05.

(37)

[18] www.rsyslog.com, ”Rsyslog Documentation”

https://www.rsyslog.com/doc/v8-stable/configuration/index.html Hämtad 2020-06-05.

(38)

Bilaga A: Dokumentation av

egenutvecklad programkod

De programkoder som finns med i Bilaga A är skrivna i antingen Python 3.6.3 och Node.js 8.11.1. Det mesta av redigeringen har skett i texteditor Nano som följer med i Linux-systemet. All programkod är skriven av rapportförfattaren.

Koden kan laddas hem från ett terminalfönster med kommandot:

git@github.com:anst9000/Master-thesis-SIEM-system.git

(39)

Bilaga B: Dokumentation av databas

och tabeller

Databasen är gjord i PostgreSQL 9.6.

Table "public.syslogprimary" - Indexes: "syslogprimary_pkey" PRIMARY KEY, btree (id)

Column Type Modifiers Storage

id integer not null default next-

val('syslogprimary_syslo g_id_seq'::regclass)

plain

timereported timestamp with time zone

hostname character varying(25) not null extended

syslogtag character varying(50) not null extended

message character varying(1024) not null extended

Table "public.postgresprimary" - Indexes: "postgresprimary_pkey" PRIMARY KEY, btree (id)

val('postgresprimary_id_

seq'::regclass)

plain

timereported timestamp with time zone plain

hostname character varying(50) not null extended

db_user character varying(1024) not null extended

database character varying(50) not null extended

pid integer not null plain

Table "public.mqttprimary" - Indexes: "mqttprimary_pkey" PRIMARY KEY, btree (id)

val('mqttprimary_id_seq' ::regclass)

plain

timereported timestamp with time zone plain