Richard de Vries (ID: 500.719.935) I I
SYSLOG & SI(E)M
Student: Richard de Vries Studentnummer: 500.719.935
Datum: 12 november 2017 Begeleider: Dhr. I. Khaksar Eerste beoordelaar: Mevr. C.A. Bombeld Tweede beoordelaar: Dhr. B. Pinkster
Een verplicht huwelijk, maar leer elkaar
wel kennen alvorens je gaat dansen.
Richard de Vries (ID: 500.719.935) II
Managementsamenvatting
Een groot deel van de werkzaamheden dat wordt uitgevoerd in het SLTN Inter Access Security Operations Center (SOC) is gebaseerd op loginformatie. ‘Als het niet is vastgelegd in de ontvangen loginformatie, is het niet gebeurd.’ luidt de stelling van het SOC. Een complicerende factor hierbij is dat de loginformatie decentraal wordt gegenereerd en de SOC vanaf een centraal punt kijkt. Daarom dient de loginformatie van de decentrale omgeving naar de centrale omgeving te worden getransporteerd. Vanwege de vele factoren welke de SOC-operatie negatief kunnen beïnvloeden vanwege deze decentrale/centrale opstelling, heeft dit onderzoek zich gefocust op het transporteren van de loginformatie.
In dit onderzoek is gekeken naar welke netwerkprotocollen het transport van de loginformatie kunnen verzorgen en welk kwaliteitsoordeel over elk netwerkprotocol kan worden gegeven. De basis van het onderzoek is gelegd door het literatuuronderzoek. De uitkomsten van het literatuuronderzoek zijn getoetst in de praktijk, zodat het kwaliteitsoordeel onderbouwd gegeven kan worden. Voor het kwaliteitsoordeel wordt gekeken of de confidentiality, integrity en availability beïnvloed kunnen worden, zodat de SOC-operatie negatief beïnvloed kan worden. Daarnaast is gekeken welke configuratie-instellingen er mogelijk zijn om deze beïnvloeding te kunnen uitsluiten.
Omdat SLTN in het verleden strategisch heeft gekozen voor het product AlienVault voor de SOC-operatie, geldt dit als randvoorwaarde. Het te adviseren netwerkprotocol dient direct te kunnen communiceren met AlienVault. Daar SLTN de loginformatie van haar klanten via het Internet ontvangt, dient het transporteren van deze loginformatie vertrouwelijk te gebeuren.
Op basis van de uitkomsten van het onderzoek luidt het advies het netwerkprotocol SYSLOG in combinatie met Transport Layer Security (TLS) en Reliable Event Logging Protocol (RELP) te gebruiken voor het verzenden van loginformatie van de decentrale omgeving naar de centrale omgeving. TLS zorgt voor de vertrouwelijkheid gedurende het transport van de loginformatie en RELP zorgt ervoor dat eventuele problemen gedurende het transport van loginformatie kunnen worden opgevangen, zodat de nog niet succesvol getransporteerde loginformatie later alsnog afgeleverd kan worden.
Omdat de loginformatie voor de SOC-operatie van cruciaal belang is, worden er twee vervolgonderzoeken geadviseerd. Het eerste onderzoek dient zich te richten op hoe AlienVault geïmplementeerd kan worden als Managed-Security-Service-Provider (MSSP). Het tweede onderzoek moet zich richten op hoe betrouwbaar het genereren van de loginformatie op de bron daadwerkelijk is. Met deze twee vervolgonderzoeken en dit onderzoek over het transporteren van loginformatie is de volledige cyclus vanaf het ontstaan van loginformatie tot verwerking door AlienVault gedekt, zodat loginformatie de SOC-operatie niet negatief kan beïnvloeden.
Richard de Vries (ID: 500.719.935) III
Inhoudsopgave
1 Inleiding ... 1 1.1 Het onderzoek ... 1 1.2 De onderzoeker ... 2 2 Onderzoeksopdracht ... 3 2.1 Aanleiding ... 3 2.2 Probleemstelling ... 4 2.3 Onderzoeksvraag ... 5 2.4 Scope/afbakening ... 5 3 Methoden en technieken ... 6 3.1 Literatuuronderzoek ... 6 3.2 Praktijkonderzoek ... 6 3.3 Kwantitatief onderzoek ... 6 4 Onderzoek ... 74.1 Wat wordt verstaan onder ‘beïnvloeding op basis van de keuze van het netwerkprotocol’? ... 7
4.2 Wat wordt verstaan onder ‘Security Monitoring-dienstverlening’? ... 12
4.3 Welke netwerkprotocollen bestaan op het gebied van het doorgeven van loginformatie? ... 13
4.4 Wat is de impact op het netwerk van loginformatie als wordt gekozen voor het meest optimale netwerkprotocol voor het transporteren van loginformatie? ... 14
4.5 Wat is de impact op andere gebruikers van loginformatie als wordt gekozen voor het meest optimale netwerkprotocol voor het transporteren van loginformatie? ... 15
4.6 Wat doen andere partijen welke een soortgelijk probleem kennen? ... 15
5 Analyse ... 17
5.1 Wat is de kwaliteit van een netwerkprotocol? ... 17
5.2 Wat is de impact op het netwerk als wordt gekozen voor een betrouwbare transmissie van loginformatie? ... 21
5.3 Wat doen andere partijen die een soortgelijk probleem kennen? ... 31
6 Relevante onderzoeken ... 38
6.1 Onderzoek naar het genereren van de loginformatie ... 38
6.2 Onderzoek naar het transporteren van de loginformatie ... 38
6.3 Onderzoek naar het verwerken van de loginformatie ... 39
6.4 Weinig onderzoeken beschikbaar ... 39
7 Conclusie ... 40
8 Advies ... 41
8.1 Advies 1 – inrichtingsadvies SIEM/SIM ... 41
8.2 Advies 2 – betrouwbaarheidsonderzoek genereren van loginformatie ... 41
A. Bronverwijzing ... 42
B. Lijst van gebruikte afkortingen ... 45
C. Enquêteformulier ... 47
Richard de Vries (ID: 500.719.935) 1
1 Inleiding
In dit hoofdstuk worden het onderwerp (paragraaf 1.1) en de onderzoeker (paragraaf 1.2) geïntroduceerd. Hierdoor worden de contouren van het onderzoek zichtbaar die nader uitgewerkt worden in de andere hoofdstukken van deze scriptie.
Vanaf hoofdstuk 2 wordt de onderzoeksopdracht nader uitgewerkt in een onderzoeksvraag. Deze onderzoeksvraag wordt in hoofdstuk 4 uitgewerkt op basis van literatuur en wordt in de praktijk getoetst in hoofdstuk 5. Hoofdstuk 3 beschrijft hoe het onderzoek zelf wordt aangepakt. In hoofdstuk 6 worden andere onderzoeken uit de literatuur vermeld die relevant zijn. Op basis van de uitkomsten van de diverse onderzoeken wordt in hoofdstuk 7 de conclusie geschreven van dit onderzoek, zodat op basis van deze conclusie een advies kan worden geformuleerd in hoofdstuk 8.
1.1 Het onderzoek
SLTN Inter Access (SLTN) is een multidisciplinaire ICT-dienstverlener die diensten aanbiedt vanaf het leveren van hard- en software tot en met het volledig ontzorgen van een klant. Hierbij heeft de klant de gebruikersrol en zorgt SLTN voor alle ICT-gerelateerde taken zoals beheer en ondersteuning. Hierbij richt SLTN zich vooral op de grotere omgevingen (SLTN Inter Access, sd).
Deze diensten worden aangeboden door de verschillende practices. Een van deze practices is de Cyber Security-practice en deze biedt onder andere de volgende diensten aan:
• Security Awareness
De gedachtegang achter de dienst Security Awareness is om de kennis en kunde van een medewerker op het gebied van cyber security naar een hoger niveau te krijgen door onlinetrainingen en onlinebeoordelingen, zodat het risico (cyber security-incidenten als gevolg van menselijk handelen) voor het bedrijf kleiner wordt.
• Vulnerability Management
De dienst Vulnerability Management helpt een bedrijf de digitale kwetsbaarheden binnen de ICT-omgeving in kaart te brengen en te prioriteren, zodat de ICT-beheerafdelingen deze op een correcte volgorde kunnen verhelpen door middel van het installeren van een patch en/of door het aanpassen van de configuratie.
• Security Monitoring
De dienst Security Monitoring verzorgt de bewaking van de ICT-componenten van een bedrijf, zodat bij een potentieel incident er tijdig kan worden geacteerd volgens de overeengekomen afspraken. De gemaakte afspraken worden uitgewerkt in zogenaamde bewakingsregels die worden geconfigureerd in de bewakingssoftware AlienVault. AlienVault is een zogenaamde Security Information Event Management (SIEM)-oplossing. Een SIEM-oplossing ontvangt, verwerkt, analyseert en acteert optioneel op basis van de ontvangen loginformatie.
Richard de Vries (ID: 500.719.935) 2 De benodigde loginformatie voor de SIEM-omgeving wordt onder andere gegenereerd door:
• Firewalls;
• Intrusion Detection System (IDS, inbraakdetectie) -apparatuur; • anti-virusoplossingen;
• proxy-oplossingen; • serverapplicaties;
• serverbesturingssystemen als Microsoft Windows en Linux.
De benodigde loginformatie wordt door diverse netwerkprotocollen en/of andere oplossingen naar de SIEM-omgeving getransporteerd. Over het transporteren van loginformatie gaat dit onderzoek. Het genereren van de loginformatie op de bron en het verwerken van de loginformatie in de SIEM-omgeving worden niet onderzocht in dit onderzoek, maar zijn losstaande onderzoeken op zich.
Het gekozen onderwerp van deze scriptie is niet alleen relevant voor SLTN zelf, maar is relevant voor elke organisatie die gebruikmaakt van een dergelijke oplossing, zowel in huis als via outsourcing. De SIEM-oplossing hoeft niet specifiek AlienVault zijn, maar kan elke willekeurige SIEM-SIEM-oplossing zijn. Regelmatig is in de media te lezen dat bij een bedrijf of organisatie digitaal is ingebroken. Bedrijven zelf komen hier vaak pas laat achter (Osborne, 2015). Zoals in dit onderzoek wordt beschreven, is dit niet alleen te wijten aan personeel maar ook aan de techniek.
Er zijn nog geen onderzoeken gepubliceerd waarom de techniek niet tijdig alarm slaat bij een IT-security-incident. Het is aannemelijk dat digitale inbrekers op de hoogte zijn dat er mogelijk een SIEM-oplossing actief is en zij hebben hun arsenaal hierop aangepast om ontdekking door een SIEM-oplossing zolang mogelijk uit te stellen. De digitale inbrekers doen dit onder andere door de loginformatie te manipuleren (onderbreken en/of valse informatie). Door ervoor te zorgen dat de loginformatie via een betrouwbare methode wordt afgeleverd bij een SIEM-oplossing, moet het mogelijk zijn een digitaal security incident sneller te ontdekken.
1.2 De onderzoeker
Door de ervaring van systeem- en netwerkbeheer te combineren met de benodigde kennis en kunde van een ethische hacker wordt er gekeken naar hoe loginformatie betrouwbaar en veilig is te transporteren over een datanetwerk, zodat de SIEM-oplossing de loginformatie tijdig, volledig, veilig en integer ontvangt.
Hierbij is van belang te weten dat een ethisch hacker zich verplaatst naar de verdedigende kant van cyber security. Deze red-team-/blue-teamaanpak is een militaire aanpak en wordt regelmatig toegepast binnen de cybersecuritywereld voor kruisbestuiving op het gebied van kennis en kunde (Zurkus & Drinkwater , 2017). De aanvaller leert de verdedigende partij hoe deze aanvalt, zodat de verdedigende partij zich beter kan wapenen. De onderzoeker (red-team) verplaatst zich naar de verdedigende kant (blue-team) en gebruikt zijn kennis van het red-team om het blue-team zo optimaal mogelijk te adviseren.
Richard de Vries (ID: 500.719.935) 3
2 Onderzoeksopdracht
Zoals in de inleiding is beschreven gaat dit onderzoek over het transporteren van loginformatie over een datanetwerk. In dit hoofdstuk wordt dit onderwerp nader uitgewerkt en wordt via de aanleiding (zie paragraaf 2.1) de probleemstelling (zie paragraaf 2.2) verduidelijkt. Op basis van deze probleemstelling kunnen de onderzoeksvraag (zie paragraaf 2.3) en bijbehorende deelvragen worden geformuleerd. Daarnaast worden de kaders (zie paragraaf 2.4) van het onderzoek beschreven.
2.1 Aanleiding
Het vastleggen van gebeurtenissen (audit-trails) is niet iets specifieks van Information Communication Technology (ICT)-Security, maar wordt al gedaan sinds mensen kunnen schrijven en lezen. Met het uitvinden van de personal computer door IBM (IBM, z.j.), is het vastleggen eenvoudiger en toegankelijker geworden voor een grotere populatie. Daarvoor werd informatie veelal vastgelegd in grote mainframes en/of andere systemen.
Met de komst van het (D)ARPA-netwerk (het latere internet) in 1973 (DARPA, z.j.) is de keuze welk netwerkprotocol moet worden gebruikt voor het verzamelen of transporteren van loginformatie belangrijker geworden, omdat de aanvaller vanaf veel meer locaties dan alleen vanaf het netwerk waar het doel zich begeeft kan aanvallen.
Hierdoor is de noodzaak van het centraal verzamelen van loginformatie ontstaan. In het begintijdperk van internet waren nog weinig standaarden (Request for Comments, RFC) beschreven. Het gevolg hiervan was dat de loginformatie niet op een consequente manier werd gegenereerd, getransporteerd en opgeslagen. Met de introductie van de personal computer en de komst van internet is het tijdperk van informatie ontstaan (Sterling, 1997). Als gevolg hiervan worden steeds meer diensten die vroeger een menselijke interactie vereisten heden ten dage via internet afgehandeld. Hierdoor bevindt zich steeds meer data van een persoon in de onlinewereld. De nut en noodzaak om deze data te beveiligen neemt dan ook steeds meer toe. Dit gebeurt onder andere door het vastleggen van de audit-trail (wie doet wat wanneer).
Vanwege de reeds voortgekomen cyberincidenten en om toekomstige cyberincidenten te voorkomen zijn in de wetgevingen (onder andere de Algemene Verordening Persoonsgegevens) passages opgenomen waaraan een bedrijf of instelling moet voldoen (Autoriteit Persoonsgegevens, z.j.). Daarnaast hebben overkoepelende of certificerende organisaties regels opgesteld waaraan een bedrijf of instelling aan moet voldoen om lid te zijn of gebruik te maken van de organisatie (S7, 2006) (ISO, z.j.). Ook zonder de verplichting vanuit diverse wetgevingen willen bedrijven en instellingen actie ondernemen om data veilig te houden, zodat de bedrijfscontinuïteit niet in gevaar komt.
Bovengenoemde punten hebben geleid tot het ontwikkelen van Security Event Management (SEM)-oplossingen zoals:
• een firewall: welke datastromen mogen wel en niet;
• een intrusion detection system (IDS): welke datastromen komen overeen met vooraf gedefinieerde patronen van (verdacht) dataverkeer;
Richard de Vries (ID: 500.719.935) 4 Dit kunnen zowel puntoplossingen zijn, waarbij alleen wordt gekeken naar één bepaald systeem of probleem tot aan volwaardige Security Information Event Management (SIEM)-oplossingen, waarbij ook wordt gekeken naar de verbanden van de loginformatie tussen de verschillende SEM-oplossingen. Zowel bij een SEM- als bij een SIEM-oplossing is het van belang dat de loginformatie volledig, betrouwbaar en integer wordt afgeleverd bij de centrale omgeving waar de management console van de oplossing veelal draait.
Zoals in paragraaf 1.1 is beschreven, biedt SLTN vanuit haar cyber security-ervaring een bewakingsdienst (centraal) aan waarbij het overeengekomen gedeelte van de ICT-omgeving van de klant (decentraal) wordt bewaakt. Vanuit het Security Operations Center (SOC) worden de inkomende meldingen (loginformatie) met behulp van de bewakingsoplossing geanalyseerd. Op basis van de uitkomst van deze analyse kunnen mogelijke vervolgacties worden opgestart. Om een goede analyse te kunnen uitvoeren, is het van belang dat de bewakingsoplossing de loginformatie volledig, betrouwbaar, integer en tijdig ontvangt. Wanneer loginformatie onjuist en/of onvolledig is, kan dit tot gevolg hebben dat de bewakingsoplossing niet of niet tijdig een notificatie naar de SOC-medewerker stuurt. Dit heeft als gevolg dat er niet of niet tijdig geacteerd wordt en kan er voor de klant mogelijkerwijs meer schade ontstaan.
Het SOC is echter niet de enige gebruiker van deze loginformatie. De loginformatie wordt ook gebruikt door: • de IT-beheerders als bron van informatie voor het oplossen van problemen;
• het Network Operations Center (NOC) voor het bewaken van beschikbaarheid.
Deze groepen (SOC, NOC en beheer) van gebruikers stellen andere eisen aan de loginformatie. IT-beheer kan bijvoorbeeld stellen dat loginformatie binnen vijf minuten zichtbaar moet zijn in de centrale omgeving en dat het geen probleem is wanneer loginformatie onderweg verloren gaat of wordt ingezien door derden. Terwijl het voor het SOC van belang is dat de loginformatie near-real time ontvangen wordt.
2.2 Probleemstelling
Zoals in paragraaf 2.1 te lezen is, zijn de SOC-medewerkers afhankelijk van de bewakingsoplossing voor het tijdig signaleren van potentiele securityincidenten. De bewakingsoplossing is op zijn beurt weer afhankelijk van de ontvangen loginformatie. Deze laatste afhankelijkheid is verder te splitsen in de volgende deelgebieden:
• het genereren van de loginformatie zelf;
• het transporteren van de decentrale loginformatie naar de centrale omgeving; • het verwerken van de loginformatie in de centrale omgeving;
• het analyseren van de verwerkte loginformatie in de centrale omgeving.
Hoe eerder in deze keten van afhankelijkheid (van ontstaan tot aan analyse) de loginformatie wordt aangepast, hoe meer effect deze uiteindelijk heeft. Elk gebied is een onderzoek op zich waard om tot de meest optimale situatie voor het desbetreffende gebied te kunnen komen. In paragraaf 1.1 is beschreven dat dit onderzoek zich alleen focust op het transporteren van de loginformatie.
Richard de Vries (ID: 500.719.935) 5 Aangezien door transport van de loginformatie de verantwoordelijkheid van deze informatie in veel gevallen van de klant (decentraal) naar SLTN (centraal) gaat, is het voor SLTN van belang dat het transport op dusdanige wijze plaats vindt, zodat de loginformatie betrouwbaar, volledig, integer, veilig en tijdig doorkomt. Hieruit is de volgende probleemstelling van dit onderzoek af te leiden:
‘Hoe kan SLTN in samenwerking met de klant ervoor zorgen dat de loginformatie tijdig, volledig, integer en betrouwbaar wordt getransporteerd naar de bewakingsoplossing in de centrale omgeving?’
2.3 Onderzoeksvraag
De probleemstelling van dit onderzoek (zie paragraaf 2.2) handelt over het transporteren van loginformatie van punt A naar punt B, waarbij de loginformatie in veel gevallen voortkomt uit een SEM-achtige oplossing. Het transporteren van deze data gaat over een netwerk, waarbij een netwerk communiceert op basis van netwerkprotocollen. Op basis hiervan kan de hoofdvraag beschreven worden. De hoofdvraag van dit onderzoek luidt:
‘Wat is het meest optimale netwerkprotocol voor het transporteren van (security-)loginformatie, zodat de Security Monitoring-dienstverlening niet negatief kan worden beïnvloed op basis van de keuze van het netwerkprotocol?’
Bovenstaande hoofdvraag is te splitsen in de volgende deelvragen:
• Wat wordt verstaan onder ‘beïnvloeding op basis van de keuze van het netwerkprotocol’? • Wat wordt verstaan onder ‘Security Monitoring-dienstverlening’?
• Welke netwerkprotocollen bestaan op het gebied van het doorgeven van loginformatie? • Wat doen andere partijen die een soortgelijk probleem ondervinden?
• Wat is de invloed op een netwerk als wordt gekozen voor ‘het meest optimale netwerkprotocol voor het transporteren van loginformatie’?
• Wat is de invloed op de andere gebruikers van de loginformatie als wordt gekozen voor ‘het meest optimale netwerkprotocol voor het transporteren van loginformatie’?
2.4 Scope/afbakening
Het onderzochte netwerkprotocol dient de loginformatie rechtstreeks aan AlienVault aan te leveren. Het netwerkprotocol wordt niet zelf onderzocht of deze fouten bevat, alleen de implementatie van het netwerkprotocol wordt onderzocht.
Indien er separate servers nodig zijn voor het uitvoeren van een bepaalde test, dan dienen deze servers hetzelfde besturingssysteem te hebben als de bewakingsoplossing (AlienVault). AlienVault is gebouwd boven op het besturingssysteem Debian 8. Indien additionele software benodigd is, dan dient AlienVault dit te ondersteunen.
Richard de Vries (ID: 500.719.935) 6
3 Methoden en technieken
De in paragraaf 2.3 beschreven onderzoeksvraag wordt op basis van een systematische en reproduceerbare methode nader onderzocht. Door de systematische aanpak wordt het onderzoek impliciet ook reproduceerbaar. Binnen dit onderzoek worden een aantal methodieken gebruikt, namelijk literatuur (zie paragraaf 3.1), praktijk (zie paragraaf 3.2) en kwantitatief (zie paragraaf 3.3).
3.1 Literatuuronderzoek
Voordat kan worden bepaald welk netwerkprotocol het meest geschikt is voor het veilig en betrouwbaar transporteren van loginformatie, wordt in de documentatie van AlienVault gezocht welke netwerkprotocollen ondersteund worden (zie paraaf 2.4 voor afbakening). Tevens wordt er per netwerkprotocol uitgezocht welke configuratiemogelijkheden er zijn. Op basis van de Confidentiality, Integrity, Availability (CIA)-triade wordt elke configuratiemogelijkheid tot een van deze drie toegerekend (Stallings & Brown, Computer Security - Principles and Practice, 2015).
Op basis van deze informatie verplaatst de onderzoeker zich naar het blauwe team en stelt zich constant de vraag ‘Hoe kan ik vroegtijdige ontdekking door een SIEM-oplossing voorkomen?’ Hierbij is het mogelijk dat per as verschillende mogelijkheden zijn. Door het juist formuleren van de vraag blijft de hoeveelheid mogelijkheden echter beperkt.
Daarnaast wordt onderzocht welke andere onderzoeken op dit gebied reeds hebben plaatsgevonden. Hierbij kunnen de onderzoeken in het verlengde liggen van dit onderzoek of juist ervoor. In alle gevallen dienen de onderzoeken te maken hebben met het genereren, transporteren en/of verwerken van loginformatie.
3.2 Praktijkonderzoek
In het praktijkonderzoek wordt met behulp van een laboratoriumopstelling de in de literatuur gevonden netwerkprotocollen met hun configuratiemogelijkheden getoetst op hun werking en impact op de prestaties van het netwerk. Tevens wordt hierbij gekeken welk effecten er zouden kunnen zijn voor de andere gebruikers van de loginformatie.
3.3 Kwantitatief onderzoek
In het kwantitatieve onderzoek wordt gekeken hoe gebruikers van andere organisaties omgaan met loginformatie gedurende het transport van punt A naar punt B en hoe zij de door hen gehanteerde aanpak beoordelen. Het kwantitatieve onderzoek wordt met behulp van een online-enquête uitgevoerd. In verband met de gevoeligheid rondom cyber security wordt de enquête volledig anoniem verspreid en wordt alleen om niet herleidbare gegevens gevraagd.
Richard de Vries (ID: 500.719.935) 7
4 Onderzoek
Aan de hand van de drie beschreven onderzoekstechnieken (zie hoofdstuk 3) worden de beschreven hoofd- en deelvragen (zie paragraaf 2.3) verder uitgewerkt in onderzoeksvragen. Deze onderzoeksvragen worden vervolgens in hoofdstuk 5 beantwoord, waarmee in hoofdstuk 7 uiteindelijk de hoofdvraag mee kan worden beantwoord.
4.1 Wat wordt verstaan onder ‘beïnvloeding op basis van de keuze van het
netwerkprotocol’?
Het netwerkprotocol zorgt ervoor dat loginformatie van punt A naar punt B wordt. Vanuit de CIA-triade bestaan er drie aandachtgebieden waarover beïnvloeding gemeten kan worden:
1. Confidentiality (Vertrouwelijkheid)
Confidentiality heeft geen directe beïnvloeding, omdat de loginformatie wel aan kan komen. De confidentiality heeft echter wel impact op de Security Monitoring-dienstverlening, omdat de aanvallende partij vroegtijdig kan weten dat er een mogelijke SIEM-oplossing actief is als confidentiality niet is ingeregeld. Als gevolg hiervan kan de aanvaller additionele maatregelen nemen om vroegtijdige ontdekking te voorkomen waardoor de Security Monitoring-dienstverlening negatief wordt beïnvloed.
2. Integrity (Integriteit)
Bij integrity kan beïnvloeding direct worden aangetoond, omdat dan de loginformatie tussen punt A en punt B wordt aangepast. Met andere woorden dat wat host A vanaf punt A verstuurt, niet hetzelfde is dat wat aankomt bij host B op punt B. Indien andere loginformatie aankomt in de SIEM-omgeving, dan is gegeneerd op punt A, dan kan hierdoor de Security Monitoring-dienstverlening negatief worden beïnvloed omdat cruciale loginformatie niet betrouwbaar is. Hierdoor kan mogelijk onnodige tijd verstrijken voordat er alarm geslagen kan worden.
3. Availability (Beschikbaarheid)
Bij availability is beïnvloeding direct aan te tonen, doordat de verstuurde loginformatie van punt A niet aankomt bij punt B. Indien niet alle loginformatie aankomt in de SIEM-omgeving, dan kan hierdoor de Security Monitoring-dienstverlening negatief worden beïnvloed omdat cruciale loginformatie kan ontbreken en er niet of niet tijdig alarm geslagen kan worden.
Door objectieve criteria per as van de CIA-triade vast te stellen, voldoet SLTN aan de in paragraaf 5.2 van ISO-27004 verplichting (Bernik & Prislan, 2016) voor het meten van kwaliteit op het gebied van Cyber Security (International Organization for Standardization, 2016) en hierdoor wordt het meetbaar gemaakt. Door hieraan een waarde te koppelen, kan een score worden berekend. En op basis van deze scores kunnen netwerkprotocollen met elkaar vergeleken worden.
Voor het bepalen van de scores is uitgegaan van de internationaal geaccepteerde standaard voor het berekenen van een Common Vulnerability and Exposure (CVE)-score. De CVE-score wordt berekend met behulp van de Common Vulnerability Scoring System (CVSS) v3 standaard (FIRST, z.j.). Binnen deze standaard wegen confidentiality, integrity en availability even zwaar. Indien binnen een as verschillende punten zijn
Richard de Vries (ID: 500.719.935) 8 waarover meting kan plaatsvinden, dan wordt de score binnen deze as ook evenredig verdeeld om op deze manier gelijk te blijven aan de CVSS-standaard. Een netwerkprotocol kan maximaal 99 punten behalen, waarbij elke as goed is voor 33 punten.
Om de kwaliteit meetbaar te maken zijn de volgende criteria samengesteld. Tevens is per criterium een waarde toegekend als het netwerkprotocol dit ondersteunt en is per criterium aangegeven tot welke as van de CIA-triade deze behoort:
• Hoe kan gegarandeerd worden dat de afzender ook de echte afzender van de loginformatie is? (Confidentialiteit, 11 punten, zie paragraaf 4.1.1)
• Hoe kan gegarandeerd worden dat de ontvanger ook de echte ontvanger van de loginformatie is? (Confidentialiteit, 11 punten, zie paragraaf 4.1.2)
• Hoe kan gegarandeerd worden dat gedurende transmissie van de loginformatie deze niet kan worden uitgelezen door een onbevoegde partij? (Confidentialiteit, 11 punten, zie paragraaf 4.1.3) • Hoe kan gegarandeerd worden dat de loginformatie onderweg niet is aangepast? (Integriteit, 33
punten, zie paragraaf 4.1.4)
• Hoe kan gegarandeerd worden dat alle loginformatie daadwerkelijk aankomt bij de ontvanger? (Beschikbaarheid, 16½ punten, zie paragraaf 4.1.5)
• Hoe kan gegarandeerd worden dat alle loginformatie daadwerkelijk alsnog aankomt bij de ontvanger als de bestemming tijdelijk onbereikbaar is geweest als gevolg van een verstoring? (Beschikbaarheid, 16½ punten, zie paragraaf 4.1.6)
In paragraaf 5.1 worden de resultaten van het testen van de kwaliteit van de diverse netwerkprotocollen beschreven.
4.1.1 Hoe kan worden gegarandeerd dat de afzender ook de echte afzender van de loginformatie
is?
Om te voorkomen dat valse loginformatie de centrale omgeving vervuilt, dient met 100% zekerheid de identiteit van de versturende partij te worden vastgesteld, zodat in de SOC-dienstverlening geen tijd verloren gaat met het scheiden van goede en valse loginformatie.
Er bestaan twee methodes waarmee de identiteit van de afzender te garanderen is. Beide methodes werken op basis van het uitwisselen van een publieke sleutel en dat de data worden versleuteld met een private sleutel (Stallings & Brown, Computer Security - Principles and Practice, 2015). Met behulp van de private sleutel van de ontvanger kan de ontvanger de loginformatie van de afzender decoderen, welke data met zijn private sleutel heeft versleuteld, zodat de originele inhoud weer beschikbaar is voor verdere verwerking. Deze methode maakt gebruik van een asymmetrische sleutel, zoals is weergegeven in Figuur 1.
Richard de Vries (ID: 500.719.935) 9 Figuur 1: Schematische weergave uitwisselen van data op basis van asymmetrische encryptie
Bij methode 1 wordt gebruik gemaakt van een cliënt-certificaat dat is uitgegeven door een gemeenschappelijk vertrouwde certificaatuitgever. Bij methode 2 wordt tijdens de configuratie van de afzender een eenmalige connectie opgezet met de ontvanger, waarbij gedurende deze eenmalige sessie een publieke sleuteluitwisseling plaatsvindt.
Indien bij het aanvragen van het cliënt-certificaat naast de Fully Qualified Domain Name (FQDN) het IP-adres wordt geregistreerd in het certificaat, dan is het mogelijk de identiteit van de cliënt aan de hand van twee criteria vast te stellen. Hierdoor is met een hogere nauwkeurigheid de identiteit van de cliënt vast te stellen dan bij methode 2.
Het gebruik van een gemeenschappelijke encryptiesleutel is onvoldoende om de afzender te identificeren, omdat er geen uniek element van de afzender wordt gebruikt. Met behulp van een gemeenschappelijke encryptiesleutel wordt alleen het dataverkeer gecodeerd. Deze methode maakt gebruik van een symmetrische sleutel, zoals is weergegeven in Figuur 2 (Stallings & Brown, Computer Security - Principles and Practice, 2015).
Figuur 2: Schematische weergave uitwisselen van data op basis van symmetrische encryptie
4.1.2 Hoe kan worden gegarandeerd dat de ontvanger ook de echte ontvanger van de
loginformatie is?
Om te voorkomen dat onbevoegden de loginformatie kunnen zien en mogelijk worden gewaarschuwd dat een bewakingsoplossing actief is, is het noodzakelijk dat de versturende partij alleen loginformatie verstuurd
Richard de Vries (ID: 500.719.935) 10 als de versturende partij 100% zeker is dat de ontvangende partij daadwerkelijk de correcte ontvangende partij is.
Dit criterium is verder gelijk aan het criterium waarbij de afzender wordt gevalideerd. Alleen waar ‘afzender’ staat vermeld, moet ‘ontvanger’ staan.
4.1.3 Hoe kan worden gegarandeerd dat gedurende de transmissie van de loginformatie deze niet
kan worden uitgelezen door een onbevoegde partij?
Om te voorkomen dat onbevoegden de loginformatie kunnen inzien gedurende het transport van punt A naar punt B, en mogelijk worden gewaarschuwd dat een bewakingsoplossing actief is, is het noodzakelijk dat de loginformatie gedurende het transport van punt A naar punt B is versleuteld.
Het beveiligen van het transport van loginformatie van punt A naar punt B met behulp van encryptie is zowel mogelijk op basis van asymmetrische als symmetrische encryptie (zie Figuur 1 en Figuur 2).
Vanuit security geredeneerd is het gebruik van asymmetrische encryptie veiliger dan symmetrische encryptie, omdat elke sessie waarover loginformatie wordt uitgewisseld een unieke encryptiesleutel heeft. Vanuit beheer geredeneerd is het gebruik van symmetrische encryptie eenvoudiger, omdat elke host gebruikmaakt van dezelfde encryptiesleutel. Dit is minder veilig dan asymmetrische encryptie, omdat het encryptieprotocol vaak bekend is. De aanvaller kan bij voldoende tijd en middelen de encryptiesleutel vinden door een zogenaamde brute-force-aanval uit te voeren. De enige bescherming tegen een brute-force-aanval is het gebruik van een lange en ingewikkelde encryptiesleutel en een sterk encryptieprotocol, zoals AES en 3DES (Stallings & Brown, Computer Security - Principles and Practice, 2015). Deze aanval kan ook offline gebeuren waardoor de SOC-dienstverlening niet merkt dat wordt geprobeerd de encryptiesleutel te vinden.
4.1.4 Hoe kan worden gegarandeerd dat de loginformatie onderweg niet is aangepast?
Om te voorkomen dat gedurende het transport gemodificeerde loginformatie wordt verwerkt door de ontvangende partij, is het noodzakelijk dat de versturende partij de loginformatie beveiligd tegen ongemerkte aanpassingen.
Het aanpassen van loginformatie is aan te tonen als op basis van de volgende een HASH- of CRC32-waarde wordt toegekend: • verzender; • ontvanger; • datum; • tijd; • logberichtnummer;
• lengte van de loginformatie; • de loginformatie zelf.
Hierbij is een HASH-waarde een sterkere beveiliging dan een CRC32-waarde, omdat een CRC32-waarde uit 32-bits bestaat. Tevens hangt de lengte van een HASH-waarde af van het gebruikte HASH-protocol en deze is vaak langer dan 128-bits. Een HASH-waarde is het resultaat van een cryptografische berekening (Stallings & Brown, Computer Security - Principles and Practice, 2015). Een probleem bij deze beveiliging is waar de
Richard de Vries (ID: 500.719.935) 11 sleutel wordt bewaard welke is gebruikt voor het berekenen van de HASH-waarde. Indien deze wordt meegestuurd, verlies de HASH-waarde zijn toegevoegde waarde, omdat een aanvaller met behulp van deze sleutel een geldige HASH-waarde kan worden nadat hij de data heeft aangepast.
Het gebruik van serverside encryptie en authenticatie ten behoeve van het transporteren van loginformatie is in dit geval onvoldoende, omdat bij een Man-In-The-Middle (MITM)-aanval de mogelijkheid bestaat om de loginformatie aan te passen om vervolgens alsnog af te leveren bij de originele ontvanger (zie Figuur 3). Een mogelijke oplossing voor het tegengaan van MITM-aanval is gebruik te maken van zowel client als serverside authenticatie, waarbij met grote zekerheid bewezen wordt dat het device ook echt het device is (zie ook paragraaf 4.1.1 en 4.1.2).
Figuur 3: Datastromen bij een MITM-aanval
Een mogelijke oplossing voor het veilig berekenen en valideren van de HASH-waarde is om de HASH-waarde toe te voegen op het moment dat de loginformatie wordt gegenereerd en de gebruikte sleutel op te slaan op zowel de afzender als de ontvanger. Het uitwerken en testen van deze oplossing valt echter buiten de scope van dit onderzoek.
4.1.5 Hoe kan worden gegarandeerd dat alle loginformatie daadwerkelijk aankomt bij de
ontvanger?
Om te voorkomen dat slechts een gedeelte van de loginformatie aankomt bij de ontvangende partij, is het noodzakelijk dat de configuratie zodanig is ingesteld dat bij missende en/of corrupt geraakte loginformatie deze automatisch opnieuw wordt verzonden door de versturende partij. Zodat de ontvangende partij altijd het volledige logbericht heeft.
De volgende methode is toegestaan:
• Het versturen van de loginformatie vindt op basis van het TCP-protocol.
Bij gebruik van het TCP-protocol wordt de ontvangst van een of meerdere netwerkframes bevestigd. Daarnaast is in het TCP-protocol een aantal veiligheden ingebouwd waardoor de versturende partij moet bijhouden of de ontvangende partij de data goed heeft ontvangen. Indien niet het geval is, dan dient de versturende partij de data (of delen daarvan) opnieuw te versturen.
Richard de Vries (ID: 500.719.935) 12
4.1.6 Hoe kan worden gegarandeerd dat alle loginformatie daadwerkelijk alsnog aankomt bij de
ontvanger als de bestemming tijdelijk onbereikbaar is geweest als gevolg van een
verstoring?
Om te voorkomen dat loginformatie verloren gaat als gevolg van een verstoring in of onderhoud aan de ICT-omgeving, dient de versturende partij een noodbuffer en -functionaliteit te hebben om loginformatie te bufferen.
De volgende methode is toegestaan:
• In het protocol is de functionaliteit van een noodbuffer ingebouwd, zodat de loginformatie later alsnog kan worden verstuurd naar de ontvangende partij.
Hierbij moet worden opgemerkt dat de omvang van de noodbuffer wordt bepaald door het IT-securitybeleid van het bedrijf. Hierin kan bijvoorbeeld staan dat de noodbuffer van een netwerkapparaat of server een minimale omvang dient te hebben. Zodat bij een normale situatie de loginformatie maximaal 24 uur kan worden opgeslagen voordat er loginformatie verloren gaat.
4.2 Wat wordt verstaan onder ‘Security Monitoring-dienstverlening’?
Security Monitoring-dienstverlening staat voor het bewaken van de ICT-omgeving. Dit gaat van het handmatig analyseren van loginformatie tot en met complete 24x7-alarmdiensten die automatisch in actie komen als iets wordt gedetecteerd wat niet is toegestaan volgens de afgesproken regels (Stallings & Brown, Computer Security - Principles and Practice, 2015).
De bewakingsdiensten kunnen van volledig reactief tot volledig (pro)actief worden ingericht, waarbij de gekozen softwareoplossing van grote invloed is op hoe (pro)actief de bewakingsdienst kan zijn. Hierbij dient te worden opgemerkt dat de nadruk steeds meer komt te liggen op (pro)actieve bewaking van de ICT-omgeving, omdat de impact van een security-incident steeds groter wordt (Trend Micro, 2016). Daarnaast wordt het dreigingsbeeld steeds meer complex (Julian, 2014). Maar ook vanwege de nodige wet- en regelgeving: het National Institute of Standards and Technology (NIST) heeft al de nodige voorwaarden opgesteld aan het verzamelen en opslaan van loginformatie (SANS Institute, 2016).
Voor een volledig reactieve bewakingsdienst is het verzamelen van alle loginformatie in één centraal punt voldoende volgens de opzet van een Security Information Managementsysteem (SIM). Dit centrale punt ontvangt de ruwe loginformatie en verwerkt deze naar het formaat van de oplossing. Bekende SIM-oplossingen zijn onder andere:
• SPLUNK (Splunk Inc, 2017);
• ElasticSearch (Elasticsearch, 2017).
Voor een volledig (pro)actieve bewakingsdienst wordt de ontvangen loginformatie, nadat deze is genormaliseerd door de bewakingsoplossing, direct gecontroleerd door de bewakingsoplossing aan de hand van de in de bewakingsoplossing opgestelde regels. Dit geschiedt volgens de opzet van een SIEM, waarbij de SIM dan een onderdeel vormt van de SIEM-oplossing. Bekende SIEM-oplossingen zijn onder andere:
• IBM QRadar (IBM, IBM QRadar SIEM, z.j.); • HP ArcSight (EntIT Software LLC, 2017); • AlienVault(AlienVault, Inc., 2017); • Sentinel (Micro Focus, 2017).
Richard de Vries (ID: 500.719.935) 13 Afhankelijk van de volgende zaken kan worden gekozen voor een hybride oplossing van SIM en SIEM:
• opzet van het te bewaken netwerk;
• de gekozen inrichtingsfilosofie van de SIEM-omgeving; • wensen en eisen van de te bewaken ICT-omgeving.
Bij een hybride aanpak wordt alle loginformatie opgeslagen in de SIM-omgeving en wordt alleen een beperkte set aan loginformatie doorgezet naar de SIEM-omgeving waar deze tevens ook voor een korte tijd wordt bewaard.
Bij complexe netwerken of netwerken met bijzondere eisen kan voor een hybride inrichtingsfilosofie worden gekozen. Hierbij wordt de loginformatie niet op één centraal punt opgeslagen maar op meerdere decentrale punten die bepaalde taken (loginformatie-normalisatie en -analyse) waarnemen van het centrale punt en alleen een beperkte datastroom sturen/ontvangen naar/van het centrale punt.
Het onderzoeken welke opzet in welke situatie tot het meest optimale resultaat leidt, valt buiten de scope van dit onderzoek, omdat dit onderzoek zich alleen focust op het transporteren van loginformatie.
4.3 Welke netwerkprotocollen bestaan op het gebied van het doorgeven van
loginformatie?
Als AlienVault onderzocht wordt, dan zijn de volgende methodes te onderscheiden die zich bezighouden met het versturen en/of ontvangen van loginformatie over het datanetwerk:
• SYSLOG (RFC 3164/ 5424) – paragraaf 4.3.1; • SNMP (RFC 1157/ 1901/ 3410) – paragraaf 4.3.2; • software agent – paragraaf 4.3.3.
De hierboven benoemde methodes worden in paragraaf 5.1 getoetst op basis van de in paragraaf 4.1 benoemde kwaliteitscriteria.
4.3.1 SYSLOG
Het SYSLOG-protocol is begonnen als standaardonderdeel van het Berkeley Software Distribution-besturingssysteem en is een onderdeel geworden van de TCP/IP-stack (Lonvick, 2001). De doelstelling achter RFC-3164 (IETF Tools Team, 2017) is om de wildgroei aan mogelijkheden van het opslaan van loginformatie te beperken door hiervoor een uniforme methode aan te bieden.
De implementatie van RFC-3164 heeft echter de nodige beperkingen wat betreft het verwerken van de loginformatie opgeleverd. Om deze beperkingen te verhelpen is RFC-3164 als verouderd verklaard en vervangen door RFC-5424 (IETF Tools Team, 2017). Alle moderne SYSLOG-implementaties zijn gebaseerd op RFC-5424.
Als een applicatie op het gebied van verwerken van loginformatie zich conformeert aan deze RFC, dan hoeft alleen binnen de applicatie te worden aangegeven waar de loginformatie naar moet worden toegestuurd. De ontvangende partij zorgt dan voor verdere afhandeling van de loginformatie. Dit levert naast een uniforme verwerking van de loginformatie in veel gevallen prestatieverbetering van de individuele applicatie op, omdat er geen verwerkingscapaciteit voor het verwerken van loginformatie hoeft te worden gebruikt.
Richard de Vries (ID: 500.719.935) 14
4.3.2 SNMP
SNMP staat voor Simple Network Management Protocol en wordt gebruikt om op afstand de status van een apparaat uit te lezen en de configuratie aan te passen, zoals beschreven staat in 1157, 1901 en RFC-3410 (IETF Tools Team, 2017). Tevens kan door middel van het gebruiken van een SNMP-trap het apparaat een melding versturen op het moment dat aan een conditie (gebeurtenis/trap) wordt voldaan.
Afhankelijk van de gekozen configuratie-instellingen op het apparaat/de server kunnen meerdere versies van het SNMP-protocol gelijktijdig actief zijn.
Indien een applicatie zich conformeert aan deze RFC’s, kan de applicatie op afstand worden beheerd en bewaakt. Tevens is het dan mogelijk om naar de bewakingsoplossing notificaties te versturen als gedefinieerde condities zich voordoen.
4.3.3 Software agent
Afhankelijk van het besturingssysteem van het netwerkapparaat of van de server bestaat de mogelijkheid deze op afstand uit te lezen met behulp van een software agent, zodat de loginformatie rechtstreeks in de bewakingsoplossing verwerkt kan worden. Volgens de beschreven scope en afbakening (zie paragraaf 2.4) wordt tijdens de analyse uitgegaan van de software agent (OSSEC) van AlienVault.
4.4 Wat is de impact op het netwerk van loginformatie als wordt gekozen voor het meest
optimale netwerkprotocol voor het transporteren van loginformatie?
In paragraaf 2.2 is beschreven dat de SOC-medewerkers onder meer afhankelijk zijn van de tijdigheid dat een logbericht wordt ontvangen in de omgeving waar de bewakingsoplossing draait. Tijdigheid houdt in dat de tijd tussen het ontstaan en afleveren van de loginformatie zo kort mogelijk moet zijn. Deze tijd wordt beïnvloed door de wijze waarop de loginformatie zich over het netwerk begeeft van het punt waar de loginformatie is ontstaan naar het punt waar de loginformatie wordt verwerkt. Tevens zijn de volgende zaken van invloed:
• de hoeveelheid punten waarover het verkeer heen wordt gerouteerd; • de doorvoersnelheid;
• de keuze van het netwerkprotocol.
Met behulp van een laboratoriumopstelling wordt gekeken hoeveel invloed een configuratie instelling van het netwerkprotocol heeft op het doorsturen van loginformatie. Voor het bepalen van de invloed wordt gekeken naar de volgende twee zaken:
• Het verschil in volume van het netwerkverkeer wanneer van het netwerkprotocol alle beschreven kwaliteitscriteria uit staan en wanneer deze allemaal aan staan.
• Het verschil in ontvangstbetrouwbaarheid van de loginformatie wanneer van het netwerkprotocol alle beschreven kwaliteitscriteria uit staan en wanneer deze allemaal aan staan.
Beide metingen worden uitgevoerd op de server die de loginformatie ontvangt. De tijd die nodig is voor het versturen van de loginformatie wordt niet gemeten, omdat de benodigde tijd kan worden beïnvloed door het netwerk en de presentaties van de bron- en doelserver.
Richard de Vries (ID: 500.719.935) 15
4.5 Wat is de impact op andere gebruikers van loginformatie als wordt gekozen voor het
meest optimale netwerkprotocol voor het transporteren van loginformatie?
Om de impact te kunnen bepalen voor andere gebruikers als gekozen wordt voor het meest optimale netwerkprotocol voor het transporteren van loginformatie, dient deze groep van gebruikers te worden opgesplitst in de volgende vier groepen:
1. Eindgebruikers
De impact voor de groep 1 is verwaarloosbaar. De overgang naar het meest optimale netwerkprotocol voor het transporteren van loginformatie veroorzaakt wel meer dataverkeer op het netwerk, maar dit is veelal in het centrale gedeelte van het netwerk. Veelal zijn hier grotere doorvoersnelheden mogelijk dan een gebruiker normaal gesproken heeft.
2. ICT-beheerders die zich bezighouden met de configuraties van diverse netwerk- en serverapparatuur Voor groep 2 is de impact wat groter, omdat de configuratie complexer wordt en daardoor meer tijd kost. Hierbij moet worden gedacht aan onder meer het aanvragen en inregelen of vervangen van encryptiesleutels.
3. ICT-beheerders die zich bezighouden met het oplossen van problemen van diverse netwerk- en serverapparatuur
Voor groep 3 is de impact nagenoeg verwaarloosbaar. Het enige effect wat ICT-beheerders merken van het gebruik van het meest optimale netwerkprotocol, is dat deze alle loginformatie binnenkrijgen. Dit is zowel positief als negatief voor het oplossen van problemen. Positief omdat ICT-beheerders alle loginformatie binnenkrijgen en daardoor mogelijk de oorzaak van het probleem sneller kunnen traceren. Negatief omdat ICT-beheerders alle loginformatie binnenkrijgen en daardoor meer tijd kwijt zijn bij het zoeken naar de mogelijke oorzaak.
4. ICT-security-medewerkers
Voor groep 4 bestaat geen impact en is het juist een voordeel wanneer wordt gekozen voor het meest optimale netwerkprotocol voor het transporteren van loginformatie. Door het toenemen van de betrouwbaarheid van aanlevering van loginformatie kan de ICT-veiligheid toenemen doordat de loginformatie sneller en vollediger beschikbaar is.
4.6 Wat doen andere partijen welke een soortgelijk probleem kennen?
Zoals in paragraaf 1.1 is beschreven, is dit onderzoek niet specifiek voor SLTN. Elke organisatie die loginformatie centraal verzamelt, is voor de juiste conclusies van elke onderzoek afhankelijk van hoe betrouwbaar het transport van loginformatie van de decentrale naar de centrale locatie is.
Om hierin meer inzicht te verkrijgen is een kleinschalige online-enquête verspreid binnen het LinkedIn-netwerk van de onderzoeker. In verband met de gevoeligheid van dit onderwerp is de enquête volledig anoniem opgezet en is niet gevraagd naar herleidbare gegevens zoals e-mailadres en/of bedrijfsnaam. Hiervoor is gekozen om de kans op het invullen van de enquête zo groot mogelijk te maken.
Richard de Vries (ID: 500.719.935) 16 Het enquêteformulier is opgenomen in deze rapportage als bijlage C. In paragraaf 5.3 worden de ontvangen antwoorden op de enquête geanalyseerd en beschreven. De ruwe data van de online-enquête websitetool zijn opgenomen in bijlage D.
Richard de Vries (ID: 500.719.935) 17
5 Analyse
In dit hoofdstuk zijn de resultaten uitgewerkt van de beschreven onderzoeken van hoofdstuk 4. Voordat de impact van de diverse configuratieopties in een laboratoriumopstelling in de praktijk kan worden getest (zie paragraaf 5.2), wordt aan de hand van het literatuuronderzoek bepaald welke configuratieopties elk netwerkprotocol heeft (zie paragraaf 5.1). Daarnaast worden de resultaten van de online-enquête in paragraaf 5.3 weergegeven.
5.1 Wat is de kwaliteit van een netwerkprotocol?
In paragraaf staat beschreven welke netwerkprotocollen ondersteund worden door AlienVault (zie paragraaf 4.3). Deze netwerkprotocollen worden tegen de benoemde criteria (zie paragraaf 4.1) aangehouden, zodat per netwerkprotocol bepaald kan worden welke theoretische score deze heeft (zie subparagraaf 5.1.6). Op basis van deze scores wordt bepaald welke netwerkprotocollen in de praktijk getest zullen worden op werking en impact (zie paragraaf 5.2).
5.1.1 SYSLOG
Indien de configuratie van de SYSLOG-software van het netwerkapparaat of van de server de RFC-5425 (Miao, Ma, & Salowey, 2009) volledig en correct heeft geïmplementeerd, dan wordt voldaan aan de volgende criteria:
• Criterium 1 – Hiervoor dient de cliënt zich te identificeren met een certificaat. • Criterium 2 – Hiervoor dient de server zich te identificeren met een certificaat.
• Criterium 3 – Hiervoor dient de server alleen connecties te accepteren vanaf een cliënt die is voorzien van encryptie.
• Criterium 5 – Hierbij is het opzetten van een connectie die is voorzien van encryptie op basis van het TLS-protocol is het TCP-protocol verplicht.
Indien de configuratie van de SYSLOG-software van het netwerkapparaat of van de server de RFC-5848 (Kelsey, Callas, & Clemm, 2010) volledig en correct heeft geïmplementeerd, dan wordt voldaan aan het volgende criterium:
• Criterium 4 – Aan elk logbericht wordt door het SYSLOG-protocol automatisch een SYSLOG-SIGN toegevoegd waarmee kan worden ontdekt of het bericht onderweg is aangepast.
Indien de configuratie van de SYSLOG-software van het netwerkapparaat of van de server de RFC-6587 (Gerhards & Lonvick, 2012) volledig en correct heeft geïmplementeerd, dan wordt voldaan aan het volgende criterium:
• Criterium 5 – Indien moet worden gecontroleerd of de loginformatie daadwerkelijk aankomt, dan dient deze te worden verstuurd over het TCP-protocol.
Richard de Vries (ID: 500.719.935) 18 Als uitbreiding op, maar geen onderdeel van RFC-6587, is het SYSLOG-protocol voorzien van een feature die regelt dat loginformatieberichten tijdelijk lokaal worden opgeslagen als het doeladres tijdelijk onbereikbaar is (Gerhards, RELP - The Reliable Event Logging Protocol, 2008):
• Criterium 6 – Het device biedt de functionaliteit aan voor tijdelijke lokale opslag voor het geval dat problemen optreden tijdens de transmissie van de loginformatie.
Een opmerking hierbij is dat voor criterium 6 van belang is om binnen de gehele ICT-omgeving dezelfde implementatie van de SYSLOG-software wordt gebruikt. De implementatie van RFC-6587 in RSYSLOG noemt deze functionaliteit RELP, terwijl in de SYSLOG-NG implementatie de functionaliteit RLTP noemt (Balabit, 2017). Technisch is het niet mogelijk een RELP-client te laten communiceren met een RLTP-server. Hiermee dient bij de implementatie rekening te worden gehouden.
AlienVault is gebaseerd op basis van Debian en maakt standaard gebruik van RSYSLOG, terwijl andere netwerkapparaten of servers gebruik kunnen maken van SYSLOG-NG. Hierdoor kunnen deze apparaten of servers geen gebruikmaken van de SYSLOG-RELP-functionaliteit waardoor de afleverbetrouwbaarheid van deze apparaten of servers lager wordt.
5.1.2 SNMP v1
Het SNMP-netwerkprotocol is ontwikkeld als antwoord op een grote storing in het ARPA-netwerk (Rosen, Beranek, & Newman Inc., 1981). Ten tijde van deze storing was geen monitoringsoplossing voorhanden en daarom is RFC-1067 geschreven (Case, Fedor, Schoffstall, & Davin, 1988). Aangezien in 1988 IT-security nog geen rol van betekenis had, zijn geen securityfeatures in deze versie gedefinieerd en dus geïmplementeerd. Dit protocol werkt alleen op basis van UDP. Hierdoor wordt aan geen enkel criterium voldaan.
5.1.3 SNMP v2
SNMP v2 is geen uitbreiding op maar een aanpassing van het SNMP v1-protocol. Het verschil tussen v1 en v2 is onder meer dat de ondersteuning van 64-bits integers is toegevoegd, zodat grotere getallen kunnen worden ondersteund (Francis, 2012). Dit komt overeen met RFC-1902 (Case, McCloghrie, Rose, & Waldbusser, 1996). Er zijn echter geen toevoegingen op het gebied van security doorgevoerd in deze versie. De uitkomsten van het onderzoek zijn hierdoor gelijk gesteld aan de uitkomsten van SNMP v1.
5.1.4 SNMP v3
SNMP v3 is een security-uitbreiding op het SNMP v2-protocol (Francis, 2012). Hierdoor kan het protocol gebruikt blijven worden in omgevingen die security-eisen stellen aan netwerkprotocollen.
Indien de SNMP-configuratie is geconfigureerd volgens RFC-3430 (Schoenwaelder, 2002), dan kan worden voldaan aan het volgende criterium:
• Criterium 5 – Het opzetten van een connectie op basis van het TCP-protocol.
Indien de SNMP-configuratie is geconfigureerd volgens RFC-3414 (Blumenthal & Wijnen, 2002), dan kan worden voldaan aan het volgende criterium:
• Criterium 4 – In het User-based Security Model van SNMP v3 bevindt zich onder meer een onderdeel dat de integriteit van het bericht bewaakt.
Richard de Vries (ID: 500.719.935) 19 Indien de SNMP-configuratie is geconfigureerd volgens RFC-5953 (Hardaker, 2010), dan kan worden voldaan aan de volgende criteria:
• Criterium 1 – Door het gebruik van een cliëntcertificaat, dat is uitgegeven door een gemeenschappelijk vertrouwde certificaatuitgever, wordt voldaan aan dit criterium.
• Criterium 2 – Door het gebruik van een servercertificaat, dat is uitgegeven door een gemeenschappelijk vertrouwde certificaatuitgever, wordt voldaan aan dit criterium.
• Criterium 3 – Hiervoor dient de server alleen connecties te accepteren die zijn voorzien van encryptie. • Criterium 5 – Hierbij is het opzetten van een connectie, die is voorzien van encryptie is het
TCP-protocol, verplicht.
Aan criterium 6 wordt niet voldaan. Het doeladres van de SNMP-configuratie moet daarom altijd bereikbaar blijven. Het kan dus voorkomen dat gedurende een ICT-verstoring berichten verloren gaan.
5.1.5 Software agent
AlienVault maakt gebruik van OSSEC-software (OSSEC Project Team, 2010-2017) ten behoeve van het ophalen van loginformatie bij cliënten (servers of werkstations) die deze software ondersteunen. Daarnaast biedt deze software andere mogelijkheden zoals het bewaken van de cliënt zelf.
Doordat elke host apart moet worden toegevoegd aan de AlienVault-omgeving, krijgt elke host zijn eigen sleutel. Hierdoor kan worden voldaan aan de volgende criteria:
• Criterium 1 – Doordat de cliënt via een speciale procedure wordt toegevoegd aan de AlienVault-serveromgeving ten behoeve van het uitwisselen van loginformatie, wordt voldaan aan dit criterium. • Criterium 2 – Doordat de cliënt via een speciale procedure wordt toegevoegd aan de
AlienVault-serveromgeving ten behoeve van het uitwisselen loginformatie, wordt voldaan aan dit criterium. • Criterium 3 – Doordat de cliënt via een speciale procedure wordt toegevoegd aan de
AlienVault-serveromgeving ten behoeve van het uitwisselen loginformatie, wordt voldaan aan dit criterium. Doordat de software agent ook de integriteit van het bestandssysteem van de cliënt bewaakt en omdat wordt gebruikgemaakt van een eigen encryptieprotocol, kan worden voldaan aan het volgende criterium:
• Criterium 4 – Door de combinatie van een eigen encryptieprotocol en bewaking van het bestandssysteem kan worden voldaan aan dit criterium.
Met behulp van de veilige modus van de software agent kan worden voldaan aan de volgende criteria: • Criterium 5 – Voordat loginformatie kan worden uitgewisseld met de server, dient eerst te worden
gecontroleerd of de server beschikbaar is. Dit gebeurt met behulp van het TCP-protocol. Hierdoor kan worden voldaan aan dit criterium.
• Criterium 6 – Doordat de software agent een point bijhoudt van welke loginformatie wel/niet is doorgestuurd naar de server, kan worden voldaan aan dit criterium.
Richard de Vries (ID: 500.719.935) 20
5.1.6 Samenvatting
Tabel 1 geeft schematisch de resultaten van het onderzoek van de theoretische mogelijkheden van een netwerkprotocol weer.
Tabel 1: Onderzoeksresultaten diverse netwerkprotocollen op basis van theoretisch onderzoek
Nr. Criterium SY SLO G SN M P v 1 SN M P v 2 SN M P v 3 So ftw ar e Ag en t
1 Kan worden gegarandeerd dat de afzender ook de
echte afzender van de loginformatie is? √ X X √ √
2 Kan worden gegarandeerd dat de ontvanger ook de
echte ontvanger van de loginformatie is? √ X X √ √
3 Kan worden gegarandeerd dat gedurende de
transmissie van de loginformatie deze niet kan worden
uitgelezen door een onbevoegde partij? √ X X √ √
4 Kan worden gegarandeerd dat de loginformatie
onderweg niet is aangepast? √ X X √ √
5 Kan worden gegarandeerd dat alle loginformatie
daadwerkelijk aankomt bij de ontvanger? √ X X √ √
6 Kan worden gegarandeerd dat alle loginformatie daadwerkelijk alsnog aankomt bij de ontvanger als de bestemming tijdelijk onbereikbaar is geweest als gevolg van een verstoring?
√ X X X √
Totaal aantal punten 99 0 0 83½ 99
Toelichting symbolen: √ = criterium behaald; X = criterium niet behaald.
De volgende netwerkprotocollen dienen als input voor de praktijktest: • SYSLOG;
• SNMPv3; • software agent.
Richard de Vries (ID: 500.719.935) 21
5.2 Wat is de impact op het netwerk als wordt gekozen voor een betrouwbare transmissie
van loginformatie?
De in paragraaf 5.1 beschreven resultaten van het theoretische onderzoek, worden in deze paragraaf in de praktijk getest. Met behulp van een laboratoriumopstelling wordt elk netwerkprotocol en de daarbij behorende configuratieopties getest. De opzet van de laboratoriumopstelling staat beschreven in subparagraaf 5.2.1. De resultaten zijn vermeld vanaf subparagraaf 5.2.2. De wijze waarop is getest, wordt bij het netwerkprotocol zelf vermeld.
Per netwerkprotocol wordt steeds gekeken naar de volgende punten om de impact op het netwerk te kunnen bepalen:
• verschil in dataverkeer tussen UDP en TCP;
• verschil in dataverkeer tussen UDP en betrouwbaar TCP;
• verschil in dataverkeer tussen UDP en betrouwbaar TCP met encryptie;
• verschil in dataverkeer tussen UDP en betrouwbaar TCP met encryptie en ondertekening.
5.2.1 Laboratoriumopstelling
De laboratoriumopstelling bestaat uit een Fujitsu E782 (500GB HDD, 16GB RAM, Intel i7) die is voorzien van een Ubuntu Desktop 17.04 en een VirtualBox 5.2. Deze computer heet UBUNTUHOST die fungeert als host machine waarop alle benodigde virtuele servers draaien. Alle virtuele servers zijn, tenzij anders vermeld, op basis van de volgende specificaties opgebouwd:
• Debian 8 inclusief RSYSLOG, Wondershaper; • 2x CPU;
• 4GB RAM; • 40GB HDD; • 1x netwerkkaart.
De volgende virtuele servers worden gebouwd:
• SENDER – vanaf deze server worden alle test-loginformatieberichten verstuurd; • RECEIVER – op deze server worden alle test-loginformatieberichten ontvangen.
De netwerkkaart van de virtuele server draait in bridge met de netwerkkaart van de host, waardoor beide zich in hetzelfde netwerk bevinden. Voor het beperken van de bandbreedte wordt gebruikgemaakt van het programma WonderShaper (SPI Inc., 2017). Door het commando ‘wondershaper eth0 64 64’ uit te voeren op de server RECEIVER is de bandbreedte beperkt tot 64KBps, zowel voor het ontvangen als voor het versturen van data. De server SENDER kent geen snelheidsbeperking.
Voor het testen van de software agent is tevens een AlienVault server (naam: MONITOR) gebouwd op basis van de volgende specificaties:
• AlienVault OSSIM v5.4; • 2x CPU;
• 8GB RAM; • 100GB HDD; • 1x Netwerkkaart.
Richard de Vries (ID: 500.719.935) 22 Schematisch ziet het netwerk van de laboratoriumopstelling er als volgt uit (zie Figuur 4):
Figuur 4: Laboratoriumopstelling
De host UBUNTUHOST heeft een dynamisch IP-adres.
5.2.2 SYSLOG
In Tabel 2 is te lezen hoeveel dataverkeer het logbericht ‘Sep 10 10:55:34 sender sshd[1666]: Accepted password for richard from 127.0.0.1 port 55171 ssh2’, dat 95 tekens groot is, genereert in de verschillende opstellingen. Het logbericht is gegenereerd op de virtuele server SENDER door een SSH-sessie naar zichzelf op te zetten. Hierbij is gekeken naar het totaal aantal verstuurde en ontvangen bytes door de RECEVER en het aantal benodigde netwerkpakketten (frames) om de informatie te versturen. De metingen zijn gedaan op de RECEIVER-server.
Tabel 2: Overzicht dataverkeer van één logbericht
Bericht verstuurt via Aantal Bytes Afwijking % Aantal frames
UDP 141 - 1
TCP 232 +64% 2
Betrouwbaar TCP 345 +244% 3
Betrouwbaar TCP met encryptie 403 +285% 3
Betrouwbaar TCP met encryptie en ondertekening Niet ondersteund Niet ondersteund Niet ondersteund
Om te kunnen controleren of alle logberichten aankomen en in welke volgorde dit is gebeurd, is het volgende logbericht gebruikt: ‘Test-<protocol> <nummer>’. Het nummer is een oplopend getal van 1 tot 100.000. Deze logberichten worden automatisch gegenereerd met behulp van een script (zie Figuur 5). Dit script wordt gestart vanaf de server SENDER.
Richard de Vries (ID: 500.719.935) 23 #!/bin/bash
logger ’UDP - start’ for i in {1..100000} do
logger ’Test-UDP $i’ done
logger ’UDP - end’ Figuur 5: Testscript
De SYSLOG-configuratie van de server SENDER staat ingesteld volgens Figuur 6 en de SYSLOG-configuratie van de server RECEIVER staat ingesteld volgens Figuur 7.
$ModLoad imuxsock $ModLoad imklog
# provides UDP reception $ModLoad imudp
$UDPServerRun 514 # Log Files
*. * /var/log/SYSLOG
Figuur 6: SYSLOG-configuratie SENDER
$ModLoad imuxsock $ModLoad imklog
# provides UDP reception $ModLoad imudp
$UDPServerRun 514 # provides TCP reception $ModLoad imtcp
$TCPServerRun 10514
# provides TCP-RELP reception $ModLoad imrelp
$InputRELPServerRun 20514
# provides TCP-RELP-TLS reception $ModLoad imrelp
Input(type=”imrelp” port=”20515” tls=”on” tls.caCert=”/root/ca.pem” tls.myCert=”/root/tlsserver.pem” tls.myPrivKey=”/root/tlsserver-key.pem” tls.authMode=”name” tls.permittedpeer=[”sender.security.local”, ”sender”] ) # Log Files *.* /var/log/SYSLOG
Richard de Vries (ID: 500.719.935) 24 De SYSLOG-software stuurt deze logberichten automatisch: dit is ingesteld volgens Figuur 8. Afhankelijk van de test wordt de benodigde configuratie voor het doorsturen in- of uitgeschakeld door het plaatsen of weghalen van een hekje. Op basis van Figuur 8 wordt elk logbericht doorgestuurd naar elk ingesteld doel (UDP, TCP, TCP-RELP, TCP-RELP-SSL, TCP-RELP-SSL-SIGN).
module(load=”omrelp”) # UDP forwarding *.* @192.168.2.160 # TCP forwarding *.* @@192.168.2.160:10514 # TCP-RELP forwarding
action(type=”omrelp” target=”192.168.2.160” port=”20514” tls=”off”) # TCP-RELP-SSL forwarding
action(type=”omrelp” target=”192.168.2.160” port=”20515” tls.caCert=”/root/ca.pem” tls.myCert=”/root/tlsclient-cert.pem” tls.myPrivKey=”/root/tlsclient-key.pem” tls.authmode=”name” tls.permittedpeer=[”receiver.security.local”, ”receiver”]) Figuur 8: SYSLOG-forwarding-configuratie
Voor het testen van SYSLOG-encryptie op basis van certificaatuitwisseling is gebruikgemaakt van zelf ondertekende certificaten. Deze zijn aangemaakt op de server RECEIVER met behulp van de commando’s zoals vermeld in Figuur 9. De SENDER-certificaten zijn vervolgens gekopieerd naar deze server, inclusief het publieke certificaat van de uitgever (CA.PEM).
Certificaat uitgever
• certtool --generate-privkey --outfile ca-key.pem
• certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem Sender certicaat
• certtool --generate-privkey --outfile tlsclient-key.pem --bits 2048
• certtool --generate-request --load-privkey tlskey.pem --outfile client-request.pem
• certtool --generate-certificate --load-request client-request.pem --outfile tlsclient-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem Receiver certificaat
• certtool --generate-privkey --outfile tlsserver-key.pem --bits 2048
• certtool --generate-request --load-privkey tlskey.pem --outfile server-request.pem
• certtool --generate-certificate --load-request server-request.pem --outfile tlsserver-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem Figuur 9: Gebruikte commando’s ten behoeve van het maken van de SSL-certificaten
Ondanks de theoretische ondersteuning van het digitaal ondertekenen van SYSLOG berichten (RFC–5848), bleek deze in de praktijk niet te werken. Dit heeft te maken hebben met dat de softwarelijsten van AlienVault niet dezelfde softwarelijsten van Debian, ondanks dat AlienVault op basis van Debian is gebouwd. Dit is zeer waarschijnlijk het gevolg van dat AlienVault alleen ondersteunde software in deze softwarelijsten wil hebben om ervoor te zorgen dat het product stabiel blijft.
Richard de Vries (ID: 500.719.935) 25 Voor deze test is de beschikbare netwerkbandbreedte op de RECEIVER gereduceerd naar 64Kb/s, zodat eventuele problemen duidelijk naar voren komen. De test is herhaald voor elk ingesteld doel (UDP, TCP, TCP-RELP, TCP-RELP-SSL, TCP-RELP-SSL-SIGN).
Als optimaal testresultaat worden de logberichten in oplopende volgorde vanaf nummer 1 ontvangen. Afwijkingen van het optimale testresultaat moeten de door de ontvangende partij worden gecompenseerd, bijvoorbeeld door van de aanleverende partij te verlangen dat het logbericht ook een datum-/tijdveld bevat. Tabel 3: Testresultaten Gebruikte protocol Verstuurde berichten Ontvangen berichten Gemiddelde bandbreedte Ontvangen/ Verstuurd Logische volgorde UDP 100.000 22.456 45KB/s, 0KB/s Nee TCP 100.000 100.000 35KB/s, 1KB/s Nee TCP+RELP 100.000 100.000 25KB/s, 3KB/s Nee TCP+RELP+TLS 100.000 100.000 15KB/s, 3KB/s Nee TCP+RELP+TLS+SIGN Niet ondersteund Niet ondersteund Niet ondersteund Niet ondersteund Uit Tabel 3 is het af te lezen:
• hoeveel berichten zijn verstuurd; • hoeveel berichten zijn aangekomen;
• hoeveel netwerkbandbreedte gemiddeld is gebruikt;
• of de berichten in een logische volgorde (oplopend vanaf 1 naar 100.000) zijn aangekomen.
Verder onderzoek naar waarom de berichten niet in de optimale volgorde zijn aangekomen, heeft uitgewezen dat dit te maken heeft met de wijze waarop het TCP/IP (RFC-791/ 793/ 768 (IETF Tools Team, 2017)) protocol werkt.
Bij het testen van het TCP-protocol is diverse keren een TCP-reset waargenomen waardoor de connectie opnieuw is opgebouwd. Tijdens de TCP-reset zijn de berichten die niet of niet goed zijn verzonden opnieuw in de verzendqueue geplaatst. Deze verzendqueue werkt op basis van het FIFO-principe waardoor andere berichten met een hoger nummer eerder worden verzonden.
Het UDP-protocol controleert niet of het bericht daadwerkelijk is aangekomen maar wil het bericht zo snel mogelijk verzenden. Wanneer ten tijde van het verzenden van de loginformatie geen connectie (poort) naar het doeladres mogelijk is, dan wordt niet nogmaals geprobeerd om het bericht te verzenden.
Richard de Vries (ID: 500.719.935) 26 Figuur 10: Overzicht ontvangen loginformatie met behulp van UDP
Richard de Vries (ID: 500.719.935) 27 Figuur 12: Overzicht ontvangen loginformatie met behulp van TCP-RELP
Figuur 13: Overzicht ontvangen loginformatie met behulp van TCP-RELP-SSL
Figuur 10, Figuur 11, Figuur 12 en Figuur 13 laten per bestand zien hoeveel regels zijn ontvangen en of de regels in de optimale volgorde zijn ontvangen. Daar waar de regel is gearceerd, is een afwijking in de optimale ontvangst waargenomen.
Richard de Vries (ID: 500.719.935) 28
Figuur 14: Netwerkbelasting UDP-test
Figuur 15: Netwerkbelasting TCP-test
Figuur 16: Netwerkbelasting TCP-RELP-test
Figuur 17: Netwerkbelasting TCP-RELP-SSL-test
Figuur 14, Figuur 15, Figuur 16 en Figuur 17 geven de netwerkbelasting gedurende de test weer. Hierbij valt op dat de belasting van het UDP-protocol vrij constant is, terwijl de overige netwerkprotocollen meer fluctueren wat betreft de hoeveelheid netwerkverkeer die wordt geproduceerd. Daarnaast is het opvallend dat bij het gebruik van de SYSLOG-configuraties op basis van de netwerkprotocollen RELP en SSL ook dataverkeer van de ontvangende host (RECEIVER) naar de versturende host (SENDER) wordt gestuurd. Gedurende het opzetten van de diverse testen is geconstateerd dat alle logberichten die worden gegenereerd vanaf het moment van het starten van de server SENDER tot het moment dat de netwerkkaart van deze server online is gekomen, niet worden ontvangen worden op de server RECEIVER bij het doorsturen op basis van het UDP-protocol. De logberichten komen wel aan bij gebruikmaken van het TCP-protocol.
Richard de Vries (ID: 500.719.935) 29
5.2.3 Software agent
Voor het testen van de software agent is gebruik gemaakt van AlienVault v5.4. In AlienVault is een agent geconfigureerd die tijdens het testen gebruikt zal worden. De benodigde client (Software agent) is geïnstalleerd op UBUNTUHOST. Daar de installatie bestanden van de software agent niet van AlienVault zelf, maar van OSSEC vandaan komen, is het afwijkende besturingssysteem (UBUNTU) geen effect op de resultaten van dit onderzoek.
Deze client is ingesteld volgens Figuur 18. De op de server (MONITOR) gegenereerde sleutel is via het commando ‘/var/ossec/bin/manage_agent’ toegevoegd aan de cliënt-configuratie. Voor de server zelf is geen speciale configuratie toegepast. Dit wordt door AlienVault zelf geregeld.
<client>
<server>192.168.2.150</server> </client>
Figuur 18: OSSEC.CONF (cliënt)
Bij het bepalen van de impact van de diverse configuratie-instellingen van de software agent is gebleken dat niet alle beschreven configuratie-instellingen werken. Nadere analyse heeft uitgewezen dat tijdens het onderzoek de gebruikte versie van AlienVault (v5.4) niet de meest recente versie (v2.9) van de OSSEC-software bevatte. In plaats daarvan wordt binnen AlienVault v5.4 OSSEC-serverversie 2.8.1 gebruikt.
Figuur 19: Overzicht afgevangen dataverkeer van/naar AlienVault
Aan criterium 5 en 6 wordt niet voldaan, omdat de OSSEC-software alleen op basis van het UDP-protocol blijkt te werken. Het TCP-protocol wordt nagebootst door met een nog niet waargenomen regelmaat een of meerdere datapakketten terug te sturen naar de originele verzender, zoals te zien is in Figuur 19. Ook dit gebeurt op basis van het UDP-protocol.
