IT-Forensik

Interview mit Martin Wundram
1
Okt

IT-Forensik: „Software kann Tatort oder Tatmittel sein“

Das Ziel, möglichst sichere IT-Systeme zu bauen, ist Entwicklern nicht fremd – zumindest theoretisch. Was aber, wenn das Kind schon in den Brunnen gefallen ist und die Software bereits angegriffen wurde? Dann helfen IT-Forensiker wie Martin Wundram, der uns im W-JAX-Interview eine kleine Einführung gibt und erklärt, warum IT-Forensik auch Entwickler und Software-Architekten angeht.

IT-Forensik – was ist das eigentlich?

Redaktion: Hallo Martin. Du sprichst auf der W-JAX über IT-Forensik. Dabei geht es ja explizit nicht um das Bauen möglichst sicherer IT-Systeme. Worum geht es dann?

In jedem Fall suchen wir nach digitalen Spuren.

Martin Wundram: IT-Systeme und deren Programme werden leider immer wieder etwa bei Industriespionage angegriffen, oder einfach missbräuchlich verwendet, z.B. um illegitim an geheime Informationen eines Unternehmens zu gelangen. Die betroffenen Unternehmen, IT-Experten, externe Beteiligte brauchen dann Antworten auf die typischen W-Fragen: Wer hat wann was gemacht? Wie wurden welche Informationen wohin übertragen?

Software kann dabei Tatort oder Tatmittel sein. In jedem Fall suchen wir nach digitalen Spuren. Mein Talk legt dabei die Perspektive auf Entwickler und Architekten, und was man tun kann, um Software für solche Fälle möglichst gut vorzubereiten, damit IT-Forensiker später einmal möglichst zuverlässig wertvolle Spuren finden, verstehen und auswerten können. Und es geht auch darum, zu überlegen, wie Entwickler selbst Ziel von Angriffen werden könnten.

 
Redaktion: Warum betrifft IT-Forensik auch Entwickler und Architekten?

Martin Wundram: IT-Forensik betrifft insofern auch Entwickler und Architekten, dass sie sich und ihre Umgebungen zum einen selbst schützen und zum anderen bei eventuellen Angriffen auf ihre eigene IT wirksam reagieren können müssen. Und wenn bereits in Design und Entwicklung einer Software wichtige Aspekte von IT-Forensik, z.B. aussagekräftige Protokollierung/Logging, berücksichtigt werden, dann hilft das später „im Einsatz“ oft sehr.

 

Recht auf Privatsphäre

Redaktion: Wie gehen IT-Forensiker typischerweise vor? Welche Methoden & Tools kommen da zum Einsatz?

Martin Wundram:  Maximal verkürzt dargestellt: sichern, analysieren, präsentieren. Wenn möglich, erstellen IT-Forensiker beweiskräftige, sogenannte forensische Kopien von Datenträgern oder Datenbeständen. Ein wesentlicher Unterschied liegt darin, ob „Tot-Forensik“ zum Einsatz kommt, es handelt sich dabei z.B. um ausgeschaltete Datenträger, oder „Live-Forensik“, also die unmittelbare Arbeit am und mit einem laufenden System.

Als Tools kommen sowohl kommerzielle als auch Open-Source-Software zum Einsatz. Interessant ist, dass nicht immer Spezial-Software verwendet wird, sondern auch „Alltags-Software“, etwa normale System-Programme bei einer Live-Analyse eines laufenden Systems.

 
Redaktion: Du erwähnst auch das Spannungsfeld zwischen erwünschter Aufklärung und „Ausschnüffeln“. Wie sind diesbzgl. deine Erfahrungen? Weshalb kann es da zu Spannungen kommen?

Es gilt, eine Balance aus Art und Menge der Datenspeicherung und des Zugriffs im „Bedarfsfall“ zu finden.

Martin Wundram: Jeder Mensch hat grundsätzlich das Recht auf Privatheit und Intimsphäre. „Big Brother is watching you“ ist keine angenehme Vorstellung. Spätestens, wenn es um die PIN zur Kreditkarte oder das geheime Rezept eines Getränkeherstellers geht, wird das sehr deutlich. Was aber, wenn wir Opfer einer Straftat werden, wenn jemand unser E-Mail-Postfach oder gleich den ganzen PC „hackt“? Dann wünschen wir uns doch auch eine erfolgreiche Aufklärung und nicht bloß die Erkenntnis, dass irgendeine IP-Adresse der Ursprung des Angriffs ist. Hier eine Balance aus Art und Menge der Datenspeicherung und des Zugriffs im „Bedarfsfall“ zu finden, ist das herausfordernde Spannungsfeld. Welche Daten soll ein IT-System speichern? Wie lang? Wo? Mit welchen Zugriffsmöglichkeiten?
 
Redaktion: Und wie kann man diese Spannungen entschärfen?

Martin Wundram: Ein Weg sind offener Umgang mit dem Thema, Aufklärung der Betroffenen und Implementierung einfacher Auswahlmöglichkeiten für Art und Umfang von gewünschter Protokollierung. Natürlich lässt sich das Logging von Serversoftware seit jeher meist umfangreich einstellen. Aber aus Sicht der Anwender z.B. von Cloud-Anwendungen schaut es dann vielleicht mau aus. Bildhaft gesprochen: Es ist nicht leicht, das Pendel in der Mitte zu halten, und manchmal schwingt es irgendwer oder irgendwas ganz schön hin und her…
 
Redaktion: Was ist die Kernbotschaft deiner Session, die jeder Teilnehmer mit nach Hause nehmen sollte?

Martin Wundram: Weder Angst noch Kopf-in-den-Sand sind geeignet. Natürlich gibt es wichtigere Themen als IT-Forensik, aber wenn es dann doch einmal zu einem Vorfall kommt, kann verlässlich und nachvollziehbar arbeitende, gründlich entwickelte Software mit einem geeigneten Maß an Logging vielleicht überhaupt erst die Aufklärung ermöglichen oder zumindest ausreichend effizient machen. Daher ist die Kernbotschaft meiner Session: Vorbereitung ist die beste Medizin – oft hilft schon etwas Aufwand im Vorfeld mit großem Effekt in der Zukunft. Und schützt eure eigenen Systeme!
 
Redaktion: Vielen Dank für dieses Interview!

 

Quarkus-Spickzettel


Quarkus – das Supersonic Subatomic Java Framework. Wollen Sie zeitgemäße Anwendungen mit Quarkus entwickeln? In unserem brandaktuellen Quarkus-Spickzettel finden Sie alles, was Sie zum Loslegen brauchen.

 

Jetzt herunterladen!

Alle News der Java-Welt:
Alle News der Java-Welt:

Behind the Tracks

Agile & Culture
Teamwork & Methoden

Data Access & Machine Learning
Speicherung, Processing & mehr

Clouds, Kubernets & Serverless
Alles rund um Cloud

Core Java & JVM Languages
Ausblicke & Best Practices

DevOps & Continuous Delivery
Deployment, Docker & mehr

Microservices
Strukturen & Frameworks

Web Development & JavaScript
JS & Webtechnologien

Performance & Security
Sichere Webanwendungen

Serverside Java
Spring, JDK & mehr

Digital Transformation & Innovation
Technologien & Vorgehensweisen

Software-Architektur
Best Practices