Sammeln von Logdaten

Logging

Während der poten­tielle Kunde Daten in die Felder der Web­ap­pli­kation eingibt, der Einkauf eine Mail an einen Dienst­leister schickt und ein Angreifer nach Schwach­stellen in der Ver­tei­digung des eigenen Netz­werks sucht, werden im Hin­ter­grund Daten über all diese Ereig­nisse erhoben und als Logs für einen bestimmten Zeitraum auf­be­wahrt. Dieser Zeitraum richtet sich nach der Art der Daten, die gesammelt werden, aber darum soll es nicht gehen.

Auf Netz­wer­kebene sammeln Router, Fire­walls, Security-Appli­­ances, Load­ba­lancer und weitere Geräte Daten. Auf Appli­ka­ti­ons­ebene pro­to­kol­lieren Web­server, Appli­kation, weitere Security-Vor­­rich­­tungen und Systeme und schreiben Daten­sätze in das Log­system. Je nach Größe der Firma, und je nachdem wie geschwätzig die ver­schie­denen Logs ein­ge­stellt wurden, kommen pro Sekunde, Minute oder viel­leicht Tagen einige hun­dert­tausend Log­da­ten­sätze zusammen und füllen die betei­ligten Festplatten.

Was aber pas­siert jetzt nor­ma­ler­weise damit? In vielen Unter­nehmen wird das Potential dieser Daten nur wenig genutzt. Log­daten werden haupt­sächlich her­an­ge­zogen, um im Falle eines Pro­blems oder Security-Inci­­dents die Ursachen zu ergründen und Feh­ler­analyse oder foren­sische Betrach­tungen zu betreiben. Aus Aspekten der Sicherheit kann man aber noch sehr viel mehr aus den gewon­nenen Daten lesen.

Aller­dings nicht manuell; selbst ein enthu­si­as­ti­scher Analyst wird nach wenigen Tagen auf­geben, in Daten­vo­lumen von Mil­lionen Ein­trägen etwas zu finden, was merk­würdig ist. Zum einen muss man hierfür ein gutes Ver­ständnis dafür haben, was normal ist und was nicht, und zum anderen ist das eine Tätigkeit, die schnell ermüdend wirkt. Man kann über zwei Wege an dieses Problem her­an­treten: ent­weder man filtert alle Ein­träge aus, die nicht inter­essant oder relevant für Sicherheit sind, oder man erstellt Alarme, die bei Ver­kettung bestimmter Umstände aus­gelöst werden.

Die erste Alter­native, das Filtern unnö­tiger Ein­träge, erweist sich fast immer als nicht machbar. Es ist schwer zu erkennen, welche Ein­träge in der Zukunft bei einem Secu­ri­ty­problem relevant sind oder nicht. Die Kol­le­ginnen und Kol­legen vom Helpdesk brauchen außerdem ganz andere Log­in­for­ma­tionen als das Security-Team. Bei einer foren­si­schen Nach­be­trachtung hat man am Liebsten so viele Daten wie möglich. Die zweite Methode, das Alar­mieren beim Auf­treten (oder Weg­fallen) bestimmter Log­ein­träge, macht für die Security sehr viel mehr Sinn.

Ein Lieb­lings­bei­spiel vieler Her­steller oder Dienst­leister in dem Bereich ist der Login von Europa und Asien zur gleichen Zeit. Viel­leicht ist im Log unbe­denklich, wenn ein Mit­ar­beiter sich meist von Europa, aber manchmal auch aus Asien oder einem anderen Kon­tinent anmeldet, weil er oder sie nun mal auch reist. Wie sieht es aber aus, wenn diese Person sich um acht Uhr in Europa anmeldet, und kurz nach acht aus, sagen wir, Sin­gapur? Für viele Sicher­heits­teams wäre das schon eine inter­es­sante Infor­mation, und man könnte den betrof­fenen Mit­ar­beiter mal anrufen und fragen, was Sache ist und ob die zweite Anmeldung tat­sächlich von ihm oder ihr durch­ge­führt wurde.

Alarme sind aber auch nur dann sinnvoll, wenn sie eine Aktion ermög­lichen. Sonst wird der Security-Analyst eben mit Alarmen als mit Logs über­flutet — auch nicht Sinn der Sache. Man sollte sich also Gedanken machen, was man prüfen möchte und was ein Mensch anschauen sollte, bevor man neue Alarme gene­riert. Diese Rah­men­be­din­gungen sind häufig sehr fir­men­spe­zi­fisch, aber es gibt durchaus ein paar gene­rische Dinge, die man prüfen kann; schreibt ein Server z.B. wesentlich mehr Daten als normal, oder wesentlich weniger? Bauen Web­server selb­ständig eine Ver­bindung ins Internet auf, obwohl sie eigentlich nur auf Ver­bin­dungs­an­fragen ant­worten sollten? Schicken andere Server als ihre desi­gnierten Mail­server Mails ins Internet?

Diese und viele mehr Sze­narien kann man in Use Cases abbilden, und vor allem diese den Ana­lysten zur Bear­beitung wei­ter­geben. Natürlich kann man auch noch wei­ter­gehen und mit Hilfe von Machine Learning model­lieren, was in den Log­files “normal” ist, was nicht, und ab welcher Abwei­chung man etwas alar­mieren sollte; aber das ist dann defi­nitiv schon fortgeschritten.