WHAHAA, wie ooit naar de logs van Cisco heeft gekeken snapt wel waarom er problemen zijn met logging, wat een chaos heeft Cisco van zijn logs gemaakt.

Dit rapport gaat niet over Cisco oplossingen of logs. Het beschrijft bevindingen van (Cisco) Talos die allerlei organisaties by cyberdefense ondersteunen. Een van de punten die ze vaststellen is dat veel bedrijven (te) weinig logs bewaren.

Meestal staat er default wel wat mee te pruttelen. Alleen heb je daar weinig aan als er ellende komt. De helft is al dagen overschreven, de andere helft is nutteloos. Goede logging begint met beleid en ontwerp: wat, waarom, wanneer, hoe lang, waar etc. En dat dan ook nog op een manier dat het veilig staat en er goed over te rapporteren is. Heb je meteen ook een mooie bak met data waar je SIEM op los kan.

Sterker nog, wanneer ik ransomware zou uitrollen, zou ik beginnen bij de logs. Die wissen of encrypten zorgt ervoor dat ik mijn sporen als eerste verhul. Lukt het de aangevallene om tijdig in te grijpen, dan is waarschijnlijk toch de logging al onbruikbaar en kan niet worden gebruikt om anderen te beschermen.

Vroeger bewaarden we ALLES. Maar ja dat mag niet meer he? AVG en bewaartermijnen.
Die wetten maken meer kapot dan je lief is!

Eerdere poster had wel een punt. Cisco logs zijn dramatisch van kwaliteit

Misschien moet je eens beginnen met zorgen dat je de AVG begrijpt. Ten eerste is verlies van persoonsgegevens (bijvoorbeeld omdat ze versleuteld zijn) een datalek. Dat moet je dus voorkomen. Ten tweede is een van de grondslagen voor verwerking van persoonsgegevens gerechtvaardigd belang. Persoonsgegevens in logs verwerken om aan de AVG te kunnen voldoen is echt wel een gerechtvaardigd belang.

Het punt is wel dat je van tevoren goed moet nadenken over wat je nodig hebt, dat goed moet beschrijven, inclusief de verantwoording ervoor, het vervolgens goed moet inrichten en (ook de logs) beveiligen, en logs weer moet verwijderen als ze geen doel meer hebben. Over wanneer dat is moet je dus goed hebben nagedacht. Dat gaf degene op wie je reageerde allemaal al aan, trouwens: het begint met beleid en ontwerp.

Veel bedrijven hebben inderdaad geen goede log management omgeving. Dat komt vaak omdat men niet weet wat je ermee moet doen omdat men het nog niet echt nodig heeft gehad. En daarmee is er een analogie met backups: die maak je alleen maar, om ze in geval van dataverlies terug te zetten. En dat betekent dat je van te voren moet nadenken wat je wilt kunnen restoren. En dat komt erop neer dat je de backup scheidt van het systeem waar de backup vandaan komt.
Hetzelfde met logs: die heb je pas nodig als er een probleem is. Je wilt dan
a) dat je erbij kan , dus dat de logs op een apart systeem staan
b) dat de juiste dingen gelogd worden, dus alle relevante logs, niet gefiltert omdat je normaal alleen maar naar specifieke zaken zoekt
c) dat er voldoende logs zijn, dus meer dan een paar dagen
d) dat de logs niet aangepast kunnen worden

Dus een voldoende grote selectie van log elementen, van alle relevante systemen, op een apart log management systeem, met voldoende opslag om bv. 3 maanden op te slaan, en met bv. hashes zodat je kan aantonen dat de logs niet aangepast (delen toegevoegd of verwijderd) zijn.

Oh, en voordat iemand roept: dat doet mijn SIEM allemaal... De meeste SIEMs betaal je op basis van EPS (Events Per Second). Alles doorsturen naar je SIEM, terwijl je geen use cases hebt die er wat mee doen, zorgt voor een extreem duur log management systeem. Een SIEM gebruik je om specifieke zaken te beschermen en specifieke aanvallen te detecteren. Het is geen wonder machine die vanzelf betekenis aan chaos geeft (1). Daarom vereist het invoeren van een SIEM, als je er werkelijk voordeel uit wilt halen, een kostbare en langdurige tuning fase.

Q

1) voorbeelden incorrecte interpretaties correlatie https://www.buzzfeednews.com/article/kjh2110/the-10-most-bizarre-correlations