US National Security Agency (NSA) hat
das im NSA-Report vom Oktober 1998 auf den Punkt gebracht:E-Business-Anwendungen, gemeinsame Marktplätze, Entwicklungskooperationen über das Netz und Extranets zwischen Niederlassungen, aber auch schon differenzierte Zugriffe auf gemeinsame Datenbestände beispielsweise in Krankenhäusern erfordern einen hohen Grad an Offenheit bei gleichzeitiger Kontrolle. Nur dies ermöglicht einen unbehinderten und dennoch sicheren Zugriff auf Webserver oder Back-End-Systeme. Perimeter Defences wie Firewalls können diese Anforderungen nicht erfüllen, da sie in erster Linie nach außen sichernde Applikationen sind, die durch "Zutrittskontrollen" eine sichere Trennung von vertrauenswürdigen und nicht-vertrauenswürdigen Netzen realisieren sollen.
Zudem sind Firewalls selbst verwundbar, da Applikationen nur so
sicher sein können, wie das Fundament (Betriebssystem), auf
dem sie basieren. Die US National Security Agency (NSA) hat
das im NSA-Report vom Oktober 1998 auf den Punkt gebracht:
Die Bedrohungen, denen moderne Computerumgebungen ausgesetzt sind, können ohne sichere Betriebssysteme nicht gebannt werden. Jeglicher Sicherheitsansatz, der diese Tatsache ignoriert, kann nur in einer 'auf Sand gebauten Festung' resultieren.
Das Betriebssystem bildet den gemeinsamen Nenner für die beiden Anforderungen "Sicherheit trotz Offenheit" und "fundamentale Sicherheit". Denn das Betriebssystem kontrolliert alle Systemressourcen und bildet damit die letzte und eigentliche Entscheidungsebene. Damit sind darin implementierte Sicherheitsmaßnahmen umfassend und nicht auszuhebeln. Zugleich verursachen im Kernel implementierte Sicherheitsfunktionen wesentlich geringere Performanceeinbußen als solche auf Applikationsebene.
Die derzeit eingesetzten kommerziellen Standardbetriebssysteme werden diesem Anspruch jedoch nicht gerecht. Die gängigen Unixderivate, Linux und Windows NT berücksichtigen die IT-Sicherheit nur rudimentär. Bei Standard-Unix beschränken sich die Sicherheitsmöglichkeiten auf die Login-Prozedur, die Zugriffssteuerung für Daten und Prozesse (Besitzer/Gruppe/alle, Lesen/Schreiben/Ausführen) sowie einfachste Logfile-Möglichkeiten.
Sicherheit und Offenheit - ein nicht lösbarer
Widerspruch?
Insbesondere bei Sicherheitsanwendungen hat man die Gefahren, die aus einem nicht sicheren Betriebssystem resultieren können, oftmals bereits erkannt. Durch so genannte Härtung des Betriebssystems wurde dann versucht, die Sicherheit zu verbessern, indem man potenziell riskante Funktionen und Programme entfernt (Hardened Operating System). Doch auch die Reduzierung der Funktionalität und Offenheit auf ein Minimum bietet keinen adäquaten Schutz, da sie zwar die Anzahl der Angriffspunkte reduziert, die eigentlichen Schwachstellen des Betriebssystems jedoch nicht entfernt. Gleichzeitig besteht die Gefahr, dass durch Misskonfiguration Lücken offen bleiben oder bei einem System-Upgrade oder der Installation neuer Softwarekomponenten wieder aufgerissen werden. Das Resultat ist ein bezüglich Leistungsfähigkeit und Funktion eingeschränktes Betriebssystem, das dennoch einer ständigen Pflege und Aufmerksamkeit bedarf.
Der Erkenntnis, dass kommerziell verfügbare Standardbetriebssysteme nicht sicher genug für kritische Anwendungen sind, wurde bereits im Jahr 1985 auch von offizieller Stelle Rechnung getragen: Damals hat das US-amerikanische Verteidigungsministerium die so genannte Rainbow Series an Dokumenten herausgegeben. Teil davon waren die Trusted Computer System Evaluation Criteria (TCSEC), nach der Farbe des Einbandes auch Orange Book genannt. Es dokumentiert erstmals die Anforderungen an ein sicheres Betriebssystem.
Internationale Sicherheitslevel nach TCSEC/ITSEC und die
Einstufung einiger Produkte
1991 folgten die europäischen Information Technology Security Evaluation Criteria (ITSEC) und 1998 die weltweit abgestimmten Common Criteria for Information Technology Security Evaluation (CC). Sie beschreiben einerseits die für die jeweilige Zertifizierungsstufe zu erfüllenden Sicherheitsfunktionalitäten und andererseits die Evaluationsstufen, sprich die Genauigkeit, Art und Tiefe der Überprüfung. Die Evaluierung kann neben einer Überprüfung der Implementation auch praktische Penetrationstests umfassen. Die Durchführung der Evaluation erfolgt ausschließlich durch akkreditierte unabhängige Labors und bildet die Voraussetzung für die Zertifizierung: den Nachweis für die Vertrauenswürdigkeit der Systeme.
Die anfangs nach diesen Richtlinien entwickelten Betriebssysteme waren noch proprietärer Natur und kamen in erster Linie im behördlichen und militärischen Umfeld zum Einsatz. Doch die zertifizierten Betriebssysteme (Trusted Operating Systems, TOS) neuerer Generation wurden für den Einsatz im kommerziellen Umfeld konzipiert. Sie erfüllen die damit verbundenen Anforderungen an Performance, Stabilität, Skalier-, Administrier- und Konfigurierbarkeit. Der Nachweis hierfür wurde bereits vielfach in sicherheitskritischen, kommerziellen Projekten insbesondere im Bankenumfeld geführt.
Für die Entwicklung eines TOS ist zwingende Voraussetzung und Basis der jeweilige Sourcecode des zu Grunde liegenden Standardbetriebssystems (daher gibt es auch kein TOS auf Basis von Windows NT). Die Sicherheitsfunktionen werden durch entsprechende Modifikationen im Source-Code implementiert. Je nach Produktgeneration und Hersteller bleibt dabei idealerweise die Binärkompatibilität für Standardapplikationen (Commercial Off The Shelf, COTS) erhalten, und die Installation erfolgt vergleichbar einem Betriebssystem-Upgrade auf einem bereits fertig installierten und konfigurierten System. Bestehende Applikationen laufen damit ohne Änderungen und mit geringstem Konfigurationsaufwand nach der Installation sofort weiter.
Doch welche Vorzüge bieten Trusted Operating Systems? Weshalb sind sie in aktuellen IT-Landschaften zur Notwendigkeit geworden? Fragen, die sich am deutlichsten durch das Aufzeigen der Sicherheitslücken von Standardbetriebssystemen beantworten lassen. Sicherheitslücken, die teilweise so gravierend sind, dass das ganze System übernommen werden kann.
Ein TOS gewährt den Zugriff auf Daten nur bei
Übereinstimmung von Bereich und Sicherheitsstufe der Security
Labels.
Ein großes Risiko geht von den kommerziellen Applikationen aus. Die in jeder Anwendung verborgenen Fehler können durch Attacken wie Buffer Overflow, aber auch ohne äußere Einflüsse zu Abstürzen führen. Dadurch gelangt ein Nutzer oft auf die Betriebssystemebene (Shell-Oberfläche). TOS können die Applikationen selbst zwar auch nicht sicherer machen, unterbinden jedoch unerwünschte Konsequenzen für das Gesamtsystem wie eine Übernahme der Betriebssytemkontrolle oder den möglichen Angriff auf weitere, auf dem Rechner selbst befindliche Applikationen oder auch auf verbundene Systeme.
Trusted Operating Systems unterteilen ein System in mehrere
virtuelle Server.
Das Prinzip der Least Privileges splittet hierzu die vorhandenen Unixrechte wesentlich feiner auf. Dies ermöglicht es, den Programmen nur diejenigen Rechte zu verleihen, die sie zur Erfüllung ihrer Aufgaben wirklich benötigen. Am Beispiel eines Backup-Prozesses lässt sich das besonders gut darstellen: Unter Standard-Unix müssen dem Backup-Prozess Root-Rechte zugewiesen werden, nur um das Kopieren aller Dateien zu Sicherungszwecken zu ermöglichen. Das Root-Privileg ermöglicht dem Backup-Prozess zusätzlich, alle Dateien auch zu verändern und zu löschen sowie (Sicherheits-)Applikationen zu stoppen, Logfiles zu verändern, neue Nutzer anzumelden. Selbst das Aufbringen und Starten neuer Software, die Abschaltung des ganzen Systems durch Herunterfahren oder gar Löschen der Festplatte sind möglich. Gleiches gilt auch für einen Anwender, der die Rechte des Prozesses nach einem Absturz geerbt hat und sich dann auf der Shell-Oberfläche befindet.
Ein Trusted Operating System hingegen kann die Privilegien des Backup-Prozesses auf das Einzelrecht "Kopieren aller Dateien auf das Sicherungslaufwerk" beschränken und verhindert damit möglichen Missbrauch. Zudem verbietet das Prinzip der Least Privileges das Vererben der Rechte auf Sub-Prozesse. Im Beispiel also vom Backup-Prozess auf die Shell-Oberfläche. Damit lassen sich selbst Applikationen mit sehr weit reichenden Rechten nach einem Absturz nicht missbrauchen.
Doch selbst wenn die Shell-Oberfläche inklusive entsprechender Rechte erreicht würde, unterliegen entsprechend ausgezeichnete Objekte nach wie vor einem Schutz: Das TOS weist hierzu allen Objekten wie beispielsweise Nutzern oder Dateien so genannte Labels zu. Durch die Labels werden die Objekte einem oder mehreren Bereichen zugeordnet und außerdem mit einer Sicherheitsstufe versehen (allgemein, vertraulich, hoch vertraulich). Damit lassen sich beispielsweise differenzierte Zugriffssteuerungen auf Dateien realisieren.
Der Aufbau einfacher Zugriffsregelungen besteht auch unter Standard-Unix. Hat der Nutzer jedoch das Recht, auf Dateien zuzugreifen, so kann er diese unbehelligt vom System problemlos auch Dritten zugänglich machen. Die Sicherheit beruht rein auf dem Vertrauen zum Nutzer und unterliegt keiner weiteren Überwachung (Discretionary Access Control). Bei einem TOS sind die zur Zugriffssteuerung genutzten Labels nicht durch Anwender oder Prozesse veränderbar, und deren Einhaltung wird durch das Betriebssystem überwacht (Mandatory Access Control). Das Übertragen von Zugriffsrechten an Dritte ist nicht möglich.
Statt eines "allmächtigen" Superusers arbeiten
TOS mit mehreren Administratoren nach dem Mehr-Augen-Prinzip (z.B.
System Administrator, System Operator und Information Systems
Security Officer).
Eine weitere Schwachstelle von Standard-Betriebssystemen stellt die gegenseitige Kompromittierung von Applikationen dar, die auf dem gleichen Server laufen. Gelingt es, einen Prozess zum Absturz zu bringen, so sind über die Betriebssystemebene auch die weiteren Datenbestände und Applikationen in Gefahr. Gleiches gilt für andere Systeme, die mit dem Server verbunden sind. Trusted Operating Systems teilen einen physischen Server jedoch in mehrere virtuelle Server, so genannte Compartments auf, die nach außen hin wie getrennte Systeme wirken. Damit lassen sich nicht nur verschiedene Applikationen trennen, sondern auch fehleranfällige Teile kapseln, wie beispielsweise die CGI-Scripts eines Webservers. Stürzen die CGI-Scripts ab, so bleibt das Ge-samtsystem weiterhin geschützt.
Das Hauptziel von Angriffen ist und bleibt jedoch die Übernahme der Root/Superuser-Rechte. Mit diesen Rechten kann man naturgemäß das komplette System kontrollieren und auch als Basis für Angriffe auf verbundene Rechner nutzen. Least Privileges entfernen die klassischen Superuser-Rechte und verteilen die darin vereinigten Privilegien per Default auf drei Administratoren, die nach dem Mehr-Augen-Prinzip tätig werden müssen. Damit sind nicht nur Kontrollmöglichkeiten und höhere Sicherheit gegenüber Fehleinstellungen gegeben, sondern auch die Übernahme der Root-Rechte nach Hacker-Angriffen extrem erschwert.
Das klassische Schutzkonzept basiert auf Isolation und
Überwachung der gefährdeten Server.
Unter einem Standard-Betriebssystem kann ein Angreifer zudem seine Spuren verwischen, indem er die entsprechenden Abschnitte der Logfiles entfernt. TOS isolieren daher die Log-Datei in einem separaten geschützten Bereich, um Manipulation zu verhindern. Dies garantiert die auch aus Revisionsgesichtspunkten wichtige Nachvollziehbarkeit aller Vorgänge.
TOS bilden damit die ideale Sicherheits-Plattform insbesondere für Anwendungen, die Offenheit erfordern. Denn TOS verlagern die Sicherheit nach innen, direkt auf den Server, um trotz offenen Zugangs zu bestimmten Diensten ein Höchstmaß an Sicherheit gegen Gefahren von außen und innen zu bieten. Diese Sicherheit ermöglicht auch neue System-Architekturen.
Bei klassischen Sicherheitsapplikationen beruht der Sicherheitsansatz auf Isolation (Firewall) und Überwachung (Intrusion Detection System). Da viele IT-Anwendungen und Geschäftsmodelle es erfordern, dass Nutzer die Marktplätze und damit Server betreten, kann die Isolation aber nie hunderprozentig sein. Damit muss die Firewall zumindest teilweise geöffnet werden und das Intrusion Detection System gewisse Aktionen auf dem Server als ge-wollt und erlaubt einstufen. Sobald der Nutzer sich auf dem Server befindet, ist dann keine wirkungsvolle Kontrolle mehr möglich. Doch auch die Sicherheitsapplikationen selbst sind Gefahren ausgesetzt. Gelingt es, deren Betriebssystem zu übernehmen, so können Angreifer sie aushe-beln.
Eine TOS-basierte Sicherung verlagert den Schutzmechanismus an
den "Ort des Geschehens", auf die Server selbst.
Der Fokus der TOS-basierten Lösung richtet sich nicht auf Sicherung nach außen, sondern auf den Schutz der Serverplattformen selbst, den "Ort des Geschehens". Durch die Kombination der dargelegten TOS-Funktionen ist es möglich, eine hochperformante und fundamental sichere Architektur ohne externe Überwachungssysteme zu realisieren. Auf Firewalls oder Intrusion Detection kann man für den Schutz gegen äußere Angriffe bei dem aufgezeigten Einsatz eines TOS komplett verzichten. Dadurch sind sowohl Performancesteigerungen und bessere Skalierbarkeit als auch geringere Kosten denkbar. Firewalls sind jedoch weiterhin wichtig zur Trennung von Netzen, die nicht durchgängig mit TOS gesichert sind.
Da prinzipiell jedes System eines Netzwerkes der Gefahr des Missbrauchs ausgesetzt ist, sollte man aber nicht nur die nach außen gerichteten Systeme wie Firewall oder Webserver durch ein TOS sichern, sondern generell jeden Computer, der sensitive Daten speichert oder verarbeitet. Dies gilt insbesondere auch für die Server mit Sicherheitsapplikationen wie Authentifizierung, VPN oder PKI.
So sind Transaktionen im Bereich von Banken und Versicherungen wie E-Banking oder E-Brokerage auf allen Ebenen besonders schützenswert, da hohe Werte und sensible Markt- und Kundendaten verarbeitet werden, meist über Online-Zugriff auf Back-End-Systeme. Zudem ist der Bankenbereich für Hacker-Angriffe besonders attraktiv, da die "gewonnenen Werte" für jedermann nutzbar sind. TOS können die Applikationen gegeneinander und den Zugriff auf die Back-End-Systeme an sich schützen. Gleichzeitig gewährleisten die Teilung der Zuständigkeiten und das geschützte Logfile die Revisionssicherheit.
Aber auch Patientendaten im Medizin- und Gesundheitswesen sind höchst sensibel und im Falle der Medikation sogar lebenswichtig.
Die im Intra- und Extranet liegenden Daten erfordern einen differenzierten Zugriff, abhängig von der jeweiligen Funktion des Bearbeiters (Pflegepersonal, Schwestern, Ärzte usw.). Dabei sollten nicht nur die Bearbeitungsmöglichkeiten des Datensatzes an sich, sondern auch dessen Darstellung abhängig von der Funktion des Nutzers steuerbar sein, was eine tiefe Verankerung des Zugriffsschutzes im System bedingt. Doch TOS ermöglichen nicht nur einen differenzierten Zugriff von innen, sondern auch durch externe Stellen, beispielsweise die Krankenkasse zu Abrechnungszwecken oder den Hausarzt zur Einsichtnahme in Untersuchungsergebnisse.
Prädestinierte Einsatzmöglichkeiten sind auch im ISP-/ASP-Umfeld vorhanden: Die Aufsplittung eines physischen Server-Systems in mehrere virtuelle Systeme (Compartments) liefert neben dem Sicherheitsgewinn auch eine erhöhte Servicefreundlichkeit. Auf Seiten der Anbieter können damit weniger, aber größere Systeme zum Einsatz kommen; entsprechend müssen auch weniger Systeme administriert werden. Womöglich sind sogar Einsparungen in Raum- und Investitionsvolumen sowie ein besserer Lastausgleich bei Peak-Situationen denkbar. Trotz mehrerer Kundensysteme auf dem gleichen Rechner bleibt durch die Compartments der Datenschutz gewährleistet. Auch die Übertragung gewisser definierbarer Administrationsrechte an den Kunden selbst ist realisierbar, ohne das Gesamtsystem zu kompromittieren.
Herstellerübersicht Trusted Operating Systems | ||
|---|---|---|
| Hersteller | Produktname | verfügbar für |
| ARGUS Systems Group | PitBull |
SUN Solaris 2.x, Solaris 7, IBM AIX, in Vorbereitung für Linux |
| Hewlett-Packard | VirtualVault |
HP Unix |
| Sun microsystems | Trusted Solaris |
SUN Solaris 2.x |
Thomas Weisschuh ist Product Marketing Manager Central Europe der ARGUS Systems Group (Europe) AG
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 4/2000, Seite 54
