© Tom Grundy, 123RF.com

Open Source sei sicherer, weil jedermann jederzeit nachvollziehen könne, was die Software alles treibt – so lautet ein gängiges Urteil. Doch wie sieht das in Unternehmen wirklich aus? Wer sich nicht auf die Peer Review der Community verlassen kann oder darf, steht vor einer Herausforderung.

Am Tag der offenen Tür der Raumfahrtagentur ESA im bayerischen Oberpfaffenhofen steht der aktuelle Status des Galileo-Projekts im Mittelpunkt. Bei der Führung durch die Satellitenkontrollzentrale stellt ein Teilnehmer die auf der Hand liegende Frage: “Warum setzen Sie hier eigentlich Linux auf den Arbeitsplätzen ein?” In der Tat überwachen die Mitarbeiter der Raumfahrtagentur an KDE-Desktops die Flugbahnen der ersten beiden Testsatelliten des europäischen GPS-Programms. Die kurze Antwort des Spezialisten sitzt, überrascht aber doch einige der Besucher: “Für unsere Ansprüche an Ausfallsicherheit haben sich gängige Closed-Source-Betriebssysteme als ungeeignet erwiesen.”

Die Aussage ist typisch für Unternehmen oder Institutionen, die höhere Ansprüche an Security oder Stabilität der eingesetzten Software haben. Aber mit Open- und Closed-Source konkurrieren nur zwei Entwicklungsmodel-le, die für IT-Leiter in den kritischen Einsatzszenarien nicht unbedingt das Maß aller Dinge sind. Viel wichtiger ist es für sie, überhaupt Zugriff auf den Quelltext zu erhalten, weil ohne diesen gründliche Audits und Analysen kaum möglich sind.

Dabei spielt es nur eine untergeordnete Rolle, ob der Code im Rahmen eines Partneragreements wie etwa Microsofts Shared-Source-Initiative für Regierungsbehörden [1] oder als vollständig freie Software verfügbar ist. Wer von seinem Closed-Source-Lieferanten per Vertrag vollen Zugriff auf den Code erhält und somit seine Software fortlaufend selbst überprüfen kann, ist zumindest theoretisch auf der sichereren Seite.

Hauptsache Sourcecode

Aber ist der Quelltext wirklich so bedeutsam für die IT-Sicherheit eines Unternehmens? Zahllose Firmen verwenden doch Open-Source-Programme in Routern, Firewalls und Servern, ohne jemals die Sourcen heruntergeladen und eines Blickes gewürdigt zu haben. Für viele Anwender und Admins ist das Versprechen ausreichend, dass eine Community mit gemeinsamer Anstrengung, Peer Review und verteiltem Debugging Fehler und Lücken deutlich schneller findet als eine Firma, die exklusiv über ihre Programmierleistungen herrscht, auch wenn sie Millionen Entwickler beschäftigt.

Dieser Ansatz ist jedoch eher pragmatisch, entscheidend ist der Anspruch, den ein Unternehmen an seine IT-Security hat. Denn der Aufwand, den eine Firma bereit ist zu leisten, wächst nahezu exponentiell mit dem Schutzbedürfnis oder den zu erwartenden Gefahren und Risiken.

Paranoiker-Leitfaden

Für den, der mit sehr hoher Wahrscheinlichkeit Sicherheitsprobleme in der von ihm verwendeten Software ausschließen will, stellt auch das BSI-Grundschutzhandbuch [2] nur einen – wenn auch durchaus sinnvollen – Einstieg dar. Darüber hinaus muss die IT-Leitung mindestens folgende Punkte umsetzen:

• KIS-Prinzip (Keep it simple): Alle unternehmenskritischen Bestandteile der IT müssen so einfach und übersichtlich wie nur möglich gestaltet sein. Funktionen, Hard- und Softwarekomponenten, die nicht unternehmensrelevant sind, sind zu entfernen.
• Zugriff auf den Quellcode: Regelmäßige Analysen und Säuberungsaktionen vermindern das Risiko von Softwarefehler oder Backdoors.
• Experten-Audits: Zusätzlich prüfen externe Spezialisten kritische Teile der Quellcodes.
• Definierte Build-Prozeduren: Nur Binärcode, der nachvollziehbar mit einer dokumentierten Build-Prozedur aus den geprüften Quellen kompiliert ist, darf Verwendung finden.
• Test Harness: Ein automatisiertes Test-Framework [3] gibt Admins die Möglichkeit, sicherheitskritische Funktionen zu prüfen, ohne die eigene IT zu gefährden.
• Quellcode-Repository: Ein eigenes Repository ist unverzichtbar. Es hilft Admins den Überblick zu bewahren und die Software transparent zu verwalten. Seine Versionskontrolle stellt die Nachvollziehbarkeit der Änderungen (Wer hat wann was geändert?) sicher und hilft bei der Softwareverteilung.
• Updates: Jedes Patch, jedes Update oder Upgrade muss den kompletten Zyklus der oben beschriebenen Maßnahmen durchlaufen. Aktualisierungen und Bugfixes sind nur erlaubt, wenn sie im Quelltext vorliegen und die IT-Abteilung sie selbst kompiliert, testet und verteilt.

Dem vom Controlling gegängelten IT-Leiter dürfte sich jetzt angesichts der zu erwartenden Kosten für diese Vorgehensweise die Stirn in Falten legen. Die meisten Unternehmen wägen hier den im Katastrophenfall zu erwartenden finanziellen Schaden mit dem notwendigen Aufwand an IT-Personal ab und entscheiden danach, welche der Punkte sie in welchem Maß umsetzen.

Wer nicht ganz so lax vorgehen will, weicht die Vorgaben für einzelne Bereiche auf, zum Beispiel bei den (hoffentlich) unkritischeren Gerätetreibern wie Grafikkarten oder Druckern. Wichtig ist dabei jedoch fast immer ein externer IT-Dienstleister, der im Ernstfall die Verantwortung übernimmt.

Für Firmen mit speziellen Risikoszenarien ergeben sich manchmal sogar rechtliche Vorgaben, etwa durch die US-Börsenaufsicht SEC oder als Voraussetzung für die Kreditvergabe durch Banken (Basel II, [4]). Typische Situationen, die es notwendig machen, die oben beschriebenen Maßnahmen umzusetzen, sind:

• Aufträge mit sehr hohem Volumen, zum Beispiel im Bereich dreistelliger Millionen-Euro-Beträge.
• Sehr hohe Vertragsstrafen, die den Bestand des Unternehmens gefährden.
• Unternehmenskritisches Know-how auf IT-Systemen.
• Nicht vermeidbare Speicherung sehr sensibler Personendaten (Steuerberatung, Anwälte, Health Care, …).
• Einsatz in Gefahrenbereichen, zum Beispiel Nukleartechnik, Waffentechnik, Militär, Chemische Industrie.
• In der IT von Nachrichtendiensten.
• Ausgeprägte Wettbewerbssituationen, vor allem mit ausländischen Konkurrenten (Stichwort Echelon, [5]).

Immerhin bewegt sich der laufende Aufwand in einem akzeptablen Rahmen, wenn das KIS-Prinzip in IT-Sicherheits-relevanten Bereichen umgesetzt ist, also beispielsweise für die Identifikation der unternehmenskritischen Daten, IT-Systeme, Funktionen, Prozesse und Benutzer. Konkret bringt die Reduktion der Anzahl von Datenbanken, Repositories, Servern, Benutzern, Softwarefunktionen und alternativen Zugriffsmöglichkeiten viele Vereinfachungen.

Migration

Die langwierigste und arbeitsintensivste Phase einer Migration hin zu einer sicheren IT umfasst die Bestandsaufnahme, Klassifikation und Dokumentation der IT-Prozesse und ihrer Gefährdungsszenarien. Dabei helfen die Migrationsleitfäden des Innenministeriums [6] oder von IBM [7].

Nach der Überlegung, welche der Prozesse redundant auszulegen sind, folgt die Prüfung der Dateiformate, auch mit der Bewertung, ob an der jeweiligen Stelle Lese- oder Schreibzugriff nötig ist – getreu dem KIS-Prinzip. Dann stellt sich die Frage nach dem zu verwendenden Open-Source-Betriebssystem.

Da nur wenige Anwender in Unternehmen Zugriff auf Microsofts Sourcen erhalten werden, scheiden das Redmonder OS wie auch die Serverprodukte in sensiblen Umgebungen von vornherein aus – siehe Galileo bei der ESA. Typischer ist eher, dass Firmen mit großen Umgebungen mehrere freie Systeme parallel verwenden, meist sind dies Linux, BSD oder Open Solaris.

Aus den benötigten Dateiformaten ergibt sich zwangsläufig die Liste erforderlicher Open-Source-Anwendungen. Proprietäre Dateiformate, die keine freie Software unterstützt, müssen die IT-Strategen hier einer besonderen Prüfung unterziehen: Ist das Dateiformat wirklich operationell notwendig? Unterstützt die Software, die das Format erzwingt, alle kritischen Prozesse des Unternehmens? Gibt es kostengünstige Alternativen?

Wer nicht um die ungewollten Formate herumkommt, muss auf Virtualisierung und Terminalserver setzen. So lassen sich auch unsichere proprietäre Umgebungen wie MS Windows mit installierten Closed-Source-Anwendungen in einer Art Sandbox betreiben. Die setzt der Server automatisch (beispielsweise mit VM-Image-Templates) auf einen sicheren Ausgangszustand zurück, sobald sich der Anwender abmeldet.

Ebenfalls prüfen muss die IT-Leitung, inwieweit für kritische Funktionen Hardwareverschlüsselung zum Einsatz kommen soll, etwa in Mobiltelefonen. Certgate zeigt das anhand der Sprachverschlüsselung in sicheren Smartcards für das “Merkel-Smartphone” (Abbildung 1, [8]). Den gleichen Stellenwert sollten Passwort-Policies (Länge, Gültigkeitsdauer, Sonderzeichen, lexikalische Überprüfung), Arten der Authentifizierung (Token, Smartcards, Zertifikate) und Stellvertreterdefinitionen genießen.

Abbildung 1: Zarafas freie Groupware unterstützt den Simko2-Standard für sichere Telefonie, der bisher aber nur in wenigen HTC-Geräten funktioniert.

Eine Single-Sign-on-Struktur erweist sich in vielen Fällen als schwierig, vor allem mit Open-Source-Mitteln. Hier hat die Community abseits von LDAP-Kerberos noch einige Entwicklungsarbeit zu leisten, vor allem bei der Integration mit gängigen Desktop-Utilities.

Auch für die Verteilung der nach den beschriebenen Vorgaben erstellten und verifizierten Software gelten klare Regeln. Ein eigenes Repository ist Pflicht, Binärpakete müssen unbedingt mit Hashcodes abgesichert und verifizierbar sein. Downloads über ungesicherte Protokolle wie HTTP oder FTP sind tabu, für die stattdessen ausschließlich verwendeten HTTPS und SFTP bedarf es signierter Zertifikate. Eine eigene PKI ist spätestens dann nötig, wenn Mitarbeiter Zugang über ein VPN erhalten.

Viel Arbeit – die sich lohnt

Egal ob es sich um den eigenen LDAP-Server, das VPN-Gateway, die Kernel der im Unternehmen verwendeten Betriebssysteme oder die Office-Suite handelt: Im Extremfall muss dieser Leitfaden für jede Softwarekomponente Anwendung finden. Admins mit hohem Sicherheitsanspruch kommen nicht umhin, jede x-beliebige Software, die sie im Unternehmen einsetzen, von der Quelle bis zum Desktop des Mitarbeiters zu verfolgen, zu analysieren und abzusichern.

An offener Software, freien Standards und vollständig dokumentierten APIs führt da kein Weg vorbei. Dabei gilt immer der KIS-Grundsatz “Weniger ist mehr”: Schon im Quelltext lassen sich unnötige Komponenten entfernen, nicht verwendete Optionen und Funktionen rauswerfen und so das potenzielle Angriffsziel minimieren.

In den meisten Fällen ist das nur mit freier Software möglich, weil nur wenige große Hersteller ihren Kunden Einblick in ihre proprietären Produkte gewähren. Hier schließt sich ein Kreis: Das berechtigte Sicherheitsbedürfnis der Software-Entwickler, die ihr geistiges Eigentum vor der Konkurrenz schützen wollen, verhindert häufig den Einsatz in Umgebungen mit hohem Sicherheitsanspruch.

Für Kommentare