TC Blog

M 2.300 Sichere Außerbetriebnahme oder Ersatz von Komponenten eines Sicherheitsgateways

Die Aussonderung von Geräten ist ein oft vernachlässigter Schritt im Lebenszyklus von IT-Systemen. Gerade bei Sicherheitsgateways oder Routern, aber auch bei anderen IT-Komponenten ist dies äußerst wichtig.

Der jüngste Vorfall zeigt recht deutlich, wie wichtig es ist, dass Geräte vor der Aussonderung von Restinformationen befreit werden.

Oft wird bei der Aussonderung nur an eine Entschriftung der Geräte oder an die Unbrauchbarmachung durch Kurzschluss der Netzteile (o. Ä.) gedacht. Eine Entschriftung alleine ist völlig unzureichend und mit etwas Aufwand kann man auch an die Daten im Gerät kommen, selbst wenn es kurzgeschlossen wurde. Vielmehr sollten weitere Aspekte berücksichtigt werden, so z. B.:

• Factory-Reset: Löschen aller Daten (Konfiguration, Logs, temporäre Daten, Schlüssel und Passwörter). In Sicherheitsgateways finden sich für potentielle Angreifer wichtige Informationen! „Die Vorgehensweise hängt dabei stark von der Art und vom Verwendungszweck des Gerätes ab. In der Sicherheitsrichtlinie für das Sicherheitsgateway sollten hierfür entsprechende Verantwortlichkeiten definiert werden.“ (Zitat aus dem Maßnahmentext)
• Prüfen, ob Restinformationen nach einem Factory-Reset noch vorhanden sind und nicht durch diesen gelöscht wurden. Falls nicht bereits geschehen sollten diese Informationen ebenfalls gelöscht oder durch mechanische Zerstörung gänzlich unbrauchbar gemacht werden.
•  (Wechsel-)Medien sollten aus dem Gerät entnommen werden und gesondert behandelt werden (hierfür gibt es einen eigenen Baustein).
• Ist ein Factory-Reset oder die Entnahme von Datenträgermedien nicht möglich, so sollten diese nach Möglichkeit mechanisch zerstört werden.

Weiterhin ist aber auch wichtig, dass bei einer (Teil-)Ersetzung bzw. Aussonderung der Komponentenlandschaft die Konfiguration der verbleibenden Komponenten dahingehend angepasst wird, dass die Nutzung der Konfigurationsdaten oder Schlüssel der gelöschten oder zerstörten Geräte (mögen sie in Frieden ruhen ) nicht mehr Nutzbar sind.

Die Aussonderung ist jedoch nicht nur bei Sicherheitsgateways wichtig, sondern bei allen IT-Systemen oder Daten. Weitere Hinweise hierzu können aus der Maßnahme M 4.234 Geregelte Außerbetriebnahme von IT-Systemen und Datenträgern entnommen werden.

Haben Sie die Aussonderung von IT-Komponenten in Ihren Komponentenlebenszyklus eingebettet? Deckt er bei Ihnen die wichtigen Aspekte vollständig ab?

Weitere Hilfe

Haben Sie überdies noch Fragen oder benötigen Beratung bei der Anpassung Ihrer Prozesse, so nehmen Sie einfach und unverbindlich Kontakt mit uns auf. Wir Beraten Sie gerne.

/sb

P.s.: dieser Post soll kein Fingerzeig in irgend eine Richtung sein, sondern soll vielmehr verdeutlichen, dass Maßnahmen der IT-Grundschutzkataloge Ihre Daseinsberechtigung haben.

Sicherheitspaket für Windows Server 2008 R2 fertigestellt

Nach den Veröffentlichungen der Sicherheitspakete für die Clients (Windows 7 und Windows XP), Server (Windows Server 2003) sowie des kostenlosen Sicherheitspakets für Browser wurde nun auch das Sicherheitspaket für Windows Server 2008 (R2) fertiggestellt. Dabei wurde wieder die gleiche Vorgehensweise wie bei Windows 7 verfolgt. Die Anforderungen der Grundschutzkataloge des Bundesamts für Sicherheit in der Informationstechnik (BSI) wurden um die Inhalte der Microsoft Security Baselines ergänzt.

Da Microsoft die Windows Server 2008 R2-Version im Kern immer noch auf Windows Server 2008 basiert, sind die technischen Anforderungen auf beide Versionen anwendbar. Unterschiede gibt es natürlich trotzdem, diese betreffen aber hauptsächlich Detailverbesserungen wie Stromsparfunktion, DirectAccess, BrancheCache und ein verbessertes Rollenkonzept.

Als Information zur Umsetzung der Vorgaben der Grundschutzkataloge sollte erwähnt werden, dass die Vorgaben des BSI für die Betriebssysteme Windows Server 2003 (B 3.108) und der Allgemeine Server (B 3.101)  nach bestem Wissen auf Windows Server 2008 angewendet wurden, da Windows Server 2008 leider noch nicht Teil der aktuellen Grundschutzkataloge ist.

Alle Informationen zu dem Produkt finden Sie auch auf unserer Homepage.

/ssu

Serie Cloud Security: Sind shared-images sicher?

Im Juni haben Darmstädter Forscher veröffentlicht, dass rund 30% von den 1100 untersuchten Images kritische Informationen beinhalten.

Dies haben Forscher aus Frankreich tiefgehender untersucht und dabei festgestellt, dass mehr als die Hälfte ihrer Untersuchungsgegenstände Informationen preisgaben, die besser vor Image-Freigabe hätten entfernt werden sollen.

Warum Image-Sharing?

Das Prinzip des Image-Sharings ist dafür gedacht, dass Entwickler für andere Entwickler bereits vorbereitete Systemumgebungen breitstellen (MI = Machine Image). Aber natürlich kann man es auch als Template verwenden. So kann mit relativ wenig zeitlichem Aufwand eine virtuelle Maschine gestartet werden (ohne Installation des Betriebssystems).

Was ist nun das Problem?

Untersucht wurden die auf allen Kontinenten frei verfügbaren AMIs (Amazon MIs). Dabei wurden diese auf Folgende Aspekte hin untersucht:

• sensible Restinformationen (private Schlüssel,Zugangsdaten in Konfigurationsdateien, Backup-Dateien oder der Command-History)
• Schwachstellen durch veraltete Software
• Installierte Backdoors und andere Malware
• Gelöschte Daten wiederherstellen

Gibt es eine Lösung?

Es gibt keine standardisierte Lösung. Sicherheit basiert auf Vertrauen. Offenbar vertrauen viele der Image-Ersteller auf den gutmütigen Nutzer und umgekehrt der Nutzer darauf, dass der  Image-Ersteller keine bösen Absichten hat, wenn Images erstellt oder zur Verfügung gestellt werden und diese durch Andere genutzt werden. Für den Fall dass ein Nutzer dem Image nicht vertraut, dann wird er es auch nicht verwenden und sich dann (hoffentlich) die Mühe machen ein eigenes Image zu erstellen.

Wenn jetzt ein Image-Ersteller sein Image unbedingt anderen Nutzern (es muss ja nicht öffentlich sein, es kann ja auch nur unter bestimmten Nutzergruppen geteilt werden) zur Verfügung stellen will, sollte unbedingt beachten, dass keine sensiblen Restinformationen wie zum Beispiel:

• Zertifikate oder Schlüssel
• Backupdateien
• Befehle (Command-History)
• Passworte wechseln (oder ganz entfernen) bzw. im Deployment-Prozess auf Zufallspasswörter zurückgreifen

hinterlassen werden. Die gelöschten Dateien sollten zudem sicher gelöscht bzw. überschrieben werden.

Viele Anbieter (hier als Beispiel Amazon) geben darüber hinaus auch Tipps zur Image-Erstellung und vorheriger Vorbereitung.

/sb

P.s.: Anlass gab der heutige Artikel bei Heise

Die Wolke hat keine Lücken

Die Schwachstelle in Amazons Cloud Service, die von Forschern der Ruhr-Universität  Bochum gefunden wurde, ist keine Schwachstelle in Cloud-Diensten. Das liest sich jedoch leider in manchen Meldungen, als sei der Cloud-Dienst verwundbar – nur wenige wählen die Überschrift besser. Vielmehr bestanden die Schwachstelle(n) in den Webanwendungen, die zur Verwaltung dieser Dienste genutzt werden. Schwachstelle in Webanwendung != Schwachstelle im Cloud-Computing bzw. Cloud-Dienst.

Verwundbar gewesen ist hier eine SOAP-Schnittstelle zur Verwaltung von EC2-Diensten gegenüber sogenannter XML-Signature Wrapping Attacken. Kurz zusammengefasst kann man sagen, dass dem signierten Inhalt der SOAP-Nachricht weiterer Content hinzugefügt bzw bestehender verändert wurde, der trotz Signaturprüfung zur Ausführung für valide gehalten wurde und dadurch verarbeitet wurde.

Weiterhin sind Cross-Site-Scripting (XSS) Schwachstellen entdeckt worden.

Sollten Sie neugierig geworden sein oder wünschen Sie Beratung zum Thema Webanwendungssicherheit bzw. Prüfung von Webdiensten, so nehmen Sie doch einfach und unverbindlich Kontakt mit uns auf.

/sb

M 2.319 Migration eines Servers

Aus gegebenem Anlass  einer erfolgreichen Migration mal wieder etwas zum Thema IT-Grundschutz.

Die im Titel genannte Maßname M 2.319 Migration eines Servers aus den IT-Grundschutz-Katalogen des BSI gibt einen guten Anreiz, was bei einer Migration eines Servers zu beachten ist:

• Welche Daten muss ich mitnehmen? Dabei wichtig: nicht nur Konfigurations- und Anwendungsdaten (wie in 90% aller Fälle) sollten übernommen werden. Sobald Kryptografie mit an Bord ist, sollte auch bedacht werden, dass die Schlüssel sicher transferiert werden.
• Wie schaffe ich Kompatibilität? Genaue Prüfung der Kompatibilität erspart so manche Mühen, denn treten Inkompatibilitäten auf, kann das gesamte Migrationsprojekt scheitern oder zumindest nicht im dafür vorgesehenen Rahmen erfolgreich sein.
• An welchen Rädern muss gedreht werden? Nicht nur IP-Adressen oder DNS-Namen wie in der Maßnahme genannt sind wichtige Aspekte, sondern auch weitere infrastrukturelle Aspekte wie z. B. Monitoring.
• Wo sind kritische Wege? Hilreich ist sich im Voraus auch eine oder einige Notfallstrategien zurecht zu legen.

Ungemein Hilfreich ist die Abarbeitung einer sorgfältig zusammengestellten Migrationscheckliste. So ist sichergestellt, dass alle geplanten, wichtigen Punkte abgearbeitet werden  (Und für Menschen, die es glücklich stimmt, wenn man etwas abhaken kann, ist dies zudem motivierend  – Randbemerkung: der Autor zählt sich nur bedingt zu dieser Gattung von Menschen ).

Weitere Hilfe

Sofern Sie ein schwieriges Migrationsprojekt vor sich haben und das gefühl haben, dass Sie Hilfe benötigen, so nehmen Sie einfach und unverbindlich Kontakt mit uns auf – wir unterstützen Sie gerne mit unserem starken Know-How und unserer zielstrebigen Vorgehensweise.

/SB

P.s.: Es handelte sich heute übrigens um einen Releasewechsel unserer Groupware und vorherigem Betriebssystemrelease- und Architekturwechsel von 32 Bit auf 64Bit. Ein vergleichsweise kleines Migrationsprojekt aus unserem Portfolio – aber auch das will geplant sein.