Client Security

Plug and Play ist nett weil alles ohne Mühe funktioniert aber Sicherheit und Zugriffschutz sind auch in kleinen und mittleren Netzwerken wichtig und erforderlich. Was sollten Sie dabei beachten

Diese Seite beschreibt sehr kurz die Verschiedenen Dinge, um die Sicherheit in ihrem Netzwerk zu erhöhen und Ausfälle und Angriffsflächen zu minimieren. Dies kann auf mehreren Ebenen geschehen und im Idealfall sind alle Schutzfunktionen sinnvoll kombiniet.

Das Kennwort / Die Anmeldung

Noch immer werden zur Anmeldung an verschiedenen Daten normale Kennworte genutzt. Nur wenige Zugänge erfordern z.B. Zertifikate oder andere starke Authentifizierungen. Über Gruppenrichtlinien können Sie auch in ihrer Domäne so genannte "Komplexe Kennworte" fordern. So müssen Benutzer dann auch Sonderzeichen und Zahlen verwenden. Was der Sicherheit dient sorgt aber auch für ärger, wenn Sonderzeichen auf anderen Tastaturen nicht einfach erreichbar sind. Viele Anwender haben schon Probleme mit der Gross/Klein Schreibung (Caps Lock on) und haben Sie schon mal versucht ihr komplexes Kennwort im OWA-Anmeldebildschirm einzugeben, wenn Sie ein anderes TastatURLayout vorgesetzt bekommen ? (z.B. im Urlaub)

Die "Cracker" haben mittlerweile aber auch nachgerüstet und dank moderner Grafikkarten GPus können diese sogar noch ein vielfaches schneller die Hashwerte mit roher Gewalt (Brute Force Attacke) durchprobieren, als dies vor wenigen Jahren noch denkbar war. (Siehe auch http://www.heise.de/ct/inhalt/2009/06/204/). So kann ein normales Kennwort aus Buchstaben und Zahlen [a-zA-Z0-9] mit weniger als 7 Stellen schon in Minuten geknackt werden. Selbst komplexe Kennworte mit der Länge halten einem Angriff nicht länger als 30 Minuten Stand. Der Angreifer muss einfach nur das verschlüsselte Kennwort abgehört haben, was z.B. mit Cain&Abel im LAN gar kein Problem ist. Entsprechende auf Grafikkarten optimierte" Tools gibt es z.B. Unter http://3.14.by/en/md5 und anderen Quellen.

Erst mit zunehmender Länge eines Kennwort wird es für solche Angriffe immer schwerer, solche Attacken in vertretbarer Zeit erfolgreich zu fahren. Wenn Sie also ihr Kennwort entsprechend lange wählen und häufig genug (z.B. mindestens alle 60 Tage) ändern, dann ist das Risiko schon erheblich reduziert.

Ein weiterer Aspekt ist natürlich die Übertragung des Kennworts selbst. Wer heute noch per POP3, IMAP4, TELNET oder HTTP auf sensible Daten zugreift, ist selbst schuld, weil ich dann nicht mal das Kennwort knacken muss, sondern zumindest bei "Basic-Auth" direkt einsehen kann.

Neben einem "guten Kennwort" ist natürlich auch eine entsprechend gesicherte Übertragung per SSL (POP3S, IMAP4S, HTTPS, SSH etc.) oder eine starke Authentifizierung (Kerberos, Zertifikate) ratsam, so dass sich wenig Angriffsflächen für Mitleser oder Hash-Cracker bieten.

Leider wird genau das allzu oft vernachlässigt, da die Beantragung, Installation, Verlängerung und Konfiguration von z.B. SSL-Zertifikaten natürlich ein zusätzlicher Aufwand darstellt und auch die Clients entsprechend angepasst werden müssen.

Hinzu kommt auch, dass sie sicher alarmiert sind, wenn an ihrer Eingangstür seltsame Kratzspuren zu finden sind, aber fast niemand aktiv die fehlerhaften Anmeldungen an einem Netzwerk überwacht. Zwar hilft Windows hier mit einer "Lockout"-Strategie, dass nach zu vielen Fehlversuchen ein Konto temporär gesperrt wird, aber das funktioniert nicht bei "geknackten" Kennworten. Eine Überwachung der Anmeldungen kann aber wertvolle Hinweise auf unregelmäßigkeiten liefern, da sich die meisten Anwender doch primäre an "ihrem" PC anmelden und Fremdanmeldungen daher einfach zu erkennen sind.

Wenn Sie nun die Übertragungswege weiter gesichert haben und auch lange Kennworte einsetzen, dann steigt der Aufwand für Angreifer natürlich sehr hoch an. Auf der anderen Seite belegen aber Projekte wie seti@home und andere, dass Millionen von PCs an einer gemeinsamen Rechenaufgabe arbeiten können. Andererseits gibt es auch immer wieder Viren und BOT-Netze, welche ferngesteuert werden können. Vielleicht erleben wir zukünftig Schadprogramme, die keinen direkten Schaden mehr auf ihrem Wirt verursachen, um möglichst lange unerkannt zu bleiben und statt dessen als verteilter Password-Knacker-Dienst arbeiten.

Kennwort Komplexität, Brute Force

Viel Wirbel wird auch um Kennworte und deren Komplexität gemacht. Es ist schon erschreckend, wie viele Dienste ein "komplexes" Kennwort (mit Zahlen, Gro/Kleinschrift, Sonderzeichen) erfordern aber bei der Länge passen. Auch Windows war früher mit LM-Hashwerte auf 14 Zeichen beschränkt, von denen sogar nur zwei Gruppen al 7 Zeichen "verhashed" wurden und ein Entwickler am Hashwert schon sehen konnte, ob das Kennwort 7 oder weniger Stelle hatten. Damit konnte der Aufwand zum "erraten" eines Kennworts natürlich reduziert werden.

Aber diese "Brute Force"-Attacken erfordern zwei Dinge:

  • Schnelle Systeme
    Hier haben aber nicht nur die Host-CPus immer weiter zugelegt, sondern die Zweckentfremdung von Grafikkarten-CPus (GPu) als Nummernknacker hat hier die Zeitdauer stark verkürzt, um auch lange Kennworte "durchzuproben"
  • Zugriff auf den CryptoKey bzw. "dummes" System ohne Sperren
    Massentests sind aber nur möglich, wenn auch große Vergleiche möglich sind. Wer ein gutes System aufbaut, der sperrt ein Konto nach zu vielen Fehlversuchen. Dabei ist es relativ unwichtig, ob das nach 3, 5 oder auch 10 Versuchen passiert, solange dann für einige Minuten gesperrt wird. Das gesperrte Konto kann sogar nach wenigen Minuten (z.B.10) wieder entsperrt werden. mit 10 Versuchen und 10 Minuten funktioniert Brute-Force nicht mehr. Wohl aber das Erraten aus einer Liste von bekannten bzw. "wahrscheinlichen Kennworten.

Die Komplexität statt der Länge ist aber kein wirklich guter Ratgeber. Ein Kennwort mit 10 Zeichen aus einem Zeichensatz von [a-zA-Z0-1Sonderzeichen} ist weniger sicher als ein langes Kennwort aus [a-z]

Zeichensatzauswahl Zeichenmenge Stellen Varianten (Menge hoch Stellen)

0-9  (z.B. PIN der EC-Karte oder SIM-Karte etc.)

10

4

10000

a-z, A-Z, 0-9, Sonderzeichen

ca 80

8

1677721600000000

a-z

26

11

3670344486987776

a-z, A-Z, 0-9, Sonderzeichen

ca 80

10

10737418240000000000

a-z

26

14

64509974703297150976

Wer also ohne Zahlen, Sonderzeichen und Groß/Kleinschrift auskommt, muss nur 11 statt 8 oder 14 statt 10 Stellen fordern, um viel mehr Varianten zu haben. Oder es mit einem Comic zu sagen:


Quelle: http://xkcd.com/936/

Hinweis: Das Comic beschreibt den Begriff "Entropie". Auch wenn ein Betriebssystem z.B. einen 128bit Hashwert hat, so muss ein BruteForce keine 2hoch128 Varianten prüfen. Denn mehrere Kennworte können durchaus zum selben Hashwert führen. Und dass auch ein komplexes Zeichen keine 8 Bit braucht, reduziert die Entropie weiter.

Interessant ist hier auch die Geschwindigkeit, mit der Brute-Force-Angriffe durch Grafikkarten beschleunigt werden: (Quelle: Cheap GPus are rendering strong passwords useless. http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125)

Passwortlänge HostCPu 10 Mio try/Sek GDu 3,3 Mrd try/Sek

4 Zeichen a-zA-Z0-9

24 Sek

<1 Sek

6 Zeichen a-zA-Z0-9

1h30min

4 Sek

7 Zeichen a-zA-Z0-9

4 Tage

17 Min

7 Zeichen komplex

75 Tage

7h

9 Zeichen a-zA-Z0-9

43 Jahre

48 Tage

Und es gibt Berichte, dass Systeme mit 4x HD 5970 (8 GPus) bis zu 33 Mrd Hashes/Sek durchtesten können. Von dem Einsatz von Rainbow-Tables gar nicht zu reden.

Die Lösung kann eigentlich nur sein, dass sehr sehr lange Kennworte verwendet werden oder das Kennwort auf einer Hardware (z.B. Smartcard) hinterlegt ist, welche die Entschlüsselung macht und falsche Versuche aussperren, oder der Schlüssel von einem Server/Service bereitgestellt wird. (wie z.B. TPM-Chip für Bitlocker)

Empfehlung ?
Es ist sicher nicht einfach einen Ratschlag zu geben, aber ich bin dazu übergegangen, meinen Anwendern keine "komplexen" Kennworte mehr aufzuzwingen, aber die Mindestlänge entsprechend anzuheben, so dass auch mit vielen Grafikkarten eine Attacke auf den Hashwert erst in Jahren und nicht in Tagen erfolgreich ist. Dies wird kombiniert mit einem maximalen Kennwortalter von z.B. 60 Tagen und die Vermeidung jeder Übertragung in unverschlüsselter (FTP, POP3) oder schwach versteckter (BASE64 bei HTTP) Form.

Lockout Policies

Ein wirksames Mittel, gegen Brute Force aber noch mehr gegen Dictionary-Attacken ist natürlich das "Bremsen" der Versuche. Das funktioniert leider nicht, wenn der Angreifer eine Kopie der SAM, der PFX oder der verschlüsselten DOC-Datei etc. hat. Aber wenn er z.B. ein Anmeldkonten auf einem DC über das Netzwerk "probieren" will, dann sind die Lockout-Policies ein effektives Mittel. Allerdings muss man hier auch wieder die richtige Wahl zwischen Sicherheit und Nutzbarkeit finden.

Wer nach drei Fehlerversuchen ein Konto für eine Stunde "aussperrt" oder sogar eine manuelle Entsperrung erfordert, der macht es einem Angreifer zwar sehr schwer, das Kennwort zu "erraten", sofern er keinen deutlichen Hinweise auf das möglich Kennwort hat. Aber dann kann ein Angreifer eben "anders" stören, indem er eine Liste der Benutzer bösartig abläuft und in kurzer Zeit alle Konten "gesperrt" hat. Viel Spaß beim Lösen dieses Knotens. Und Webserver versuchen schon mal gerne zwei Anmeldeverfahren, so dass mit einem falschen Kennwort schon zwei Versuche weg sein können.

Wer aber z.B. ein Konto erst nach 5-8 Fehlversuchen sperrt und nach 1 Minute wieder automatisch entsperrt, der verhindert weiterhin recht effektiv "Brute Force"-Attacken. Mit 5-8 Versuchen pro Minute muss ein Angreifer nicht nur viel Geduld haben, sondern setzt sich durch die permanente Sperrung eines Kontos auch der Entdeckung aus. Wenn ein Angreifer aber einen überwiegenden Teil des Kennworts ausgespäht, hat, dann könnte er so an das Ziel kommen. Auf der Habenseite einer entspannter eingerichteten Richtlinie steht, dass der Anwender einfach kurz warten muss und der Helpdesk weniger zu tun hat.

Wer es etwas pfiffiger haben will, kann ja das Konto weiterhin nach 3-5 Versuchen für "immer" sperren aber die Freischaltung über eine eigene Logik realisieren, die dynamischer auf die Häufigkeit oder die Quelle der Sperrung eingeht. Es ist recht einfach, das Active Directory zeitnah dahingehend abzufragen, ob ein Konto gesperrt wurde und darauf zu reagieren (siehe auch Get-USNChanges). Auch das Eventlog ist eine gute Quelle um "getriggert" eine Sperrung zu erkennen und angepasst zu reagieren

Übrigens ist eine Lockout-Policy nur die halbe Miete. Es hilft ihnen nicht, wenn ein Anwender sich meldet, weil sein Konto immer wieder gesperrt wird und sie keine Hilfsmittel haben, um die Ursache der Sperrung zu ermitteln. Gerade wenn ein Konto immer wieder gesperrt wird, sollten Sie schnell heraus finden, ob es wirklich ein einfacher Benutzerfehler ist, z.B. ein PC der noch mit dem alten angemeldet ist, oder ob tatsächlich jemand "probt". Das Windows Security Eventlog der Domain Controller ist hier die erstelle Quelle.

Wenn die Kennwort ausreichend Lange sind und eine passende Sperr-Richtlinie etabliert ist, dann könnten Sie darüber nachdenken, den "Wechselzwang" alle 60 Tage ein neues Kennwort zu vergeben, zu lockern. Allerdings sollten Sie dann eine Lösung haben, die Anmeldungen der Anwender "protokolliert" und auswertet um Missbrauch zu erkennen. Aber so eine Protokollierung ist ja für die Analyse von "Lockout"-Vorgängen eh schon relevant.

Netzwerkphysik (MAC)

Mal abgesehen von einem direkte Zugriff zu einem PC oder Server finden viele unerwünschte Zugriffe natürlich über das Netzwerk statt. Hier muss erst einmal das physikalische Netzwerk untersucht werden. Wenn ich mit meinem Notebook mich einfach an einen freien Port anschließen kann oder einen Mini-Hub in das Anschlusskabel eines anderen PCs oder Druckers einschleife, dann ist der Weg frei für interne Angriffe mit voller Brandbreite. Viele Firmen haben ja nur Angst vor Angriffen aus dem Internet. Das ist aber ein Irrtum.

Aber was kann ein Administrator hier tun ?. Es gibt mehrere Möglichkeiten:

  • aktive/inaktive Anschlüsse/Ports
  • MAC-Adressen Authentifizierung
  • 802.1x

Weitere Details finden Sie auf 802.1x

Sicherer Datentransfer

Sie glauben gar nicht, wie viele Nutzdaten komplett unverschlüsselt über das LAN übertragen werden. D.h. selbst wenn Sie den Zugriff auf das Medium kontrollieren, so sind ja nicht alle Mitarbeiter "gut" bzw. Trojaner und Viren können ohne Wissen des Mitarbeiters die Berechtigungen missbrauchen. Daher sollten Sie generell kontrollieren, welche Protokolle in ihrem Netzwerk genutzt werden und wie diese zu verschlüsseln sind, z.B.:

  • IPSec
    Seit Windows 2000 können Sie mittels IPSec die Kommunikation zwischen einzelnen Servern und Gruppen oder auch innerhalb des gesamten Netzwerks verschlüsseln und signieren. Der zusätzliche Ressourcenbedarf ist eher gering. IPSec ist aber nicht nur eine Verschlüsselung als solches, sondern erlaubt auch die Kontrolle bis auf Portebene und Subnetze. Sie können damit Netzwerke quasi von anderen Systemen abschotten. (Stichwort Domain Isolation)
  • WPA
    Gerade mit drahtlosen Netzwerken (WiFi) ist natürlich die Verschlüsselung von Daten (WEP, WPA, WPA2 etc.) eine essentielle Funktion, um unerwünschten Mithörern den Zugriff zu erschweren. Im Gegensatz zu kabelgebundenen Netzwerken sind hier fremde Stationen nicht so einfach zu erkennen und müssen sich nicht in den eigenen Räumlichkeiten befinden. Natürlich sollten Sie auch hier nicht vergessen, dass Sie das Endgerät authentifizieren müssen. Eine Verschlüsselung bringt nicht viel, wenn jeder den Schlüssel durch Plug and Play-Techniken einfach so erhält.
  • Nutzprotokolle sichern (SSL/TLS)
    Sehr viele andere andere Protokolle (HTTP, FTP, SNMP, TELNET, SMTP, POP3 etc.) werden im eigenen Netzwerk sehr sorgenfrei genutzt. Leider werden hierbei die Kennworte quasi in Klartext übertragen. Dabei ist es mit einer eigenen CA (siehe CA installieren) sehr einfach, zumindest intern alle Verbindungen per SSL abzusichern. Stellen Sie sich vor, Sie melden sich per TELNET auf ihrem Switch oder per POP3 oder OWA an ihrer Mailbox an und jemand liest das Kennwort einfach mit. Einfacher kann ein Angreifer nicht an ihr Kennwort kommen und Programme, die dies per Mausklick erlauben, sind im Internet verfügbar (z.B. Cain&Abel auf www.oxid.it)
    Denken Sie dabei auch die NTLM-Authentifizierung: Wenn sie keine alten Client mehr haben, sollten Sie die Übertragung unverschlüsselter Kennworte verbieten. Zusätzlich können Sie z.B. NTLM V2 erzwingen und die Signierung der Datenpakete verlangen. (Gruppenrichtlinien)
  • Segmentierung mit VLANs
    Neben Verschlüsselung und logischer Segmentierung ist natürlich auch eine Trennung der verschiedenen Netzwerke ein praktikabler Weg, um verschiedene Klassen von Clients voneinander zu separieren. Viele Lauschprogramme scheitern an Routern und verschiedene Subnetze sind eine Grundlage, um zwischen Netzwerken mit Filtern aktiv zu arbeiten. Dabei unterstützen VLANs auf Switches, um Subnetze entsprechend logisch zu trennen. In Verbindung mit 802.1x können sie oftmals sogar abhängig von der Anmeldung das System in ein passendes VLAN patchen.

Systemschutz

Die Sicherheit eines Gesamtsystems nicht nur vom Netzwerk abhängig. Auch die Server sollten Sie etwas genauer untersuchen, da Sie als permanent verfügbare Systeme natürlich auch erstes Ziel eines Angriffs sein werden.

  • Firewalls
    Wenn Sie schon Windows XP oder Windows 2003 nutzen, dann sollten Sie den Einsatz der vorhandenen Firewall erwägen, um das System besser gegen Angriffe zu schützen. Eine Firewall zum Internet sichert nur die externe Kommunikation aber nicht die sehr viel häufiger auftretenden absichtlichen oder unabsichtlichen Angriffe von innen.
  • Bindungen, Portfilter und IPSec
    Erst Windows XP und 2003 enthalten eine "Firewall". Aber selbst bei Windows 2000 können Sie IPSec nutzen, um Verbindungen auf Portebene zu kontrollieren. Auf Windows NT4 konnten Sie schon seit 1995 mit den IP-Portfiltern nur ausgewählte Verbindungen erlauben. Das ist zwar nicht elegant, aber wenn ihr Webserver zwei Netzwerkkarten hatte, dann könnte Sie so die Verbindung aus dem Internet auf Port 80 und 443 beschränken. Das geht sogar noch mit Windows 2003, wenn Sie die Firewall nicht verwenden wollen.
  • Dienstbindungen und Beschränkungen
    Beschränken Sie die Dienste auf ihrem Server auf das notwendige Minimum. Ein Webserver mit ASP muss nur dann installiert und aktiv sein, wenn er benötigt ist. Selbst dann kann und muss er mit IISLockD etc. gesichert werden. Viele Server haben auch sie "Simple TCP Dienste" installiert, die vermutlich niemand braucht. Aber auch erforderliche Dienste können besser gesichert werden. Wenn ein Webserver nur von bestimmten Subnetzen erreichbar sein muss, dann stellen Sie dies in den Beschränkungen ein. Auch der anonyme Zugriff auf einem SMTP-Server könnte nur für die Firewall erlaubt sein. Alle anderen Systeme sollten sich anmelden. So können Sie mit ganz wenig Aufwand viele Gefahren abwehren.
  • Dienstkonten und Berechtigungen
    Viele Schwächen eines Servers sind keine Probleme der Software, sondern der Menschen davor. Höchste Zeit, dass Sie hier für klare Verhältnisse Sorgen. (Siehe auch Adminkonzept). Entsprechend sollten Sie auch sicher stellen, dass Dienste mit jeweils eigenem Konto gestartet werden, so dass eine getrennte Steuerung der Berechtigung aber auch eine selektive Deaktivierung überhaupt erst möglich ist.
  • Monitoring und Checks
    Angriffe zeigen sich oft an vielen Anmeldeversuchen, Zugriffe auf gesperrte Dienste oder einfach Meldungen im Eventlog. Die Aktualität eines System lässt sich mit Tools wie MBSA, ExBPA etc. Prüfen. Das gilt auch für die Überwachung von Protokollen der Webserver auf Fehlerseiten. Dies kann ebenfalls automatisiert werden.

Desktop Absicherung

Oft sind es die kleinen Dinge, die ein Gesamtsystem schon sehr viel sicherer machen. Wenn Sie die Haustür einfach nur schließen, dann hilft das schon sehr viel. Wenn ein Einbrecher in ihrem Haus ist, dann kann er auch die Werkzeuge nutzen, die Sie selbst haben. Übertragen bedeutet dies:

  • Kennwort, Tokens
    Es ist unverantwortlich, wenn heute Zugänge ohne Kennwort genutzt werden. Eine Authentifizierung ist wichtig und erst wirkungsvoll, wenn das Kennwort auch komplex genug ist und geändert werden muss. Eine stärkere Authentifizierung ist mit Smartcards oder Einmaltokens möglich. Nach einigen Fehlversuchen sollte das Konto für bestimmte Zeit deaktiviert werden und eine Meldung erfolgen.
  • Bildschirmschoner mit Schutz, Cookies
    Wird ein Computer oder eine Anwendung eine bestimmte Zeit nicht mehr genutzt, d.h. der Anwender arbeitet nicht mehr aktiv, dann sollte die Verbindung entweder beendet oder zumindest gesperrt werden. Outlook Webzugriff 2003 meldet dazu einen Benutzer nach einigen Minuten Inaktivität ab und erfordert eine erneute Anmeldung. Ihr Windows Desktop kann nach einiger Zeit einen Bildschirmschoner mit Kennwortschutz aktivieren.
  • "Log on Local"-Steuerung
    Bei einer Standardinstallation kann ein Anwender, der Mitglied von "Domänen Benutzer" ist, sich auf jedem Computer anmelden, der Mitglied der Domäne oder anderen Domänen im Forest ist. Das muss nicht sein. Über das Recht "Log on Locally", entsprechenden Sicherheitsgruppen und Gruppenrichtlinien können Sie sehr einfach steuern, welche Mitarbeiter sich an welchen Computern anmelden können. Damit stellen Sie sicher, dass sich an den Adminworkstations, die vielleicht per 802.1x andere Systeme erreichen können, keine normalen Benutzer anmelden und umkehrt auch in der Personalabteilung sich nur die Anwender aus der Abteilung anmelden. Dies reduziert das Risiko bzw. die Chancen für böse Buben

Unterstützung durch Net at Work:
Die Umsetzung einer solchen Anmeldesteuerung geht mit Bordmitteln und ganz einfach, wird aber auf der MSXFAQ nicht beschrieben. Sprechen Sie uns einfach an,  wenn Sie hier Bedarf haben.

  • Ordnerumleitung
    Daten sind um so sicherer, je weniger ein Angreifer direkt darauf zugreifen kann. Ein Desktop mit Windows kann auch mit Linux oder BartPE gebootet und damit der Zugriff auf Dateien ausgehebelt werden. Nutzdaten sollten daher direkt auf dem Server gespeichert werden. Hierzu eignen sich z.B.: die Ordnerumleitungen von Windows, so dass "Eigene Dateien" und andere Daten nicht auf C:\Dokumente und Einstellungen\Benutzername" sondern auf einem Netzwerklaufwerk gespeichert werden.

Nutzdatensicherung

Zuletzt schauen wir uns natürlich noch mal die Daten selbst an. Die meisten Dokumente werden mehr oder minder ungeschützt auf Dateiservern, USB-Stick, CD-Roms und Backupbändern gespeichert

  • Zugriffsrechte
    Der erste Schritt ist natürlich die Steuerung der Zugriffe über Berechtigungen (Siehe Datenhaltung). Wenn die Daten auf dem Server liegen und es keine Lücken gibt, dann ist es sehr schwer, diese Daten unberechtigt zu erhalten. Natürlich sollten Sie auch eine Überwachung dieser Anmeldungen ins Auge fassen um den Versuch eines Missbrauchs zu erkennen.
  • EFS, PGPDisk, TrueCrypt
    Eine weitere Funktion ist die Verschlüsselung der Dateien durch das NTFS-Dateisystems oder Zusatzprogramme wie PGP-Disk oder das kostenfreie TrueCrypt. Ein Angreifer benötigt dann immer das entsprechende Zertifikat oder Kennwort um das Archiv zu öffnen. Das größere Problem hierbei ist aber die eingeschränkte Funktion, eben solche Daten gemeinsam mit mehreren Personen zu nutzen. Je nach Produkt sind auch die Datensicherung (Gesamtcontainer statt einzelner Dateien), und die Sicherheit des Kennworts als solches zu berücksichtigen.

REM Kommandozeile zum decodieren aller Dateien in einem Baum, wenn "versehentlich"
REM die Daten beim Kopieren auf den Server verschlüsselt wurden.

cipher /d /s:\\server\share

  • Applikationskennworte
    Schon sehr lange können Sie z.B. auch in verschiedenen Anwendungen wie Word, Excel, Acrobat, Access etc. Kennworte auf Dokumente und Datenbanken setzen. Zumindest die neueren Versionen scheinen dabei auch sehr gut gegen Passwortattacken gesichert zu sein. Das Arbeiten wird aber damit auch immer umständlicher, besonders im Team.
  • S/Mime und PST-Kennwort
    Für Nachrichten in ihrem Postfach gilt, dass diese auf einem Exchange Server relativ sicher liegen. Nur wenn Sie diese auf ihrem lokalen PC als PST oder OST-Datei mitführen, muss diese Datei z.B.: mit einem Kennwort gesichert werden. Bei der Übertragung von Nachrichten zu anderen Empfängern sollten Sie sich natürlich Gedanken über Verschlüsselung machen. (Siehe auch Verschlüsseln und Signieren)

Soweit eine kurze Übersicht der verschiedenen Stellen, an denen Sie die Sicherheit aktiv steuern können.

Weitere Links