Die Gefahr lauert an der Hintertür

Das Software Change Management ist ein unterschätztes Sicherheitsrisiko. Lesen Sie, was Unternehmen tun können, um ihre Clients sauber zu halten.
von Michael Krammel (Geschäftsführer der Koramis GmbH), Eberhard Rademeier (technischer Journalist in Heiligkreuzsteinach) und Markus Woitzik (Mitglied der Geschäftsleitung der Mentopolis CSC GmbH)

Firewalls und Virenscanner sichern seit Jahren das Frontend einer klassischen Business-IT-Umgebung. Auch in der Industrial-IT sind diese Sicherheits-Mechanismen mittlerweile angekommen. An der Hintertür einer IT-Umgebung existiert jedoch eine häufig unbemerkte Lücke, durch die sich Schadsoftware einschleusen lässt: die Distribution neuer Softwarepakete und -Updates. In diesem Moment liegt das System offen, da die Installation häufig nur unter Administratorrechten vorgenommen werden kann - der Schadcode kann sich also besonders schnell und "effektiv" einnisten.

Der Lebensweg eines Datenpakets

Warum ist diese Gefahr so groß? Werfen wir dazu einen Blick auf das durch Kostendruck erzwungene, weltweit übliche Verfahren der Softwarewareverteilung in großen Unternehmen: Der Anwender erhält von seinem Softwarehersteller ein neues Paket und verlässt sich auf dessen Integrität. Wird das Paket 1:1 zum Rollout durchgereicht, ist er auf der sicheren Seite und kann die Software ohne Bauchschmerzen im Unternehmen verteilen.

In der Regel unterliegt ein Softwarepaket vom Wareneingang bis zum Rollout einer Reihe von Prozessen, die in der Mehrzahl der Fälle aus Kostengründen - auch an unterschiedliche Zulieferer - ausgelagert werden. Im Outsourcing liegt dabei ein Einsparpotenzial von bis zu 50 Prozent. Dazu gehören die Reformatierung in andere Installer-Formate, Kompatibilitätstests, Qualitätssicherung, User-Akzeptanztests (UAT), Re-Paketierung und so weiter. Das bedeutet, dass der Anwender am Ende dieses Prozesses ein Installations-Paket in Händen hält, welches dem ursprünglichen in keiner Weise mehr entspricht. Vom Hersteller genannte Prüfsummen über das Originalpaket werden nutzlos und lassen sich zur Integritätsprüfung nicht mehr heranziehen. Virenscanner können ohnehin nur bereits bekannte Infektionen aufspüren. Der Anwender muss sich also darauf verlassen, dass in seiner Zulieferkette respektive in den Prozessen, die das Paket soeben durchlaufen hat, keine unerwünschten Veränderungen an der Funktionalität der Software vorgenommen wurden.

In der Industrial IT sind es nicht das Outsourcing, sondern die "wilden" Installationen und Updates aus unterschiedlichen Quellen und verschiedenen Wegen, die den Kontrollverlust über die Inhalte der Software-Pakete bedeuten.

Das schwarze Loch

Die Tatsache, dass bisher unbekannte und Zielsystem-spezifisch entwickelte Angriffe zu wenig Beachtung finden, stellt - so geben Security-Verantwortliche zu - ein schwarzes Loch in der Sicherheit dar. Man schaut lieber nicht so genau hin, weil bekannt ist, dass unbekannte Angriffe mit herkömmlichen Methoden kaum zu identifizieren sind. Theoretisch könnte ein Spezialist das Verhalten einer Applikation während der Installation in einer isolierten Hardware-Umgebung beobachten und versuchen, anhand von verdächtigen Aktionen, wie auffälligem Netzwerkverkehr oder bestimmten Dateien, eine Kompromittierung festzustellen. So ein Vorgehen wäre bei größeren Applikationen, deren Installation mehrere Stunden dauert und bei der tausende von Dateien kopiert werden, jedoch extrem zeitaufwändig und unbezahlbar.

Schutz vor kompromittierter Software

Eine praktikable und wirtschaftliche Lösung besteht darin, das Verhalten eines nicht kompromittierten Pakets direkt nach dem Wareneingang mit seinem Verhalten nach den Zuliefer-Prozessen zu vergleichen. Dazu wird das Paket in einer Test-Umgebung installiert und das Verhalten mit Hilfe einer Agentensoftware protokolliert. Der Agent betrachtet nicht den jeweiligen Installer, sondern analysiert die Ergebnisse der Installation - also alles, was auf dem System landet oder verändert wurde. Dieses Vorgehen liefert exakte Informationen darüber, wie eine Software aussieht und wie sie sich während der Installation und Laufzeit verhält. Das Ergebnis ist ein so genannter Referenz-Application-Fingerprint. Der Referenz-Fingerprint kann, muss aber nicht, beim Anwender erzeugt werden. Denkbar ist auch, dass der Softwarehersteller ihn direkt mit dem Paket ausliefert oder er von einem vertrauenswürdigen Dienstleister erstellt wird.

Wichtig ist, die komplette Installation bis hin zum Start der Applikation zu durchlaufen. Nur so erhält der Anwender vollständige Informationen über Änderungen in der Registry, im Dateisystem, in Dateiinhalten und an Betriebssystemkomponenten.

Nun lässt sich das Verhalten einer gelieferten Applikation vor der Installation unabhängig von Paketierung und Quelle automatisch mit der Referenz vergleichen. Die Betonung liegt hier auf "automatisch", denn so hält sich der Aufwand in einem wirtschaftlich vertretbaren Rahmen. Verfügt ein Unternehmen über einen Software-Qualitätssicherungsprozess, kann dieser direkt für einen Integritätscheck eingesetzt werden.

Die Prüfsumme jeder einzelnen installierten Komponente des Pakets wird mit denen der Referenz verglichen. Durch die Umpaketierung ist es nämlich nicht mehr möglich, Prüfsummen über das komplette Paket zu bilden.

Bis zum "Go"

Mit dieser Vorgehensweise lässt sich unabhängig von ihrem Format sicher feststellen, ob Software im Laufe der verschiedenen Prozesse zur Paketierung, während diverser Tests oder im Zuge der Qualitätssicherung verändert wurde. Ist keine Veränderung festzustellen, darf das "Go" zum Rollout ruhigen Gewissens erfolgen. Im Falle einer Veränderung hingegen liefert die Methodik Informationen zu den Modifikationen. Die ermöglichen Spezialisten einen schnelleren Zugang zur Analyse, weil der kompromittierte Code beziehungsweise das unerwünschte Verhalten der Software bereits isoliert wurde. Die Forensik muss nicht bei Null beginnen, sondern kann gezielt ansetzen, was Zeit und Geld spart. Wer das Monitoring im operativen Betrieb mitlaufen und automatisch mit der erstellten Referenz abgleichen lässt, erhält so Hinweise auf unerwünschte Veränderungen von installierter Software in der bestehenden Infrastruktur.

Die Referenz-Fingerprints können in einer zentralen Datenbank vorgehalten werden. Mit einer breiten Datenbasis lässt sich zudem vorhersagen, wie sich authentische Software auf einem Zielsystem zu verhalten hat. Ohne Mehraufwand ist eine Sicherheitsprüfung in einen UAT integrierbar. Für Unternehmen, die sich vor komplexen und gezielten Angriffen schützen möchten, gibt es somit eine automatisier- und bezahlbare Lösung, die nicht mehr ignoriert werden kann.
(Computerwoche / rb)