Von der statischen Sicherheit zum virtuellen Schutzschild

Durch Virtualisierung mehrerer IT-Ressourcen versucht man Server-Farmen in Rechenzentren zu konsolidieren. Hatten die Unternehmen früher für jedes Betriebssystem beziehungsweise Anwendungssystem eine dedizierte Hardware im Einsatz, versuchen sie heute mittels Virtualisierung, Hardware besser zu nutzen oder zu reduzieren. Dabei sollen mehrere verschiedene Betriebs- und Anwendungssysteme auf einer Hardware installiert werden. Das ist vor allem die Erwartungshaltung der CIOs. Allerdings geht diese Rechnung so einfach nicht auf…

Virtualisierung löst in der Form ein Problem, das es gar nicht gibt. Bis zu diesem Punkt im Wunschdenken der CIOs müsste man eigentlich von Server-Provisionierung sprechen, das eignet sich viel besser für obiges Ziel, und wenn dies automatisiert stattfindet, dann erst recht. Die meisten Virtualisierungsprojekte verlaufen wie folgt: Hatte man anfänglich 123 verschiedene Server-Systeme, hatte man danach meist 123 virtuelle Maschinen (VM). Ich behaupte, der sicherste Weg einen Server aufzubauen ist, die Abweichungen auf dem Server, die durch den Systemeigner eingepflegt wurden, zu beseitigen, sprich: zu automatisieren. Server-Systeme sind immer noch derart einzigartig, dass man durch Virtualisierung 123 einzigartige Server auf einer VM am Laufen hat. Das nutzt nicht wirklich. Hinzu kommt, dass die Virtualisierung Risiken birgt, vor allem in der IT-Sicherheit, die – sehr oft vernachlässigt – schnell zum gegenteiligen Resultat des Geplanten führen können.

Nun, ich kann es leider nicht lassen vorwegzunehmen, dass ich vom Großrechner (MVS/XA/ESA/z-OS) stamme (und ich bin überhaupt nicht voreingenommen, denn ich arbeite nunmehr genauso lange mit Client/Server wie mit Mainframes, so dass ich sagen muss, dass viele jüngere IT-Leiter in größeren Unternehmen sich schwer tun diese klobigen Geräte zu akzeptieren. Meist fehlt dafür das Verständnis). Wer ernsthaft vorhat solche virtualisierten Umgebungen aufzubauen, sollte vorher abwägen, ob er unbedingt Client/Server-Verarbeitung benötigt, oder ob es nicht auch einmal ein Großrechner sein darf. Der kostet in seiner Anschaffung natürlich eine kleine Stange mehr Geld als Client/Server, doch in ihm steckt schon so viel Virtualisierung und Sicherheit, wie man dato in der Client/Serverwelt nicht einmal einkaufen könnte, selbst wenn das Geld dafür vorhanden wäre. Das muss auf Client/Server alles erst noch entwickelt werden. Für eine größere Firma sollte der Mainframe von der Kostenseite her kein Problem darstellen. Es wird von Tag zu Tag mehr, was die Fähigkeiten bezüglich IT-Sicherheit bei Virtualisierung in der Client/Server-Welt angeht – doch dem Großrechner ist in dieser Aufgabe noch nichts Gleichberechtigtes gewachsen.
Dieser Artikel ist als Ratgeber gedacht, was die Sicherheit in virtualisierten Umgebungen angeht. Ich möchte zum einen die größten Risiken aufzeigen, und in einem zweiten Schritt in einigen wesentlichen Sicherheitsmaßnahmen beraten.

Allgemeines, Wissenswertes, Hintergründe und Zukunftsaussichten
Man sollte wissen, was der Hypervisor ist. Ein Hypervisor ist in der Umgangssprache ein Software-Switch für virtuelle Maschinen. Er ist sozusagen der VM-Host. Ein Hypervisor hat im Gegensatz zu einem Windows-Betriebssystem sehr viel weniger Zeilen an Programmcode. Er sollte damit auch weniger Fehler im Programmcode beinhalten und nicht so angreifbar sein wie physische Betriebssysteme mit zum Teil bis zu 80 Millionen Zeilen Source-Code. Die Betonung liegt auf “sollte”. Ich bezweifle, dass es in Zukunft eine einzelne Lösung für die IT-Sicherheit in virtualisierten Umgebungen geben wird.

Durch Virtualisierung werden Einsparungen bei den Infrastrukturkosten erzielt, wenn diese richtig geplant ist, und man nicht durch die Nachbearbeitung zum Zweck der Sicherheit alles wieder drauflegen muss. Ich bezweifle jedoch, dass man dadurch auch massive IT-Sicherheitskosten einsparen wird. VM(ware) ist unumstritten eine Rechenzentrumsrevolution der Client/Server-Welt – und ich muss mich nicht dazu zwingen, das zu behaupten, doch himmelhochjauchzend macht es mich auch nicht.

Laut Gartner werden in 2009 etwa 60 Prozent der in Produktion gesetzten virtuellen Maschinen weniger sicher sein als ihre physischen “Serverkollegen”. Die Virtualisierung wird uns Folgendes bringen. Entweder wird der Virtualisierungsmarkt durch Schwachstellen in der IT-Sicherheit völlig zugrunde gehen, oder der Markt für IT-Security wird für die Zukunft wiederbelebt. Andreas Antonopoulos, ein netter Landsmann, Senior Vize Präsident und Gründungspartner von Nemertes Research, schreibt darüber in einem Artikel, der Anfang 2007 veröffentlicht wurde und den Titel “From Static Security to Virtual Shields” trägt – von dem ich mir die Überschrift für diesen Artikel geborgt habe.

2007 war die meistgestellte Frage bei der Virtualisierung von Rechenzentren “Wie viel Zeit und Geld spart uns das?”. 2008 wird die meistgestellt Frage sein “Wie sicher sind wir?”, was mir persönlich leider zeigt, dass wie so oft der An- und Verbindungstrieb der IT-Leiter und das “get the job done” wieder einmal stärker im Fokus stehen, als dass man sich richtig um die IT-Sicherheit kümmert. Bei richtiger Planung stellt man sich die letzte Frage gar nicht als letzte Frage.

Nach einer Quelle von IDC verwenden 75 Prozent aller Firmen mit über 1000 Mitarbeitern Virtualisierung in ihrer IT. Bei der Virtualisierung geht es in der IT-Sicherheit mehr oder minder immer um eine einzige Frage. “Sind virtuelle Server sicherer oder unsicherer als ihre physischen Pendants?”. Das ist leider die falsche Frage. Die Richtige lautet: ” Wenden Sie das, was Sie über IT-Sicherheit schon wissen, auch konsequent auf Ihre virtualisierten Umgebungen an?” Virtualisierung bedeutet zu 90 Prozent Planung mit dem Netzwerk-, dem Security- und dem Storage-Team. IT-Leiter vermeiden es, virtuelle Server in die DMZ zu stellen und lassen keine geschäftskritischen Anwendungen auf virtuellen Servern laufen. Diese Meinung kursiert insgeheim. Muss man annehmen, dass sie eventuell doch relativ unsichere Sache ist, die VM – also besser noch ein wenig “psssst leise” in Produktion testen.

Der Trend in der Industrie sieht vor, Hypervisors in die Hardwareplattform einzubauen. Ein Switch im Server, oder ein Server im Switch? Administratoren ohne Netzwerk-Know-how kann man von nun an nach Hause schicken, ach ja, und die Netzwerker ohne Administrations-Know-how auch. Firmen wie Dell und HP haben mitgeteilt, dass sie den VMware ESX 3i Hypervisor auf ihren physischen Servern ausliefern werden. Bei der Dell-Lösung können alle VM-Images auf dem SAN liegen. Der Server bootet sogar vom SAN. Phoenix Technologies stellt ein Bios her, in dem Hypervisor-Funktionen auf den Desktops und Laptops integriert sind. Damit kann etwa ein PC als Web-Browser oder E-Mail-Client schon verwendet werden, bevor überhaupt ein Betriebssystem gestartet wurde, und man kann endlich mal richtig leidenschaftlich surfen, und der URL-Blocker bekommt nicht einmal die IP-Adressse mit, denn die kommt ja bekanntlich erst mit dem Betriebssystem – doch bleiben wir beim Thema.

Bedrohungen und Risiken
VMware kann man nicht einsetzen, wenn in der IT-Umgebung viele I/O-Anforderungen erstellt werden. XEN kann nicht wirklich für Windows verwendet werden, und Solaris Container kann man nicht benutzen, um andere Betriebssysteme zu virtualisieren. Man erkennt schon an dieser Stelle des Artikels recht schnell, dass man unter Umständen mehr als einen Virtualisierungsansatz benötigt – ich spreche an dieser Stelle über Server-Virtualisierung und noch nicht über Storage-Virtualisierung.

Jedes neue Betriebssystem ist voller Sicherheitsschwachstellen. Virtualisierungs-Systeme sind neu und stellen dem Grunde nach ein Betriebssystem dar. Die ausgedehnte Verwendung von Virtualisierungs-Tools von bekannten Herstellern bietet Angreifern eine Menge relativ neuen und unerforschten Programmcodes, der von diesen nach Sicherheitslücken und möglichen Angriffsmethoden durchforstet wird. Man erinnere sich an den Patch von Microsoft in 2007, um eine Sicherheitslücke in ihrer Virtualisierungs-Software zu schließen. Diese Lücke ließ Benutzer mit administrativen Rechten, die nur auf ein spezifisches Gastbetriebssystem Zugriff hatten, andere wiederum ohne Rechte laufen. Dazu stufte Microsoft die Schwachstelle damals nur als “wichtig”, aber nicht “kritisch” ein. Wird schon alles “Gates” gehen.

Dass man mehrere Server-Systeme in einen einzelnen Server “quetschen” kann, ändert nichts an den IT-Sicherheitsanforderungen jedes einzelnen “gequetschten” Servers. Man merke sich: Die Sicherheitsanforderung jedes einzelnen gequetschten Servers ist gleich der Summe der Sicherheitsanforderungen aller gequetschten Server, doch der Stromverbrauch ist geringer. Hat ein virtualisierter Host eine Sicherheitsschwachstelle, entsteht für alle damit in Verbindung stehenden virtuellen Gastmaschinen und deren Anwendungen ein Risiko. Daher bestehen für einen einzelnen physischen Server weniger Risiken bei einer Schwachstelle, als für einen Server, der mehrere virtuelle Maschinen beherbergt. Man merke sich: Die Summe der Sicherheitsrisiken eines nicht gequetschten Servers ist niedriger als die Summe der Sicherheitsrisiken eines gequetschten Servers, und darüber hinaus noch niedriger als die Summe der Sicherheitsrisiken aller gequetschten Server, doch der Stromverbrauch ist höher.

Virtuelle Server unterliegen den gleichen Angriffsversuchen wie physische Server.Es gab noch nie ein Angriffserfolg, der ein Sicherheitsproblem von einem virtuellen Host auf einen anderen via Hypervisor-Technologie streute. Es könnte aber einmal passieren und dann könnte der Attackierende oder der Einbruch von virtueller zu virtueller Maschine springen beziehungsweise gelangen. Die Folgen müssen an dieser Stelle, glaube ich, nicht im Detail ausgeführt werden. Der Film hieße dann ApoVMkalypse now, oder ähnlich.

Die alte Schule lehrt uns Perimeter-Sicherheit, etwa durch die klassische Firewall zwischen Datenbank und Applikations-Layer. In virtuellen Umgebungen überschneiden sich die Grenzen der Perimeter-Sicherheit, und man sollte nicht an den mittelalterlichen Prinzipien der Perimeter-Sicherheit festhalten (zumindest werden einen solche Gedankengänge nicht wirklich ans Ziel führen). Hier werden ganz andere Tricks gefragt sein. Wuchernde Server-Farmen führen zu kritischen Zuständen im Schritthalten mit den Aktualisierungen und dem Patchen der Betriebs- “und schön wäre wenn” -Anwendungssysteme. Konnte man seine einzelnen physischen Systeme in der Vergangenheit schon nicht patchen – ohne jemandem zu nahe treten zu wollen- weil kein Wartungsfenster dafür frei war, wird man dies in virtualisierten Umgebungen noch eine Dimension heftiger erleben. Auch vermehren sich die Systeme und “swap-pen” auf der eingesetzten Hardware hin und her wie beim Ping-Pong. Daher ist es in der virtuellen Welt schwieriger, den Überblick über Patch-Stände zu bewahren, als dies normalerweise schon der Fall ist. Auch dauert das Patchen länger, wenn sich die Maschinen hinter der direkten Kontrolle – wie so oft – vermehren. Klonen geht relativ schnell. Software, die das Patchen in virtuellen Umgebungen automatisiert übernehmen kann, ist mir keine bekannt.

Ein weiteres Problem stellen Überwachungstools von virtuellen Maschine dar, mit denen Virtualisierungs-Funktionen verwaltet werden, da sie eine potenzielle Plattform für Angriffe auf virtualisierte Maschinen darstellen. Die Konsolen dieser Tools verwalten die Ressourcen der Hardware, die die virtuellen Maschinen beherbergen, und agieren als Interface zwischen der Hardware und den beherbergten virtuellen Servern. Da Überwachungssoftware und deren Konsolen nur eine Stufe über der Hardware angesiedelt sind – was man aus dem OSI-Nachhilfeunterricht kennt, kann man diese natürlich dazu verwenden, virtuelle, nicht entdeckte Angriffe auf das Betriebssystem und die installierten Anwendungsschichten über Überwachungssoftware zu starten. Es wird bestimmt schon alles gut gehen! Hier geht es ja nicht nur um Vertrauen, sondern auch um Mut.

IT-Sicherheit und Compliance sind in virtuellen Welten und in Projekten sehr viel schwieriger abzudecken als auf einzelnen physischen Maschinen, auf denen ein einzelnes Betriebssystem beziehungsweise ein einzelnes Anwendungssystem betrieben werden. Virtualisierung eröffnet eine Reihe potenzieller Netz-Zugriffskontrollproblemen. So hat der Host, der mehrere virtuelle Server mit unterschiedlichen Zugriffsanforderungen beherbergt, meistens nur eine einzige IP-Adresse (zu dumm für den, der die Rules auf der Firewall anlegt, die ACLs auf dem Router, …auf dem Switch, …den Hub steckt usw.). Regel Nummer Eins: Netzzugangskontrolltechnologien sind heutzutage noch nicht für Virtualisierungen geeignet.

Man verliert die Gewaltenteilung bei der Trennung administrativer Aufgaben in virtualisierten Welten – hinzu kommt, dass die Administratoren mit mehreren Ausprägungen eines zusätzlichen Komplexitäts-Layers fertig werden müssen. Man hat nur eine eingeschränkte Sicht in das Host-Betriebssystem und das virtuelle Netzwerk, um Schwachstellen zu finden, und die Kontrolle über die richtige(n) Konfiguration(en) zu bewahren. Man hat auch nur eingeschränkte Scanning-Möglichkeit von Inter-VM-Verkehr durch Intrusion-Prevention-Systeme in virtualisierten Umgebungen, zumindest benötigt man ganz spezielle, ganz teure Maschinen, die das können. Man sollte großen Wert auf ein ordentliches Budget für Sicherheit in virtualisierten Welten legen.

Mobile VMs und deren Sicherheitsrichtlinien stellen ein Problem dar. Es gibt nur unausgereifte und unvollständige Sicherheits- und Managementwerkzeuge zur Verwaltung virtualisierter Umgebungen. Virtualisierte Server müssen nach außen abgesichert werden, doch auch gegen die anderen virtuellen Maschinen geschützt werden.

Ich nenne vermutlich als erster eine neue Bedrohung in virtualisierten Server-Welten und bezeichne diese als “DominoVMpoolinfekteffekt” – man wird das Wort bestimmt bald im Duden nachlesen können. Damit meine ich, wenn ein einzelner virtuelle Server eines Pools durch eine veröffentlichte Schwachstelle infiziert wird, so wird der Infekt sofort an alle VM-Server übertragen, die die gleiche veröffentlichte Schwachstelle besitzen und perimetrisch nicht gegeneinander abgesichert sind – das möchte man sich nicht wirklich vorstellen, oder?

Die Hersteller von Sicherheitssoftware für virtualisierte Umgebungen halten sich an keinen Standard. Das wird dazu führen, dass alle Entwicklungen konzeptionell verschieden sein werden. IBM hat den Secure Hypervisor (sHype) entwickelt und ist stolz, dass Websphere schon in diesen Umgebungen arbeitet. Sun hat den Xen Open Source Hypervisor entwickelt, der schon in die neuste Version des Betriebssystems Solaris integriert ist. VMware ist mit seinen 20.000 Kunden “richtig satt und eben schlicht VMware” und stellt dar, dass die Sicherheit in virtualisierten Umgebungen sogar recht gut sei, doch leider nur in Bezug auf Backup und Disaster Recovery, und das mit Recht, behaupte ich.

Es gibt noch Hersteller von Hardware-basierenden Lösungen, die Hypervisor-Schutz anbieten möchten. So Intel und AMD. Symantec arbeitet mit Intel daran, eine Hardware-basierende IPS-Lösung für den Hypervisor zu entwickeln. So scheint Computer Associates einer der wenigen Hersteller zu sein, die sich am Industriestandard OASIS (Organisation for the Advancement of Structured Information) orientieren, und rügt zu Recht die anderen Hersteller, dass sie nur ihr eigenes Süppchen brauen.

Administration kann zur Schwachstelle werden. Nehmen wir an, man hätte VMware’s VMotion im Einsatz. Ein schönes Tool, das bei Maschinenproblemen hilft, VMs hin und her zu “swap-pen” – von einem Host auf den anderen. Ein Administrator könnte allerdings einmal per Zufall (oder auch nicht) zwei VMs miteinander kombinieren, die in der physischen Welt immer höchst separiert wurden, aus Gründen etwa des Netzverkehrs, wegen klassifizierten Anwendungen und Daten, die keinesfalls auf einer Maschine laufen sollten, Test und Produktion… und/oder aus anderen Sicherheitsgründen.

Bei einer stark anwachsenden virtualisierten Welt wird einen das Budget für nachträgliche IT-Sicherheitsmaßnahmen mit großer Sicherheit verlassen. Wenn man erst den Job erledigt und erst im Nachgang über Sicherheit nachdenkt, ist es schon zu spät – es sei denn, man gehört zur Executive-Klasse, die im Budget unendlich nachbuttern kann.

“Ge-fakte” IP-Adressen könnten von einem virtuellen Desktop, auf dem ein DHCP-Server installiert wird, erstellt und damit für Denial-of-Service-Attacken in virtualisierten Umgebungen verwendet werden. Das geht einfach. Es gibt noch mehr Schwachstellen…

Sicherheitsmaßnahmen
Eine gute Sicherheitsmaßnahme ist das Sequestrieren von virtuellen Maschinen in Ressource Cluster, die abhängig von der Sicherheitsklassifizierung der Anwendung sind (für alle, die das Wort nicht kennen – ich kannte es auch nicht, da ich dem Altgriechischen näher stehe als dem Altitalienischen – zwangsverwalten – wir Griechen würden es “Diktatur” nennen, das finde ich allerdings ein wenig zu hart).

Man sollte virtuelle Umgebungen gegen andere Umgebungen und andere VMs so weit wie möglich isolieren – und man frage bitte nicht “warum…”. In Umgebungen, in denen man Firewalls als physische Maschinen vor Ort einsetzt, kann man virtuelle Server auch in einer DMZ einsetzen. Noch sicherer ist, wenn man die Ressourcen auf den Clustern verteilt und eigene dedizierte Zugriffsregeln definiert, um ein Hin- und Herspringen (“swap-pen”) innerhalb des Clusters zu vermeiden.

Was einen Wert für das Unternehmen darstellt, sollte hinter der Firewall lokalisiert sein. Man frage mich an dieser Stelle bitte nicht hinter welcher… Virtuelle Maschinen sollte man in einem vertrauenswürdigem Netzsegment und Host laufen lassen. Stehen virtuelle Maschinen in einer DMZ, dann ist man gut beraten, vertrauenswürdige von nicht vertrauenswürdigen Netzwerken zu separieren.

Eine der Tugenden in virtualisierten Umgebungen sollte es sein, bei jeder einzelnen virtuellen Maschine auf alle Belange der IT-Sicherheit zu achten. IT-Abteilungen sind des Öfteren nicht gut auf die Komplexität virtueller IT-Umgebungen eingestellt, was das Verständnis der virtuellen Maschine an sich angeht, und welche davon aktiv und inaktiv sind, immerhin haben diese nur jahrelang testen dürfen, bevor man den Schalter auf “ERNST” gestellt hat. Man möge Software installieren, die virtuelle Maschinen erkennen kann. Man sollte strenge IT-Sicherheitsrichtlinien platzieren, die eine Ausbreitung virtueller Maschinen einschränken und regeln, und strenge Change-Management-Richtlinien, um den Zugriff auf die virtuellen Umgebungen (etwa durch Entwickler) einzuschränken.

Man etabliere separate Patch-Prozesse für alle virtuellen Maschinen. Die Netzzugangskontrolle für eine virtuelle Maschine auf dem Host sollte nicht für alle VMs gelten. Erinnern wir uns an das, was wir aus der Sicherheit bisher gelernt haben. Man sichere jeden einzelnen Server richtig ab, und wendet alles, was man bisher gelernt hat, darauf an. Man etabliere, wo notwendig, traditionelle Anti-Malware auf Servern und Desktops virtualisierter Maschinen. Dies erzeugt in virtualisierten Umgebungen allerdings einen Performance-Overhead bei der CPU-Auslastung von 5 – 50 Prozent. Man sollte sie trotzdem installieren, denn das lässt einen nachts wenigstens besser schlafen, und man setze nebenbei seinen Hersteller massiv unter Druck, diese Art von Software für den Hypervisor (den Softwareswitch) zu erstellen, und man drohe ihm mit Vertragskündigung oder ähnlichem.

In den meisten Fällen hat Virtualisierung im Unternehmen das Ziel, Server zu konsolidieren. VLANs helfen, die Unsicherheit virtualisierter Umgebungen zu kompensieren. Doch ist der VLAN-Ansatz weit weg vom Ideal, da die Sicherheitskomponenten statisch sind und gar nicht auf Änderungen in den virtualisierten Umgebungen reagieren können. Auch wird dieser Ansatz in sehr großen Firmen scheitern, zumal VLANs auch noch sehr schwer zu verwalten und zu grob gerastert sind, um als effiziente Sicherheitskontrolle zu dienen.

Man implementiere ausreichend Prozesse für Virtualisierung innerhalb der IT und bringe Virtualisierung in Cobit, ITIL oder BS15001, die IT-Fabrik, oder was auch immer man im Unternehmen für einen operationellen Standard mit mehr als etwa. 932 Seiten Text etabliert hat, ein. Man starte mit den Sicherheitsmaßnahmen für seine physischen Umgebungswelten und etabliere diese Schritt für Schritt auch in der virtualisierten Welt. Man setze eine zweite interne Firewall in der virtualisierten Welt ein, aber man sollte bitte vorher genau abwägen, welche Performance-Einbußen die IT-Umgebung dadurch erleiden wird, nicht dass man mich später noch etwa verklagen wird. Man gewähre Applikationsentwicklern nur minimalen Zugriff – und nur auf Testumgebungen – die produktive Welt “sollte” ohnehin tabu sein für diese sehr elitäre Spezies aus der IT-Riege.

Manche IT-Abteilungen haben schon Probleme, normale Application-Layer-Firewalls einzusetzen und zu konfigurieren, damit das dahinter liegende NAS oder SAN richtig gespeist, verwendet und bedient wird. Tier 1, Tier 2, Tier 3 …so viele Tiere. In virtuellen Welten ist dies noch um eine weitere Stufe schwieriger. Hat das dahinter liegende SAN eine Informationsklassifizierung in Stufen “public” bis “secret” für Anwendungen und Daten, so könnten durch Zulassung des falschen VMs und einer schlechten Zugriffsregelung Informationen auf jegliche vorstellbare Art und Weise missbraucht werden. Einen in Zonen unterteilter Storage muss eingeführt werden. Leider gibt es noch kein mir bekanntes Tool, das Speicher eines SAN nur einer VM zuordnen kann, aber ich heiße ja auch nicht Bruce, dieser allmächtige, aber vielleicht hilft uns hier bald Dell. Die können so viel, die haben bestimmt schon einen (Einkaufs-)Plan.

Wenn man VMs in einer DMZ einsetzen möchte, sollten diese auf physisch anderen Netzsegmenten liegen als die anderen IT-Systeme, wie etwa eine als kritisch einzustufende Datenbank.Auch sollte man die Sicherheitsmaßnahmen auf dem Client genauer unter die Lupe nehmen. VMs können auf einem Desktop betrieben werden. Mit VMware Player kann man mehrere unterschiedliche Betriebssysteme auf einem Client fahren und mehr, zum Beispiel virtuelle Appliances-Software-Produkte auf dem Client testen und auswerten, die noch in einem sehr rudimentären Patch- und Entwicklungslevel sind, und deren Schwachstellen bei Verteilung im Netz ein wahres Chaos auslösen können – zu dem Zeitpunkt hat man besser Urlaub. Alle die, die nun einen Geheimtipp von mir haben möchten – sollte es noch administrative Rechte auf Ihrem Computersystem geben – mögen mich jetzt bitte kontaktieren, doch der § 202c ist mir natürlich sehr heilig, fragen Sie bitte Herrn Schäuble.

Man installiere Kontrollen, die erkennen, wer eine VM-Workstation im Netz erhält.
Man auditiere periodisch die Inhalte von Benutzer-Festplatten (aber man sollte vorher eine gute Betriebsvereinbarung abschließen und man automatisiere den Vorgang bitte anonymisiert – und als alter Datenschützer mahne ich unbedingt daran zu denken, dass uns ausschließlich interessiert “was hat wer” und nicht “wer hat was?”). Man erwirke Budget beim Geschäftsführer oder Vorstand für das virtualisierte Sicherheits-Management, und man sollte vermeintlich darauf aufpassen, dass er einen nicht über den Tisch zieht und das Sicherheitsbudget in dem Maße konsolidiert, wie er das Budget anderer IT-Fachbereiche eindämmt, die normalerweise im Zuge der Migration von virtualisierten Umgebungen zum Schrumpfen verdammt sind – denn man wird es am Tage X bitter nötig haben, das Budget.

Ach ja, und bevor ich es vergesse zu erwähnen, oder hatte ich das schon einmal gesagt? “Man kaufe sich einen Großrechner”, wenn man in virtualisierten Client/Server-Welten alles ausprobiert hat und immer noch unzufrieden ist, und man lege die Nintendo-Gameboys wieder in den Schrank zurück – Spaß muss sein.

Gute Hersteller von Software für virtualisierte Umgebungen

  • Blue Lane Technologies
  • Reflex Security
  • StillSecure
  • EqualLogic (wurde von Dell übernommen)
  • Die oben genannten Hersteller haben ihren Appliances die Fähigkeiten gegeben, als softwarebasierende Schutzschilde in Virtualisierungssoftware, die VMware, XenSource und
    Virtual Iron beinhalten, zu arbeiten.

Hackingsoftware:

  • SubVirt – eine Software, die ein Root-Kit verwendet, um einen virtuellen Maschinen-Monitor unter dem Betriebssystem zu installieren. Dies erlaubt dem Angreifer, gleich mehrere  virtuelle Maschinen zu übernehmen auf dem Host.
  • Blue Pill – eine ähnliche Angriffsmethode wie SubVirt, dessen Root-Kit auf AMD’s Secure Virtual Maschine basiert, ermöglicht es, ein virtuelles System zu übernehmen und dabei  gänzlich unentdeckt zu bleiben.

Sicherheitssoftware

  •  Virtual Shield – macht Schnappschüsse von virtuellen Servern, inventarisiert offene Ports, erstellt aktive Service- und Anwendungsprotokolle und sendet Alarme aus, wenn gegen  Richtlinien verstoßen wird.
  • Virtual Security Appliance (VSA) – hat seine Hardware-basierende Firewall und IPS dahin gehend adaptiert, die als Linux-basierendes Gast-Betriebssystem auf einem VM arbeitet.<
  • CiRBA – Audit Tool für virtuelle Welten<
  • PlateSpin – Audit Tool für virtuelle Welten
  • Vizioncore – Tool für das Backup auf File-Ebene
  • Akorri – Performance Management und Workload Balancing
  • EqualLogic – bekannt für iSCSI Storage-Area Network (SAN) Produkte, die für virtualisierte Umgebungen optimiert wurden
  • VMware’s ESC 3i hypervisor – (aus Sicherheitsgründen nur 32 MB groß

27.07.2010
Alexander Tsolkas