Um für eine Vorlesung einen Überblick über gängige Security Standards und Methodologien zu geben, habe ich mir eine Mindmap dazu erstellt. Die Perspektive hierzu ist im wesentlichen Deutschland/Europa, andere nationale Standards/Guidelines habe ich nur selektiv aufgelistet, wo ich einen praktischen Mehrwert für den Alltag sehe. Ebenso habe ich weitgehend auf Branchen-spezifische Standards/Guidelines verzichtet.

Die Mindmap erhebt keinerlei Anspruch auf Vollständigkeit. Sollte jemand Anregungen oder Ergänzungsvorschläge haben, dann bitte einfach Kontakt aufnehmen. Ich empfehle die Nutzung des Freemind-Formats, da hier die Standards/Guidelines direkt verlinkt sind.

Download: Freemind-Format; PDF-Format
Lizenz: Creative Commons CC BY-SA

PCI-DSS is the Payment Card Industry Data Security Standard. If you are accepting credit cards for payment, you are probably aware of this standard and its requirements. In order to comply with PCI-DSS you have to be compliant with over 200 requirements. These requirements are partly very technical/specific and  partly very general.

One approach (the most often seen one) to implementing PCI-DSS is to get the requirements document, and

• compile a huge check list, one item per requirement
• find for each requirement the cheapest/easiest solution
• hire a PCI-QSA (Qualified Security Assessor – your external auditor) to attest compliance

Jede Firma hat Sicherheits-Schwachstellen, das dürfte unbestritten sein. Firmen, die ein Informationssicherheits-Management-System (ISMS) etabliert haben, haben damit in der Regel auch einen geordneten Prozess, wie mit den Schwachstellen umzugehen ist. Spätestens bei den Fragen “Wie schlimm ist es denn?” und “Was soll zuerst beseitigt werden?” treten dann aber Probleme auf. Hat man unterschiedliche Quellen, die einem Schwachstellen melden (externe Penetration Tester, interne Tester, Security-Listen  …) , dann hat jede dieser Quellen meist auch ihr eigenes System, um die Schwachstelle zu bewerten. Für fundierte Entscheidungen genügt dies nicht (ist “Nebenabweichung” schlimmer als “Mittelschwere Schwachstelle”  …?).

Manche Organisationen haben daher ein eigenes Scoring-System entwickelt, um etwaige Schwachstellen zu klassifizieren. Beispiele hierfür sind Microsoft und das US-CERT. Deren Scores sind aber nur jeweils in ihrem eigenen Kontext verwendbar, sie können nicht zur Klassifizierung beliebiger Schwachstellen verwendet werden. Aus diesem Grund wurde vor einigen Jahren das Common Vulnerability Scoring System (CVSS) entwickelt. Dieses stellt ein Framework zur Verfügung, um Schwachstellen einheitlich zu bewerten. Diverse Hersteller von Produkten (z.B. Vulnerability Scanner) verwenden mittlerweile diesen Score, um gefundene Schwachstellen zu bewerten. CVSS ist bereits in der Version 2.0 angekommen, hier wurden einige grundlegende Probleme angepasst. Seit das PCI (Payment Card Industry) Council den CVSS Score im Rahmen von ASV (Approved Scanning Vendor) Vulnerability Scans als Entscheidungskriterium für PCI-DSS (Data Security Standard) Compliance heranzieht, hat CVSS endgültig seinen Durchbruch geschafft und kann als etablierter Standard betrachtet werden.

CVSS bewertet Schwachstellen mit drei aufeinander aufbauenden Scores (mit einem Werte von jeweils 1-10, wobei 10 ein sehr hohes Risiko darstellt):

• Base Score: Wie der Name sagt, wird hier der Basis-Score für die Schwachstelle berechnet
• Temporal Score: Hier wird der Base Score mit zeitlichen Parametern bewertet. Beispielsweise ist hier relevant, ob gerade mal ein “Proof-of-Concept”-Code zur Verfügung steht, oder ob bereits ein Wurm die Schwachstelle vollautomatisch ausnutzt.
• Environmental Score: Der letzte Score bewertet das eigene Umfeld, aufbauend auf den Temporal Score. Hier wird zum Beispiel der Verbreitungsgrad der Schwachstelle im Unternehmen in betracht gezogen.

Hersteller von Sicherheits-Produkten können daher immer nur maximal den Temporal Score zur Verfügung stellen, der Environmental Score muss von jedem Unternehmen selbst berechnet werden.

In der Praxis hat CVSS seine Tücken, denen man sich bewusst sein sollte. Beispielsweise wird der Temporal Score durch einen Parameter namens “Remediation Level” beeinflusst. Hier wird der Score gesenkt (also, das Risiko geringer bewertet), wenn der Hersteller eines anfälligen Produkts beispielsweise schon einen Patch bereitgestellt hat. In der Praxis hilft das natürlich wenig (sprich: gar nicht), das Risiko zu minimieren, solange der Patch nicht eingespielt wurde. Wenn der Patch dann eingespielt wurde und wirksam ist, dann benötigt man wiederum keinen CVSS Score mehr, denn dann ist die Schwachstelle ja bereits geschlossen … Daher ist im Alltag zu empfehlen, diesen Parameter zu ignorieren, indem man ihn auf “n/a” setzt.
Ebenfalls sollte beachtet werden, dass sich CVSS nur zum Scoring von technischen Schwachstellen in Software eignet. Andere Schwachstellen können damit nicht bewertet werden. Daher sollte man nicht versuchen, CVSS als allgemeines Risiko-Scoring im Rahmen von Risiko-Analysen zu verwenden. Allerdings kann man CVSS sehr gut verwenden, um technische Software-Schwachstellen über eine geeignete Metrik in das eigene Risiko-Management einfließen zu lassen.

Was lässt sich nun in der Praxis mit CVSS anfangen? Ein guter Weg ist, CVSS in eine Policy für Vulnerability Management einzubetten. In dieser Policy beschreibt man die Prozesse zum Umgang mit Schwachstellen im Unternehmen. Der CVSS Score kann dann herangezogen werden, um Aktivitäten abhängig vom Score abzuleiten. Beispielsweise kann ein sehr hoher CVSS Score eine  Sondersitzung des Security Councils als nächsten Schritt nötig machen. Ebenso kann diese Policy mit einer Risiko-Management-Policy verlinkt werden, um, abgeleitet aus dem CVSS Score, eine Normierung auf einen Risiko-Index durchzuführen (für alle oder für ausgewählte Scores).

Zur praktischen Berechnung eines CVSS Scores sollte entweder ein geeignetes Hilfs-Tool (z.B. ein Excel-Sheet) erstellt werden, oder ein Online-Rechner herangezogen werden. Bei Online-Rechnern sollte beachtet werden, dass manche alten Rechner nur die Version 1 des CVSS berechnen und damit nicht mehr eingesetzt werden sollten.

Seit kurzem gibt es neben CVSS noch ein zweites, unabhängiges Scoring System: Das Common Weakness Scoring System (CWSS). Mehr dazu in einem Folge-Artikel.

Viele Firmen scheuen den Einsatz von Überwachungs-Software, um die Konfiguration und Aktualität Ihrer Betriebssysteme und Applikationen zu überprüfen, da entsprechende Tools relativ teuer in Anschaffung und Unterhalt sind. Microsoft bietet hier schon seit Jahren kostenlose Tools an, um dieses Problem (zumindest teilweise) zu lösen. Hierbei handelt es sich um den sogenannten Microsoft Baseline Security Analyzer (MBSA).

Was kann denn MBSA nun leisten? Die Software erlaubt, aktuelle Windows-Betriebssysteme und einige ausgewählte Applikationen zu prüfen. Die Prüfung umfasst dabei in der Regel den aktuellen Patch-Stand sowie grundsätzliche Konfigurations-Probleme. Das Tool kann sowohl mittels einer graphischen Oberfläche als auch mittels Kommandozeile genutzt werden. Grundsätzlich ist MBSA für den Einsatz auf einer lokalen Maschine ausgelegt. Das Tool wird also lokal gestartet und das Ergebnis dann lokal ausgewertet. Es besteht allerdings auch die Option, ein Remote-System zu überprüfen. Dazu muss auf der Kommandozeile Username und Passwort des Remote-Systems angegeben werden. Dies setzt natürlich voraus, dass die Sicherheitseinstellungen auf dem Remote System sowie die Konfiguration von Network Security Devices (Firewalls, IPS …) einen direkten Zugriff erlauben. Hier beginnen dann allerdings auch die Probleme, da Username und Passwort jeweils im Klartext auf der Kommandozeile angegeben werden müssen. Der verwendete Account muss Administrator-Rechte auf dem Zielsystem haben. Ein automatisierter Aufruf ist zwar mittels eines kleinen Skripts problemlos möglich, allerdings muss man sich im klaren sein, dass bei einem erfolgreichen Angriff auf das Scan-System alle Usernamen und Passwörter der Administrator-Accounts der Zielsysteme im Klartext verfügbar sind. Dies macht es nötig, das Scan-System maximal zu härten, ebenso sollte eine Mehrfachnutzung des Systems für andere Applikationen (E-Mail Server, Fileserver …) unterbleiben. Dies sollte im Zeitalter von Hyper-V allerdings kein großes Problem darstellen.

MBSA erzeugt für jedes Zielsystem pro Durchlauf einen Report. Dieser kann mit der MBSA GUI betrachtet werden. Der Report wird im XML-Format erzeugt, so dass auch ein eigener Parser erstellt werden kann, um die Ergebnisse systematisch auszuwerten und in einer Datenbank zu speichern. Bei Nutzung der MBSA GUI zur Analyse stößt man auch schnell an die Grenzen des Systems, da man damit jeden einzelnen Report manuell auswerten muss. Es stehen auch keine Optionen zum Vergleich von zwei Reports zur Verfügung, um zu ermitteln, was sich seit dem letzten Scan geändert hat.

Wem der Funktionsumfang von MBSA nicht genügt, kann das kostenlose Tool Shavlik NetChk Limited nutzen, das zusätzliche Applikationen unterstützt. Das Tool wird parallel zu MBSA installiert, die Auswertung der XML Reports kann innerhalb der MBSA GUI erfolgen. Jedoch ist auch mit Shavlik NetChk Limited eine vollständige Abdeckung aller Applikationen nicht möglich. Dies gilt allerdings auch für beliebige kommerzielle Produkte.

Summa summarum lässt sich sagen, dass MBSA (und Shavlik NetChk Limited) die Möglichkeit bieten, für Microsoft Betriebssysteme und bestimmte ausgewählte  Applikationen eine Basis-Sicherheitsprüfung mit relativ geringem Aufwand zu implementieren. Der Einsatz mit Auswertung über die GUI lässt sich allerdings nur für kleinere Netzwerke empfehlen, da die manuelle Auswertung umständlich ist und bei größeren Server-Zahlen nicht skaliert. Dies lässt sich zwar beseitigen, indem man die XML-Reports auswertet und in eine Datenbank bzw. in ein SIEM System importiert, allerdings verliert dann dass Argument zum Einsatz eines “kostenlosen Tools” schnell an Überzeugungskraft, da die Aufwände für Customizing nicht unerheblich sind.

Es ist immer wieder ein Phänomen: Man kommt in ein Unternehmen um Sicherheitsanalysen durchzuführen und irgendwann stößt man auf das Thema “Nutzung von Smartphones/PDAs”. In der Regel hört man dann vom Verantwortlichen für die IT “Alles hat damit begonnen, dass der Chef sich ein Smartphone gekauft hat …”.

Vorab gesagt: Es geht nicht darum, dass “die Sicherheitsleute immer alles verbieten wollen”. Smartphones gehören nun mal mittlerweile zum Arbeitsalltag, daran lässt sich in den seltensten Fällen etwas ändern (meist nur dann, wenn der Chef selbst kein Smartphone hat). Es geht auch nicht darum, über Sinn oder Unsinn der “Always On”-Kultur zu schwadronieren. Das würde den Scope eines Security-Blogs sprengen.  Dieser Artikel beleuchtet die Untiefen des Themas und versucht ein paar Tipps zu geben, um rechtzeitig steuernd einzugreifen.

Bevor man sich mit dem Thema “Smartphones” auseinandersetzt, sollte man sicherstellen, dass es vernünftige Regelungen für die Nutzung von Handys und Datendiensten im Unternehmen gibt. Spätestens wenn der Datenschutzbeauftragte das Verfahren “Telefonie” prüft, dann sollte man eine gute Antwort haben, ob man personenbezogene Daten (z.B. Einzelverbindungsnachweise) im Haus hat, und wie man mit diesen umgeht. Eine Analyse der Einzelverbindungsnachweise wird sich nur schwer abbilden lassen, wenn man Privatnutzung nicht verbietet oder keine Einwilligung dafür hat. Bei dieser Gelegenheit kann man auch gleich prüfen, ob die Personen, die Einzelverbindungsnachweise handhaben, alle auf Fernmeldegeheimnis (§88 TKG) verpflichtet sind.

Der ideale Zeitpunkt, um den Umgang mit Smartphones zu regeln ist, bevor sich das gesamte Unternehmen mit Smartphones verschiedenster Marken und Betriebssysteme ausgestattet hat. Etwaige Regelungen sollten hier in einer eigenen Policy/Richtlinie verwaltet werden.

Bevor wir über Lösungen reden, sollten wir uns der Probleme gewahr sein:

1. Wie will man sich schützen, wenn das Gerät geklaut wird?
   Ein typisches Smartphone enthält Unmengen personenbezogener Daten (Kontaktlisten …), unter Umständen die gesamte Email des Besitzers in Kopie, evtl. vertrauliche Dokumente, die mit mobiler Software geschriebenen werden, Passwortlisten und mehr.
2. Wie will man sich vor dem Abfangen von Emails schützen?
   Smartphone-Nutzer möchten in der Regel Zugriff auf ihren betrieblichen Mailaccount haben. Die Standard-Funktionen der Smartphones sind hier meist auch die unsichersten.
3. Wie will man sich gegen Schadsoftware schützen?
   Smartphones kommunizieren häufig mit dem Unternehmensnetzwerk. Aus Sicht eines Angreifers bietet sich das Smartphone als optimales Ziel, um darüber ein Unternehmensnetzwerk anzugreifen.

Die oben genannten Themen sind nur eine Auswahl einer größeren Problem-Liste. Um diese Probleme nicht unnötig zu multiplizieren, sollte man sich vorab auf auf eine einzige unterstützte Smartphone-Variante einigen. Um unnötige Grabenkriegen im Unternehmen zu vermeiden (“iPhone vs. Blackberry” …), sollte man vorab den Bedarf erheben und die relevanten Entscheider von einer einzelnen Lösung überzeugen. Da man bei Preisverhandlungen üblicherweise bessere Karten hat, je mehr Geräte man vom selben Typ einsetzt, hat man als Sicherheitsspezialist hier unter Umständen den seltenen Luxus, mit Kostenersparnis zu argumentieren.

Was sollte das Gerät der Wahl denn nun alles sicherheitstechnisch können? Orientieren wir uns dazu an der oben genannten Problem-Liste.

Das Gerät sollte sich sperren lassen, so dass bei einem Diebstahl die Entsperrung nur mit dem passenden Code erfolgen kann. Da der typische Anwender diese Sperre vermutlich innerhalb der ersten fünf Minuten deaktivieren wird, weil er sie als lästig empfindet, muss das Gerät zentral mit Richtlinie versehen werden können. Zentral bedeutet, dass man einen Konfigurationsserver hat, der diese Richtlinien an alle Smartphones automatisch verteilt. Eine dieser Richtlinien wäre dann, dass der Anwender die Geräte-Sperre nicht deaktivieren kann.
Bei der Entsperrung ist auch auf die Art der Entsperrung zu achten. Android-Smartphones lassen sich beispielsweise mit einem Zeichnungsmuster entsperren. Dies ist aber auf einem typischen Smartphone sehr einfach an den Fettspuren der Finger auf dem Display zu erkennen. Wenige Rate-Versuche führen hier zum Erfolg. Deshalb sollte man lieber bei PIN-Codes oder (besser) bei Passphrases bleiben. Man sollte allerdings die Richtlinie für die Länge der Passphrases nicht übertreiben, denn wer möchte schon bei jeder Nutzung des Smartphones eine 20 Zeichen lange Passphrase auf der Mini-Tastatur eintippen …

Eine weitere wichtige Anforderung im Unternehmens-Umfeld ist die Verschlüsselung der Daten. Es macht wenig Sinn, einen aufwändigen Zugangsschutz für das Smartphone zu implementieren, wenn ein Dieb nur die SD-Karte entfernen muss, um dann doch an alle Daten zu kommen. Daher sollte man per Richtlinie (nicht-optional) sicherstellen, dass der Datenspeicher mit einem vernünftigen Algorithmus komplett verschlüsselt ist. Speziell problematisch ist hier die Speicherung der Email, da hier üblicherweise die gesamte Email des Anwenders vorhanden ist. Wie relevant das ist, hängt von der Email-Strategie des Unternehmens ab. Wenn alle vertraulichen Emails End-to-Ende verschlüsselt werden, und man auf die Entschlüsselung auf den Smartphones verzichtet (da sich hier der Schlüssel mit der bisherigen Technik nicht vernünftig schützen lässt), kann man auf eine Verschlüsselung im Smartphone evtl. verzichten. Problematisch ist hier der Einsatz von Crypto-Gateways, da hier sämtliche Mails bei Eingang entschlüsselt werden. In diesem Fall (und in den “üblichen” Fällen, in denen in Unternehmen Email gar nicht verschlüsselt wird) kommt man um eine Device-Verschlüsselung nicht herum.

Ebenfalls ein interessantes Feature ist die Remote-Löschung des Smartphones. In der Regel wird dies über eine SMS mit einem bestimmten Inhalt (Key) ausgelöst. Dabei wird das Handy wieder in den Werkszustand versetzt. Hier gilt es zu prüfen, was genau in den Werkszustand versetzt wird. Speziell Speicherkarten sollten hier auch durch komplettes überschreiben gelöscht werden. Die wenigsten Apps bieten hier eine wirklich sichere Konfiguration. Gerade bei professionellen Dieben sollte man sich aber von diesem Feature nicht zu viel versprechen, denn diese werden in der Regel die SIM-Karte zuerst entfernen.

Ebenfalls ein häufig angebotenes Feature ist die Remote-Ortung des Smartphones. Dabei wird das Smartphone bei einem Dienst-Anbieter registriert, der auf Nachfrage die Funkzelle bestimmt, in der das Handy eingebucht ist. Bevor man derartige Features nutzt, sollte man vorher die rechtliche Lage prüfen, da man hier problemlos ein komplettes Geo-Tracking des Nutzers umsetzen kann. Auch hier gilt: professionelle Diebe werden als erstes die SIM Karte entfernen, der Nutzen dürfte in der Realität für Firmen eher gering sein.

Punkt zwei auf unserer Problem-Liste war der Schutz vor dem Abfangen von Emails. Eigentlich alle Smartphones bieten Schnittstellen für pop3 und imap, manche bieten Schnittstellen für Exchange-Server, pop3s und/oder imaps. Hier sollte man darauf achten, dass die Kommunikation zwingend verschlüsselt ist (über imaps, pop3s oder verschlüsselte Exchange-Kommunikation) und dass das Smartphone das Protokoll der Wahl auch unterstützt. Insbesondere sollte man sich nicht auf einen Automatik-Modus bei der Anbindung des Email-Servers verlassen, weil sich die meisten Geräte hier für unverschlüsselte Kommunikation entscheiden, auch wenn es verschlüsselte Protokolle als Option gibt. Bei hauseigenen Lösungen mit externen Dienstleistern wie bei Blackberrys muss darauf geachtet werden, dass eine adäquate End-To-End Verschlüsselung zum Einsatz kommt. Bei Blackberrys kann dies beispielsweise durch Nutzung eines Blackberry BES umgesetzt werden.

Der dritte Punkt auf unserer Liste ist “Schutz vor Schadsoftware”. Gegenwärtig ist noch relativ wenig zu hören von Schadsoftware auf Smartphones, allerdings finden sich immer mal wieder Hinweise auf trojanisierte Software. Idealerweise gibt man dem Anwender ein vorkonfiguriertes Smartphone und erlaubt ihm nur den Einsatz freigegebener Software. Zur Sicherheit sollte auch eine Antiviren-Software auf dem Smartphone installiert werden, auch, wenn deren Wirkung gegenwärtig eher noch übersichtlich ist (in Ermangelung von großer Mengen an Schadsoftware). Bei einem komplett vorkonfigurierten System macht auch eine lokale Firewall Sinn, die nur die absolut notwendigen Dienste erlaubt. Firewalls, die den Anwender nach Entscheidung fragen (“Darf ich eine Verbindung von A nach B zulassen?”) machen eher weniger Sinn, da der typische Anwender nicht tief genug in die Materie eingetaucht ist, um eine fundierte Entscheidung zu treffen.

Zuletzt sollte man für das Betriebssystem/die Marke der Wahl prüfen, ob es spezifische Schwachstellen gibt, die ein Angreifer nutzen könnte. Beispielsweise muss man unter Android darauf achten, dass der Anwender das Feature “USB Debugging” nicht aktiviert, da ein Angreifer sonst munter beliebig Software über USB installieren kann. In diese Themen-Kategorie fällt auch das Thema “rooten”. In dem Moment, wo ein Anwender das Smartphone rooted, können alle Sicherheitsmaßnahmen des Unternehmens ausgehebelt werden. Hier gibt es zwei Lösungsansätze: Entweder man setzt Software ein, die ein rooting erkennt und Alarm auslöst, oder man verbietet jegliche Änderungen am Smartphone per Policy (verbunden mit entsprechenden Sanktionen) und führt regelmäßig Stichproben durch.

Die beschriebenen Themen können dazu dienen, eine eigene Entscheidungsliste aufzubauen. Mit Sicherheit wird man, egal, für welches Smartphone man sich entscheidet, nicht alle Themen abdecken können. Ebenso sicher ist, dass eine Entscheidung nicht rein aus sicherheitstechnischen Überlegungen getroffen werden wird. Mit einer vernünftigen Strategie, die auf klare Anforderungen aufbaut, kann man aber wenigstens versuchen, steuernd auf solche Diskussionen einzuwirken.

Ein beliebtes Thema bei Security Audits ist die Prüfung der Passwort-Verwaltung bei Usern. Das Thema ist (für ein IT Thema) uralt, in vielen Betrieben scheint dafür aber immer noch keine vernünftige Lösung gefunden zu sein. In Umgebung, in denen es keine Erzwingung von Passwort-Komplexitätsvorgaben gibt, ist die Verwaltung für die meisten User relativ einfach: sie verwenden einfach ein extrem simples Passwort für alle Anwendungen und Anmeldungen. Da in den gängigen Betriebssystemen die Umsetzung von Komplexitätsvorgaben relativ einfach erzwungen werden kann, ist dieser Fall heutzutage selten geworden. Stattdessen wird den zum Teil sehr komplexen und langen Passwortvorgaben damit begegnet, dass man die Passwörter einfach aufschreibt. Bevorzugt auf einen Post-It am Monitor oder unter der Tastatur.

Häufig wird vergessen, den Usern mit der Einführung von komplexen Passwörtern auch eine Möglichkeit zu geben, diese vernünftig zu verwalten. Die meisten User verwenden die PostIt-”Verwaltung” nicht aus Boshaftigkeit, sondern weil sie keine anderen Optionen gezeigt bekommen.

Hier kommen Passwort-Manager ins Spiel. Diese Tools erlauben den Usern, sämtliche Passwörter zentral zu speichern, und mit einem einzigen (komplexen) Passwort zu schützen. Der Grad an Sicherheit, den man hier gewinnt, hängt natürlich direkt mit der Auswahl des richtigen Passwort-Managers zusammen. Idealerweise gibt man in einem Firmen-Umfeld ein bestimmtes Tool für diese Aufgabe frei und schult die User in der Nutzung durch die Erstellung eines “HOWTOs”. Dies verhindert Wildwuchs von Passwort-Tools, die evtl. nicht einmal den Mindest-Vorgaben entsprechen.

Bis vor kurzem waren Online-Passwort-Manager groß in Mode. Hierbei werden die Passwörter “In der Cloud” gespeichert und sind von überall aus zugreifbar, wo man Online ist. Unbeirrt von den Warnungen von Sicherheitsexperten fanden diese Dienste großen Zulauf. Seit dem vermuteten Hacker-Angriff auf LastPass dürfte diese Euphorie etwas nachgelassen haben. Das Problem bei diesen Diensten ist, dass der Dienstleister Zugriff auf die Passwörter hat. Bei einem erfolgreichen Einbruch kann dann eben auch nicht ausgeschlossen werden, dass der Angreifer ebenfalls Zugriff auf die Daten hat. Ganz abgesehen davon stellt sich bei Dienstleistern aus nicht-europäischen Ländern natürlich die Frage, wie einfach Strafverfolgungsbehörden “eben mal so” Zugriff auf diese Daten nehmen können, auch ohne richterlichen Beschluss …

Ein ebenso schlechter Ansatz ist die Nutzung der eingebauten Passwort Manager der diversen Browser. Zwar hat sich beim Thema “Browser-Sicherheit” in den letzten Jahren viel getan, allerdings ist bei einem erfolgreichen Browser-Angriff der Zugriff auf die Daten im Browser, in diesem Fall auf die Passwort-Datenbank, in der Regel nicht weit entfernt. Abgesehen davon bieten viele Browser mittlerweile die Möglichkeit, die Daten “in der Cloud” zu speichern, wobei wir wieder bei Problem Nummer 1 wären. Zuletzt ist hier auch zu bedenken, dass diese Passwort-Manager nur dafür ausgelegt sind, Web-Passwörter zu speichern. Man hat hier immer noch keine Lösung für Betriebssystem- und Applikations-Passwörter.

Eine gute Lösung ist die Nutzung ist die Nutzung eines lokalen Passwort-Managers, der die Daten entweder lokal oder auf einem persönlichen Laufwerk stark verschlüsselt abspeichert. Aus persönlicher Erfahrung kann ich hier KeePass empfehlen. Die Nutzung ist auch einem unerfahrenen User einfach beizubringen und das Tool steht kostenlos für die klassischen User-Betriebssystem (Windows, Linux, MAC OS X) zur Verfügung. Die gesamte Datenbank ist standardmäßig AES verschlüsselt, so dass ein direkter Angriff auf die Datenbank wenig erfolgversprechend ist. Für unterwegs gibt es eine Portable-Version.

Zum Schluss noch ein Gedanke zur Passwort-Verfügbarkeit: Bei der Einführung eines Passwort-Managers in Unternehmen sollte man sich sicher sein, dass man über geeignete Prozesse einem User, der sein Master-Passwort vergisst, wieder Zugriff auf seine Accounts geben kann. In der Regel sollte das aber kein Problem sein, da man diese Lösung ja auch bei einer “Post-It Verwaltung” benötigt.

Immer wieder kommt es vor, dass man im Firmen-Umfeld plötzlich das Bedürfnis verspürt, Daten verschlüsselt zu kommunizieren, ohne die notwendige Infrastruktur dafür zu haben. Langfristig besteht dann natürlich die Möglichkeit, eine entsprechende Infrastruktur (z.B. durch ein Crypto-Gateway, einen pgp/gpg-Rollout oder durch eine PKI-Intergration mit S/MIME) aufzubauen. Kurzfristig hilft dies allerdings nicht weiter, da sich keine dieser Maßnahmen “eben mal so” implementieren lässt. Hier stellt sich dann die Frage, welche Optionen man für kurzfristige Übergangslösungen hat.

Im Wesentlichen hängt die passende Lösung von den Möglichkeiten des Empfängers ab:

• Falls bereits eine Crypto-Infrastruktur beim Empfänger besteht:
  Hat der Empfänger ein Crypto-Gateway, dann kann dies unter Umständen genutzt werden, ohne dass man eigene Software benötigt. Manche Crypto-Gateways bieten eine Webmail-Schnittstelle, bei der der Sender einen Account eingerichtet bekommt, mit dem er Senden und Empfangen kann. Die eigentliche Kommunikation wird dann mittels https verschlüsselt.
  Hat der Empfänger eine pgp/gpg Infrastruktur, dann kann bis zur Umsetzung einer permanenten Crypto-Lösung erst einmal mit Einzelplatzlösungen gearbeitet werden. Setzt man  selbst Outlook ein, dann bietet sich der Einsatz von gpg4win an. Für Outlook 2003 und 2007 ist in dem Programmpaket das Modul GpgOL enthalten. Für Outlook 2010 steht diese Lösung nicht zur Verfügung. Kommt dagegen Thunderbird als Email-Lösung zum Einsatz, dann kann man das Plugin enigmail zusammen mit gpg nutzen. In beiden Fällen muss man selbst-generierte Schlüssel einsetzen, da eine Firmen-Infrastruktur fehlt.
  Hat der Empfänger eine S/MIME Infrastruktur, dann man zwar theoretisch auch dafür eine lokale Lösung finden. Praktisch ist dies aber schwierig, da man in einem Firmen-Umfeld in der Regel nicht selbstständig Zertifikate importieren kann.
• Falls der Empfänger keinerlei Crypto-Infrastruktur hat:
  Erfahrungsgemäß wird man sich schwer tun, einen Empfänger zum Aufbau einer komplexen Crypto-Infrastruktur zu bewegen. Hier müssen dann alternative Methoden eingesetzt werden.
  Der einfachste Weg ist der Einsatz von verschlüsselten ZIP-Dateien. Hierzu wird einmalig ein Schlüssel zusammen mit dem Kommunikationspartner festgelegt. Der Schlüsselaustausch sollte natürlich nicht gerade per Mail stattfinden, da ein Angreifer, der Klartext-Mails abfangen kann, damit auch gleich das Passwort abhören kann. Am besten vereinbart man das Passwort per Telefon oder tauscht es per SMS aus. Der Schlüssel sollte möglichst komplex sein, keine Wörter aus einem Wörterbuch enthalten, und hinreichend lang sein (10 Zeichen sind ein guter Grundwert). Zu guter Letzt: Mit jedem Kommunikationspartner sollte ein eigener Schlüssel generiert werden.  Als Software kann man gute kostenlose Tools einsetzen (z.B. Pea ZIP,IZArc oder 7-Zip). 7-Zip steht auch unter Linux-Betriebssystemen zur Verfügung. Hat man im Unternehmen sowieso eine Winzip-Lizenz, dann kann man dies natürlich auch nutzen. Bei allen Tools sollte man darauf achten, dass man als Verschlüsselungs-Algorithmus “AES 256″ einstellt. Die schwache PKZIP-Verschlüsselung ist sehr einfach zu brechen, andere Verfahren (z.B. AES 128 oder AES 192) werden nicht von allen Tools unterstützt.
  Besteht keinerlei Option zur Installation eines Tools auf beiden Seiten, dann bleibt nur der Einsatz eines alternativen Mediums. Dies kann zum Beispiel ein oben beschriebenes existierendes Crypto-Gateway sein, oder zum Beispiel der Einsatz eines Datei-Servers, der eventuell schon bei einem der Kommunikationspartner zur Verfügung steht. Viele Unternehmen setzen beispielsweise heutzutage Sharepoint-Server ein. Wenn der Sharepoint-Server für externe Kommunikation eingesetzt wird, dann kann man hier relativ einfach einen Bereich zum Datenaustausch einrichten. Der andere Kommunikationspartner benötigt dann nur noch einmalig einen Account, und kann ab dann seine Daten über den Web-Browser via https verschlüsselt auf den Sharepoint-Server hochladen.

Zum Abschluss sollte beachtet werden, dass die oben beschriebenen Lösungen als Workaround in großen Unternehmen eingesetzt werden können. Ein vollwertiger Ersatz für eine vernünftige Crypto-Struktur sind sie in der Regel nicht. Dies fällt sehr schnell auf, wenn man beispielsweise die ZIP-Passwörter für 100 oder mehr Kommunikationspartner verwalten muss. Oder, wenn man die Passwörter alle wechseln muss, weil ein Kollege die Abteilung verlässt, der die Passwörter kennt. Daher empfiehlt sich rechtzeitig die Implementierung einer unternehmensweiten Crypto-Infrastruktur. Dies ist heutzutage eigentlich eine Pflichtübung für nahezu alle Unternehmen.

Jeder hat vermutlich schon das Ergebnis von URL Shorteners gesehen. Aus dem Link “http://www.forinsect.com/datenschutz” wird zum Beispiel “http://v.gd/UTnoib“. Dies ist gerade für Twitter-Fans und SMS-Nutzer praktisch, die eine Zeichenbeschränkung bei Nachrichten haben. Mittlerweile sieht man die gekürzten Links allerdings überall, viele Blogs enthalten nur noch gekürzte Links.

So bequem das Ganze ist, hat dies natürlich auch Sicherheits-Implikationen.

Ein simpler Effekt beim Einsatz eines URL Shorteners ist erstmal, dass ein Leser nicht mehr auf den ersten Blick sieht, wo der Link eigentlich hinführt, auf den er gerade klickt. Gerade im Unternehmens-Umfeld, wo man den Mitarbeitern im Zeitalter von Phishing beibringt, nicht mehr blind auf jeden Link zu klicken, sind URL Shortener kontraproduktiv. Auch automatische Systeme wie SPAM-Filter lassen sich damit zum Teil umgehen, da diese die URL nicht mehr so einfach auswerten können. Für Web-Proxy-Filter ist das Thema allerdings weniger relevant, da nach der Auflösung der verkürzten URL vom Browser die dahinter liegende Seite angesteuert wird. Spätestens hier würde die Seite geblockt, wenn sie auf der Sperrliste ist.
Um zumindest für den Anwender das Leben zu erleichtern, besteht die Möglichkeit, einen URL Shortener mit Preview-Funktion zu verwenden.  Wenn Sie auf den gekürzten Link oben klicken, dann können Sie dies einfach selbst ausprobieren.

Ein anderes Thema ist die Datenhaltung. Der Betreiber eines URL Shorteners kann nicht unerhebliche Daten, nämlich die Kommunikationsprofile der Anwender, die auf die gekürzten Links klicken, sammeln. Dies ist auch ein Feature, das Marketing-Fachleute sehr an diesen Diensten schätzen, da man seine Kunden damit sehr effizient analysieren kann. Damit kommen wir auch schon zum Thema “Datenschutz”. Ich kann Ihnen nur empfehlen, einmal einen genaueren Blick auf die Datenschutz-Erklärung des URL Shorteners Ihrer Wahl zu werfen. Mit etwas Glück finden Sie vielleicht eine Datenschutz, gerade bei so manchem Dienst im Nicht-Europäischen Ausland wird die Luft hier allerdings schon sehr dünn.
Sollten Sie einen Dienstleister haben, der eine Datenschutzerklärung vorweisen kann, dann sollten Sie sich die Zeit nehmen, diese einmal etwas genauer zu studieren. Sie werden überrascht sein, was die Dienstleister hier zum Teil mit Ihren Daten anstellen.
Aus diesem Grund lohnt sich die Suche nach einem URL Shortener, der Ihnen vernünftige Datenschutz-Klauseln bietet und idealerweise eine Datenhaltung innerhalb Europas zusichert. Wenn die Daten außerhalb Europas liegen, dann sollten sie wenigstens in einem Rechtsstaat liegen, der die Daten nicht gewohnheitsmäßig an staatliche Stellen weitergibt. Ihre Anwender werden es Ihnen danken.

Eine spannende Frage ist auch, wo die Daten denn eigentlich liegen. Im Jahr 2009 gab es diverse Blog-Posts zum Thema, dass der URL Shortener bit.ly eine libysche Domain nutzt. Die Überlegung, ob man mit der Reservierung einer Domain in einem sogenannten “Schurkenstaat” diesen Staat wirtschaftlich unterstützt (zur Erinnerung: eine libysche Domain kostet zur Zeit etwa 200 EUR/Jahr …), würde mich hier weniger beunruhigen als die Tatsache, dass die Server eben jenes Dienstes in den USA stehen (und damit die Datenhaltung auch dort stattfindet).

Neuerdings sieht man immer häufiger, dass viele Websites ihren eigenen URL Shortener implementieren. Schließt man sich der Einschätzung des Düsseldorfer Kreises an, dass IP-Adressen personenbezogene Daten sind, dann macht dieser Schritt durchaus Sinn, da man dann die Daten unter eigener Kontrolle hat. Um ehrlich zu sein, dürfte der Hauptgrund für einen eigenen URL Shortener allerdings in der Praxis eher aus den Resorts PR und Marketing stammen.
Was man beim Betrieb eines eigenen URL Shorteners nicht vergessen sollte ist die Anpassung der Datenschutz-Erklärung (siehe §13 TMG), wenn man diese Daten nicht automatisch anonymisiert. Sonst kann der Spaß dank Abmahnungen relativ teuer werden …

Im letzten Teil der Serie haben wir auf einem Ubuntu-Server einen syslog-ng Server aufgesetzt. In diesem Teil betrachten wir etwas genauer, wie man das System weiter verbessern kann.

Als erstes machen wir einen Exkurs zum Thema “Systemhärtung”. Der schönste Log-Server hilft wenig, wenn er als zentrales Einfallstor für einen Angriff missbraucht werden kann. Generell gibt es diverse Härtungs-Guidelines für Ubuntu Server. Ein Beispiel dafür findet man hier. Ein wichtiges Thema betrachten wir im Rahmen dieses Artikels:

Lokale Firewall: Wenn der Server nicht bereits von einer zentralen Firewall geschützt ist (z.B. indem er an einem dedizierten Interface einer Netzwerk-Firewall angeschlossen ist), dann sollte man sich zumindest mit einer lokalen Firewall behelfen. Unter Linux kommt hier üblicherweise iptables zum Einsatz. Ubuntu bietet hier mit ufw ein simples Interface zur Konfiguration. Dies geschieht wie Folgt:

sudo apt-get install ufw

sudo ufw enable

sudo  ufw allow ssh

sudo ufw allow 514/tcp

Bitte beachten Sie: ufw hat als Basis-Setup “default deny”. Sollten Sie also nicht lokal vor dem Rechner sitzen, dann schneiden Sie sich mit “ufw enable” Ihren Remote-Zugriff ab. In diesem Fall bitte VORHER unter /etc/ufw die passende Zugriffsregel definiern.

Mit dem Beispiel oben erlauben Sie nur Remote-Zugriff via ssh und Zugriff auf den syslog-ng-Dienst über Port 514 (tcp). Sollten Sie noch weitere Dienste zwingend benötigen, dann können diese analog ergänzt werden.

Nachdem Sie das System gehärtet haben, stellt sich die Frage nach der Sicherheit der Log-Daten während der Übertragung. Bisher werden die Daten im Klartext übertragen. Dies kann durchaus akzeptabel sein, wenn man ein dediziertes Log-Netzwerk betreibt. Sollte man die Daten allerdings über ein öffentliches Netzwerk (z.B. das Internet) senden, dann bietet sich eine Kommunikations-Verschlüsselung an. Früher musste man dazu die Log-Daten relativ umständlich über ssh oder stunnel tunneln. In neueren Versionen (ab 3.0) von syslog-ng ist allerdings direkt TLS-Verschlüsselung eingebaut, so dass sich Verschlüsselung relativ einfach aktivieren lässt.

Zuerst generiert man die Zertifikate für den Server und die jeweiligen Datenquellen. Wer damit keine Erfahrung hat, der möge hierauf einen Blick werfen. Freunde von grafischen User-Interfaces können hierfür unter Ubuntu auch tinyca verwenden.
Die Zertifikate müssen jeweils im pem-Format sein. Zusätzlich erwartet syslog-ng den Dateinamen des CA Zertifikats in einem bestimmten Schema. Dies erreicht man so:

ln -s cacert.pem `openssl x509 -noout -hash -in cacert.pem`.0

Anschließend konfiguriert man den syslog-ng Dienst auf dem Loghost neu:

source s_tls
{
    tcp
    (
        ip(<IP Adresse des Servers>)
        port(514)
        tls
            (
                ca_dir("/etc/syslog-ng/ca.d")
                cert_file("/etc/syslog-ng/server-cert.pem")
                key_file("/etc/syslog-ng/server-key.pem")
            )
    );
};

Auf einem Linux-Client geht man analog vor, nur dass hier entsprechend eine Destination definiert wird:

destination d_tls
{
    tcp
    (
        "<IP Adresse des Servers>"
        port(514)
        tls
        (
            ca_dir("/etc/syslog-ng/ca.d")
            cert_file("/etc/syslog-ng/client-cert.pem")
            key_file("/etc/syslog-ng/client-key.pem")
        )
    );
};

Mit dieser Konfiguration stellt man sicher, dass die Kommunikation verschlüsselt ist und dass der Server nur Verbindungen von Clients akzeptiert, die ein Zertifikat vorweisen können, das von der eigenen CA unterschrieben wurde.
Weiteres Anpassungen des Logservers dann in einem Folge-Artikel

Eine der ersten Aufgaben, denen man sich als frischgebackener (interner oder externer) Datenschutzbeauftragter (DSB) zu stellen hat, ist das interne Verfahrensverzeichnis. Idealerweise liegt das Verfahrensverzeichnis schon vor und man muss es nur noch weiterpflegen. Die Realität sieht in der Regel allerdings anders aus. Häufig wird der DSB dieses interne Verfahrensverzeichnis komplett neu erstellen müssen. Natürlich sollte der DSB dazu gemäß §4 Abs. 2 von der verantwortlichen Stelle eine “Übersicht über die in §4e Satz 1 genannten Angaben sowie über zugriffsberechtigt Personen” zur Verfügung gestellt bekommen. Wenn der DSB allerdings DARAUF wartet, dann ist er grundsätzlich wohl eher der Typ “Optimist”…

Wenn man das Projekt “internes Verfahrensverzeichnis” angeht, dass sollte man das von Beginn an mit einem guten Plan angehen. Kennt man das Unternehmen so gut wie gar nicht, dann ist meiner Erfahrung nach der beste Ansatz, sich zuerst einmal das Organigramm geben zu lassen. Anhand des Organigramms baut man eine Interview-Liste mit den jeweiligen Abteilungs-Leitern/Verantwortlichen auf. Die Interviews haben zum Ziel, sowohl die wichtigen Geschäftsprozesse kennenzulernen, als auch gleich schonmal mögliche Datenschutz-Probleme zu erkennen (diese wandern dann auf die Task-Liste für das erste Dienst-Jahr).

In dieser Stelle sollte man prüfen, ob man”die üblichen Verdächtigen” auf seiner Liste hat. In nahezu jedem Unternehmen lassen sich die Verfahren in drei Bereiche teilen:

1. Human Resources
   Hier sollten sich klassische Personal-Verfahren finden, die den gesamten Mitarbeiter-Lifecycle umfassen: vom Recruiting über die Führung der Personalakte bis zur Personalentwicklung.
2. IT
   IT-Verfahren sind in der Regel Unterstützungsverfahren für die anderen Verfahren. Hier hat jeder DSB in der Regel seine eigenen Präferenzen, ob und wie er diese modellieren möchte. Auf jeden Fall sollte man aber einen Blick auf Backups und Archive werfen.
3. Geschäftsprozesse
   Bei dieser Kategorie kann man keine allgemein gültigen Aussagen treffen, da sich die Geschäftsprozesse einfach zu sehr unterscheiden. Prinzipiell startet man mit der Frage “Womit verdient dieses Unternehmen sein Geld?” und arbeitet sich dann systematisch durch die Schlüsselprozesse, in denen personenbezogene Daten beteiligt sind.

Als nächstes stellt sich die Frage, wie das Ganze zu dokumentieren ist. Neben den allgemeinen Angaben zum Inhalt aus §4e BDSG gibt es keine Vorgaben zur Form, man hat hier also eine große Gestaltungsfreiheit. Spätestens hier muss man sich entscheiden, ob man ein kommerzielles Produkt anschafft, oder eine eigene Dokumentationsform wählt. Für ein kommerzielles Produkt spricht:

• Die Produkte sind in der Regel so strukturiert, dass sie speziell Anfänger gut unterstützen
• Manche der Produkte werben damit, dass Aufsichtsbehörden an der Erstellung mitgewirkt haben. Hier besteht zumindest die Hoffnung, dass das Produkt bei einem “Besuch” der Aufsichtsbehörde gefallen findet.

Für eine selbsterstellte Dokumentationsform spricht:

• Im Gegensatz zu einem kommerziellen Produkt passt man hier die Dokumentation seinen eigenen Bedürfnissen an, und nicht umgekehrt

Eine kostenlose Vorlage für ein Verfahrensverzeichnis in Excel findet sich hier auf meiner Website.

Bei der Erstellung des Verfahrensverzeichnisses wird man sehr schnell feststellen, dass der Erfolg direkt proportional zum Reifegrad der Information Security im Unternehmen ist. Wenn man sich erst beim Verfahrensverzeichnis zum ersten Mal Gedanken über technische und organisatorische Maßnahmen (TOMs) für Verfahren macht, dann wird man sich sehr schwer tun, ein schlüssiges Sicherheitskonzept für ein Verfahren darzustellen.

Das Thema “Sicherheitskonzept” werde ich in einem Folge-Post im Detail betrachten.