zurück zur Übersicht

Threat Intelligence: Ordnung in der Asservatenkammer

Informationen aus der Threat Intelligence richtig ablegen und verwertenAus Threat Information wird Threat Intelligence. Doch wie legt man diese in einer digitalen Asservatenkammer strukturiert ab? Einen digitalen Tatort kann sich wohl jeder von uns vorstellen, also geht es jetzt ans Eingemachte. Schauen wir der Spurensicherung bei ihrer Arbeit über die Schulter und steigen hinab in die Asservatenkammer. Dort lagern all die sichergestellten Beweisstücke: ganze Festplatten voll mit verdächtigen IP-Adressen, Domains und Malwaresamples, die im besten Fall analysiert und mit Hashes und anderen Erkennungsmerkmalen versehen sind.

Unordnung im Keller

Auf den ersten Blick: heilloses Chaos.

Regale über Regale, Festplatten über Festplatten voll mit Informationsschnipseln und Ordnern voller Informationen. Jede der gesammelten IP-Adressen, Domains oder Malware-Häppchen ist ein Indikator für einen Angriff auf das System (ein Indicator of Compromise), aber eben auch nur das: ein Indiz, ein Hinweis. Kein Beweis. Und dass es immer deutlich mehr Hinweise gibt als Beweise, kennen wir aus den einschlägigen Krimiserien.

Damit diese digitalen Hinweise nicht zu allzu vielen False Positives führen, muss aus ihnen Intelligence gemacht werden, eine Arbeit, die viel Erfahrung und Fingerspitzengefühl erfordert. Wir haben die Kommissare und Analysten beobachtet, wie sie aus einzelnen Informationen durch hartnäckige Ermittlungen und Korrelation Threat Intelligence geschaffen haben. Gehen wir also davon aus, dass das bereits geschehen ist.

Es versteht sich nun von selbst, dass nicht nur menschliche Analysten Zugriff auf diesen Datenschatz haben sollten, sondern auch und insbesondere SIEM Systeme, Next Generation Endpoint Protection Systeme und andere Sicherheitslösungen. Erst diese Systeme sind in der Lage, aus den gesammelten Informationen einen Mehrwert zu ziehen und die Intelligence in Taten umzusetzen.

Jetzt stellt sich nur die Frage, wie gleichzeitig Analysten und Maschinen auf die gesammelten Indikatoren zugreifen, sie auswerten, bearbeiten und automatisiert vervollständigen sollen. Die Antwort gehört seit Jahren zur gängigen Praxis: Man nehme XML (Extensible Markup Language) und erstelle eine Struktur, die den eigenen Anforderungen genügt. XML, für Menschen bekanntlich lesbar, aber trotzdem nicht angenehm, eignet sich gut dazu, Ordnung in der digitalen Asservatenkammer zu halten. Im Falle von Threat Intelligence entsteht aus diesem Gedanken unter anderem STIX (Structured Threat Intelligence eXchange).

Mensch und Maschine sprechen eine Sprache

STIX ist ein offener Standard, der von der OASIS (Organization for the Advancement of Structured Information Standards) übernommen wurde und technisch unterstützt wird. Gesammelte Daten können in die folgenden acht Kategorien eingeteilt und je nach Vorfall miteinander verknüpft werden.

  • Observables, also zu überwachende Entitäten, dienen als allgemeines Basiskonstrukt zur Ablage von Informationen. Unter diesem Überbegriff werden generelle Informationen über verdächtige Dateien, Registry Keys, Services und anderem abgelegt.
  • Indicators, also Hinweise, sind Observables, die mit Kontextinformationen angereichert worden sind. Darunter fallen all die gesammelten Informationen über den Angriff bzw. das Verbrechen, also z.B. Testmechanismen, um den Angriff einzuordnen, und der vermutete Effekt des erfolgreichen oder versuchten Angriffs auf die eigene Infrastruktur.
  • Incidents sind Instanzen von Indikatoren, also tatsächlich aufgetretene Angriffe mit dem Muster, das als Indicator abgelegt worden ist. An dieser Stelle werden Informationen über diesen speziellen Vorfall abgelegt, z.B. der Zeitraum, in dem sich der Angriff abgespielt hat, involvierte Parteien, betroffene Assets, vermuteter oder tatsächlicher Effekt auf das Netzwerk, verwandte Indikatoren, tatsächlich getroffene Maßnahmen und deren Effekt, usw.
  • Tactics Techniques and Procedures (TTP) beschreibt die Vorgehensweise bzw. den Ablauf des Angriffs im Detail. Angriffsvektoren, Malwaresamples, verwendete Exploits, Tools und allgemeine Informationen über typische Charakteristika von Opfern und Zielsystemen finden hier ihren Platz.
  • Threat Actors beschreiben die tatsächlichen Täter hinter dem Angriff – oder zumindest alles an Informationen, was sich über diese Instanz angesammelt hat. Diese Informationen gehen über das technische hinaus und beinhalten unter anderem die mögliche Identität des Angreifers, seine Motivation, typisches beobachtetes Verhalten und verwandte Akteure. Ein Threat Actor kann sowohl eine einzelne Person als auch eine Gruppe von Angreifern sein.
  • Mehrere Threat Actors, die sich für einen bestimmten Angriff gegen ein definiertes Ziel zusammenschließen, ein bestimmtes Verhalten zeigen und möglicherweise sogar ähnliche Werkzeuge verwenden, werden in Kampagnen Auch hier werden nicht-technische Daten abgelegt. Referenzen zu Vorfällen (Incidents) gehören genauso dazu wie die erwähnten Akteure (Threat Actors), der angestrebte Effekt und typisches Verhalten für diese Gruppe (TTP).
  • Exploit Targets repräsentiert Schwachstellen in Software, Systemen, Netzwerken und Konfigurationen, die für bestimmte Angriffe ausgenutzt werden und deshalb mit besonderer Sorgfalt abgelegt werden müssen.
  • Courses of Action ist schließlich der Ort, an dem die getroffenen Maßnahmen zur Abwehr von Angriffen und zur Korrektur von Schwachstellen dokumentiert werden. Hier finden auch organisatorische Informationen Platz, wie z.B. die geschätzte Effizienz der Maßnahmen, ihr Einfluss auf das Netzwerk und die geschätzten oder realen Kosten der Umsetzung.

Abgelegt und eingestaubt

Mit Hilfe von STIX sind nun also alle gesammelten Informationen fein säuberlich kategorisiert, zu Intelligence verknüpft und in ihren Regalen abgelegt. Was bleibt, ist die lästige Problematik, dass immer noch erst ein Vorfall auftreten muss, damit die Analysten die wichtigen Informationen zusammentragen und ablegen können. Zudem sind die Hinweise, die nach einem Schaden im eigenen Netzwerk gesammelt wurden, möglicherweise für den nächsten Angriff schon irrelevant und verstauben im Keller. Haben die Analysten sie dann umsonst gesammelt? Und muss ein Angreifer oder Betrüger jetzt einfach ein System oder eine Stadt weiter gehen, um denselben Angriff bzw. denselben Trickbetrug noch einmal mit Erfolg durchzuführen?

Auch dagegen gibt es ein Heilmittel, dem wir einen der nächsten Artikel, Teil 4 der Serie, widmen werden.

Hier gehts zum Teil 1 der Serie (Aufklärung auf dem Cyber-Schlachtfeld)
Hier gehts zum Teil 2 der Serie (Threat Information vs. Threat Intelligence)
Hier gehts zum Teil 4 der Serie (Aus den Attacken auf andere lernen)
Hier gehts zum Teil 5 der Serie (Threat Sharing Platforms)

 

 

 


Weiterführende Links:
https://www.it-cube.net/cubespotter/threat-information-vs-threat-intelligence/

https://www.it-cube.net/cubespotter/aufklaerung-auf-dem-cyber-schlachtfeld/

https://www.it-cube.net/cubespotter/threat-information-vs-threat-intelligence/

https://www.it-cube.net/cubespotter/stix-mit-taxii-zum-threat-intelligence-austausch/

https://securityintelligence.com/how-stix-taxii-and-cybox-can-help-with-standardizing-threat-information/

http://stixproject.github.io/getting-started/whitepaper/

 

Schreibe einen Kommentar