Arbeiten Sie intelligenter - nicht härter: Nutzen Sie interne Honeynets, um Bösewichte zu erkennen
Protokollerfassung, SIEM und Sicherheitsüberwachung sind der Weg, nicht das Ziel. Leider ist das Ziel oft falsch positiv. Das liegt daran, dass wir sehr gut darin geworden sind, Protokolle und andere Informationen aus Produktionssystemen zu sammeln, diese Daten dann zu filtern und auf einem Dashboard darzustellen. Aber wir sind noch nicht so gut darin, Ereignisse, die von Bösewichten ausgelöst werden, von solchen zu unterscheiden, die durch normale Alltagsaktivitäten ausgelöst werden.
Ein Honeynet ändert das völlig.
Auf die Gefahr hin, eine schlechte Analogie aufrechtzuerhalten, beziehe ich mich auf das Signal-Rausch-Verhältnis, das oft in den Raum geworfen wird, wenn es um Sicherheitsüberwachung geht. Wenn Ihnen dieses Lärm-/Signalkonzept gefällt, dann ist der Unterschied so, als würde man zur Hauptverkehrszeit eine Eieruhr mitten auf den Times Square stellen. Der Versuch, es zu hören, ist so, als würde man versuchen, in Protokollen, die von Produktionssystemen gesammelt werden, die Aktivitäten von Bösewichten herauszufinden. Stellen Sie die Eieruhr nun in einen ruhigen Raum. Das ist das Geräusch eines Bösewichts, der ein internes Honeynet angreift.
Honeynets in Ihrem internen Netzwerk sind normalerweise sehr leise. Die einzigen legitimen Dinge, die sie treffen werden, sind Dinge wie Schwachstellenscanner, Netzwerk-Mapping-Tools und ... was sonst? Was sonst noch in Ihrem Netzwerk geht regelmäßig aus und berührt IP-Adressen, mit denen es nicht speziell für die Kommunikation konfiguriert ist?
Entweder konfigurieren Sie diese wenigen Scanner so, dass sie Ihre Honeynet-IP-Bereiche überspringen, oder Sie nutzen sie als positive Bestätigung dafür, dass Ihr Honeynet funktioniert und meldet, wenn es berührt wird. Sie priorisieren einfach den erwarteten Datenverkehr und verschieben ihn in den Bereich „Ehrenvolle Erwähnung“ auf Ihrem Dashboard.
Andererseits wird der Bösewicht nichts von der Existenz Ihres Honeynets oder seinen Koordinaten erfahren (es sei denn, jemand veröffentlicht es törichterweise). Wenn er also regelmäßig Ihr Netzwerk scannt, stolpert er unweigerlich über Ihr Honeynet - wenn Sie es richtig gemacht haben. Aber lassen Sie uns über einige dieser Punkte sprechen.
Erstens: Wie würde ein Bösewicht von Ihrem Honeynet erfahren?
- Sobald er die Kontrolle über die Benutzerkonten von IT-Administratoren erlangt und deren E-Mails liest, Zugriff auf Ihr Netzwerk und Ihre Sicherheitsdokumentation usw. hat, sollte dies bei guten privilegierten Zugriffskontrollen jedoch erst in einem relativ späten Stadium erfolgen. Honeynets sollen Eindringlinge im frühen bis mittleren Stadium auffangen.
- Indem Sie sich in Support-Foren aufhalten und das Internet durchsuchen (z. B. Stackoverflow, Supportseiten von Honeynet-Anbietern). Es versteht sich von selbst, dass Sie in Ihren Beiträgen weder Ihren Namen noch Ihr Unternehmen oder Ihre Firmen-E-Mail-Adresse preisgeben.
- Indem Sie Ihr Netzwerk scannen. Es ist ziemlich einfach, Honeynets zu identifizieren, wenn man ihnen begegnet - insbesondere Honeynets mit geringer Interaktion, die am häufigsten vorkommen. Aber rate mal was? Wen interessiert das? Sie haben bereits Alarm ausgelöst. Das hier zählt also nicht.
Bei Honeynets geht es also definitiv um Sicherheit durch Unklarheit. Aber weißt du was? Wir verlassen uns viel mehr auf Sicherheit durch Dunkelheit, als wir denken. Verschlüsselungsschlüssel sind grundsätzlich Sicherheit durch Unklarheit. Einfach wirklich, wirklich, wirklich, gute Dunkelheit. Und Sicherheit durch Unklarheit ist nur dann ein Problem, wenn Sie sich darauf als präventive Kontrolle verlassen - etwa durch die Verwendung einer „geheimen“ Portnummer, anstatt eine authentifizierte Verbindung zu erfordern. Honeynets sind Detektiv-Kontrollen.
Was aber, wenn Sie es nicht nur mit einem hartnäckigen Bedrohungsakteur zu tun haben, sondern mit einem geduldigen, professionellen und vorsichtigen Menschen, der davon ausgeht, dass Sie ein Geheimnetz haben und darauf hören? Er wird viel vorsichtiger auf Zehenspitzen gehen. Wenn ich er wäre, würde ich nur Systeme da draußen anfassen, von denen ich Grund zu der Annahme hätte, dass es sich um legitime Produktionsserver handelt. Wo würde ich solche Informationen sammeln? Orte wie DNS, Browserverlauf, Netstat-Ausgabe, Links auf Intranetseiten und so weiter.
Derzeit machen sich die meisten Angreifer nicht die Mühe, dies zu tun. Es verlangsamt sie wirklich und sie wissen, dass es in den meisten Umgebungen einfach nicht notwendig ist. Da dies jedoch ein ständiges Wettrüsten ist, ist es gut, über die Zukunft nachzudenken. Erstens ist ein Bösewicht, der davon ausgeht, dass man ein Honeynet hat, aufgrund dessen, was ich gerade erwähnt habe, eine gute Sache. Es verlangsamt sie und gibt Ihren anderen Verteidigungsebenen mehr Zeit, ihre Arbeit zu erledigen.
Aber gibt es Möglichkeiten, Ihre Honeynet-Implementierung zu optimieren, um den Honeynet-bewussten, geduldigen Angreifer zu fangen? Eine Sache, die Sie tun können, ist, den zusätzlichen Aufwand und die Koordination mit Ihrem Netzwerkteam zu betreiben, um mehr und kleinere Teilbereiche von IP-Adressen für Ihr Honeynet zu reservieren, sodass es weit und detailliert über den gesamten Adressraum verteilt ist. Dies macht es schwieriger, etwas zu unternehmen, ohne Ihr Honeynet zu treffen, und reduziert die Annahme, die Angreifer normalerweise für sicher halten, weiter - dass sich alle Ihre Server im Bereich für statische Adressen befinden, Workstations in einem anderen diskreten Bereich für DHCP und dann noch ein großer Block, der Ihrem Honeynet gewidmet ist.
Das Fazit ist jedoch, dass Honeynets großartig sind. Mit einer vergleichsweise geringen Investition erhalten Sie eine sehr hohe Erkennungsleistung. Schauen Sie sich mein aktuelles Webinar zu Honeynets an, gesponsert von EventTracker, der jetzt Honeynet-as-a-Service anbietet, der vollständig in Ihr SIEM integriert ist. Ein Honeynet bereitzustellen und am Laufen zu halten ist eine Sache, es jedoch in Ihr SIEM zu integrieren, eine andere. EventTracker schafft beides.