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.

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

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

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

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.

Vielfach liest man Empfehlungen wie etwa beim Portal „BSI für Bürger“

• Mindestens acht Zeichen
• Sonderzeichen und Ziffern
• Eselsbrücken helfen

Ein Beispiel für eine Eselsbrücke wird auch gegeben: Aus dem Satz “Morgens stehe ich auf und putze meine Zähne.” nimmt man nur die 1. Buchstaben: “MsiaupmZ”. “i” sieht aus wie “1″, “&” ersetzt das “und”. Das ganze ergibt: “Ms1a&pmZ”.

Dies ergibt eine Entropie von 51 Bits. Damit benötigt man 2 hoch 51 Versuche, um alle möglichen Zeichenkombinationen auszuprobieren. Nicht schlecht.

Nimmt man den Satz der als Basis für das „leicht zu merkende“ Passwort (ohne Leerzeichen und mit „ae“ statt „ä“), also „MorgenssteheichaufundputzemeineZaehne.“ ergibt dies eine Entropie von 142 Bits. Nur mit Groß- und Kleinschreibung und einem Sonderzeichen (dem Punkt). Man tippt vielleicht etwas länger, aber vertippt sich garantiert weniger oft.

Wie schnell man ein Passwort knacken kann, hängt neben der Komplexität des Passworts vom verwendeten Hash-Algorithmus ab. Das hat man als Endanwender nicht in der Hand, diese Entscheidung trifft der Programmierer.

Nutzt man die Passwörter für die Windows-Anmeldung, werden diese z. B. mit LM gehasht gespeichert. Bedient man sich einer GPU -beschleunigten Methode (man fand heraus, dass die Rechenaufgaben für „Passwort-Knacken“ und Grafiken bereechnen sich sehr ähneln und damit eine GPU deutlich schneller als eine CPU ist) und glaubt den Herstellerangaben , so kann man mit dieser Ausstattung fast unglaubliche 250 Millionen Passwörter pro Sekunde ausprobieren.

Da hält der kurze Merker immerhin gut 10 Tage, der lange Satz hingegen mehr als sieben Jahre einem Brute-Force-Angriff stand. In Konsequenz heißt das: Nehmen Sie lieber längere Passworte, als komplizierte Sonderzeichen, die zu einem Passwort führen, dass man jeden Morgen erst nach dem dritten Versuch erfolgreich eingibt – sofern das in Ihrer verwendeten Software möglich ist. Häufig erhalten Sie eine Fehlermeldung, z. B. das Sonderzeichen fehlen oder das Passwort zu lang ist (!).

Leider gibt es derzeit keine (uns bekannte) Möglichkeit, Entropie-Vorgaben für Passwörter in Standardprogrammen zu hinterlegen. Man kann zwar meist einstellen, wie lange ein Passwort mindestens sein muss, wie viele Sonderzeichen mindestens vorkommen müssen, aber wie man sieht haben diese Indikatoren sehr unterschiedliche Auswirkungen auf die tatsächliche Passwortqualität.

Es gibt natürlich noch weitere implementierungsabhängige Fragestellungen, ob ein Anmeldeverfahren als sicher gelten kann. So sind EC-Karten mit einer vierstelligen aus Zahlen bestehenden PIN gesichert, von erfolgreichen Brute-Force-Angriffen ist jedoch nichts bekannt, da die Karten nach drei Fehlversuchen gesperrt.

Dies ist sogar nach den Vorgaben des BSI in den IT-Grundschutzkatalogen zulässig. In Maßnahme M 2.11 Regelung des Passwortgebrauchs steht:

„Wenn für das Passwort nur Ziffern zur Verfügung stehen, sollte es mindestens 6 Zeichen lang sein und das Authentisierungssystem sollte den Zugang nach wenigen Fehlversuchen sperren (für eine bestimmte Zeitspanne oder dauerhaft).“

Ergebnis: Viele Jahre hat man uns antrainiert Passwörter für Menschen unlesbar, für Maschinen jedoch weiterhin leicht zu knacken zu gestalten. Eine gute Passwortrichtlinie sollte genau diese Aspekte reflektieren und prüfen, wie eine möglichst gute Entropie erzwungen werden kann, die dennoch zu gut merkbaren Passwörtern führt.

P:S.: für diesen Artikel gab es eine Inspiration

In Windows existieren Gruppenrichtlinieneinstellungen, welche sehr ähnlich klingen. Exemplarisch seien hier die Einstellungen “Domänenmitglied: Daten des sicheren Kanals digital signieren (wenn möglich)” und “Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)” genannt.

.

Die Grupperichtlinie “Domänenmitglied…” (M 5.89 Konfiguration des sicheren Kanals unter Windows) kann immer angewendet werden, da diese Einstellung lediglich bewirkt, dass die Kommunikation verschlüsselt wird sofern der Kommunikationspartner dazu in der Lage ist. Dabei wird bei der Anmeldung von einem Client am Domänencontroller versucht, die Kommunikation zu verschlüsseln, sofern der Kommunikationspartner, also der Domänencontroller, dazu fähig ist. Ist der Server dazu nicht in der Lage, wird die Kommunikation unverschlüsselt fortgesetzt.

Nach den Vorgaben des IT-Grundschutzes sind aus Kompatibilitätsgründen, sofern sämtliche Rechner im Informationsverbund auf Microsoft Windows basieren und höher als Windows 2000 sind, sämtliche oben aufgeführten Einstellungen zu setzen. Falls auch Linux-Betriebssysteme zum Einsatz kommen, sind zumindest die ersten zwei Einstellungen zu aktivieren.

Neben den Einstellungen für die Anmeldevorgänge gibt es weitere, welche die Kommunikation nach der Anmeldung, z. B. für die Ablage von Dateien im Netzwerk (über Datei- und Druckerfreigabe) bei Microsoft Windows zuständig sind. Diese lauten ziemlich ähnlich (“Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)”) und es ist sowohl bei den Einstellungen für die Authentifizierung an einem Domänencontroller, als auch die Einstellungen für das SMB-Protokoll möglich, die Einstellungen so zu setzen, dass die Kommunikation sowohl verschlüsselt als auch signiert durchgeführt wird. Als kleine Randinfo für Personen, die sich mit dem Thema näher befassen möchten, das Absichern des SMB-Protokolls wird in der Informationstechnik auch “SMB-Signing“ genannt.

Diese Funktion wird auch im Linux-Bereich durch den Samba Daemon ab Version 3 unterstützt und daher können diese Einstellungen im Regelfall immer, unabhängig vom Betriebssystem, umgesetzt werden.

Durch das Produkt „Sicheres Windows“ erhalten Sie eine konsolidierte Übersicht über diese und weitere technische Anforderungen, die in den Maßnahmen der IT-Grundschutzkataloge enthalten sind.

Diese Übersicht bietet den Vorteil, dass die Grundschutzkataloge nicht nach den relevanten Einstellungen durchsucht werden müssen. Falls Sie Interesse an der Dokumentation und an der Vorgehensweise für die Umsetzung der technischen Vorgaben haben, können Sie sich gerne über unsere Homepage bei uns melden.

/ssu

Begriffsdefinitionen erfolgen nur bedingt, man wird hier oder hier für den Einstieg fündig.

Der HBGary-Hack und der Zusammenhang mit Cloud-Sicherheit

Zu aller erst betrachten wir den Hack von HBGary im März diesen Jahres. Die sog. “Hacktivisten” Anonymous sind durch Ausnutzen einer Lücke im verwendeten CMS-Systems und weiterer Methoden an die Passwörter gelangt. Aber zurück zur Cloud-Security: CEO Aaron Barr war gleichzeitig Administrator des Google-Cloud-Accounts und dummerweise hatte er für dessen Zugang dasselbe Passwort, wie für das CMS, verwendet. Das ist ein anderes Thema, wir bleiben bei der Cloud-Security…

Durch diesen mehrstufigen Angriff hatten die Angreifer also das Passwort für administrative Zugänge der E-Mail-Verwaltung erhalten. Durch Änderung der Passworte der Benutzer konnten die Mails entwendet und gelesen werden. Dies war nur möglich, weil der Zugriff auf die administrativen Funktionen bei Google Mail und allen uns bekannten Cloud-Diensten standardmäßig per Benutzername und Passwort direkt über das Internet möglich ist. Ein Zugriff auf Infrastrukturkomponenten sollte jedoch nie ohne starke Verschlüsselung möglich sein, ein administrativer Zugriff am besten nur aus lokalen Netzen und nicht über das Internet bzw. wenn, dann eingeschränkt via VPN.

Neben dem direkten Zugriff trat ein weiteres, typisches Problem im Verlauf des Angriffs auf. Dieser wurde zwar vergleichsweise rasch bemerkt (was nicht schwer sein dürfte, wenn plötzlich keine E-Mail-Passwörter mehr funktionieren), jedoch konnte sich Barr gegenüber dem Google-HelpDesk nicht schnell genug authentifizieren, um den Service herunterzufahren. Das mangelhafte Incident-Handling ist der erste Kritikpunkt, den wir hier näher beleuchten.

SLAs hin oder her, diese bringen nur etwas, wenn man auch den Gesamtablauf des Prozesses testet, der für die Behandlung von Vorfällen, verbunden mit in der Cloud gehosteten Diensten, etabliert wurde. Manch einer hört da ganz leise das Wort “Notfallübung” des IT-Grundschutzes.

Das Ende vom Trauerlied liegt auf der Hand: Die Mails waren zwar verschlüsselt, jedoch für den Benutzer transparent abgelegt (d.h. sobald man Zugang zum Mailaccount hat, kann man die verschlüsselten Mails im Klartext lesen). Dadurch konnten die Mails abgezogen werden, da der Dienst nicht schnell genug vom Netz ging. Das führt zum zweiten Kritikpunkt: unsichere Speicherung von Daten in der Cloud. Sofern der Schlüssel nicht bekannt, trivial oder der verwendete Verschlüsselungs-Algorithmus nicht veraltet ist, sind die Daten für einen Angreifer unbrauchbar. Insbesondere, wenn Daten in der Cloud verarbeitet werden sollen (bei E-Mails z. B. für die Nutzung von Spam-Filtern), oder die Entschlüsselung gegenüber dem Endbenutzer transparent erfolgt, ist einem Angreifer das entschlüsseln, sobald er Kontenzugriff hat, möglich.

Fassen wir zusammen:

• Feindliche Angriffe auf Cloud-Dienste sollten in der Notfallvorsorge betrachtet werden (nicht immer nur der Ausfall von Diensten und Komponenten)
• Der Service des Providers sollte in jedem Fall getestet werden (nochmals: “Notfallübung” )
• Intransparente Verschlüsselung von Daten erhöht den Sicherheitsfaktor (damit der Usability-Faktor nicht darunter leidet können andere Mechanismen für Ver- und Entschlüsselung etabliert werden)

Alle Details zum HBGary-Hack stellten wir im Übrigen beim IT-Kolloquium „Sicherheitslecks in IT-Infrastrukturen“ im März 2011 vor. Wer Interesse an den Folien hat oder den Vortrag in seinem Unternehmen für Sensibilisierungsveranstaltungen nutzen möchte, kann uns jederzeit gerne ansprechen.

Weitere Hilfe
Wie immer hoffen wir, dass Ihnen die Informationen in unserem Blog möglichst konkret weiterhelfen. Sollten Sie darüber hinaus gehenden Beratungsbedarf haben, z. B. um die Sicherheitsmaßnahmen für Ihr Unternehmen gemeinsam zu untersuchen und zu verbessern, so nehmen Sie bitte unverbindlich Kontakt mit uns auf.

/sb

Einleitung
Mitte März 2011 schrieb Art Coviello, CEO bei RSA, einen offenen Brief an die Kunden. In einem „ausgeklügelten Angriff“ wurden „bestimmte Informationen“, davon „einige, die in direktem Zusammenhang mit der RSA Zwei-Faktor-Authentisierung stehen“ entwendet. Obwohl mit diesen Informationen nach Coviello kein direkter Angriff auf die Endkunden möglich wird, könnte die der Angriff die „Wirksamkeit der Implementierung der Zwei-Faktor-Authorisierung reduzieren“. Also die Kombination aus Besitz (Token) und Wissen (PIN).

Was genau passiert ist, ob etwa wie gemutmaßt der SecurID-Quellcode oder die Seeds, die für die Berechnung der von den Tokens generierten Einmalpasswörter (One-Time-Passwords, OTP) benötigt werden entwendet wurden, weiß man leider dank der Informationspolitik von RSA bis heute nicht.

Die Empfehlungen, die von RSA bzw. dem mittlerweile Mutterkonzern EMC herausgegeben wurden, helfen leider ebenso nur bedingt weiter. Weitere Informationen sind auch der Channel Communication Guideline, die an die Kunden direkt versendet wurde nicht zu entnehmen.
Man möge:

• Vermehrt den Fokus der Sicherheitsanstrengungen für Soziale Netze und die Nutzung durch Anwender, die Zugriff auf kritische Infrastrukturen haben, legen
• Starke Passwort- und PIN-Richtlinien durchsetzen
• Nur die Rechte vergeben, die ein Benutzer wirklich benötigt (Principle of least privilege)
• Den Authentication-Manager im Auge behalten
• Fernzugriff auf den Authentication-Manager einschränken
• Die Benutzer und das Help-Desk sensibilisieren

Auf die Frage, ob SecurID-Token-Records gestohlen worden sind, wird mit folgender lapidaren Begründung nicht geantwortet: “Im Interesse der Sicherheit unserer Kunden erteilen wir keine nähere Auskunft zu den ausgespähten Daten.”.

Welche Auswirkungen hat dies für die Praxis?
Leider kann man nur Annahmen treffen. Aufgrund der Aussagen vom EMC/RSA muss davon ausgegangen werden, dass die Generierung der OTPs vorhersagbar geworden ist. Dafür spricht auch, dass die „einige Abläufe“ seitens RSA unterbrochen worden sind, darunter die Vertriebstätigkeit (!). Insofern scheint das Problem nicht nur eine Datenbank mit Seeds zu betreffen, sondern man kann davon ausgehen, dass auch neu produzierte Tokens, die nicht in einer solchen Datenbank beinhaltet sind betroffen wären. Also scheinen die Informationen entwendet worden zu sein, die man braucht, um aus der Seriennummer des Tokens den jeweils gültigen OTP zu berechnen.

Wann kommt also nun ein Angriff in der Praxis mit dieser Annahme zum Tragen? Sobald ein Angreifer weiß, welche Tokennummer einem Benutzer zugeordnet ist und im Besitz der bei RSA gestohlenen Informationen ist, kann er mutmaßlich den OTP-Wert berechnen. Hierfür benötigt er wie bisher zumindest kurzzeitig den Token selbst oder muss (z. B. über Inventarlisten bei der Firma, die die Token einsetzt oder Bestellinformationen bei Distributoren) anderweitig an die Tokennummer gelangen. Damit kann man die Kenntnis der Tokennummer mit der Nutzung bzw. dem Diebstahl des Tokens gleichsetzen. Kann sich der Angreifer nun anmelden? Ab diesem Zeitpunkt ist der Angriff der exakt gleiche, der er immer schon war. Der Angreifer benötigt weiterhin die Adressen der Zugangsportale, an denen der Token verlangt wird, ebenso wie den Benutzernamen und die Zugangs-PIN.

Bisher benötigte ein Angreifer also:

• Token
• Passenden Zugangspunkt
• Zum Token passenden Benutzername
• Zum Token passenden PIN

Jetzt benötigt er (weiterhin eine Annahme)

• Token ODER Tokennummer
• Zum Token/Tokennummer passenden Zugangspunkt
• Zum Token/Tokennummer passenden Benutzername
• Zum Token/Tokennummer passenden PIN

Welche Handlungsempfehlungen lassen sich für IT-Sicherheitsbeauftrage, IT-Sicherheitsverantwortliche, CISOs in dieser solchen Situation ableiten?
Es wird davon ausgegangen, dass folgende Maßnahmen bereits in der Vergangenheit ergriffen worden sind. Falls nicht, ist dies in jedem Falle sofort nachzuholen. Die angegeben Beispielwerte stellen aus unserer Sicht für einen durchschnittlichen Sicherheitsanspruch belastbare Empfehlungen dar. Diese sind jedoch stets individuell zu bewerten.

• Regelmäßiges Ändern der PIN (z. B. 90 Tage, variiert je nach Sicherheitsanspruch)
• Definierte Komplexitätsanforderungen die PIN (z. B. 6 Zeichen alphanumerisch, variiert je nach Sicherheitsanspruche)
• Generierung der PINs durch das System, nicht Vergabe durch den Nutzer
• Sperren des Zugangs nach definierter Anzahl Fehlversuche (z. B .3 Versuche, variiert je nach Sicherheitsanspruch)
• Entsperren nur manuell
• Regelmäßige Prüfung der Authentication Manager-Protokolle auf fehlgeschlagene Logins und „Next Tokencode Required“ Meldungen (z. B. alle zwei Wochen, variiert je nach Sicherheitsanspruch)
• Regelmäßige Nutzersensibilisierung
• Help-Desk-Sensibilisierung
• Authentication-Manager wird Out-Of-Band und auf keinen Fall remote gemanaged
• Datenbank des Authentication-Managers ist geschützt
• Die Seriennummern der Tokens werden nirgends (z. B. in Inventarlisten) gespeichert

Es empfiehlt sich, die Maßnahmen zu überprüfen und darüber hinaus folgende Maßnahmen ad hoc zu ergreifen:

• Nutzerinformation über den Vorfall, Sensibilisierung
• PINs und Passwörter dürfen an niemanden, weder extern noch intern weitergeben werden
• Tokennummern und –Codes dürfen nur im Supportfall dem Helpdesk genannt werden. Beim Anruf des Helpdesks stets die Rufnummer prüfen oder das Helpdesk aktiv zurückrufen
• Eingabe des Token-Codes nur auf durch das Helpdesk benannte Adressen. Hierbei niemals einen Link anklicken, sondern die Adresse selbst ins Adressfeld eintragen
• Sensibilisierung des Help-Desks
• Prüfen der Authentisierungsmethoden gegenüber dem Helpdesk. Wie wird die Identität eines Anrufers verifiziert? Ist es einem Angreifer möglich, die Informationen die abgefragt werden auf anderem Weg zu erlangen? Wie werden neue PINs im Falle des Zurücksetzens übermittelt?

Stellen Sie einen schriftlichen Plan der zu ergreifenden Maßnahmen auf und besprechen Sie diese in Ihrem Sicherheitsteam bzw. mit den Administratoren. Dokumentieren Sie die ergriffenen Maßnahmen und begründen sie diese.

Gibt es mögliche weitere Probleme
Möglicherweise wurde auch Quelltext entwendet, so dass es Angreifern möglich sein könnte Schwachstellen in den Authentisierungsservern zu finden. Ist dies der Fall, kann dies theoretisch auch dazu führen, dass die Sicherheit der Gesamtlösung vollständig nicht mehr gegeben ist. Hält man dies für realistisch kommt man nicht umhin, die RSA-Lösung sofort außer Betrieb zu setzen und für eine äquivalente Lösung ohne Sicherheitsmängel zu sorgen. Dies scheint unserer Einschätzung nach jedoch für die meisten Einsatzbereiche derzeit nicht notwendig.

Nachsatz
Es ist für den Einsatz einer Sicherheitslösung wie RSA Secure-ID Tokens im Falle eines Einbruchs unerlässlich um die Gesamtsicherheit der Lösung zu wissen. Es ist in keinem Fall zuträglich, dass EMC/RSA die Sicherheit der Kunden vorschiebt, um nicht Stellung zu den entwendeten Daten beziehen zu müssen. Damit wird der Kunde letztlich allein gelassen und kann nicht mit ausreichender Sicherheit adäquat auf das durch EMC/RSA verursachte Problem reagieren.

Update 28.05.: Angriff auf Lockheed Martin Ende Mai
Am 28.05. veröffentlichte das Rüstungsunternehmen Lockheed Martin eine Mitteilung, dass Angriffe auf Ihre Infrastruktur erfolgten, aber dank der sofortigen Intervention nichts passiert ist. Dem Vernehmen nach steht der Angriff im Zusammenhang mit den Vorfällen bei RSA. So wurden die Remote-Zugänge zunächst gesperrt, neue Tokens verteilt und bei der Anmeldung ein zweites Passwort nach der eigentlichen Anmeldung verlangt.

Es ist fraglich, ob diese Sicherheitsmaßnahmen greifen, insbesondere was den Tausch der Tokens betrifft. Offensichtlich wird jedoch das Problem: Bei großen Unternehmen sind die Zugangsportale meist leicht zu finden und an eine gültige Tokennummer zu kommen, ist bei 100.000 (!!) Nutzern ebenfalls deutlich leichter, als bei vergleichsweise kleinen Nutzerkreisen.

Ändert sich durch den Vorfall die eingangs beschriebene Einschätzung und die abgeleiteten Empfehlungen? Nein. Der Fall bringt nichts Neues ans Tageslicht, auch wenn es natürlich beunruhigend ist, wenn ein Angriff gegen einen RSA-Kunden nun erfolgreich wird. Derzeit ist ein realer Angriff dennoch vergleichsweise unwahrscheinlich und die benannten Gegenmaßnahmen sinnvoll. Es könnte jedoch jeden Tag passieren, dass die Seeds für die Token-Berechnung im Internet veröffentlicht werden. Damit steigt die Gefahr von Angriffen massiv. Es ist daher sicherlich empfehlenswert, sich bereits heute für ein entsprechendes Szenario zu wappnen.

Update 06.06. Tokens werden getauscht
Also doch: RSA hat sich binnen kürzester Zeit *hust* dazu entschlossen, die Tokens zu tauschen. Alle. Auf Wunsch der Kunden. Der “offene Brief an die Kunden” ist wiedermal sehr lesenswert: Natürlich besteht weiterhin keinerlei Gefahr, wenn man die Best-Practice-Ansagen umsetzt. Diese ganzen Hacks der letzten Zeit gegen “Epsilon, Sony, Google, PBS, and Nintendo” stehen in keinem Zusammenhang mit dem RSA Problem – hatte das wer behauptet? Der Angriff gegen Lockheed Martin (siehe Update 28.05.) irgendwie schon, aber hey, Lockheed hat ihn ja vereitelt. Und der Angriffsvektor, der bei Lockheed Martin zum Tragen kam, ist kein neuer Angriffsvektor (der letzte Teil ist im Original unterstrichen). In anderen Worten: Das, was Lockheed Martin passiert ist, kann allen anderen auch passieren die SecurID einsetzen.
Wer übrigens nach einer Alternative sucht, bekommt eine Liste von Marktbegleitern direkt bei RSA..

Dieser Token-Tausch kann im Übrigen nur eines bedeuten: Die Seeds sind – wie bereits zu Beginn vermutet – entwendet worden. Das ist schlimm genug. Viel schlimmer aus unserer Sicht ist, dass die Seeds überhaupt bei RSA gespeichert wurden. Das ist das Secret des Kunden, der den Token einsetzt! Das hat bei RSA nichts, aber auch nichts mehr verloren, nachdem der Token produziert wurde. Insofern lohnt sich der Blick auf den Markt durchaus..

Weitere Hilfe
Wie immer hoffen wir, dass Ihnen die Informationen in unserem Blog möglichst konkret weiterhelfen. Sollten Sie darüber hinaus gehenden Beratungsbedarf haben, z. B. um die Sicherheitsmaßnahmen für Ihr Unternehmen gemeinsam zu untersuchen und zu verbessern, so nehmen Sie bitte unverbindlich Kontakt mit uns auf.

/GT

Diesen Monat dreht sich alles um die Einstellungen zum Thema BIOS. BIOS-Einstellungen können zwar je nach System auch zentral ausgerollt werden, meistens fehlt jedoch die entsprechende Software bzw. die dafür notwendige homogene Umgebung. Die gute Nachricht: In den Grundschutzkatalogen existieren lediglich zwei Anforderungen zur Absicherung des BIOS von Windows Clients (siehe Bild).

Es muss sowohl das BIOS-Passwort aktiviert, als auch die Boot-Reihenfolge definiert festgelegt werden. Die Reihenfolge ist so zu wählen, dass das Booten von anderen Medien verhindert wird. Für jeden Client-PC ist nach Grundschutz ein individuelles BIOS-Passwort zu vergeben. Da für Administratoren dadurch ein erheblicher Mehraufwand entsteht, stößt diese Maßnahme selten auf freudige Gesichter. Um das Setzen und Merken der BIOS-Passwörter zu beschleunigen, empfiehlt es sich,  zusammengesetzte Passwörter (z. B. aus Parameter wie Seriennummer und der ID des PCs) zu nutzen. So besitzt jeder Rechner ein individuelles Passwort. Damit wird das Einrichten bzw. Betreuen von Rechnern erheblich einfacher, als wenn man die Passwörter zunächst aus einer Passwortdatenbank holen muss. Bei dieser Methodik muss natürlich sichergestellt werden, dass die Regel zum Erstellen des Passworts nur einem kleinen Personenkreis bekannt ist und nicht nach außen kommuniziert wird. Natürlich ergibt sich dadurch die Problematik, dass beim Ausscheiden von Mitarbeitern, das Passwort nicht mehr sicher ist. Für hochsichere Informationsverbünde müssten hier sukzessive die BIOS-Passwörter mittels einer neuen Methodik geändert werden.

Alternativ können auch Passwortspeicher-Tools verwendet werden, jedoch besteht auch hier die Möglichkeit, dass ein potentieller Angreifer, der die Datenbank kopiert und anschließend ausscheidet, auch Zugriff auf sämtliche BIOS-Informationen eines Rechners erhält.

Letztendlich kann jeder Angreifer auch einfach die BIOS-Batterie ausbauen um an das gewünschte BIOS heranzukommen. Trotz allem erschwert diese Einstellung einem Angreifer das Kompromittieren von Systemen und das muss ja schließlich das Ziel eines Informationsverbundes sein

/ssu