Dynamische Analysen: Software-Rollout - Sind die Risiken beherrschbar? Detail - Computerwelt

Computerwelt: Aktuelle IT-News Österreich


30.09.2011 Thomas Moers*, Abdus Salam*

Dynamische Analysen: Software-Rollout - Sind die Risiken beherrschbar?

Blindes Vertrauen empfiehlt sich beim Rollout neuer Applikationen oder Updates in komplexen IT-Umgebungen nicht. Sicherheit bringen nur dynamische Analysen - auch in der Cloud.

Pannen beim Rollout neuer Applikationen, Versionen, Betriebssystem-Patches oder -Hotfixes sind der Albtraum jedes IT-Verantwortlichen, bedeuten sie dch auf alle Fälle Kosten und beim Ausfall geschäftskritischer Systeme auch einen Imageschaden. Der Grund für solche Störungen liegt meist in den Inkompatibilitäten zwischen der neu installierten Software und der existierenden Umgebung. Derzeit hat ein durchschnittliches Unternehmen zwischen 400 und 15.000 Softwarepakete einschließlich unterschiedlicher Versionen der gleichen Software, Patches, Hotfixes, Betriebssystem-Updates etc. im Einsatz. Probleme beim Rollout neuer Applikationen sind somit geradezu programmiert.

Genau aus diesem Grund wird Qualitätssicherung beim Ausrollen neuer Softwarekomponenten immer wichtiger. Ein Beispiel: In einem Großunternehmen sollte eine verhältnismäßig kleine Applikation neu installiert werden, die automatisch einen Mail-Footer erzeugt - an sich eine relativ triviale Angelegenheit. Man hatte allerdings nicht bedacht, dass eine Bestellkomponente, die in den Vertriebsstellen eingesetzt wird, vom Mail-System als Kommunikationskomponente benutzt wird.

Verhängnisvolle Konflikte Die neue Kombination ist zwar zuvor analysiert worden, aber es war nicht bekannt, dass die Bestellkomponente eine bestimmte Dynamic Link Library (DLL) aus dem MAPI-Interface nutzt, die jedoch durch die Mail-Footer-Applikation verändert wurde. Die Folge war, dass die Bestellkomponente eine Woche lang nicht funktionierte. Die durch den Ausfall entstandene materielle Einbuße ließ sich zwar ermitteln, nicht bezifferbar dagegen war der Imageschaden. Mit einer entsprechenden Analyse (oder einem Test) hätte man diese Abhängigkeit bereits im Vorfeld erkennen und beseitigen können. Ein weiteres Beispiel sind Börsenplätze oder international operierende Call-Center. Wenn dort Handelssysteme über Stunden nicht verfügbar sind, entstehen extreme finanzielle Schäden.

Vermeiden lassen sich solche Pannen nur durch wirksame Maßnahmen zur Qualitätssicherung im Vorfeld des Rollouts, also durch Untersuchungen, ob und wie Softwarepakete sich gegenseitig beeinflussen. Zu reduzieren beziehungsweise vermeiden sind derartige Konflikte durch das so genannte Glass Box Testing, bei dem zwischen statischer (White Box Testing) und dynamischer Analyse unterschieden wird.

Statische Analysen haben in jüngerer Vergangenheit zweifellos die Qualitätssicherung beim Rollout verbessert und die Kosten gesenkt. Bei dieser Technik wird in der Regel das Installationspaket analysiert, wobei man davon ausgeht, dass der Softwarehersteller das Standard-Installationspaketformat MSI von Microsoft verwendet. Dieses Format ist dokumentiert und offengelegt. Allerdings findet je nach Unternehmen nur bei etwa 75 bis 95 Prozent der erwähnten Softwarepakete das MSI-Format Verwendung. Fünf bis 25 Prozent der Installationspakete setzen Non-MSI-Installer ein.

Analyse der MSI-Installer Im besten Fall wird der MSI-Installer in einer Weise verwendet, die mehr oder weniger vollständig analysierbar ist. Vollständig meint hier, dass ausschließlich Installer-Aktionen genutzt werden, etwa das Kopieren von Dateien durch den Installer, Änderungen an der Registry und die Vergabe von Berechtigungen. In diesem Fall müsste man die Applikation nicht real installieren, es würde genügen, die MSI-Datei mit Hilfe eines Tools zu analysieren. Sämtliche Veränderungen wären in einem Application-Fingerprint enthalten.

So viel zur Theorie. In der Praxis enthalten allerdings zwischen 25 und 55 Prozent der MSI-Installer so genannte Custom Actions, die während der Installation aufgerufen werden. Damit lassen sich beliebige Dateien ansprechen. Das können exe-Dateien sein, aber auch ein weiteres Installer-File (geschachtelte MSI) oder eine Batch-Datei. Alles, was unter einem Windows-Betriebssystem ausführbar ist, kann durch den Installer aufgerufen werden.

An dieser Stelle beginnt die Crux: Executables und andere Binärdateien können - technisch bedingt - nicht analysiert werden. Damit tut sich in der Analyse die erste Lücke auf, da man nicht vollständig feststellen kann, wie eine Installation das System beeinflusst.

Die zweite Lücke beginnt mit dem ersten Start einer neuen Applikation. Dabei werden von der Applikation oft selbst noch Einträge in der Registry vorgenommen, weitere Dateien auf das System kopiert oder Berechtigungen geändert. Alle diese Vorgänge lassen sich mit rein analytischen Verfahren technisch bedingt nicht erfassen. Ein Applikations-Monitoring ist nötig, um solche Veränderungen zur Laufzeit der Software feststellen zu können.

Wenn kein MSI-Format vorliegt Das nächste Problem, mit dem die analytischen Methoden in der Realität zu kämpfen haben, ist die Tatsache, dass zwischen fünf und 25 Prozent der Softwarepakete nicht im MSI-Format vorliegen. Theoretisch ist es zwar möglich, die verwendeten Batch- oder Script-Dateien auf ihr Verhalten gegenüber dem Zielsystem zu analysieren, aber der Aufwand, Pseudo-Interpreter für all diese unterschiedlichen Skriptformate zu schreiben, steht in keinem vernünftigen Kosten-Nutzen-Verhältnis. Diese Überlegungen führen zu einem Schluss: Bei der statischen Analyse ist der Anwender an ein bestimmtes Format gebunden, er muss mit einigen "schwarzen Löchern" leben und weiß nicht exakt, was die Applikation bei der Installation, beim ersten Starten oder zur Laufzeit tut. Der Application-Fingerprint ist in vielen Fällen unvollständig.

Verschärft werden diese Probleme durch die Themen Virtualisierung und Cloud Computing. Der Anteil virtualisierter Applikationen liegt momentan zwischen 15 und 55 Prozent des gesamten Applikationsportfolios - mit steigender Tendenz. In zunehmendem Maße werden auch Desktops virtualisiert, die dann entsprechende Anwendungssoftware benötigen. Dabei muss sichergestellt sein, dass diese Applikationen, auch in unterschiedlichen Versionen, auf den physischen oder virtuellen Desktops kollisionsfrei nebeneinander laufen. Wird beispielsweise ein Hotfix ausgerollt, das eine Sicherheitslücke im Betriebssystem schließen soll, muss der IT-Verantwortliche sicher sein, dass die gesamte Installation auch nach dem Rollout reibungslos funktioniert.

Grenzen der statischen Analyse In diesem Kontext stoßen statische Analyseverfahren vollends an ihre Grenzen, denn virtuelle Applikationen lassen sich mit statischen Methoden nur teilweise analysieren, nie aber vollständig. Besondere Aufmerksamkeit verdienen geschäftskritische Applikationen, die häufig als Fachanwendungen mit unternehmensspezifischen Erweiterungen im Einsatz sind. Gerade hier sind die Installationsvorgänge und Abhängigkeiten von hoher Bedeutung.

Die logische Konsequenz ist ein physikalischer Test, der auch mögliche Konflikte wie Probleme mit Benutzerberechtigungen oder Konflikte beim Zugriff auf Ressourcen aufdecken kann. Hier greift die dynamische Analyse; treffender wäre eigentlich die Bezeichnung "dynamischer Test".

Bei einer dynamischen Analyse wird die Applikation real in einer definierten Umgebung installiert. Damit ist der Test vollkommen unabhängig vom eingesetzten Installer, die Ergebnisse bei MSI-Installern sind ebenso zuverlässig wie die bei Non-MSI-Installern. Der grundsätzliche Unterschied zur statischen Analyse besteht darin, dass hier das tatsächliche Ergebnis einer Aktion betrachtet wird und nicht die Installer-Komponente, die eine Aktion anstößt. Das Ergebnis ist eine 100-prozentige Testabdeckung.

Diesen Artikel

Bewertung:

Übermittlung Ihrer Stimme...
Noch nicht bewertet. Seien Sie der Erste, der diesen Artikel bewertet!
Klicken Sie auf den Bewertungsbalken, um diesen Artikel zu bewerten.
  Sponsored Links:

IT-News täglich per Newsletter

E-Mail:
Weitere CW-Newsletter

CW Premium Zugang

Whitepaper und Printausgabe lesen.  

kostenlos registrieren

Aktuelle Praxisreports

(c) FotoliaHunderte Berichte über IKT Projekte aus Österreich. Suchen Sie nach Unternehmen oder Lösungen.

Service

Acceptance Testing: Trotz knapper Ressourcen

Zum Thema

  • APC Business Services GmbH

    APC Business Services GmbH IT-Personalbereitstellung, Individual-Softwareentwicklung, IKT-Consulting mehr
  • Rittal GmbH

    Rittal GmbH Netzwerk-Management, Netzkomponenten, Zugangs- und Zutrittskontrolle, Unterbrechungsfreie Stromversorgung (USV), Überwachungssysteme, Notfalls-Rechenzentren, Netzwerk- und Systemüberwachung,... mehr
  • EASY SOFTWARE GmbH

    EASY SOFTWARE GmbH Schrifterkennung, Mobile Lösungen und Applikationen, Management Informationssysteme (MIS), Dokumentenmanagement und ECM, Business Intelligence und Knowledge Management mehr
  • ELO Digital Office AT GmbH

    ELO Digital Office AT GmbH Mobile Lösungen und Applikationen, Dokumentenmanagement und ECM, Übernahme von Softwareprojekten, Systemintegration und Systemmanagement, Programmierung, Individual-Softwareentwicklung, IKT-Consulting,... mehr

Hosted by:    Security Monitoring by: