sichere nutzung von e-mail (isi-s)

Sichere Nutzung von E-Mail (ISi-Mail-Client)

BSI-Studie zur Internet-Sicherheit (ISi-S)

Version 1.0

ISi-Reihe ISi-S ─ Sichere Nutzung von E-Mail

Vervielfältigung und Verbreitung

Bitte beachten Sie, dass das Werk einschließlich aller Teile urheberrechtlich geschützt ist.

Erlaubt sind die Vervielfältigung und Verbreitung zu nicht-kommerziellen Zwecken, insbesondere zu Zwecken der Ausbildung, Schulung, Information oder hausinternen Bekanntmachung, sofern sie unter Hinweis auf die ISi-Reihe des BSI als Quelle erfolgen.

Dies ist ein Werk der ISi-Reihe. Ein vollständiges Verzeichnis der erschienenen Bände findet man auf den Internet-Seiten des BSI.

http://www.bsi.bund.de oder http://www.isi-reihe.de

Bundesamt für Sicherheit in der Informationstechnik

ISi-ProjektgruppePostfach 20 03 6353133 BonnTel. +49 (0) 228 99 9582-0E-Mail: [email protected]: http://www.bsi.bund.de© Bundesamt für Sicherheit in der Informationstechnik 2009

2 Bundesamt für Sicherheit in der Informationstechnik

http://www.bsi.bund.de/

mailto:[email protected]

http://www.isi-reihe.de/

http://www.bsi.bund.de/

ISi-S ─ Sichere Nutzung von E-Mail ISi-Reihe

Vorwort

Liebe Leserinnen und Leser,

immer mehr Prozesse verlagern sich in die virtuelle Welt des Internets: Kommunikation und Daten-austausch erfolgen per E-Mail, Bankgeschäfte und Einkäufe werden zunehmend online getätigt.

Dabei müssen häufig persönliche und vertrauliche Daten über das Internet versendet werden. Diese sind ein attraktives und lukratives Ziel für Online-Kriminelle, die heute international organisiert und professionell strukturiert zusammen arbeiten. IT-Kriminalität ist für die Angreifer ein lohnenswer-tes Geschäft bei vergleichsweise niedrigem Risiko. Identitätsdiebstahl und Angriffe mit Schadpro-grammen unterschiedlichster Art gehören bei der Nutzung des Internets zu den ernstzunehmenden Bedrohungen für alle Anwender. Diesen Gefahren muss man mit umfangreichen IT-Sicherheits-maßnahmen entgegentreten.

Die BSI-Schriftenreihe zur Internet-Sicherheit (ISi-Reihe) beschäftigt sich mit einzelnen Aspekten der Internet-Sicherheit. Das Modul „Sichere Nutzung von E-Mail“ beleuchtet Sicherheitsaspekte aus Sicht der Anwender. Es zeigt mögliche Gefährdungen auf und gibt konkrete Empfehlungen für Schutzmaßnahmen.

Bonn, im März 2009

Dr. Udo HelmbrechtPräsident des Bundesamtes für

Sicherheit in der Informationstechnik

Bundesamt für Sicherheit in der Informationstechnik 3


Inhaltsverzeichnis

1 Einleitung..........................................................................................................................................7

2 Grundlagen........................................................................................................................................8

2.1 E-Mail-Kommunikation.........................................................................................................................82.1.1 E-Mail-Komponenten.......................................................................................................................................82.1.2 Funktionen eines E-Mail-Clients....................................................................................................................10

2.2 Protokolle............................................................................................................................................122.2.1 Kommunikationsprotokoll POP3...................................................................................................................122.2.2 Kommunikationsprotokoll IMAP...................................................................................................................132.2.3 Kommunikationsprotokoll SMTP..................................................................................................................132.2.4 Kommunikationsschnittstelle MAPI..............................................................................................................152.2.5 Protokolle für den Adressbuchzugriff............................................................................................................152.2.6 Protokolle für den Kalenderzugriff................................................................................................................152.2.7 Protokolle zur Authentisierung......................................................................................................................162.2.8 Übersicht der Protokolle.................................................................................................................................18

2.3 Aufbau und Formate............................................................................................................................202.3.1 Struktureller Aufbau von E-Mails..................................................................................................................202.3.2 Zeichensätze...................................................................................................................................................232.3.3 Dateianhänge..................................................................................................................................................232.3.4 Lesebestätigungen..........................................................................................................................................252.3.5 HTML-E-Mail................................................................................................................................................252.3.6 E-Mail-Dateien/Postfächer.............................................................................................................................252.3.7 Adressbücher..................................................................................................................................................262.3.8 Kalender.........................................................................................................................................................262.3.9 Übersicht der Formate....................................................................................................................................27

2.4 E-Mail-Sicherheitskomponenten.........................................................................................................272.4.1 Anti-Phishing..................................................................................................................................................272.4.2 Spam-Filter.....................................................................................................................................................272.4.3 Virenschutzprogramme..................................................................................................................................282.4.4 Personal Firewall............................................................................................................................................29

2.5 Digitale Signatur und Verschlüsselung................................................................................................302.5.1 Standards........................................................................................................................................................312.5.2 Übersicht der Standards..................................................................................................................................352.5.3 MailTrusT, SPHINX und Ägypten................................................................................................................35

3 Sichere Grundarchitektur für normalen Schutzbedarf.....................................................................37

3.1 Sichere E-Mail-Client-Architektur.......................................................................................................373.1.1 Komponenten der E-Mail-Client-Architektur................................................................................................373.1.2 Ein- und ausgehende E-Mails.........................................................................................................................40

3.2 Sichere Anbindung der E-Mail-Clients an den internen E-Mail-Server...............................................41

3.3 Nutzung von S/MIME ........................................................................................................................433.3.1 Beschreibung der Komponenten....................................................................................................................433.3.2 Sicherheitsaspekte bei der Benutzung von S/MIME gesicherten Nachrichten..............................................44

3.4 Nutzung von OpenPGP .......................................................................................................................493.4.1 Beschreibung der Komponenten....................................................................................................................493.4.2 Sicherheitsaspekte bei der Benutzung von OpenPGP gesicherten Nachrichten............................................50

3.5 Sichere Nutzung der Virtuellen Poststelle...........................................................................................54

4 Komponenten sicher auswählen, konfigurieren und betreiben (normaler Schutzbedarf)...............55

4.1 Grundanforderungen an ein sicheres Produkt......................................................................................55



4.1.1 Client..............................................................................................................................................................554.1.2 E-Mail-Client-Software / Plug-Ins.................................................................................................................564.1.3 Virenschutzprogramm....................................................................................................................................584.1.4 Anti-Phishing-Software..................................................................................................................................584.1.5 Anti-Spam-Software.......................................................................................................................................594.1.6 Personal Firewall............................................................................................................................................59

4.2 Sichere Grundkonfiguration der Komponenten...................................................................................604.2.1 Client..............................................................................................................................................................604.2.2 E-Mail-Client-Software .................................................................................................................................604.2.3 Virenschutzprogramme..................................................................................................................................634.2.4 Anti-Phishing-Software..................................................................................................................................634.2.5 Anti-Spam-Software.......................................................................................................................................644.2.6 Personal Firewall............................................................................................................................................64

4.3 Grundvorgaben für einen sicheren Betrieb..........................................................................................654.3.1 Allgemein.......................................................................................................................................................654.3.2 E-Mail-Richtlinie............................................................................................................................................654.3.3 E-Mail-Client-Software..................................................................................................................................664.3.4 Virenschutzprogramm....................................................................................................................................664.3.5 Anti-Phishing-Software..................................................................................................................................664.3.6 Anti-Spam-Software.......................................................................................................................................664.3.7 Personal Firewall............................................................................................................................................66

5 Gefährdungen und Empfehlungen mit Varianten für normalen und hohen Schutzbedarf..............67

5.1 Gefährdungen durch Eindringen..........................................................................................................675.1.1 Computer-Viren und Würmer........................................................................................................................675.1.2 Viren und Würmer in verschlüsselten E-Mails..............................................................................................715.1.3 Nicht aktuelle Virenschutzprogramme...........................................................................................................725.1.4 Nachladen von Programmen über MIME-Types...........................................................................................735.1.5 HTML-E-Mail: Aktive Inhalte.......................................................................................................................745.1.6 HTML-E-Mail: IFrames.................................................................................................................................745.1.7 HTML-E-Mail: OBJECT-Tags......................................................................................................................755.1.8 Exploits...........................................................................................................................................................76

5.2 Gefährdungen durch Täuschen, Fälschen und Betrügen......................................................................785.2.1 Trojanische Pferde..........................................................................................................................................785.2.2 Fälschen von Header/Envelope-Daten (Spoofing).........................................................................................795.2.3 Manipulation des Absenderfeldes einer Nachricht (Spoofing)......................................................................795.2.4 Fälschen von E-Mail-Inhalten (Spoofing)......................................................................................................805.2.5 Verschleierung von Dateianhängen (Spoofing).............................................................................................815.2.6 Hoax...............................................................................................................................................................825.2.7 Nichtanerkennung einer Nachricht.................................................................................................................82

5.3 Gefährdungen durch Entwenden und Ausspähen.................................................................................835.3.1 Spyware/Adware............................................................................................................................................835.3.2 Phishing: Ausspähen personenbezogener oder vertraulicher Daten..............................................................845.3.3 E-Mail-Protokolle ohne Verschlüsselung......................................................................................................855.3.4 Gemeinsame Benutzung eines PCs................................................................................................................875.3.5 Automatisches Weiterleiten von E-Mails ......................................................................................................875.3.6 Web Bugs.......................................................................................................................................................885.3.7 Automatische Lesebestätigungen...................................................................................................................885.3.8 Kompromittierung privater Schlüssel (OpenPGP, S/MIME).........................................................................89

5.4 Gefährdungen durch Verhindern und Zerstören...................................................................................905.4.1 Spam...............................................................................................................................................................905.4.2 In Anhängen versteckter Spam.......................................................................................................................915.4.3 Joe-Job-Angriffe.............................................................................................................................................925.4.4 Ausgehende DoS-Angriffe.............................................................................................................................935.4.5 Verlust der Verfügbarkeit lokal gespeicherter E-Mails.................................................................................935.4.6 Verlust der privaten Schlüssel (VPS, OpenPGP oder S/MIME)....................................................................94



5.5 Gefährdungen auf einen Blick.............................................................................................................94

6 Fazit.................................................................................................................................................96

7 Literaturverzeichnis.........................................................................................................................97

8 Anhang..........................................................................................................................................100

8.1 Abdeckungsmatrix.............................................................................................................................100

9 Glossar...........................................................................................................................................103

10 Stichwort- und Abkürzungsverzeichnis......................................................................................116



1 EinleitungDie ISi-Reihe bietet allen mit der IT-Sicherheit befassten Personen in Behörden und Unternehmen umfassende und aktuelle Informationen zu weiten Bereichen der IT-Sicherheit. Durch ihren Aufbau aus mehreren Teilen wendet sie sich zielgruppenspezifisch an Entscheidungsträger (mit dem Leitfa-den ISi-L) sowie an diejenigen, die mit der Umsetzung der IT-Sicherheit betraut sind (Studien ISi-S und Checklisten ISi-Check). Die unterschiedlichen Module der ISi-Reihe befassen sich jeweils mit einem sicherheitsrelevanten Teilbereich von IP-Netzen und IP-Diensten.E-Mails sind als Kommunikationsmittel aus Behörden und Unternehmen heute kaum noch wegzu-denken. Die Vorteile dieser Art der Mitteilung sind unbestritten, so dass die Handlungsfähigkeit ei-ner Organisation in hohem Maße vom Funktionieren des E-Mail-Systems abhängt. Es erfolgen häu-fig Angriffe auf dieses System, um dessen Verfügbarkeit zu beeinträchtigen und an Informationen durch Ausspähen von E-Mails zu gelangen. Die Sicherung dieser Lebensader der Kommunikation muss für alle Beteiligten eine hohe Priorität einnehmen.Die vorliegende Studie zeigt auf, wie sich Behörden und Unternehmen gegen diese Gefahren schüt-zen können. Sie stellt eine Grundarchitektur für den E-Mail-Client vor (in Abschnitt 3), die unter den Gesichtspunkten der IT-Sicherheit dem Schutz der fundamentalen Grundwerte Vertraulichkeit, Verfügbarkeit, Integrität und Authentizität Rechnung trägt. Empfehlungen zur Konfiguration und zum Betrieb runden die Darstellung ab (Abschnitt 4). Die Anforderungen an die IT-Sicherheit vari-ieren von Organisation zu Organisation. Um hier individuelle Anpassungen vorzunehmen, bei-spielsweise für den hohen Schutzbedarf oder Anpassungen an die Größe der Organisation, werden Varianten vorgestellt (Abschnitt 5), bewertet und Gefährdungen zugeordnet.Zusammen mit der Studie zu E-Mail-Server [ISi-Mail-Server] können bestehende Systeme sicherer gemacht werden oder auch neue konzipiert, umgesetzt und betrieben werden. Hierzu sind die Checklisten, die ergänzend zu jedem Modul veröffentlicht werden, eine praktische Hilfe.



2 GrundlagenDie nachfolgenden Abschnitte befassen sich mit wesentlichen Grundlagen zur Nutzung von E-Mail. Diese Grundlagen sind die Basis für das Verständnis der übrigen Abschnitte und umfassen

– die an einer E-Mail-Kommunikation beteiligten Komponenten,

– die Funktionen eines E-Mail-Clients,

– die Kommunikationsprotokolle,

– die Verfahren zur Authentisierung,

– den Aufbau einer E-Mail und verwendete Formate,

– die E-Mail-Sicherheitskomponenten und

– die digitale Signatur und Verschlüsselung.

2.1 E-Mail-Kommunikation

Eine genauere Betrachtung der E-Mail-Kommunikation zeigt, dass der E-Mail-Client und der E-Mail-Server mehrere Komponenten umfasst (Abschnitt 2.1.1). Neben dem eigentlichen Verwen-dungszweck – dem Lesen, Schreiben und Versenden von E-Mails – bietet der E-Mail-Client auch weitergehende Funktionen (Abschnitt 2.1.2).

2.1.1 E-Mail-Komponenten

Eine E-Mail-Kommunikation umfasst verschiedene Funktionen, die als gesonderte Dienstkompo-nenten − sogenannte Mail Agents − darstellbar sind. Die wesentlichen Elemente, die an einer E-Mail-Kommunikation beteiligt sind, werden in Abbildung 2.1 dargestellt und im Folgenden beschrieben.

Zu einer E-Mail-Kommunikation gehören ein Absender, der die E-Mail erstellt und versendet, und ein Empfänger, dem die E-Mail zugestellt wird und der sie liest. Sowohl auf Absender- als auch auf Empfängerseite sind ein E-Mail-Client und ein E-Mail-Server notwendig. In Abbildung 2.1 ist zu erkennen, dass auf Absender- und auf Empfängerseite beim E-Mail-Client und beim E-Mail-Server jeweils andere Komponenten beteiligt sind.



E-Mail-Client-Komponenten

– Mail User Agent (MUA):

Der MUA dient zum Erstellen, Versenden und Anzeigen von E-Mail-Nachrichten. Geläu-fige MUAs sind zum Beispiel MS Outlook, Lotus Notes, Mozilla Thunderbird oder Kmail.

– Mail Retrieval Agent (MRA):

Der MRA ist der Teil des E-Mail-Clients, der E-Mails von einem E-Mail-Server herunter-lädt und diese in der Regel auf dem Client lokal speichert. Die Funktionalität dieser Kom-ponente verläuft im Hintergrund und ist für den Nutzer nicht sichtbar.

Im vorliegenden Dokument werden die Komponenten MUA und MRA als E-Mail-Client-Software bezeichnet. Falls notwendig, wird eine explizite Unterscheidung der Komponenten vorgenommen.

Wenn der Begriff „E-Mail-Client“ oder kurz „Client“ verwendet wird, bezeichnet dies in der Regel einen Rechner mit einer installierten E-Mail-Client-Software.

E-Mail-Server-Komponenten

– Mail Transfer Agent (MTA):


Abbildung 2.1: Komponenten der E-Mail-Kommunikation


Der MTA nimmt E-Mails von einem E-Mail-Client (MUA) oder einem anderen MTA an und leitet diese an einen anderen MTA oder einen MDA (Mail Delivery Agent) weiter. Bekannte MTAs sind zum Beispiel MS Exchange, Postfix, Sendmail, Lotus Domino oder qmail.

– Mail Delivery Agent (MDA):

Der MDA nimmt E-Mails von einem MTA entgegen und verteilt sie nach vorgegebenen Regeln auf verschiedene E-Mail-Postfächer bzw. verwirft sie (E-Mail-Filter) oder sendet sie zurück, falls der lokale Dienst nicht zuständig ist. Bekannte MDAs sind zum Beispiel procmail oder maildrop.

– POP/IMAP Server:

Ein POP/IMAP Server stellt dem E-Mail-Client -Dienst MRA (Mail Retrieval Agent) die E-Mails der Postfächer zur Verfügung.

In der Praxis sind die verschiedenen Funktionen selten unabhängig voneinander realisiert. Stattdes-sen werden meist mehrere Agents in einem sogenannten E-Mail-Server integriert.

Das vorliegende Dokument beschäftigt sich in den nachfolgenden Abschnitten nur mit den E-Mail-Client-Komponenten. Auf die E-Mail-Server-Komponenten wird detailliert in der Studie [ISi-Mail-Server] eingegangen.

2.1.2 Funktionen eines E-Mail-Clients

Nach der Einführung in die E-Mail-Komponenten werden in diesem Abschnitt die wesentlichen Funktionalitäten von E-Mail-Clients beschrieben.

Allgemeine Funktionen

Die grundlegende Funktion von E-Mail-Clients ist die Verwaltung der elektronischen Post. Dazu gehören die essentiellen Aktionen von Lesen, Schreiben und Versenden von E-Mails. Das Schrei-ben von E-Mails beinhaltet auch das Beantworten und Weiterleiten von Mails.

Darstellung / Anzeige

Normalerweise zeigt der E-Mail-Client in der Eingangsliste empfangener E-Mails nur Absender-informationen (Von, Betreff, Datum, etc.) an. Der Inhalt der Mails wird zu diesem Zeitpunkt noch nicht angezeigt. Dazu muss die komplette E-Mail noch nicht vollständig vom E-Mail-Server herun-tergeladen werden. Beispielsweise kann bei mobilen Geräten der E-Mail-Client so konfiguriert wer-den, dass dieser zuerst nur die Kopfzeilen mit den Absenderinformationen vom E-Mail-Server holt und als Eingangsliste anzeigt.

Viele E-Mail-Client-Produkte verfügen über eine sogenannte E-Mail-Vorschau. Diese zeigt bereits den Inhalt einer E-Mail in einem Vorschau-Fenster an, wenn sie markiert wird. Für die Vorschau-funktionalität muss die E-Mail vom E-Mail-Server vollständig heruntergeladen werden, damit der Inhalt anschließend angezeigt werden kann. Der Anwender bekommt dann aber auch E-Mails ange-zeigt, die er zwar auswählt, um diese zu löschen, aber eigentlich nicht lesen will.

Dateianhänge in E-Mails lassen sich aus dem Vorschaufenster heraus öffnen. Auch Links in den E-Mails können verfolgt werden.



Dateianhänge

Dateianhänge sind Dateien (z. B. Texte, Bilder, Präsentationen), die einer E-Mail angefügt und mit der Nachricht an den Empfänger übertragen werden. Prinzipiell ist die Größe eines Dateianhangs nicht beschränkt, jedoch wird häufig die Größe der gesamten E-Mail begrenzt. In der Praxis haben oftmals die Provider und Unternehmen zumindest bei eingehenden E-Mails eine Größenbeschrän-kung in den MTAs festgelegt, teilweise auch bei ausgehenden E-Mails.

Dateianhänge können genutzt werden, um Schadprogramme zu verbreiten, wie Computer-Viren, Würmer etc. Zum Schutz vor solchen Schadprogrammen sollten geeignete Maßnahmen ergriffen werden. Neben dem Einsatz von Schutzprogrammen ist es wichtig die Nutzer zu sensibilisieren, so dass sie keine suspekt erscheinenden Dateianhänge öffnen.

Lesebestätigungen

Der Absender einer E-Mail kann eine Lesebestätigung vom Empfänger anfordern, die ihm nach dem Anzeigen, Drucken oder Löschen der Nachricht als E-Mail zugeschickt wird. Im E-Mail-Client kann festgelegt werden, ob die Lesebestätigung automatisch, erst nach einer Bestätigung oder grundsätzlich nicht geschickt wird.

Adressbücher

Adressbücher dienen zur Verwaltung von Kontaktdaten und sind oft in die E-Mail-Client-Software integriert. Neben der lokalen Speicherung von Kontaktdaten (lokales Adressbuch) können diese auf einem zentralen Server abgelegt werden.

Kalender

Kalender dienen zur Verwaltung von Terminen und sind oft Bestandteil der E-Mail-Client-Soft-ware. Sie können lokal auf dem Client-Rechner oder auch auf einem zentralen Server gespeichert werden.

Verwaltung eingehender E-Mails

Bei vielen E-Mail-Clients können Filterregeln definiert werden, so dass eingehende E-Mails auto-matisch in dafür vorgesehene Ordner verschoben werden. Je nach verwendeten Produkten erfolgt die Ausführung von Filterregeln auf dem MUA oder auf dem E-Mail-Server (siehe Abschnitt 2.4.2).



2.2 Protokolle

Für die Kommunikation zwischen den verschiedenen E-Mail-Komponenten sind eine Reihe spezifi-scher Protokolle erforderlich. Die wichtigsten Kommunikationsprotokolle zum Austausch oder zur Verwaltung von E-Mail sind POP3 (Abschnitt 2.2.1), IMAP (Abschnitt 2.2.2) und SMTP (Abschnitt 2.2.3). Darüber hinaus existieren proprietäre Protokolle wie beispielsweise Microsoft Messaging API (MAPI), mit dem sich Abschnitt 2.2.4 beschäftigt.

Der Standardansatz für den Abruf von E-Mails ist, dass E-Mail-Clients regelmäßig eine Verbindung zum E-Mail-Server aufbauen und dabei prüfen, ob neue E-Mails vorliegen. Dies wird Polling genannt. Bei Push-E-Mail baut der E-Mail-Server eine Verbindung zum E-Mail-Client auf, sobald neue E-Mails eingetroffen sind.

Viele Realisierungen von Push-E-Mail basieren auf proprietären Protokollen, wie z. B. die Direct Push Technology von Microsoft. Das Lemonade Profile der IETF ([RFC 4550]) ist ein Vorschlag zu einem Standardprotokoll, das auf SMTP und IMAP basiert. Push-Protokolle werden in dieser Studie nicht näher betrachtet.

Abschnitt 2.2.5 befasst sich mit Protokollen für den Adressbuchzugriff. Protokolle für den Zugriff auf Kalenderdaten werden in Abschnitt 2.2.6 beschrieben. Abschnitt 2.2.7 betrachtet Protokolle zur Authentisierung.

2.2.1 Kommunikationsprotokoll POP3

Das Post Office Protocol Version 3 (POP3 [RFC 1939]) ist ein verbindungsorientiertes, textbasier-tes Protokoll zum Herunterladen von E-Mails von einem POP/IMAP-Server auf einen E-Mail-Cli-ent, wobei die Kommunikation standardmäßig über Port 110/TCP abläuft. Verbindungsorientiert bedeutet, dass vor dem Austausch von Daten eine Verbindung zwischen den Kommunikationspart-nern hergestellt wird. Textbasiert heißt, dass Protokollnachrichten in Textdarstellung im Zeichen-satz US-ASCII kodiert verschickt werden.

POP3 ist vor allem für den Betrieb im abgesetzten Modus (disconnected operation) gedacht, bei dem der Client seine E-Mails ohne dauerhafte Verbindung zu einem zentralen E-Mail-Server auf dem lokalen Rechner verwaltet. Der Client initiiert die Abfrage auf neue E-Mails auf dem E-Mail-Server (Polling). Das Protokoll unterstützt verschiedene Methoden für die Authentisierung des Nut-zers (siehe Abschnitt 2.2.7), jedoch keine Mechanismen zur Integritätsprüfung und Verschlüsse-lung.

POP3S

Das Protokoll POP3S (POP3 über SSL, [RFC 2595]) basiert auf POP3, nutzt jedoch Secure Socket Layer (SSL bzw. SSLv3) oder Transport Layer Security (TLS bzw. TLSv1) als Transportprotokoll für einen sicheren E-Mail-Abruf. SSL/TLS ermöglicht eine sichere Kommunikation über unsichere Netze, wie beispielsweise das Internet, so dass Integrität und Vertraulichkeit der übermittelten Daten gewährleistet sind. Dazu bietet SSL/TLS Funktionen zur Verschlüsselung und Authentisie-rung. Typischerweise wird nur die Identität des E-Mail-Servers über SSL/TLS geprüft. Es ist aber möglich die Authentisierung so zu erweitern, dass auch die Identität des Benutzers geprüft wird. Dazu muss allerdings eine Public-Key-Infrastructure (PKI) eingeführt werden.

SSL/TLS nutzt eine Kombination von asymmetrischer und symmetrischer Kryptografie. Dabei erfolgt die eigentliche Verschlüsselung der Nachricht aus Performancegründen mittels eines sym-metrischer Verfahrens. Der dabei gewählte geheime, zufällige Sitzungsschlüssel wird beim Aus-



tausch mittels asymmetrischer Verschlüsselung vor unbefugtem Mitlesen geschützt. Dies wird auch als hybrides Verschlüsselungsverfahren bezeichnet. Als asymmetrische Verfahren werden RSA, Diffie-Hellman und DSA genutzt. Für die symmetrische Kryptografie werden RC2, RC4, IDEA, DES, Triple DES, AES oder Camellia verwendet. Damit werden sowohl die Authentisierungsdaten (Benutzername und Passwort) als auch der Text der E-Mail einschließlich der E-Mail-Anhänge ver-schlüsselt übertragen.

2.2.2 Kommunikationsprotokoll IMAP

Das Internet Message Access Protocol Version 4 (IMAPv4 [RFC 3501]) ist ein verbindungsorien-tiertes, textbasiertes Protokoll für den Zugriff und die Verwaltung von E-Mails auf dem E-Mail-Server, wobei zur Kommunikation standardmäßig Port 143/TCP verwendet wird. IMAP ermöglicht dem Client das Bearbeiten, Verschieben oder Löschen von E-Mails auf dem E-Mail-Server (MDA) mit entsprechenden Funktionen für das Verwalten seiner Mailbox.

Das IMAP-Protokoll hat neben dem Polling-Mechanismus eine ähnliche Erweiterung wie Push-E-Mail, womit der E-Mail-Client über das Eintreffen neuer E-Mails benachrichtigt werden kann. Der Client baut eine Verbindung zum Server auf und hält diese mit dem Kommando IMAP IDLE offen. Über diese Verbindung kann der E-Mail-Server durch das EXISTS Kommando den E-Mail-Client über neu eingetroffene E-Mails benachrichtigen.

IMAP unterstützt verschiedene Methoden zur Authentisierung des Nutzers (siehe Abschnitt 2.2.7) und bietet Protokollelemente für das Aushandeln einer SSL/TLS-Verschlüsselung.

IMAPS

Das Protokoll IMAPS (IMAP über SSL, [RFC 2595]) basiert auf IMAP, nutzt jedoch SSL/TLS als Transportprotokoll für einen sicheren E-Mail-Abruf. Das Protokoll schützt sowohl die Nutzdaten als auch die Steuerinformationen des Protokolls.

2.2.3 Kommunikationsprotokoll SMTP

Das Simple Mail Transfer Protocol (SMTP [RFC 2821]) ist ein verbindungsorientiertes, textbasier-tes Protokoll zur Übertragung von E-Mails zwischen E-Mail-Servern (MTAs) oder zwischen E-Mail-Client und E-Mail-Server. Ein Client sendet E-Mails standardmäßig an Port 25/TCP des MTA (bzw. an Port 587/TCP eines E-Mail-Servers neuerer Bauart [RFC 4409]), die Weiterleitung zwi-schen MTAs erfolgt über Port 25/TCP.

Tabelle 1 zeigt den Ablauf einer SMTP-Konversation zwischen einem E-Mail-Client und einem E-Mail-Server1:

Nr. SMTP-Befehl Erläuterung

1 telnet server.[domäne].de 25 Verbindungsaufbau

2 220 server.[domäne].de SMTP service ready

Server meldet sich

3 EHLO client.[domäne].de Client sendet ein SMTP-"Hello" und seinen vollständigen Namen

1 Im Beispiel wird beim Verbindungsaufbau das Telnet-Kommando mit Port 25 verwendet. E-Mail-Server bauen die TCP-Verbindung natürlich selbst auf und verwenden dieses Kommando nicht.



Nr. SMTP-Befehl Erläuterung

4 250 mail.[domäne].de Hello [127.126.125.124], pleased to meet you250-8BITMIME250-SIZE250-DSN250-PIPELINING 250 HELP

Antwort des E-Mail-Servers mit einer Liste unterstützter Befehle und Mecha-nismen

5 MAIL FROM: sender@client.[domäne].de Spezifikation des Absenders

6 250 ok Server akzeptiert den Empfänger

7 RCPT TO: empfaenger@server.[domäne].de

Spezifikation des Empfängers

8 250 ok Server akzeptiert diesen Empfänger

9 DATA Client möchte den Inhalt der Mail sen-den

10 354 Enter mail input, end with "." on a line by itself

Server wartet auf Daten

11 Subject: TestmailTo: empfaenger@server.[domäne].deFrom: sender@client.[domäne].deDate: Wed, 31 Oct 2007 11:55:51 +0100...

Hallo Empfänger,dies ist eine Testmail.

Mit freundlichen GrüßenSender.

Client sendet den Inhalt der E-Mail und schließt mit einem „.“ ab.

12 250 message accepted for delivery Server hat die E-Mail akzeptiert.

12 QUIT Client verabschiedet sich

14 221 server.[domäne].de closing con-nection

Server verabschiedet sich

Tabelle 1: SMTP-Konversation über Telnet

SMTP-Envelope

Ein SMTP-Envelope ist ein Umschlag, der der eigentlichen Mail vorangestellt wird. Er enthält die Absenderadresse und die Liste der Empfänger, an die der Mail-Server die E-Mail weiterleiten soll. Wenn ein Mail-Server eine Mail an mehrere Mail-Server verteilt, wird die Mail kopiert und jeder Kopie ein eigener SMTP-Envelope vorangestellt, der nur die Empfänger enthält, für die der Mail-Server zuständig ist. Dies kann beispielsweise der Fall sein, wenn in der E-Mail Empfänger aus unterschiedlicher Domänen angegeben sind. Der Endnutzer bekommt den SMTP-Envelope im Nor-malfall nicht zu sehen, da diese Informationen beim Einsortieren in das Postfach des Empfängers entfernt werden.



Im Beispiel in Tabelle 1 gehören die Zeilen 5 und 7 zum SMTP-Envelope.

SMTPS

SMTP ist ungesichert und unverschlüsselt, wie man bei den Klartextmeldungen in Tabelle 1 erken-nen kann. Zur Absicherung kann das Transportprotokoll Transport Layer Security (TLS) genutzt werden, das den Transportkanal kryptografisch sichert. Diese Erweiterung für Secure SMTP über SSL/TLS ist in [RFC 3207] beschrieben und wird als SMTPS bezeichnet.

Dabei werden sowohl die Authentisierungsdaten (Benutzername und Passwort) als auch der Text der E-Mail einschließlich der E-Mail-Anhänge verschlüsselt übertragen. Es muss allerdings beach-tet werden, dass SSL/TLS eine Punkt-zu-Punkt-Verschlüsselung ist. Das bedeutet, dass der SSL/TLS-Tunnel bei jedem MTA abgebrochen und zum nächsten MTA wieder neu aufgebaut wird. Es besteht somit keine Ende-zu-Ende Verschlüsselung wie bei S/MIME oder OpenPGP (siehe Abschnitt 2.5).

2.2.4 Kommunikationsschnittstelle MAPI

MAPI (Messaging Application Programming Interface) ist eine proprietäre Programmierschnitt-stelle, die aus verschiedenen Programmelementen besteht und in denen verschiedene Funktionen implementiert sind. Ein Programmelement dient dazu über das RPC-Protokoll E-Mails zum Microsoft Exchange Server zu verschicken und vom Server abzuholen. Andere MAPI-Programm-elemente verwalten Termine, Kontakte, Aufgaben und E-Mails auf einem zentralen E-Mail-Server.

2.2.5 Protokolle für den Adressbuchzugriff

Ein E-Mail-Client kann zur Organisation der Kontaktdaten einen lokalen Verzeichnisserver nutzen.In der Regel verwendet der E-Mail-Client für den Zugriff auf den Verzeichnisserver das Protokoll LDAPv3 (Lightweight Directory Access Protocol Version 3, [RFC 4510]) und kann dort Kontakt-daten abfragen und ggf. ändern. Die Authentisierung erfolgt bei LDAPv3 normalerweise im Klar-text. Zur Erhöhung der Sicherheit beschreibt [RFC 4513] Authentisierungs- und Sicherheitsmecha-nismen von LDAP wie z. B. SASL und STARTTLS.Einige Produkte verwenden zur Realisierung von Adressbüchern proprietäre Protokolle.

2.2.6 Protokolle für den Kalenderzugriff

Die Verwaltung von Terminen innerhalb des E-Mail-Clients kann über die lokale Kalenderfunktio-nalität oder über einen zentralen Server erfolgen. Für die Kommunikation mit einem zentralen Server kann CalDAV ([RFC 4791], kurz für Calendering Extensions to WebDAV) benutzt werden. Das Protokoll CalDAV greift über WebDAV (Web-based Distributed Authoring and Versioning) auf Kalenderdateien zu. WebDAV ist ein Standard zur Bereitstellung von Dateien im Internet, der dem Benutzer ermöglicht auf die Dateien wie auf eine Festplatte zugreifen zu können. CalDAV nutzt das Protokoll HTTP für die Kommunikation zwischen E-Mail-Client und E-Mail-Server und erweitert HTTP um Kalenderfunktionalitäten.

Ferner gibt es proprietäre Lösungen für den Kalenderzugriff wie z. B. das Exchange-Protokoll (die Microsoft Bezeichnung ist RPC/IP), bei dem über eine MAPI-Schnittstelle mit dem Server kommu-niziert werden kann.



Die Open Source Initiative Kolab verwendet IMAP für die Übertragung und Verwaltung von Kon-takt- und Kalenderdaten. Gruppenkalender und Gruppenkontaktordner werden mittels IMAP Access Control Lists (ACL) unterstützt.

2.2.7 Protokolle zur Authentisierung

Authentisierung bezeichnet den Vorgang, bei dem beispielsweise die Identität eines E-Mail-Clients oder eines E-Mail-Servers überprüft wird. Drei der wichtigsten und gebräuchlichsten Protokolle werden in diesem Abschnitt dargestellt.

SASL

SASL (Simple Authentication and Security Layer) stellt Funktionen für die Authentisierung für unterschiedliche verbindungsorientierte Protokolle (z. B. SMTP, IMAP und POP3) zur Verfügung und ist in [RFC 4422] definiert. Durch SASL werden Anwender authentisiert bzw. E-Mail-Clients am E-Mail-Server authentisiert, und es ist möglich eine verschlüsselte Verbindung auszuhandeln.

Der Ablauf einer Authentisierung ist in Abbildung 2.2 dargestellt. Der Client initialisiert eine Anfrage zur Authentisierung an den Server. Der Server antwortet dem Client mit Informationen über die unterstützten Authentisierungsmechanismen. Aus diesen wählt der Client einen Mechanis-mus aus und übermittelt nun seine Authentisierungsdaten zum Server, der sie verifiziert. Bei erfolg-reicher Verifizierung wird der Client für bestimmte Aktionen autorisiert. Optional kann nach erfolg-reicher Authentisierung ein Mechanismus verwendet werden, der sowohl eine verschlüsselte Ver-bindung als auch die Sicherstellung der Integrität erlaubt.

Zur Übertragung der Authentisierungsdaten gibt es unterschiedliche Mechanismen. Beim einfachen Mechanismus PLAIN werden alle Daten der Authentisierung im Klartext ausgetauscht. Wenn auf der Transportebene zusätzlich noch mit SSL/TLS verschlüsselt wird, werden sowohl Authentisie-rungsdaten als auch Nutzdaten geschützt. Daher ist hierbei der Mechanismus PLAIN ausreichend.


Abbildung 2.2: SASL-Authentisierung


SMTP-Auth

SMTP-Auth ([RFC 4954]) ist eine Erweiterung des SMTP-Protokolls, bei der der E-Mail-Client sich am Server authentisiert. Nach der Aushandlung eines Authentisierungsverfahrens kann sich der E-Mail-Client am E-Mail-Server authentisieren. Bei den Authentisierungsverfahren PLAIN und LOGIN wird Benutzername und Kennwort unverschlüsselt übertragen. Daher ist die Verwendung von SSL/TLS sinnvoll, um die Authentisierungsdaten zu schützen.

Die Authentisierung mit SMTP-Auth erfolgt nach dem EHLO-Befehl (vgl. Tabelle 1). In der nach-stehenden Tabelle 2 ist ein Ausschnitt einer Authentisierung mit SMTP-Auth dargestellt:

250 AUTH CRAM-MD5 LOGIN PLAIN Nach dem EHLO antwortet der Server mit einer Liste der unterstützten Authentisierungsverfahren (hier CRAM-MD5, LOGIN, PLAIN)

AUTH LOGIN Gewähltes Authentisierungsverfahren: LOGIN

334 VXNlcm5hbWU6QmVudXR6ZXJuYW1l334 UGFzc3dvcmQ6QmVudXR6ZXJwYXNzd29ydA==

Im nächsten Schritt werden Benutzername (Username)und Passwort (Password) abgefragt. Da LOGIN gewählt wurde, werden die Daten Base64-kodiert übertragen. Nachstehend sind die Daten der linken Seite im Klartext dargestellt:Username:BenutzernamePassword:Benutzerpasswort

235 ok Server akzeptiert den Empfänger

Tabelle 2: Authentisierung mit SMTP-Auth

Nach erfolgreicher Authentisierung ist eine Änderung (Fälschung) des SMTP-Envelopes, der Header-Daten oder des E-Mail-Bodys durch den Benutzer aber immer noch möglich, da mittels des SMTP-Auth-Mechanismus der Benutzer authentisiert wird, aber nicht die Envelope- und Header-Daten oder der Inhalt des E-Mail-Bodys. Der Empfänger kann nicht feststellen, ob der Absender authentisiert worden ist, da die Authentisierung üblicherweise zwischen sendendem E-Mail-Client und sendendem E-Mail-Server stattfindet.

SMTP-after-POP

SMTP-after-POP ist ein Verfahren, das einem E-Mail-Client erlaubt, auf Basis einer vorab durchge-führten erfolgreichen Authentisierung über das POP3-Protokoll, E-Mails zum E-Mail-Server zu verschicken. Beim Versenden einer E-Mail mittels SMTP findet die Identifikation des E-Mail-Cli-ents über die IP-Adresse statt, die vorher bei einer zuvor erfolgreichen POP3-Authentisierung ver-wendet wurde.

Dieses Verfahren hat den Vorteil, dass beim E-Mail-Client kein zusätzliches Protokoll realisiert werden muss. Dagegen können folgende Nachteile entstehen:



– Werden dynamische IP-Adressen benutzt, kann es vorkommen, dass der E-Mail-Client seine IP-Adresse zwischen POP3-Authentisierung und dem Verschicken von E-Mails über das SMTP-Protokoll ändert und so ein Senden der E-Mail verweigert wird.

– Auf dem E-Mail-Server muss eine Zeitbeschränkung zwischen POP3-Authentisierung und dem Freischalten von SMTP für den E-Mail-Client eingestellt werden. Dies kann zu Fehlermeldun-gen beim E-Mail-Client führen, wenn dieser außerhalb der Zeitbeschränkung eine E-Mail ver-schicken möchte.

– Der Einsatz von SMTP-after-POP in Zusammenhang mit NAT (Network Address Translation - Sammelbegriff für Verfahren, um automatisiert und transparent Adressinformationen in Daten-paketen durch andere zu ersetzen) kann dazu führen, dass ein ganzes Subnetz freigeschaltet wird.

– Ein E-Mail-Client, der eine IP-Adresse verwendet, die vorher bereits bei einer POP3-Authenti-sierung genutzt wurde (z. B. bei NAT oder dynamischer IP-Adresse), könnte ohne weitere Prü-fung E-Mails versenden.

Prüfung der Absenderadresse

Zur Authentisierung des Clients kann die Absenderadresse verwendet werden (z. B. auf Basis der Domänennamen). Problematisch ist hierbei, dass die Absenderadresse innerhalb des SMTP-Proto-kolls sehr einfach zu fälschen ist und so nur ein ungenügender Schutz vorhanden ist.

2.2.8 Übersicht der Protokolle

Einen schnellen Überblick über die relevanten Protokolle und deren Sicherheitseigenschaften gewährt Tabelle 3. Wenn das Protokoll die Sicherheitseigenschaft besitzt, wird dies in dem zugehö-rigen Feld mit einem „x“ gekennzeichnet. Ein Minuszeichen („-“) zeigt an, dass das Protokoll die Sicherheitseigenschaft nicht besitzt.

Protokoll PortSicherheitseigenschaften

Authenti-sierung

Integritäts-sicherung

Verschlüs-selung

Referenz

POP3 110/TCP x - - RFC 1939

POP3S 110/9952/TCP x x x RFC 2595

IMAP 143/TCP x - - RFC 3501

IMAPS 143/9933/TCP x x x RFC 2595

SMTP 25/TCP - - - RFC 2821

SMTP (Nur Client zu Server) 587/TCP x - - RFC 4409

SMTP-Auth 25/TCP x - - RFC 2554

SMTP über TLS (SMTPS)

465/TCP x x x RFC 3207

SASL x x x RFC 4422

2 In [RFC 2595] wird von der Benutzung eines separaten Ports für POP3 (995/TCP) über TLS abgeraten, stattdessen wird das STLS Kommando empfohlen.

3 In [RFC 2595] wird von der Benutzung eines separaten Ports für IMAP (993/TCP) über TLS abgeraten, stattdessen wird das STARTTLS Kommando empfohlen.



Protokoll PortSicherheitseigenschaften

Authenti-sierung


Verschlüs-selung

Referenz

LDAP 389/TCP x - - RFC 4511

LDAP über TLS (LDAPS) 389/6364/TCP x x x RFC 4513

CalDAV5 x (x) (x) RFC 4791

SMTP-after-POP x - -

Prüfung der Absenderadresse x - -

Tabelle 3: Übersicht der Protokolle und deren Sicherheitseigenschaften

4 In [RFC 2595] wird von der Benutzung eines separaten Port für LDAP(636/TCP) über TLS abgeraten, stattdessen wird das STARTTLS Kommando empfohlen.

5 Authentisierung kann mittels HTTP umgesetzt werden, Integritätssicherung und Verschlüsselung können mittels HTTPS umgesetzt werden.



2.3 Aufbau und Formate

Damit die Interoperabilität zwischen verschiedenen E-Mail-Clients und E-Mail-Servern gewährleis-tet ist, sind verschiedene (offene) Standards für den Aufbau und die Formate von E-Mails, Postfä-chern, Kalendern und Adressbüchern spezifiziert worden.

2.3.1 Struktureller Aufbau von E-Mails

Eine E-Mail besteht aus einem Kopfteil (E-Mail-Header) und dem Inhalt der Nachricht (E-Mail-Body). Das Format einer E-Mail wird in [RFC 2822] definiert.

MIME (Multipurpose Internet Mail Extensions) erweitert den Standard RFC 2822 durch die Defini-tion weiterer Header-Einträge, die die Art der Daten im Body der Nachricht beschreiben. Beispiels-weise kann angegeben werden, dass es sich um mehrteilige Nachrichten handelt oder dass ein Bild übertragen wird. Damit ist es möglich, dass

– Texte im E-Mail-Body auch mit einem anderen Zeichensatz als 7-Bit-ASCII geschrieben werden können,

– im E-Mail-Body auch andere Formate außer Text enthalten sein können,

– der E-Mail-Body aus mehreren Teilen bestehen (multipart) kann,

– in textbasierten Header-Informationen auch ein anderer Zeichensatz als 7-Bit-ASCII verwendet werden kann.

Die Erweiterungen werden durch neue Zeilen im Header umgesetzt (siehe Abschnitt 2.3.3).

E-Mail-Header

Der E-Mail-Header beinhaltet Einträge, die Informationen über Absender, Empfänger, Erstellungs-datum und Stationen der Übermittlung geben.

E-Mail-Header-Zeilen

Erläuterung

From „From“ bezeichnet eine oder mehrere E-Mail-Adressen (viele Mail-Clients unterstützen nur eine Mail-Adresse), von der die Nachricht gesendet wurde.Beispiel:From: [email protected]

To “To“ enthält eine oder mehrere E-Mail-Adressen, an die die Nachricht gesen-det werden soll.Beispiel:To: [email protected]

CC In „CC“ werden eine oder mehrere E-Mail-Adressen der Empfänger angege-ben, die eine Kopie der E-Mail erhalten sollen.







Erläuterung

BCC Hier werden eine oder mehrere E-Mail-Adressen der Empfänger angegeben, die eine Blindkopie der E-Mail erhalten sollen. Für die Empfänger ist so nicht sichtbar, an wen eine Kopie der Nachricht gesendet wurde. Bei der Übergabe der E-Mail an den ersten MTA werden die Empfängeradressen aus der BCC-Headerzeile in den SMTP-Envelope („RCPT TO:“ siehe Tabelle 1 auf Seite 14) übernommen und es wird die BCC-Headerzeile gelöscht. Somit kann die Zustellung der E-Mail durch den MTA auch ohne übermittelte BCC-Header-Zeile erfolgen. Beispiel:BCC: [email protected]

Subject Im „Subject“ oder auch Betreff kann der Absender eine Kurzinformation zum Inhalt der E-Mail angeben. Beispiel:Subject: ISi-S Sichere Nutzung von E-Mail

Reply-To „Reply-To“ enthält eine oder mehrere E-Mail-Adressen, an die eine Antwort gesendet werden soll, falls diese nicht mit denen im „From“-Header identisch sind.

Date Diese Zeile enthält das Datum und die Uhrzeit, wann die E-Mail gesendet wurde.Beispiel:Date: Wed, 31 Oct 2007 11:55:51 +0100

Message-ID Diese Zeile enthält eine Nummer, die zur eindeutigen Identifizierung der Nachricht dient.Beispiel:Message-Id: <[email protected]>

MIME-Version In „MIME-Version“ wird die unterstützte MIME-Version angegeben.Beispiel:MIME-Version: 1.0

Content-Type Dieser wird von MIME verwendet und klassifiziert den sogenannten „Internet Media Type“, also die Art des Textes im Mail-Body. Die Angabe erfolgt aus zwei Teilen: aus einem Typ und einem Untertyp, die über das Zeichen „/“ getrennt werden. Als Typ ist unter anderen text, image, audio, video, message oder multipart möglich. Zu jedem Typ sind ein oder mehrere Untertypen fest-gelegt. Beispiel:Content-Type: text/plain;

Content-Transfer-Encoding

„Content-Transfer-Encoding“ wird ebenfalls von MIME verwendet und gibt an, mit welchem Algorithmus die Daten des E-Mail-Bodys codiert wurden (z. B. 7 Bit, 8 Bit, quoted-printable, UUencode oder base64).

Organization Diese Zeile gibt die Organisation des Absenders an (z. B. Firma, Verein).Beispiel:Organization: Musterfirma




Erläuterung

Received In diesen Zeilen werden Vermerke über die Zustellung einer Nachricht einge-tragen. Vor dem Weiterleiten einer E-Mail fügt jeder MTA eine „Received“-Zeile in den E-Mail-Header ein und hinterlässt hier also seine Kennung.Beispiel:Received: from fw.organization01.de (mail3.organiza-tion01.de [199.199.199.199])by mail01.mail.organiza-tion02.com with ESMTP; Wed, 31 Oct 2007

User-Agent Diese Zeile enthält Angaben zum E-Mail-Client des Absenders.Beispiel:User-Agent: KMail/1.7 (proko2 2.1.10)

X-Header Nicht standardisierte Header-Zeilen können dem E-Mail-Header vom E-Mail-Client zugefügt werden. Diese werden mit „X" beginnend in den Header einge-fügt und werden auch als X-Header bezeichnet.Beispiel:X-Mailer: Produced By Microsoft MimeOLE V6.00.2800.1409

Tabelle 4: E-Mail-Header

Beispiel eines vollständigen E-Mail-Headers:

Received: from fw.maildomain1.de (mail.maildomain1.de [199.199.199.199])by mail.maildomain2.de with ESMTP; Mon Jan 7 2008Message-ID: <[email protected]> Date: Mon Jan 7 11:22:15 2008From: [email protected]: Alice <[email protected]>Cc: Sekretariat <[email protected]> User-Agent: Mozilla Thunderbird 1.0.6MIME-Version: 1.0Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: 8bitSubject: Betreff der E-Mail

Header-Zeilen können allerdings gefälscht werden. Beispielsweise kann bei „Received“-Zeilen immer nur dem letzten Eintrag vertraut werden, da dieser vom eigenen E-Mail-Server in dem Header eingetragen wurde. Die anderen „Received“-Zeilen könnten manipuliert worden sein.

E-Mail-Body

Im E-Mail-Body wird der Inhalt der Nachricht dargestellt. Der Text besteht aus Zeichen des 7-Bit-ASCII-Zeichensatzes. Erweiterungen des E-Mail-Bodys, beispielsweise mit Anhängen, werden gemäß dem MIME-Standard interpretiert (siehe Abschnitt 2.3.3). E-Mail-Bodys können auch im HTML-Format verfasst werden. Zur Gewährleistung der Interoperabilität werden HTML-E-Mails oft sowohl im HTML- als auch im Textformat übertragen. Eine genaue Betrachtung von HTML-E-Mail erfolgt in Abschnitt 2.3.5.



2.3.2 Zeichensätze

Ein Zeichensatz ist ein Vorrat an Elementen (Zeichen) zur Darstellung von Texten. In der Compu-tertechnik werden den alphanumerischen Zeichen eines Zeichensatzes Zahlen zugeordnet. Grund-sätzlich unterscheidet man

– 7-Bit-Zeichensatz (128 Zeichen, z. B. ASCII),

– 8-Bit-Zeichensatz (256 Zeichen z. B. ISO 8859-15) und

– variable Zeichensätze (8 bis 32 Bits, z. B. Unicode).

– Der verbreitetste Unicode-Zeichensatz ist der UTF-8 (8 Bit Unicode Transformation Format).

– Darüber hinaus wird auch der UTF-16 verwendet, bei dem für die Kodierung eines Zeichens 16 oder 32 Bit benutzt werden.

Der Standard [RFC 2822] schreibt einen 7-Bit ASCII-Zeichensatz für E-Mails vor. Zeichen außer-halb des 7-Bit ASCII-Zeichensatzes müssen mittels MIME kodiert werden, z. B. als Base64 oder quoted printable. Viele E-Mail-Clients unterstützen heutzutage auch 8-Bit Zeichencodes wie UTF-8 und ISO 8859. In ISO 8859-1 (Latin-1) entsprechen die mit sieben Bit kodierbaren Zeichen mit füh-rendem Nullbit dem Zeichensatz 7-Bit US-ASCII.

2.3.3 Dateianhänge

Dateianhänge werden nach MIME ([RFC 2045]) verschickt. Wie in Abschnitt 2.3.1 beschrieben, werden die MIME-spezifischen Kodierungen der E-Mail in explizit dafür vorgesehenen Header-Zeilen festgelegt. Diese Header-Zeilen wurden bereits in Abschnitt 2.3.1 aufgezeigt und werden nachstehend noch einmal kurz dargestellt:

E-Mail-Header Erläuterung

MIME-Version In „MIME-Version“ wird die unterstützte MIME-Version angegeben.Beispiel:MIME-Version: 1.0

Content-Type Die Zeile „Content-Type“ gibt den Typ der Nachricht an (z. B. text für Text-nachrichten, multipart für mehrteilige Nachrichten).Beispiel:Content-Type: multipart/mixed

Content-Transfer-Encoding

„Content-Transfer-Encoding“ gibt an, mit welchem Algorithmus die Daten des E-Mail-Bodys codiert wurden (z. B. 7 Bit, 8 Bit, quoted-printable, UUencode oder base64).

Tabelle 5: MIME-spezifische E-Mail-Header-Zeilen

Für Nachrichten des Typs multipart, bei denen der E-Mail-Body aus mehreren Teilen besteht, gibt es Untertypen, die ebenfalls im Header Content-Type hinter dem Typ multipart angegeben werden. Einige Beispiele von Untertypen sind in nachstehender Tabelle 6 dargestellt:



Untertyp des Typs multipart

Erläuterung

/mixed Bei diesem Untertyp können die einzelnen Teile der Mail unterschiedliche Content-Types haben (z. B. JPEG-Bilder und MP3-Dateien). Sofern kein Con-tent-Type angegeben wird, wird text/plain verwendet.

/digest Dies entspricht dem Untertyp /mixed, jedoch wird als Standard der Content-Type message/rfc822 verwendet.

/alternative Dieser Untertyp gibt an, dass die einzelnen Teile der Mail, soweit möglich, dieselbe Information enthalten. Dies wird beispielsweise verwendet, um eine E-Mail gleichzeitig im Textformat und HTML-Format zu übermitteln. Ein E-Mail-Client, der kein HMTL darstellen kann (z. B. E-Mail-Client in einem Handy) kann dann die Textnachricht anzeigen.

/related Dieser Untertyp wird für Objekte genutzt, auf die durch HTML-Links verwie-sen wird.

Tabelle 6: Untertypen von Multipart-Nachrichten

Da eine E-Mail des Typs multipart aus mehreren Teilen (Bodyparts) besteht, werden diese durch Grenzlinien – sogenannte Message Boundaries – voneinander getrennt.

Beispiel für eine Boundary: --- Message Boundary ---

Nachstehend ist ein Beispiel einer MIME-Nachricht aufgeführt. Diese Nachricht enthält einen Text, ein Bild im JPG-Format und eine PostScript-Datei. Die einzelnen Teile der Nachricht sind, wie oben bereits beschrieben, durch Message Boundaries voneinander getrennt:

MIME-Version: 1.0Content-Type: multipart/mixed; boundary="--- Message Boundary ---"From: Max MustermannTo: [email protected]: UnterlagenDate: Mon, 07 Sep 1998 19:45:19 -0400

--- Message Boundary ---Content-Type: text/plain; charset=us-asciiContent-Transfer-Encoding: 7bit

Hallo Alice, in der Anlage die gewünschten Unterlagen.Mit freundlichen Grüßen,Max

--- Message Boundary ---Content-Type: image/jpg Content-Transfer-Encoding: base64

<<nicht lesbare Kodierung des JPG-Bildes>>



--- Message Boundary ---Content-Type: application/postscript; name="datei.ps" Content-Transfer-Encoding: 7bit

<<nicht lesbare Kodierung des PostScript–Dokuments>>

Das E-Mail-Programm Outlook von Microsoft verschickt Nachrichten auch in einem speziellen proprietären Format, das mit „Transport-Neutral-Encapsulation-Format“ (TNEF) bezeichnet wird. Dieses Format wird verwendet, wenn das proprietäre Nachrichtenformat RTF (Rich-Text-Format) im E-Mail-Client ausgewählt wurde. Dazu wird die eigentliche E-Mail in der Dateianlage als „win-mail.dat“ oder „win.dat“ übertragen.

2.3.4 Lesebestätigungen

Lesebestätigungen sind im Standard [RFC 3798] definiert. Dabei setzt der E-Mail-Client den Ein-trag „Disposition-Notification-To:“ im E-Mail-Header.

Beispiel für die Anforderung einer Lesebestätigung:

Disposition-Notification-To: [email protected]

2.3.5 HTML-E-Mail

Nachrichten können auch als HTML-E-Mails versendet werden. Dabei wird zur Formatierung der E-Mails HTML benutzt. HTML-E-Mails besitzen eine höhere Komplexität als Text-E-Mails und sind signifikant größer. Die Darstellung einer HTML-E-Mail ist von den verwendeten E-Mail-Clients abhängig. Beispielsweise werden optische Darstellungen und Formatierungen eventuell nicht so angezeigt, wie sie der Absender erstellt hat. Zur Gewährleistung der Kompatibilität werden HTML-E-Mails oft zusätzlich im Format Text verschickt. Dazu wird der MIME-Typ multi-part/alternative genutzt, der für mehrere alternative Darstellungen von Informationen geeignet ist.

Zur Darstellung von HTML-E-Mails nutzt der E-Mail-Client häufig Bibliotheken eines Browsers (z. B. Internet Explorer). Damit treten prinzipiell die gleichen Sicherheitsprobleme wie bei einem Browser auf.

Bei HTML-E-Mails besteht auch die Möglichkeit der Nutzung von Aktiven Inhalten. Aktive Inhalte sind zusätzliche Programme im HTML-Code, die aktiv auf dem Rechner des Anwenders ausgeführt werden. Aktive Inhalte werden beispielsweise mit VBScript, JavaScript, ActiveX-Controls und Java Applets realisiert. Durch die Verwendung von Aktiven Inhalten bestehen Gefahren und Risiken, wie das Zerstören von Daten, die Übertragung vertraulicher Daten (z. B. Passwörter) an Unbefugte und die Veränderung von Daten.

2.3.6 E-Mail-Dateien/Postfächer

E-Mails können in verschiedenen Formaten gespeichert werden. Die verbreitetsten Dateiformate sind:

– durch Tabulator/Komma getrennte Werte (z. B. csv). Bei diesem Format ist die Feldzuordnung nicht standardisiert.

– Proprietäre Microsoft Formate (z. B. pst, eml, msg)



– mbox: Dieses Mail-Format wird schon sehr lange bei Unix-Systemen verwendet. Es kann eine beliebige Anzahl von E-Mails in einer Datei gespeichert werden. Da alle E-Mails in einer einzigen Datei abgelegt sind, muss darauf geachtet werden, dass nicht zwei Anwendungen gleichzeitig in diese Datei schreiben.

– Maildir:Beim maildir-Format wird jede Nachricht in einer separaten Datei gespeichert.

2.3.7 Adressbücher

Um Einträge in Adressbüchern zwischen Systemen auszutauschen (z. B. über Exportfunktionen) sind für Adressbücher folgende Formate definiert:

– ASCII-Datei mit durch Tabulator/Komma getrennten Werten. Bei diesem Format entstehen durch die nicht standardisierte Feldzuordnung Probleme.

– vCard ist eine Spezifikation eines Dateiformats für einzelne Adressbucheinträge.

– Einträge in Verzeichnisservern, die in Dateien des Formats LDIF ([RFC 2849]) exportierbar sind.

Keines der oben genannten Formate verfügt über Mechanismen zur Gewährleistung der Integrität oder Vertraulichkeit.

2.3.8 Kalender

Als Kalenderformat kann für einzelne Kalendereinträge das iCalendar-Format ([RFC 2445]) ver-wendet werden, welches das vCalendar-Format abgelöst hat. iCalendar ist ein Standard zum Aus-tausch von Kalenderinformationen. iCalendar-Informationen werden üblicherweise mittels E-Mail ausgetauscht, es ist aber unabhängig vom Transportprotokoll definiert.

Eine weitere Lösung ist die OpenSource-Groupware-Initiative Kolab. Die Daten werden im Kolab XML Format gespeichert und können mehrere Kalendereinträge enthalten.



2.3.9 Übersicht der Formate

In Tabelle 7 wird eine Übersicht über die verwendeten Standards der Formate gegeben. Die For-mate von E-Mails, Kalendern und Adressbüchern haben keine Sicherheitseigenschaften. In Abschnitt 2.5 werden Verfahren beschrieben, die die Formate um Sicherheitseigenschaften erwei-tern.

Format Titel des Standards Referenz

E-Mail-Format Internet Message Format RFC 2822

Dateianhänge: MIME MIME Part One: Format of Internet Message Bodies RFC 2045

Lesebestätigungen Message Disposition Notification RFC 3798

vCard-Adreßbuchformat

A MIME Content-Type for Directory Information RFC 2425

vCard MIME Directory Profile RFC 2426

LDIF The LDAP Data Interchange Format (LDIF) - Technical Specification

RFC 2849

iCalendar-Kalenderformat

Internet Calendaring and Scheduling Core Object Specific-ation (iCalendar)

RFC 2445

Tabelle 7: Übersicht über die Standards der Formate von E-Mails, Kalendern und Adressbüchern

2.4 E-Mail-Sicherheitskomponenten

Dieser Abschnitt gibt eine kurze Einführung in die E-Mail-Sicherheitskomponenten Anti-Phishing, Spam-Filter, Virenschutzprogramme und Personal Firewall.

2.4.1 Anti-Phishing

Unter Phishing versteht man einen Angriff, bei dem der Benutzer mittels gefälschter E-Mails dazu verführt wird, vertrauliche oder persönliche Daten preiszugeben. Beispielsweise wird eine Phishing-Nachricht als offiziell wirkende E-Mail verschickt, in der der Empfänger aufgefordert wird, eine gefälschte Webseite (für den Nutzer nicht erkennbar) aufzurufen und seine geheimen Zugangsdaten einzugeben.

Anti-Phishing-Funktionalität wird üblicherweise in Virenschutzprogramme integriert. Eingehende E-Mails werden auf Phishing-Merkmale überprüft.Dabei erfolgt üblicherweise eine Prüfung mittels Prüfsummen oder URL-Blacklists für Phishing-Seiten.

2.4.2 Spam-Filter

Ein Spam-Filter bietet Schutz gegen unerwünschte Massen-E-Mails (Spam). Zur Ermittlung von Spam kann die Spam-Filter-Funktionalität des E-Mail-Clients oder ein Spam-Filter über ein exter-nes Programm (Plug-In) benutzt werden.

Alternativ kann eine Person (z. B. der Benutzer) Spam-E-Mails aussortieren und sie entweder manuell löschen oder in einen Quarantäneordner verschieben. Diese Vorgehensweise ist sehr auf-



wändig. Außerdem können rechtliche Probleme auftreten, wenn die manuelle Filterung zentral und diese auch für Postfächer von Dritten durchgeführt wird.

Bei der Behandlung von Spam-verdächtigen E-Mails sind Filterregeln nützlich. Durch geeignete Regeln können Spam-markierte E-Mails automatisiert in einen separaten Ordner für Spam verscho-ben werden. Eine automatisierte Filterung auf dem E-Mail-Client kann auf verschiedenen Strategien aufbauen, die im folgenden kurz vorgestellt werden. Auf einem E-Mail-Server gibt es weitere Mög-lichkeiten, die in [ISi-Mail-Server] beschrieben sind.

Blacklists

Eine Blacklist ist eine Negativliste, in die Domains, E-Mail-Adressen oder auch IP-Adressen einge-tragen werden. Wenn eine eingehende E-Mail zu einem der in der Liste geführten Datensätze passt, wird sie gemäß Festlegung gelöscht, in einen Quarantäne-Ordner verschoben oder als Spam gekennzeichnet.

Whitelists

Im Gegensatz zur Blacklist enthält eine Whitelist (Positivliste) Datensätze von Versendern, von denen E-Mails immer akzeptiert werden. Wenn eine eingehende E-Mail zu einem der in der Liste geführten Datensätze passt, werden keine weiteren Prüfungen auf Spam durchgeführt. Auf Schad-programme wird trotzdem noch geprüft.

Heuristische Inhaltsanalyse

Durch heuristische Inhaltsanalyse kann ein Spam-Filter-System lernen, wie typische Spam- und Ham-Nachrichten (erwünschte E-Mails) aussehen. Auf der Basis dieses Lernprozesses kann ein System bestimmen, welche E-Mails wahrscheinlich Spam oder Ham sind.

Statistische Inhaltsanalyse

Bei der statistischen Inhaltsanalyse werden E-Mails nach bekannten Stichwörtern durchsucht. Wer-den entsprechende Wörter gefunden, ist dies ein Hinweis, dass es sich bei der E-Mail um Spam han-deln kann.

2.4.3 Virenschutzprogramme

Bei der Realisierung einer sicheren E-Mail-Client-Lösung ist die Integration eines Virenschutzpro-gramms von besonderer Bedeutung. Der E-Mail-Client muss die Möglichkeit zur Integration eines Virenschutzprogramms bieten, um eingehende und ausgehende E-Mails auf Schadprogramme zu überprüfen. Es soll verhindert werden, dass mit Schadprogrammen verseuchte E-Mails auf den E-Mail-Client gelangen. Dazu muss das Virenschutzprogramm die Möglichkeit bieten, E-Mails wäh-rend des Transports (POP3, IMAP und SMTP) zu prüfen.

Historisch bedingt werden die Programme zum Schutz vor Schadprogrammen von den Produkther-stellern oftmals Virenschutzprogramme genannt. Mittlerweile bieten viele Produkte auch Schutz vor anderen schädlichen Programmen, so dass sie zur Ermittlung von Viren, Trojanischen Pferden, Spyware etc. eingesetzt werden können.

Zur Ermittlung von Schadprogrammen in E-Mails gibt es zwei Methoden:

– Prüfung basierend auf Erkennungsmuster (Virenschutz-Signaturen)



Bei dieser Methode werden Schadprogramme ermittelt, indem eine angehängte Datei mit einer Datenbank mit Erkennungsmustern bekannter Schadprogramme verglichen wird. Voraussetzung ist eine stets aktuelle Datenbank mit Erkennungsmustern von Schadpro-grammen. Mit einer solchen Prüfung ist es nur möglich, bekannte Schadprogramme zu ermitteln.

– Heuristische Prüfung

Bei dieser Methode werden Schadprogramme ermittelt, indem eine Datei auf bekannte Merkmale überprüft wird. Mittels heuristischer Prüfung auf Schadprogramme ist es mög-lich, auch bisher nicht bekannte Schadprogramme zu ermitteln. Der Nachteil ist, dass diese Methode dazu führen kann, dass in „sauberen“ E-Mails fälschlicherweise Schadpro-gramme diagnostiziert werden.

Nachfolgend werden im Dokument die Erkennungsmuster sowie die heuristischen Regeln als Virenschutz-Signaturen bezeichnet. Die Prüfung, ob aktuelle Virenschutz-Signaturen sowie Heuris-tiken vorliegen (z. B. durch die Abfrage bei einem zentralen Update-Verteil-Dienst) und eine ent-sprechende Aktualisierung dieser sowie das Update des Virenschutzprogramms selbst, wird Viren-schutz-Update genannt.

2.4.4 Personal Firewall

Der Client-Rechner wird mittels einer Personal Firewall geschützt, die man auch als dezentrale Fi-rewall oder Desktop-Firewall bezeichnet. Eine Personal Firewall ist eine Software, auf dem Client-Rechner, die vor unerwünschten Zugriffen aus dem Netz schützen soll.

Personal Firewalls lassen sich in Paketfilter und Sandbox klassifizieren:

– Paketfilter:

Der Paketfilter prüft eingehende und ausgehende Datenpakete der Netzverbindung. Anhand der in jedem Datenpaket angegebenen Informationen wie Absender- und Empfän-ger-Adresse, entscheidet der Paketfilter aufgrund von Filterregeln, was mit diesem Paket geschieht. Unzulässige Datenpakete werden beispielsweise gemäß den Filterregeln blo-ckiert.

Einige Produkte ermöglichen es, die zulässigen Kommunikationsbeziehungen auch an ein-zelne Programme zu binden. Beispielsweise darf ein E-Mail-Client Verbindungen über POP3 aufbauen, für jedes andere Programm ist das aber nicht erlaubt.

– Sandbox:

Die Möglichkeit Zugriffe eines beliebigen Programms auf Systemressourcen einzuschrän-ken, nennt man Sandboxing. So können möglicherweise unsichere Programme – beispiels-weise mit Schwachstellen – ohne größere Gefahr genutzt werden, wenn sie nur einge-schränkte Rechte haben.



2.5 Digitale Signatur und Verschlüsselung

Digitale Signatur und Verschlüsselung sind Verfahren zur Sicherstellung von Authentizität, Integri-tät und Vertraulichkeit. Sie basieren in der Regel auf asymmetrischen Verschlüsselungsverfahren (Public-Key-Verfahren), bei denen der Anwender einen privaten Schlüssel (private key) und einen öffentlichen Schlüssel (public key) besitzt.

Trustcenter

Die eindeutige Zuordnung von öffentlichen Schlüsseln zu einer Person ist zentrale Aufgabe von sogenannten Zertifizierungsstellen, die auch als Trustcenter bezeichnet werden. Diese Zuordnung erfolgt über Zertifikate. Ein Zertifikat ist eine elektronische Bescheinigung, dass die darin angege-bene Person der Inhaber des öffentlichen Schlüssels ist. Auch die Zertifizierungsstelle besitzt ein Zertifikat, das von einer übergeordneten Zertifizierungsstelle (Wurzelzertifizierungsstelle) ausge-stellt wird. Diese Wurzelzertifizierungsstelle ist der Sicherheitsanker für die Verifikation der Zerti-fikate sowie des gesamten Verbunds und besitzt ein von ihr selbst signiertes Zertifikat. Dieser Ver-bund aus Anwender, Zertifizierungsstelle und Wurzelzertifizierungsstelle wird auch als Pub-lic-Key-Infrastructure (PKI) bezeichnet. Die Zertifikatskette vom Anwender über die Zertifizie-rungsstelle – es können auch mehrere Zertifizierungsstellen sein – bis zur Wurzelzertifizierungs-stelle ermöglicht die Überprüfung aller Zertifikate der PKI.

Zertifikate und Schlüssel können in Dateien gespeichert werden. PKCS#12 definiert ein Dateifor-mat, um private Schlüssel mit den zugehörigen Zertifikaten passwortgeschützt in einer Datei zu speichern. Zertifikate und Schlüssel können auch auf Chipkarten (Smart Cards) gespeichert werden, die auch als kryptografische Token bezeichnet werden. Für die Verwendung von Smart Cards wur-den Schnittstellen zu diesen Token definiert, wie PKCS#11 oder das proprietäre Microsoft CSP (Cryptographic Service Provider).

Die Dienstleistungen eines Trustcenters können entweder von einem am Markt etablierten Anbieter in Anspruch genommen oder durch den Aufbau einer eigenen PKI erbracht werden. Der Aufbau einer eigenen PKI bietet eine höhere Flexibilität. Sie kann nach den eigenen Anforderungen und Gegebenheiten aufgebaut werden. Allerdings ist beim Eigenbetrieb auch ein hoher Verwaltungsauf-wand durch Management der Sperrlisten und Zertifikate sowie der Administration der PKI-Systeme erforderlich. Außerdem vertrauen externe Stellen den Zertifikaten nicht. Hier kann beispielsweise eine gemeinsame übergeordnete Zertifizierungsstelle Abhilfe schaffen.

Registrierungsstelle

Ein Trustcenter hat neben der Erstellung von Zertifikaten weitere Aufgaben. Um die Zuordnung eines Schlüssels zu einer Person mittels Zertifikat zu bestätigen, muss die Person identifiziert wer-den (z. B. anhand des Personalausweises). Diese Aufgabe nimmt in der Regel die Registrierungs-stelle wahr. Sie ist die Anlaufstelle für die Beantragung eines Zertifikats. Die Registrierungsstelle identifiziert und registriert die Anwender und leitet den Antrag an die Zertifizierungsstelle weiter.

Sperrlisten

Sperrlisten, auch CRL (Certificate Revocation List) genannt, enthalten widerrufene Zertifikate, die aus unterschiedlichsten Gründen von der Zertifizierungsstelle gesperrt wurden. Sperrlisten werden für die Validierung von Zertifikaten benötigt.



Verzeichnisdienst

Das Trustcenter führt ein oder mehrere Verzeichnisse (z. B. X.500 oder LDAP) der von ihr ausge-stellten Zertifikate und Sperrlisten, die alle der PKI angeschlossenen Nutzer verwenden können.

Bei Nutzung des Protokolls LDAP (Lightweight Directory Access Protocol, siehe Abschnitt 2.2.5) wird ein sogenannter LDAP-Proxy verwendet. Auf dem LDAP-Proxy ist hinterlegt auf welchem Verzeichnisserver das Zertifikat eines bestimmten Empfängers abrufbar ist. Dieser Proxy nimmt Anfragen von Informationen über LDAP entgegen und leitet diese an bestimmte Verzeichnisserver weiter.

2.5.1 Standards

Die Verfahren S/MIME und OpenPGP stellen die wesentlichen Standards für die Verwendung von digitaler Signatur und Verschlüsselung bei E-Mails dar. Sie ermöglichen das Signieren einer E-Mail, so dass die Authentizität des Absenders sowie die Integrität der Nachricht gewährleistet wird. Die Vertraulichkeit des E-Mail-Inhalts kann durch eine Verschlüsselung erreicht werden. Die Sta-tusabfrage von Zertifikaten ist über das standardisierte Protokoll OCSP möglich. Darüber hinaus wird in diesem Abschnitt kurz die Virtuelle Poststelle beschrieben. Dabei handelt es sich zwar nicht um einen Standard sondern um ein Produkt, aber es verwendet, wie S/MIME und OpenPGP, digi-tale Signatur und Verschlüsselung.

Außerdem wird kurz auf die Rechtslage in Deutschland durch das Signaturgesetz eingegangen.

S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) ist eine Erweiterung des MIME Stan-dards, um digitale Signatur und Verschlüsselung von E-Mails mittels asymmetrischer und symme-trischer Kryptografie. Die Version S/MIMEv3 ist in [RFC 3850] und [RFC 3851] beschrieben.

Durch digitale Signatur und Verschlüsselung werden die Sicherheitsmerkmale Authentizität, Inte-grität und Vertraulichkeit einer E-Mail-Nachricht gesichert. Um dies zu erreichen, wird bei S/MIME ein Zertifikat benötigt, mit dem eine eindeutige Zuordnung zwischen öffentlichem Schlüs-sel und dem Schlüsselinhaber erfolgt. Die Zertifikate werden von übergeordneten Zertifizierungs-stellen (Trustcenter) gemäß dem Format nach X.509v3 ausgestellt.

Bei der Nutzung von S/MIME haben Zertifikate eine besondere Bedeutung, da sie die wesentliche Basis des Verfahrens sind. Ein zentraler Aspekt ist daher die Validierung von Zertifikaten. Sie ist in [RFC 3280] (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) beschrieben.

In S/MIME werden sowohl asymmetrische Kryptoverfahren wie RSA, DSA, Diffie-Hellman (Key-Agreement), als auch symmetrische Verfahren wie 3DES, RC2 und AES (mit Schlüssellängen von 128, 192 und 256 Bits) verwendet. Als Hash-Funktionen bei der Signaturerstellung werden die Funktionen MD5 und SHA-1 beschrieben. MD5 wird als nicht mehr sicher angesehen und sollte daher nicht mehr verwendet werden. Auch SHA-1 genügt nicht mehr den höchsten Sicherheitsan-sprüchen. Ein alternativer Signaturalgorithmus ist beispielsweise SHA-256. In S/MIMEv2 ([RFC 2311], [RFC 2312]) wird ein Algorithmus mit einer schwachen RC2-40-Bit-Verschlüsselung ver-wendet, so dass diese veraltete Spezifikation nicht mehr benutzt werden sollte.



Eine wichtige Voraussetzung für eine sichere E-Mail-Kommunikation mit S/MIME ist die Nutzung von starken Kryptoalgorithmen6.

Für die Signatur stehen in S/MIME zwei unterschiedliche Datentypen zur Verfügung. Beim Nach-richtenaustauschformat „Clear Signed“ (auch als „Multipart-Signed“ bezeichnet) befindet sich die Signatur im Anhang der E-Mail, so dass der E-Mail-Text auch von Programmen, die S/MIME nicht unterstützen, angezeigt werden kann. Bei Nachrichten des Formats „Opaque Signed“ (auch „Signed-Data“ genannt) werden Text und Signatur gemeinsam Base64-kodiert, so dass nur S/MIME-fähige Programme den lesbaren Text ausgeben können. Für verschlüsselte E-Mails wird das Austauschformat „Enveloped Data“ verwendet.

Für die Verschlüsselung und die digitale Signatur können unterschiedliche Schlüsselpaare verwen-det werden, so dass in diesem Fall verschiedene Zertifikate notwendig sind. Diese Schlüsseltren-nung ist aus Sicherheitsgründen sinnvoll, da beispielsweise bei Kompromittierung des Verschlüsse-lungsschlüssels der Signaturschlüssel weiterhin angewendet werden kann. Bei Verschlüsselungs-schlüsseln kann ein Verfahren zur Schlüsselhinterlegung angewendet werden, bei dem eine Kopie des privaten Schlüssels bei einer vertrauenswürdigen Stelle hinterlegt wird, so dass im Bedarfsfall eine Entschlüsselung der verschlüsselten Nachrichten möglich ist.

Um eine E-Mail zu verschlüsseln, wird das Zertifikat des Empfängers benötigt. Dieses enthält den benötigten öffentlichen Schlüssel. Da es sich bei einer PKI um einen geschlossenen Benutzerkreis handelt, müssen die Zertifikate der Infrastruktur allen Teilnehmern der PKI zugänglich sein:

– Bei einer internen PKI können die Teilnehmerzertifikate auf einem internen Verzeichnisserver abgelegt werden und für alle Nutzer des internen Netzes abrufbar sein.

– Bei einer gesicherten E-Mail-Kommunikation mit externen Empfängern stehen zwei Möglich-keiten zur Verfügung:

• Die Zertifikate sind auf einem externen Verzeichnisserver, der z. B. von einem Trustcenter betrieben wird, öffentlich abrufbar. Hierbei wird der LDAP-Proxy verwendet, auf dem hinter-legt ist, auf welchem Verzeichnisserver das Zertifikat eines bestimmten Empfängers abrufbar ist.

• Lokale Zertifikatsspeicher auf dem Rechner der Teilnehmer halten die Zertifikate vor. Hierzu muss der Empfänger sein Zertifikat vorab zum Absender schicken, damit dieser die E-Mail verschlüsseln kann. Darüber hinaus können Zertifikate auch über Verzeichnisdienste, Dateiserver oder IMAP-Directory bezogen werden.

Die S/MIME-Funktionalitäten sind oftmals in den E-Mail-Clients integriert und stehen dem Anwender nach der Erzeugung seiner Schlüssel und der Installation eines zugehörigen Zertifikats zur Verfügung. Falls der E-Mail-Client keine S/MIME-Funktionalität bereitstellt, lassen sich durch Installation von Plug-Ins entsprechende Funktionen einrichten.

Die Vorteile von S/MIME sind die hohe Sicherheit durch die verwendete Technik und die Ende-zu-Ende-Verschlüsselung, also die Verschlüsselung von einem Endanwender zum anderen. Dem gegenüber stehen die Nachteile, dass jeder E-Mail-Client bzw. jeder Nutzer, der sicher mittels S/MIME kommunizieren möchte, mit einen Schlüsselpaar und einem Zertifikat ausgerüstet werden muss. Darüber hinaus ist der Aufbau der erforderlichen PKI komplex und kostenintensiv.

6 Die Bundesnetzagentur (www.bundesnetzagentur.de) veröffentlicht regelmäßig auf Basis der Angaben des BSI im Bundesanzeiger eine Übersicht über Kryptoalgorithmen, die zur Erzeugung von Signaturschlüsseln, zum Hashen von Daten und zur Prüfung und Erzeugung von digitalen Signaturen als geeignet angesehen werden. Entsprechende aktuelle Informationen sind auch unter http://www.bsi.bund.de/esig/kryptoalg.htm zu finden.



Pretty Good Privacy (PGP)

PGP ist ein Programm, das Public-Key-Verfahren für die digitale Signatur und die Verschlüsselung verwendet. Bei PGP gibt es keine übergeordnete Stelle (Trustcenter), die Zertifikate ausgibt, son-dern die PGP-Benutzer bestätigen sich gegenseitig die Vertrauenswürdigkeit ihrer Schlüssel und bauen so eine regelrechte Vertrauenskette auf (A vertraut B, B vertraut C; also auch: A vertraut C). Diese Struktur wird auch als sogenanntes „Web of Trust“ bezeichnet.

OpenPGP ist ein offener Internet-Standard auf Basis von PGP der Version 5.x und in [RFC 2440] spezifiziert. OpenPGP nutzt hybride Verschlüsselungsverfahren bestehend aus asymmetrischen Al-gorithmen (RSA, DSA, Elgamal, Elliptic Curve, ECDSA, Diffie-Hellman für das Key-Agreement) und symmetrischen Algorithmen (IDEA, 3DES, CAST5, Blowfish, SAFER-SK128, DES-SK und AES mit 128, 192 oder 256 Bits). Zur Erzeugung der Prüfsummen sind die Hash-Funktionen MD5 und SHA-1, RIPEMD-160, MD2, HAVAL, „double-width“ SHA und TIGER/192 spezifiziert. Al-lerdings sollten die Algorithmen MD2, MD5, HAVAL und TIGER/192 nicht mehr oder nur mit Vorsicht angewendet werden, da sie nicht mehr als sicher eingestuft werden.

Bei OpenPGP gibt es zwei technische Varianten, wie digitale Signaturen und Verschlüsselung um-gesetzt werden. Bei Inline-OpenPGP werden die Signatur und/oder die verschlüsselten Daten im Body der E-Mail mitgeführt. Dagegen werden bei OpenPGP-MIME die Signatur bzw. die ver-schlüsselten Daten vom E-Mail-Text getrennt und als Anhang mitgeschickt.

Auch bei OpenPGP ist eine Ende-zu-Ende Verschlüsselung gegeben. Ein weiterer Vorteil im Ver-gleich zu S/MIME ist der einfache und flexible Aufbau einer OpenPGP-Infrastruktur. Außerdem ist eine Implementierung eines LDAP-Proxys nicht erforderlich, weil OpenPGP-Keyserver untereinan-der synchronisiert werden. Es reicht daher der Zugriff auf einem OpenPGP-Keyserver.

Jeder E-Mail-Client, der sicher kommunizieren soll, muss mit einem OpenPGP-Schlüsselpaar aus-gerüstet werden. Ein wesentlicher Nachteil gegenüber S/MIME ist, dass die Benutzung wesentlich komplexer ist, da durch die gegenseitige Vertrauensbildung durch das „Web of Trust” viele Zertifi-kate notwendig sind und vom Benutzer auch Wissen über die Technik bzw. deren Anwendung er-forderlich ist. Die Verantwortung über die Vertrauensbildung liegt beim Nutzer. Er muss entschei-den, wem er das Vertrauen ausspricht und sollte sorgsam bei der gegenseitigen Vertrauensbildung vorgehen.

Unterschied zwischen OpenPGP und S/MIME

Wie bereits oben beschrieben, basiert OpenPGP nicht auf einer zentralen Zertifizierungsstelle, wie bei einer PKI, sondern überlässt es den Benutzern wem sie vertrauen. Schlüssel werden in soge-nannten Key Rings gespeichert, die als lokale Dateien realisiert werden. Die öffentlichen Schlüssel anderer Benutzer werden lokal in einem Public Key Ring gespeichert. Dort kann zusätzlich angege-ben werden, in wieweit Nachrichten, die von einem bestimmten Benutzer signiert wurden, vertraut werden soll und in wieweit öffentliche Schlüssel, die über einen bestimmten Benutzer weiterge-reicht wurden, als vertrauenswürdig betrachtet werden sollen („Web of Trust”).

S/MIME basiert auf einem hierarchischen Modell und setzt eine PKI mit einer übergeordneten bzw. einer zentralen, vertrauenswürdigen Zertifizierungsstelle voraus. Die Zertifikate werden auf einem Verzeichnisserver veröffentlicht oder auch lokal in einem Zertifikatsspeicher abgelegt.

Online Certificate Status Protocol (OCSP)

Neben der Nutzung von Sperrlisten gibt es eine weitere Möglichkeit zur Zertifikatsprüfung. Das Online Certificate Status Protocol ([RFC 2560]) ist ein Internet-Protokoll, mit dem der Status eines Zertifikats bestimmt werden kann. Dazu wird von einem Client bei einem Auskunftsdienst (OCSP-



Server) der Zustand eines Zertifikats angefragt. Der OCSP-Server, der auch als OCSP-Responder bezeichnet wird, liefert auf die Anfrage des Clients die Antwort „good“ (Zertifikat ist gültig), „revoked“ (Zertifikat ist gesperrt) oder „unknown“ (Zertifikat ist unbekannt). Die Antworten des OCSP-Servers werden digital signiert. In der Regel wird der OCSP-Server von der Zertifizierungs-stelle betrieben. OCSP nutzt für den Transport der Informationen das Transportprotokoll HTTP oder HTTPS.

Virtuelle Poststelle (VPS)

Die Virtuelle Poststelle (VPS) ist ein zentrales System, das Sicherheitsfunktionalitäten für eine gesi-cherte Kommunikation zwischen Behörden, Unternehmen und ihren Kommunikationspartnern, wie beispielsweise Bürgern, bereitstellt ([VPS]). Sie kann eine sichere und nachvollziehbare Kommuni-kation auf elektronischem Weg in gleichem Maße wie der traditionelle Postweg oder der konventio-nelle Behördengang gewährleisten. Der gesamte elektronische Datenaustausch kann dabei auch rechtsverbindlich ablaufen, wobei der qualifizierten Signatur hierbei eine bedeutende Rolle zukommt.

Die VPS bietet Dienste zur Authentisierung, zur Herstellung von Verbindlichkeit, Integrität und Vertraulichkeit an. Die Komponente VPS-Mail bietet die Möglichkeit an einer zentralen Stelle die Verschlüsselung und Signatur von E-Mails zu gewährleisten, ohne dass E-Mail-Verschlüsselungs-programme wie S/MIME und OpenPGP auf den Clients im Unternehmen installiert und vom Anwender bedient werden müssen.

VPS-Mail wird dazu in der Regel als zusätzlicher Mail-Server zwischen Internet und Intranet eines Unternehmens platziert und verwendet das Protokoll SMTP. Sendet ein Mitarbeiter eine unver-schlüsselte E-Mail aus dem Intranet an das Internet, kann die VPS diese E-Mail automatisch mittels S/MIME oder OpenPGP mit einem Unternehmensschlüssel oder dem Schlüssel des Empfängers verschlüsseln und signieren. Der Empfänger der E-Mail kann diese E-Mail mittels S/MIME oder OpenPGP entschlüsseln. Alternativ ist es auch möglich, dass in dem Unternehmen des Empfängers wiederum eine VPS installiert ist, die die Entschlüsselung und Signaturprüfung zentral vornimmt. In der Rückrichtung (vom Internet an das Unternehmen) verschlüsselt ein Absender die E-Mail mit-tels S/MIME oder OpenPGP mit dem Unternehmensschlüssel oder dem Schlüssel des Empfängers. Die VPS des Empfängers prüft bei der erhaltenen E-Mail die Signatur und entschlüsselt die E-Mail.

Da in der Regel die E-Mail im Intranet unverschlüsselt übertragen wird, kann diese vor der Weiter-gabe der VPS an die internen E-Mail-Server mittels Virenschutzprogramme und Inhaltsfilter geprüft werden. Die Ver- und Entschlüsselung erfolgt für den Mitarbeiter des Unternehmens völlig transparent. Das Unternehmen kann ein Regelwerk definieren, wie E-Mails zu behandeln sind, so dass beispielsweise zwischen bestimmten Behörden oder Unternehmen ohne Benutzeraktion immer verschlüsselt oder signiert wird. Eine detaillierte Beschreibung der Architektur sowie des Einsatzes von VPS-Mail bietet die Studie [ISi-Mail-Server].

Die Komponente VPS-Web bietet die Möglichkeit über das Protokoll OCSI (Online Services Com-puter Interface) synchron und asynchron zu kommunizieren. Dieses verwendet als Transportproto-koll SOAP (Simple Objekt Access Protokoll) zur Strukturierung der Nutzungsdaten. Sowohl Trans-port- als auch Inhaltsdaten werden per XML verschlüsselt bzw. signiert (XML Encryption, XML Signature).

Die Nutzung der Komponente VPS-Web wird in ISi-Mail nicht weiter betrachtet, da diese Kompo-nente nicht zur E-Mailkommunikation mit den Protokollen SMTP, POP3 und IMAP verwendet wird.



Signaturgesetz

In Deutschland regelt das Signaturgesetz (SigG) den rechtlichen Rahmen für die Anwendung elek-tronischer Signaturen. Mit dem SigG ist Rechtssicherheit für den Geschäftsverkehr im Internet und für die elektronischen Verfahren in der öffentlichen Verwaltung geschaffen. Das Signaturgesetz be-schreibt die Anforderungen an die verwendeten Zertifikate und an die Anbieter der Zertifizierungs-dienste.

2.5.2 Übersicht der Standards

In Tabelle 8 wird eine Übersicht der Formate für Signatur und Verschlüsselung gezeigt, die einen schnellen Überblick über die Sicherheitseigenschaften geben soll.

Kategorie Sicherheitseigenschaften

Authenti-sierung


Verschlüs-selung

Referenz

S/MIME Version 3.1 Certificate Handling x x x RFC 3850

S/MIME Version 3.1 Message Specification x x x RFC 3851

S/MIME Version 3.1 Certificate Handling x x x RFC 2634

MIME Security with Pretty Good Privacy (PGP)

x x x RFC 2015

MIME Security with OpenPGP x x x RFC 3156

OpenPGP Message Format x x x RFC 2440

Tabelle 8: Übersicht der Formate für Signatur und Verschlüsselung

2.5.3 MailTrusT, SPHINX und Ägypten

Für die Anwendung von digitaler Signatur und Verschlüsselung wurden unter Führung des BSI mehrere Projekte durchgeführt, in denen die Technik erprobt und Produkte entwickelt wurden. Die-ser Abschnitt zeigt eine Auswahl der Projekte und Produkte.

MailTrusT

MailTrusT ist eine Spezifikation für E-Mail-Sicherheit, die auf internationalen Standards beruht. Sie beschreibt ein Gesamtkonzept, den Aufbau und die Komponenten einer PKI. Weiter werden Profile für Zertifikate und Sperrlisten definiert sowie das PKI-Management, das Austauschformat, Token und Algorithmen spezifiziert ([MailTrusT]). In der ersten Version basierte die MailTrusT-Spezifikation noch auf PEM (Privacy Enhanced Mail), einer sehr frühen Spezifikation für E-Mail-verschlüsselung, die mittlerweile kaum noch Bedeutung hat. In der Version 2 wurde auch S/MIME berücksichtigt. MailTrusT wurde inzwischen vom Nachfolger ISIS-MTT abgelöst.

SPHINX

Im Pilotversuch SPHINX wurden Produkte unterschiedlicher Hersteller zur Sicherung von E-Mails durch digitale Signatur und Verschlüsselung auf Interoperabilität und Funktionalität auf Basis der



MailTrusT-Spezifikation untersucht und erprobt. Das Ziel war die Schaffung einer herstellerunab-hängigen Interoperabilität auf Basis internationaler Standards. Dazu wurde auch die Interoperabili-tät von Produkten für S/MIME getestet. Weiteres Ziel war die Ermittlung der Akzeptanz der Sicher-heitslösungen beim Anwender sowie die Schaffung von Voraussetzungen für die breite Einführung von Sicherheitstechnik in den Verwaltungen basierend auf PKI-Technik mit digitaler Signatur und Verschlüsselung ([SPHINX]).

Ägypten

In SPHINX wurden unterschiedliche Produkte für die E-Mail-Clients MS Outlook, Lotus Notes und Novell Groupwise auf Basis des Betriebssystems MS Windows getestet und erprobt. Im Projekt Ägypten wurde Software für den Einsatz von Open Source Software (OSS) entwickelt, so dass digi-tale Signatur und Verschlüsselung für einen sicheren E-Mail-Austausch insbesondere für das Betriebssystem LINUX möglich ist ([Ägypten]). Dazu wurden beispielsweise für den Mail-Client KMail unter LINUX Plugins für S/MIME und OpenPGP bereitgestellt.



3 Sichere Grundarchitektur für normalen Schutzbedarf

Die in Abschnitt 2 beschriebenen Grundlagen bilden den Ausgangspunkt für die Konzeption einer Grundarchitektur für die sichere Nutzung von E-Mail. Um diese Grundarchitektur zu entwerfen, ist es notwendig, die benötigten Komponenten zu identifizieren und festzulegen, wie die Komponenten angeordnet werden müssen, um ein vollständiges, sicheres System zu bilden.

In diesem Abschnitt wird eine Grundarchitektur vorgestellt, die auf der in der Studie „Sichere Anbindung von lokalen Netzen an das Internet“ beschriebenen Grundarchitektur ([ISi-LANA, Kapitel 4]) beruht. In Abschnitt 3.1 werden zunächst die Komponenten der Architektur sowie die Sicherheitsüberprüfungen für ausgehende und eingehende E-Mails beschrieben. Abschnitt 3.2 beschäftigt sich mit der sicheren Anbindung des E-Mail-Clients in die E-Mail-Infrastruktur. In den Abschnitten 3.3 und 3.4 werden S/MIME und OpenPGP als Lösungen für sichere Ende-zu-Ende Kommunikation erörtert. Abschnitt 3.5 erläutert, dass alternativ zur Nutzung von S/MIME und OpenPGP auf den Clients eine sichere E-Mail-Kommunikation mittels der VPS (Virtuellen Post-stelle) möglich ist.

3.1 Sichere E-Mail-Client-Architektur

In diesem Abschnitt werden zunächst die Komponenten der E-Mail-Client-Architektur beschrieben. Im Weiteren werden die Unterschiede bezüglich der Sicherheitsüberprüfungen zwischen eingehen-den und ausgehenden E-Mails dargestellt.

3.1.1 Komponenten der E-Mail-Client-Architektur

Die Abbildung 3.1 stellt die sichere Architektur eines E-Mail-Clients mit den Komponenten MUA/MRA, Anti-Phishing, Anti-Spam, Virenschutzprogramm und Personal Firewall dar. Im Folgenden werden die einzelnen Komponenten mit ihren Rollen, ihren Funktionen und weiteren Aspekten beschrieben.



MUA/MRA

Der Mail-User-Agent (MUA) dient zum Erstellen, Versenden, Empfangen oder Anzeigen von E-Mail-Nachrichten.

Zur sicheren Nutzung von E-Mail müssen folgende Aspekte beachtet werden:

– Der Nutzer muss sich bewusst sein, dass ohne die zusätzliche Benutzung von Techniken wie S/MIME, OpenPGP oder der Virtuellen Poststelle E-Mails unverschlüsselt und damit ungeschützt über das Internet verschickt werden. Deshalb sollten keine vertraulichen oder personenbezoge-nen Daten unverschlüsselt verschickt werden.

– Header-Daten (Absender, etc.) und auch Inhalte von eingehenden E-Mails ohne digitale Signatur können beliebig gefälscht werden. Diesen Angaben kann daher nicht vertraut werden.

– Nicht erwartete Dateianhänge sollten nicht geöffnet werden. Dies gilt auch bei bekannten Absen-dern, da Absenderadressen leicht gefälscht werden können.

Anti-Phishing

Eine sichere E-Mail-Client-Architektur erfordert eine Anti-Phishing-Komponente, um Angriffe zu ermitteln und zu vereiteln, die zum Ziel haben, Benutzer mit gefälschten E-Mails zu verführen, ver-trauliche oder persönliche Daten preiszugeben. E-Mails können mittels folgenden Methoden auf Phishing-Merkmalen geprüft werden:

– Prüfsummen,

– URL-Blacklists für Phishing-Seiten.

Anti-Spam

Ein Großteil der Anti-Spam-Maßnahmen wird in der Regel auf einem vorgeschalteten Spam-Filter-Server oder auf dem E-Mail-Server durchgeführt (siehe [ISi-Mail-Server]). Auf diese Weise werden Spam-E-Mails entweder schon vom E-Mail-Server in einen sogenannten Spam-Ordner verschoben oder als Spam gekennzeichnet. Eine als Spam gekennzeichnete E-Mail kann dann auf dem E-Mail-Client mittels einer Filterregel automatisch in einen dafür vorgesehenen Ordner verschoben werden.


Abbildung 3.1: E-Mail-Client-Architektur


Normalerweise können serverbasierte Anti-Spam-Maßnahmen auf einem E-Mail-Server nicht vom Benutzer selbst konfiguriert werden. Die sichere E-Mail-Client-Architektur beinhaltet daher optio-nal eine Spam-Filter-Komponente zusätzlich auf dem Client, bei der die speziellen Anforderungen des Benutzers berücksichtigt werden können.

Zur Realisierung kann die Spam-Filter-Funktionalität der E-Mail-Client-Software benutzt oder ein Spam-Filter über ein externes Programm (Plug-In) eingesetzt werden. Verschiedene Hersteller bie-ten Anti-Spam-Software als Teil des Virenschutzprogramms an. Die Anti-Spam-Software kann aber auch als separates Programm eingesetzt werden.

Virenschutzprogramm

Die Prüfung eingehender und ausgehender E-Mails auf Schadprogramme soll verhindern, dass mit Schadprogrammen behaftete E-Mails auf den E-Mail-Client gelangen bzw. durch ihn versendet werden.

Es wird empfohlen, einen E-Mail-Client zu verwenden, der die Möglichkeit zur Integration eines Virenschutzprogramms bietet. Dabei ist darauf zu achten, dass die gesamte E-Mail inklusive Datei-anhänge geprüft wird. Denn auch im E-Mail-Body können Schadprogramme enthalten sein, z. B. in HTML-E-Mails mittels Aktiver Inhalte.

Folgende Prüfungen auf Schadprogramme sollten durchgeführt werden:

– Prüfung basierend auf Erkennungsmuster (Virenschutz-Signaturen)

– Heuristische Prüfung

Wie in Abschnitt 2.4.3 erwähnt, bieten viele Virenschutzprogramme neben einer Prüfung auf Viren auch Schutz vor anderen schädlichen Programmen (Würmer, Trojanische Pferde etc.). Zusätzlich sollte auch auf Spyware und Adware geprüft werden.

Personal Firewall

Die sichere E-Mail-Client-Architektur umfasst die Integration einer Personal Firewall. Es wird drin-gend empfohlen, alle von außen kommenden Zugriffe auf den Client-Rechner von der Personal Firewall prüfen zu lassen. Verbindungen in das Internet dürfen nur lokal über definierte Ports initi-iert werden. Die Personal Firewall ist in der Minimalkonfiguration ein zustandsloser Paketfilter, bei dem jedes einzelne Paket des Netzverkehrs analysiert wird. Optional kann die Personal Firewall auch als zustandsbehafteter Paketfilter eingesetzt werden. Hierbei wird jede neue Verbindung beim Verbindungsaufbau überprüft und dann alle zu dieser Verbindung gehörenden Datenpakete automa-tisch erlaubt. Sinnvoll ist zusätzlich, dass die Personal Firewall prüft, welche Kommunikationsbe-ziehungen der E-Mail-Client nutzen darf (z. B. nur Verbindungsaufbau über SMTP und IMAP). Eine noch höhere Sicherheit lässt sich darüber erreichen, dass der E-Mail-Client in einer einge-schränkten Umgebung läuft (Sandbox) und somit die Rechte des E-Mail-Client-Programms stark eingeschränkt werden. Diese Funktionalität wird beispielsweise mit den Sicherheitserweiterungen für Linux und Unix angeboten7.

7 Unter Linux sind derzeit eine Vielzahl solcher Sicherheitserweiterungen des Betriebssystems verfügbar, z. B. LIDS, GRsecurity, RSBAC, SElinux. Andere Unix-Betriebssysteme bieten diese ebenfalls an (z. B. RBAC bei IBMs AIX).



3.1.2 Ein- und ausgehende E-Mails

In Abbildung 3.2 wird die sichere E-Mail-Client-Architektur jeweils für das Senden und Empfan-gen einer E-Mail dargestellt. Die Sicherheitsüberprüfungen, die von Absender und Empfänger durchgeführt werden müssen, unterscheiden sich.

Ausgehende E-Mails

Der Absender benutzt den MUA für die Erstellung und den Versand der E-Mail. Eventuell wird die E-Mail digital signiert und/oder verschlüsselt.

Eine Prüfung auf Phishing-Merkmale und auf Spam erfolgt nicht. Daher sind diese Komponenten beim Absender in Abbildung 3.2 nicht dargestellt. Die E-Mail wird mit dem Virenschutzprogramm geprüft, damit keine Schadprogramme verschickt werden. Außerdem wird die Personal Firewall aktiv, um zu prüfen, ob die Netzverbindungen bzw. die Zugriffe erlaubt sind.

Eingehende E-Mails

Für eingehende E-Mails erfolgt in der Regel vorher der Verbindungsaufbau durch den E-Mail-Cli-ent zum internen-E-Mail-Server (Polling, siehe Abschnitt 2.2 ab Seite 12). Bei der Realisierung durch Push-E-Mail baut dagegen der E-Mail-Server eine Verbindung zum E-Mail-Client auf. Die Personal Firewall prüft, ob diese Verbindungen erlaubt sind. Das Virenschutzprogramm analysiert die E-Mail auf Schadprogramme. Weiterhin wird geprüft, ob es sich um unerwünscht zugesandte E-Mails (Spam) handelt und ob die eingegangene E-Mail Phishing-Merkmale aufweist.

Der Empfänger nutzt den MUA zum Öffnen und Anzeigen der E-Mail.


Abbildung 3.2: Ein- und ausgehende E-Mails


3.2 Sichere Anbindung der E-Mail-Clients an den internen E-Mail-Server

In diesem Abschnitt wird die sichere Anbindung des E-Mail-Clients an den internen E-Mail-Server dargestellt (siehe Abbildung 3.3).

Interner E-Mail-Server

Der interne E-Mail-Server sollte in einem separaten Server-Netzsegment platziert und durch einen Paketfilter (PF6) geschützt werden. Ein Zugriff soll nur von den E-Mail-Clients sowie vom Sicher-heits-Gateway erlaubt sein. Der interne E-Mail-Server darf nicht vom Internet aus direkt erreichbar sein. Die genaue Architektur ist in der Studie [ISi-LANA] sowie [ISi-Mail-Server] beschrieben.

Die Schnittstelle zwischen E-Mail-Client und E-Mail-Server sollte über standardisierte Protokolle wie SMTP (siehe Abschnitt 2.2.3), POP3 (siehe Abschnitt 2.2.1) oder IMAP (siehe Abschnitt 2.2.2) stattfinden. Zusätzlich wird die Absicherung der Protokolle über SSL/TLS (SMTPS, POP3S, IMAPS) empfohlen. Dazu sollten keine separaten Ports, sondern für das Aushandeln der SSL/TLS-Verbindung die entsprechenden Kommandos STARTTLS (IMAPS und SMTP) bzw. STLS8 (POP3) verwendet werden9. Die Validierung des Serverzertifikats nach [RFC 3280] sollte aus Sicherheits-

8 STLS steht für Start TLS.9 Bei IMAPS und POP3S wurden zwar separate Ports festlegt (IMAPS auf Port 993, POP3S auf Port 995), jedoch

wird im Internet Standard [RFC 2595] von der Nutzung abgeraten. Für SMTPS wurde offiziell kein separater Port


Abbildung 3.3: Sichere E-Mail-Server-Anbindung


gründen durchgeführt werden (siehe Abschnitt 3.3.2). Als zusätzlicher Validierungsschritt wird empfohlen, die Übereinstimmung des Servernamens im Zertifikat mit dem Namen des E-Mail-Serv-ers zu prüfen. Ferner ist es sinnvoll, die Authentisierung des Clients mindestens mittels Benutzer-name und Passwort durchzuführen (z. B. SASL PLAIN ([RFC 4616])). Es wird empfohlen, den E-Mail-Client so zu konfigurieren, dass die Authentisierung abgelehnt wird, wenn nicht vorher eine verschlüsselte Verbindung aufgebaut worden ist.

Neben den oben beschriebenen standardisierten Protokollen kann der E-Mail-Client auch mittels proprietärer Protokolle, wie z. B. Microsoft MAPI oder Lotus Notes NRPC (Notes Remote Proced-ure Call) an den E-Mail-Server angebunden werden. Bei Einsatz dieser proprietären Protokolle wird empfohlen, dass die häufig standardmäßig nicht vorkonfigurierte Verschlüsselung der Verbindun-gen verwendet wird.

Adressbücher

Kontaktdaten werden in Adressbüchern organisiert und können lokal im E-Mail-Client oder in einem Verzeichnisserver im internen Netz integriert sein. Da keine vertraulichen Daten in Adress-büchern abgelegt sind (vergleichbar mit einem Telefonbuch), kann zur Integration des E-Mail-Cli-ents mit dem Verzeichnisserver das LDAP-Protokoll auch ohne Verschlüsselung der Verbindung benutzt werden.

Für die Authentisierung des E-Mail-Clients am Verzeichnisserver wird der Einsatz sicherer SASL-Mechanismen empfohlen.

Kalender

Kalenderfunktionen (siehe Abschnitt 2.1.2) können über einen E-Mail-Server integriert werden. Für die Zugriffe auf Kalenderdaten können CalDAV und Kolab verwendet werden. Da im Kalender vertrauliche Informationen enthalten sein können (wie beispielsweise vertrauliche Dokumente als Anhang zu einer Besprechungsanfrage), wird bei der Nutzung von CalDAV der Einsatz von HTTPS empfohlen. Bei der Verwendung von Kolab empfiehlt sich der Einsatz von IMAPS.

Bei Einsatz von Kalenderfunktionalitäten mittels proprietärer Protokolle (z. B. Microsoft MAPI oder Lotus Notes NRPC ), wird empfohlen, dass die Verbindung verschlüsselt erfolgt.

festgelegt.



3.3 Nutzung von S/MIME

Die sichere Nutzung von S/MIME umfasst die beteiligten Komponenten für eine geschützte E-Mail-Kommunikation und zusätzlich die Sicherheitsaspekte bei der Benutzung von S/MIME.

3.3.1 Beschreibung der Komponenten

Die für eine sichere E-Mail-Kommunikation mit S/MIME erforderlichen Komponenten lassen sich in vier Bereiche unterteilen (siehe Abbildung 3.4).

Internes Netz

Im internen Netz befinden sich

– der E-Mail-Client-Rechner des Anwenders mit seinem Schlüsselpaar und dem zugehörigen Zer-tifikat,

– der interne E-Mail-Server,

– ein Paketfilter und

– ein interner Verzeichnisserver.


Abbildung 3.4: Beteiligte Komponenten bei einer E-Mail-Kommunikation mit S/MIME


Der zustandsbehaftete Paketfilter PF610 schützt den E-Mail-Server des internen Netzes gegen Innen-täter. Damit Client-Rechner E-Mails senden, empfangen und verwalten können, muss auf dem Pa-ketfilter PF6 zwischen E-Mail-Client und E-Mail-Server sowohl SMTP als auch POP3 bzw. IMAP freigeschaltet sein.

Vom Verzeichnisserver im internen Netz sind Zertifikate für eine verschlüsselte Kommunikation abrufbar. Rechnersysteme, die im internen Netz installiert sind, haben keinen direkten Zugang zum Internet. Nur über ein Sicherheits-Gateway ist eine Kommunikation mit Dritten über das Internet bzw. der Zugriff auf das Internet möglich.

Sicherheits-Gateway

Das Sicherheits-Gateway stellt die Infrastruktur zur Verfügung, mit der Komponenten des internen Netzes mit Komponenten im Internet kommunizieren können. In dieser Umgebung befindet sich ein LDAP-Proxy. Der LDAP-Proxy bildet eine logische Schnittstelle zu verschiedenen Verzeichnis-servern im Internet und bietet verschiedene (Sicherheits-)Funktionen. So muss nicht jeder einzelne Verzeichnisserver im E-Mail-Client konfiguriert werden, da auf dem LDAP-Proxy hinterlegt ist, auf welchem Verzeichnisserver das Zertifikat eines bestimmten Empfängers abrufbar ist. Durch den LDAP-Proxy hat der E-Mail-Client keinen direkten Zugriff auf Verzeichnisserver im Internet.

Trustcenter

Über das Internet sind externe Verzeichnisserver bei Anbietern von Zertifizierungsdiensten (Trust-center) sowie Verzeichnisdienste und OCSP-Auskunftsdienste erreichbar.

Kommunikationspartner

Nachrichten, die an einen externen Kommunikationspartner versendet werden, werden über das In-ternet ausgetauscht. Die Vermittlung der Nachrichten erfolgt über den E-Mail-Server des Kommu-nikationspartners. Der E-Mail-Client des Empfängers ist S/MIME-fähig und verfügt ebenfalls über ein Schlüsselpaar und ein zugehöriges Zertifikat. Im Bild ist das Netz des Kommunikationspartners, der in der Regel ebenfalls über ein Sicherheits-Gateway sowie weitere Komponenten verfügt, nur angedeutet.

3.3.2 Sicherheitsaspekte bei der Benutzung von S/MIME gesicherten Nachrichten

Bei der Nutzung von S/MIME wird zwischen digitaler Signatur und Verschlüsselung unterschieden.

Sichere Nutzung von S/MIME - Digitale Signatur

Der logische Verlauf des Versendens und Übermittelns einer digital signierten E-Mail lässt sich in vier Einzelschritten beschreiben (siehe Abbildung 3.5).

10 Um konsistent zu der in [ISi-LANA] dargestellten Grundarchitektur zu sein, ist der Paketfilter im internen Netz wie in [ISi-LANA, Abbildung 4.1] als PF6 bezeichnet.



– Schritt 1: Erstellen und Versenden einer digital signierten E-Mail

Auf dem E-Mail-Client-Rechner des internen Netzes befindet sich das Schlüsselpaar des Benutzers, das zugehörige Zertifikat und ein S/MIME-fähiger E-Mail-Client.

Zur Erzeugung einer digitalen Signatur wird der private Schlüssel mit einem Signaturalgo-rithmus (z. B. DSA) angewendet. Der Signaturalgorithmus erzeugt aus den zu signierenden Daten und dem privaten Schlüssel einen Datensatz, die digitale Signatur. Bei E-Mails wer-den sowohl die Nachricht als auch eventuelle Anhänge digital signiert und an den internen E-Mail-Server zur Übertragung an den Empfänger übermittelt. Dabei prüft der Paketfilter PF6 im internen Netz, ob die gewünschte Verbindung vom E-Mail-Client zum E-Mail-Server erlaubt ist.

Bei Nachrichten mit digitalen Signaturen sollte das Nachrichtenaustauschformat „Clear Signed” („Multipart-Signed”) angewendet werden. Bei diesem Format wird die Signatur getrennt von der eigentlichen Nachricht als Anhang in der E-Mail versendet. Da sich die Signatur im Anhang der E-Mail befindet, kann der E-Mail-Text somit auch von Program-men angezeigt werden, die S/MIME nicht unterstützen.

– Schritt 2: Übermitteln der digital signierten E-Mail

Der interne E-Mail-Server übermittelt die digital signierte Nachricht wie folgt an den Emp-fänger: Die Nachricht wird über das Sicherheits-Gateway sowie das Internet an den exter-


Abbildung 3.5: Sichere E-Mail-Kommunikation mit S/MIME - Digitale Signatur


nen E-Mail-Server übertragen. Nicht erlaubte Verbindungen werden vom Sicherheits-Gateway blockiert. Die E-Mail wird vom E-Mail-Server der externen Empfängerseite angenommen.

– Schritt 3: Zustellen und Prüfen der digital signierten E-Mail

Der MTA auf Empfängerseite leitet die E-Mail an den MDA (Mail Delivery Agent) weiter, der die E-Mail in das Postfach des Empfängers stellt.

Nachdem der E-Mail-Client die Nachricht empfangen hat und der Empfänger sie öffnet, wird die digitale Signatur geprüft. Mit dem öffentlichen Schlüssel des Zertifikatsinhabers (also des Signierers) und Anwendung des gleichen Algorithmus wie bei der Signaturerstel-lung wird die Signatur der Nachricht geprüft. Mit diesem Vorgehen wird die Integrität der Nachricht geprüft. Bestandteil der Prüfung der Nachricht ist auch die Validierung des Zer-tifikats, die in Schritt 4 beschrieben ist.

– Schritt 4: Validieren des Zertifikats

Die Validierung des Zertifikats umfasst die folgenden Punkte:

• Bei der Validierung eines Zertifikats muss geprüft werden, ob der aktuelle Zeitpunkt im angegebenen Gültigkeitszeitraum liegt.

• Das Zertifikat muss über einen Zertifizierungspfad zu einem vertrauten Wurzelzertifi-kat führen.

• Der Zustand der einzelnen Zertifikate muss entweder mittels einer Sperrliste (CRL) oder einem OCSP-Auskunftsdienst geprüft werden können.

• Bei der Verwendung von Sperrlisten müssen diese auf Integrität anhand der Signatur des Sperrlistenausstellers geprüft und zudem der Gültigkeitszeitraum der Sperrliste verifiziert werden.

• Falls im Zertifikat eine E-Mail-Adresse angegeben ist, wird empfohlen zu prüfen, ob diese mit der E-Mail-Adresse des Absenders übereinstimmt.

Das Zertifikat mit dem öffentlichen Schlüssel des Signierers wird entweder als Anhang zur signierten E-Mail mitgeschickt oder vom Empfänger von einem Verzeichnisserver herun-tergeladen. Anschließend erfolgt die Validierung des Zertifikats, zu der entweder eine Sperrliste (CRL) herangezogen oder bei einem OCSP-Auskunftsdienst der aktuelle Status des Zertifikats abgefragt wird.

Wenn diese Prüfungen erfolgreich durchgeführt wurden, ist die Signatur korrekt. Der Emp-fänger kann somit sicher sein, dass die Nachricht vom Absender signiert und nicht verän-dert wurde. Die Signatur bleibt auch nach dem Speichern der Nachricht erhalten.

Probleme können bei Texten (z. B. Haftungsausschlüsse (disclaimer)) auftreten, die server-seitig angefügt werden, so dass die Signatur nicht mehr korrekt ist. Einige Produkte bieten Lösungen hierfür an, indem die signierte E-Mail und der Haftungsausschluss derart von-einander getrennt werden, dass die Integrität der Nachricht gesichert ist.

Sichere Nutzung von S/MIME - Verschlüsselung

Der Verlauf des Versendens und Übermittelns einer verschlüsselten E-Mail lässt sich in fünf Ein-zelschritte unterteilen (Abbildung 3.6).



– Schritt 1a und 1b: Erstellen und Versenden einer verschlüsselten E-Mail

Auf dem E-Mail-Client-Rechner des internen Netzes befinden sich das Schlüsselpaar des Anwenders, das zugehörige Zertifikat und eine S/MIME-fähige Software (E-Mail-Client und evtl. Plug-In).

Zum Verschlüsseln einer Nachricht wird das Zertifikat des Empfängers benötigt. Bei S/MIME wird es entweder vom internen Verzeichnisserver abgefragt (Schritt 1a) oder man verwendet das Zertifikat aus einem lokalen Zertifikatsspeicher (im E-Mail-Client selbst). Ist das Zertifikat weder im lokalen Zertifikatsspeicher noch im internen Verzeichnisserver gespeichert, kann es über den LDAP-Proxy des Sicherheits-Gateways bei einem externen Verzeichnisserver abgerufen werden (Schritt 1b).

– Schritt 2: Validieren des Zertifikats

Bevor das Zertifikat benutzt werden kann, muss seine Gültigkeit geprüft werden. Dazu wird entweder eine Sperrliste herangezogen oder bei einem OCSP-Auskunftsdienst der aktuelle Status des Zertifikats abgefragt. Da die Validierung des Zertifikats wesentlicher Bestandteil ist, sollte das Sicherheits-Gateway derart konfiguriert werden, dass die Verbin-dung zum Abruf der Sperrliste oder zu einem OCSP-Auskunftsdienst mittels eines Sicher-heits-Proxys des Sicherheits-Gateways erlaubt ist.

– Schritt 3: Verschlüsseln und Versenden der E-Mail


Abbildung 3.6: Sichere E-Mail-Kommunikation mit S/MIME – Verschlüsselung


Für die Verschlüsselung der Nachricht wird ein hybrides Verschlüsselungsverfahren, eine Kombination von symmetrischer und asymmetrischer Kryptografie benutzt. Dabei wird ein zufälliger Sitzungsschlüssel (session key) generiert, der danach für die Verschlüsselung der zu versendenden Nutzdaten verwendet wird. Der Sitzungsschlüssel wird mit dem in den Schritten 1 und 2 ermittelten und geprüften öffentlichen Schlüssel des Empfängers ver-schlüsselt. Der verschlüsselte Sitzungsschlüssel und die verschlüsselten Daten werden an den internen E-Mail-Server zum Versand an den externen Empfänger übertragen.

– Schritt 4: Übermittlung der verschlüsselten E-Mail

Der interne E-Mail-Server übermittelt die verschlüsselte Nachricht wie folgt an den Emp-fänger: Die Nachricht wird über das Sicherheits-Gateway sowie das Internet an den Emp-fänger übertragen. Nicht erlaubte Verbindungen werden vom Sicherheits-Gateway blo-ckiert. Die gesendete E-Mail wird vom E-Mail-Server der Empfängerseite angenommen.

– Schritt 5: Zustellen und Entschlüsseln der verschlüsselten E-Mail

Der MTA auf Empfängerseite leitet die E-Mail an den MDA weiter, der die E-Mail in das Postfach des Empfängers stellt. Nachdem der E-Mail-Client die Nachricht empfangen hat und der Empfänger sie öffnet, wird die E-Mail vom S/MIME-fähigen E-Mail-Client ent-schlüsselt. Dazu wird unter Verwendung des privaten Schlüssels der übertragene ver-schlüsselte Sitzungsschlüssel entschlüsselt und anschließend mit diesem die eigentliche Nachricht entschlüsselt.

Die Dateianhänge werden nach dem Entschlüsseln temporär auf der Festplatte abgelegt und nach Schließen der E-Mail wieder gelöscht.



3.4 Nutzung von OpenPGP

Analog zur Nutzung von S/MIME sind bei der sicheren E-Mail-Kommunikation mit OpenPGP ver-schiedene Komponenten notwendig.

3.4.1 Beschreibung der Komponenten

Die beteiligten Komponenten für eine geschützte E-Mail-Kommunikation mittels OpenPGP lassen sich in vier Bereiche unterteilen (siehe Abbildung 3.7).

Internes Netz

Im internen Netz befinden sich

– der E-Mail-Client des Anwenders mit einem ihm zugeordneten Schlüsselpaar,

– der interne E-Mail-Server,

– ein Paketfilter und

– ein interner Verzeichnisserver.


Abbildung 3.7: Beteiligte Komponenten bei einer E-Mail-Kommunikation mit OpenPGP


Auf dem Verzeichnisserver sind die öffentlichen Schlüssel bekannter Kommunikationspartner abgelegt.

Der zustandsbehaftete Paketfilter PF6 schützt den E-Mail-Server des internen Netzes gegen Innen-täter. Damit Client-Rechner E-Mails senden, empfangen und verwalten können, müssen auf dem Paketfilter PF6 zwischen E-Mail-Client und E-Mail-Server sowohl SMTP als auch POP3 bzw. IMAP freigeschaltet sein.

Sicherheits-Gateway

Das Sicherheits-Gateway stellt die Infrastruktur zur Verfügung, mit der Komponenten des internen Netzes mit Komponenten kommunizieren können, die über das Internet erreichbar sind.

Externe OpenPGP-Keyserver

Über das Internet sind externe OpenPGP-Keyserver, auf dem die öffentlichen Schlüssel der Teil-nehmer abgelegt sind, erreichbar.

Kommunikationspartner

Nachrichten, die aus dem internen Netz vom E-Mail-Client über das Sicherheits-Gateway an einen externen Kommunikationspartner versendet werden, werden über das Internet ausgetauscht. Die Vermittlung der Nachrichten erfolgt über den E-Mail-Server des Kommunikationspartners, der E-Mails empfängt und versendet. Der E-Mail-Client des Empfängers ist OpenPGP-fähig und verfügt ebenfalls über ein Schlüsselpaar.

3.4.2 Sicherheitsaspekte bei der Benutzung von OpenPGP gesicherten Nachrichten

OpenPGP bietet Mechanismen zur Sicherung von Integrität, und Authentizität (über Signaturen) sowie zum Schutz der Vertraulichkeit (mittels Verschlüsselung). Auf den E-Mail-Clients von Absender und Empfänger, die die OpenPGP-Anwendung nutzen, sind die öffentlichen Schlüssel der Kommunikationspartner und der eigene privaten Schlüssel installiert. Letzterer muss mittels eines Passwortes geschützt sein und darf nicht exportierbar sein, damit er nicht durch z. B. fehlerhafte Bedienung der OpenPGP-Anwendung ungewollt in fremde Hände gelangt.

Die Ermittlung der Vertrauenswürdigkeit einer Person bzw. eines Zertifikats erfolgt über das „Web of Trust”-Prinzip (vgl. Abschnitt 2.5). Die Verantwortung über die Vertrauensbildung liegt beim Nutzer selbst. Die Validierung des Kommunikationspartners und dessen Schlüssel erfolgt technisch mittels der Schlüssel-ID (key id), die einen Schlüssel eindeutig identifiziert, und mittels des Finger-abdrucks (fingerprint oder auch Hashwert) des öffentlichen Schlüssels. Der Austausch der Schlüs-sel-ID und des Fingerabdrucks muss auf einem sicheren Weg erfolgen (z. B. persönlicher Aus-tausch der Schlüssel-ID und des Fingerprints).

Sichere Nutzung von OpenPGP - Digitale Signatur

Das Versenden und Übermitteln einer mit OpenPGP signierten E-Mail kann in drei Einzelschritten beschrieben werden (siehe Abbildung 3.8).



– Schritt 1: Erstellen und Versenden einer digital signierten E-Mail

Auf dem E-Mail-Client-Rechner im internen Netz befindet sich das Schlüsselpaar des Benutzers, das zugehörige Zertifikat und eine OpenPGP-fähige Software.

Ein Signaturalgorithmus (z. B. DSA) erzeugt aus den zu signierenden Daten und dem pri-vaten Schlüssel einen Datensatz, die digitale Signatur. Bei E-Mails werden sowohl die Nachricht als auch eventuelle Anhänge digital signiert und an den internen E-Mail-Server zur Übertragung an den Empfänger übermittelt. Dabei prüft der Paketfilter PF6 im internen Netz, ob die gewünschte Verbindung vom E-Mail-Client zum E-Mail-Server erlaubt ist.

– Schritt 2: Übermitteln der digital signierten E-Mail

Der interne E-Mail-Server initiiert die Übermittlung der digital signierten Nachricht an den Empfänger. Die Nachricht wird über das Sicherheits-Gateway11 sowie das Internet an den externen E-Mail-Server übertragen. Nicht erlaubte Verbindungen werden vom Sicherheits-Gateway blockiert.

– Schritt 3: Zustellen und Prüfen der digital signierten E-Mail

Der MTA auf Empfängerseite leitet die E-Mail an den MDA weiter, der die E-Mail in das Postfach des Empfängers stellt.

11 Es ist selbstverständlich keine direkte Verbindung zwischen dem internen und externen Mail-Server zugelassen. In der Regel erfolgt die Weiterleitung der E-Mail mittels eines Sicherheits-Proxys für SMTP auf dem ALG (Applicati-on-Level-Gateway) des Sicherheits-Gateways, siehe [ISi-Mail-Server].


Abbildung 3.8: Sichere E-Mail-Kommunikation mit OpenPGP - Digitale Signatur


Nachdem der E-Mail-Client des Empfängers die Nachricht empfangen hat und der Emp-fänger sie öffnet, wird die digitale Signatur geprüft. Mit dem öffentlichen Schlüssel des Signierers und unter Anwendung des gleichen Algorithmus wie bei der Signaturerstellung wird die Signatur der Nachricht auf Integrität geprüft. Die Vertrauenswürdigkeit des Zerti-fikats wird mit Hilfe des OpenPGP „Web of Trust”-Prinzip ermittelt (vgl. Erläuterung in Abschnitt 2.5.1).

Die Gültigkeit der Schlüssel kann durch die Angabe eines Endezeitpunkts der Gültigkeit beschränkt sein oder er kann durch den Anwender mit einem Widerrufszertifikat (key revocation certificate) für ungültig erklärt worden sein.

Nach erfolgreicher Integritätsprüfung und Sicherstellung der Vertrauenswürdigkeit wird die Signatur als korrekt angesehen und vom E-Mail-Client entsprechend angezeigt. Der Empfänger kann somit sicher sein, dass die Nachricht vom Absender signiert und nicht verändert wurde.

Sichere Nutzung von OpenPGP - Verschlüsselung

Der Verlauf des Versendens und Übermittelns einer verschlüsselten E-Mail kann in vier Einzel-schritten beschrieben werden (siehe Abbildung 3.9).


Abbildung 3.9: Sichere E-Mail-Kommunikation mit OpenPGP – Verschlüsselung


– Schritt 1a und 1b: Abrufen des öffentlichen Schlüssels des Empfängers

Auf dem E-Mail-Client-Rechner im internen Netz befindet sich das Schlüsselpaar des Benutzers, das zugehörige Zertifikat und eine OpenPGP-fähige Software.

Für die Verschlüsselung wird der öffentliche Schlüssel des Empfängers benötigt. Dieser wird entweder beim Verzeichnisserver des internen Netzes (Schritt 1a) oder extern bei einem OpenPGP-Keyserver (Schritt 1b) abgefragt. Alternativ kann ein lokal auf dem E-Mail-Client gespeicherter öffentlicher Schlüssel benutzt werden. Der Paketfilter PF6 prüft, ob die Verbindungen vom internen Netz zum internen Verzeichnisserver erlaubt sind. Die Abfrage des externen OpenPGP-Keyservers erfolgt über einen entsprechenden Sicherheits-proxy auf dem Sicherheits-Gateways. In der Regel wird auf den OpenPGP-Keyserver über die Protokolle HTTP oder LDAP zugegriffen.

– Schritt 2: Verschlüsseln und Versenden der E-Mail

Für die Verschlüsselung der Nachricht wird eine Kombination von symmetrischer und asymmetrischer Kryptografie (hybrides Verschlüsselungsverfahren) benutzt. Dabei wird ein zufälliger Sitzungsschlüssel (session key) generiert, der danach für die Verschlüsselung der zu versendenden Nutzdaten verwendet wird. Der Sitzungsschlüssel wird mit dem in Schritt 1 ermittelten öffentlichen Schlüssel des Empfängers verschlüsselt. Der verschlüs-selte Sitzungsschlüssel und die verschlüsselten Daten werden an den internen E-Mail-Server zum Versand an den externen Empfänger übertragen.

– Schritt 3: Übermitteln der verschlüsselten E-Mail

Der interne E-Mail-Server übermittelt die verschlüsselte Nachricht an den Empfänger. Der Paketfilter PF6 prüft, ob die Verbindung erlaubt ist. Die Nachricht wird über das Sicher-heits-Gateway sowie das Internet an den Empfänger versendet. Die gesendete E-Mail wird vom E-Mail-Server der Empfängerseite angenommen.

– Schritt 4: Zustellen und Entschlüsseln der verschlüsselten E-Mail

Der MTA auf Empfängerseite leitet die E-Mail an den MDA weiter, der die E-Mail in das Postfach des Empfängers stellt. Nachdem der E-Mail-Client die Nachricht empfangen hat und der Empfänger sie öffnet, wird die E-Mail mit dem OpenPGP-fähigen E-Mail-Client entschlüsselt. Dazu wird unter Verwendung des privaten Schlüssels des Empfängers der übertragene verschlüsselte Sitzungsschlüssel entschlüsselt und anschließend mit diesem die eigentliche Nachricht entschlüsselt.

Die Dateianhänge werden nach dem Entschlüsseln temporär auf der Festplatte abgelegt und nach dem Schließen der E-Mail wieder gelöscht.



3.5 Sichere Nutzung der Virtuellen Poststelle

In den vorherigen Abschnitten wurde die Nutzung von S/MIME und OpenPGP auf dem E-Mail-Cli-ent für eine sichere E-Mail-Kommunikation beschrieben. Die Verwendung von S/MIME und Open-PGP erfordert, dass der Benutzer selber auswählt, welche E-Mails er verschlüsselt und welche nicht.

Die Alternative besteht darin, im Unternehmen eine VPS (Virtuelle Poststelle) (siehe Abschnitt 2.5.1) einzusetzen.

Der Einsatz einer VPS erlaubt es ein Regelwerk zu definieren, wie die Verschlüsselung von E-Mails gehandhabt werden soll. Damit kann beispielsweise festgelegt werden, dass zu bestimmten Personen oder Unternehmen E-Mails grundsätzlich verschlüsselt werden.

Bei einer VPS werden aus dem Internet empfangene verschlüsselte E-Mails an einer zentralen Stel-le entschlüsselt. Daher kann hier eine zentrale Prüfung auf Schadprogramme mittels Virenschutz-programm erfolgen. Zusätzlich ist auch eine Inhaltsprüfung, beispielsweise auf zugelassene Datei-anhänge, möglich. Damit erreichen nur geprüfte E-Mails den Client des Anwenders.

Diesen Vorteilen steht nur der Nachteil entgegen, dass die Verschlüsselung der E-Mail keine wirkli-che Ende-zu-Ende-Verschlüsselung ist. In Bereichen wo dies gefordert wird, kann es daher sinnvoll sein, eine Verschlüsselung auf den E-Mail-Clients des Unternehmens zusätzlich einzusetzen.

Eine detaillierte Beschreibung der Architektur sowie des Einsatzes von VPS-Mail bietet die Studie [ISi-Mail-Server].



4 Komponenten sicher auswählen, konfigurieren und betreiben (normaler Schutzbedarf)

Ausgehend von der in Abschnitt 3 beschriebenen E-Mail-Client-Architektur werden in Abschnitt 4 umfassende Empfehlungen gegeben, wie die in der Grundarchitektur enthaltenen Komponenten des E-Mail-Clients sicher ausgewählt (Abschnitt 4.1), sicher konfiguriert (Abschnitt 4.2) und sicher betrieben (Abschnitt 4.3) werden können.

Diese Empfehlungen sollen dem Anwender Unterstützung in Phase 2 (Konzeption) des Ablaufplans gemäß [ISi-E] bieten.

4.1 Grundanforderungen an ein sicheres Produkt

In diesem Abschnitt werden für die betrachteten E-Mail-Komponenten Sicherheitsanforderungen zusammengestellt. Es wird empfohlen, diese bei der Produktauswahl zu berücksichtigen.

4.1.1 Client

Für allgemeine Grundanforderungen an den Client sind Vorgaben in einer eigenen ISi-Studie beschrieben ([ISi-Client]). In Bezug auf die E-Mail-Nutzung sollte die Leistungsfähigkeit (z. B. Rechenleistung, Hauptspeicher, Speicherkapazität) ausreichend für den gleichzeitigen Betrieb eines Virenschutzprogramms, einer Personal Firewall, der Anti-Phishing-, der Anti-Spam- sowie der E-Mail-Client-Software dimensioniert sein. Um die Verwaltung der Systeme zu vereinfachen, wird empfohlen, ein zentrales Systemmanagement einzurichten.

Generelle Anforderungen an Client-Software

Jegliche Software-Komponenten, die client-seitig installiert werden, müssen vom Hersteller unter-stützt werden (beispielsweise mit Sicherheits-Updates). Die Software sollte auch für Benutzer ohne Administrator-Rechte nutzbar sein. Ausgenommen von dieser Anforderung sind unter anderem das Virenschutzprogramm und die Personal Firewall. Diese Komponenten dürfen es einem Benutzer nicht erlauben, seine Privilegien zu erweitern. Sollten zusätzliche Programme benötigt werden, wel-che mit System- oder Administratoren-Privilegien arbeiten, sollte anhand einer Analyse festgestellt werden, ob das resultierende Risiko akzeptiert werden kann.

Betriebssystem

Die Anforderungen an das Betriebssystem aus Sicherheitssicht sind vielfältig. Eine umfassende Aufzählung ist jedoch nicht Ziel dieser Studie. Daher werden hier nur die Anforderungen aufge-führt, die für die Umsetzung der in der Studie vorgeschlagenen Maßnahmen empfohlen sind.

Das Betriebssystem sollte die Benutzer eindeutig authentifizieren und autorisieren. Nach Möglich-keit sollte es ein zentrales Management unterstützen.



4.1.2 E-Mail-Client-Software / Plug-Ins

Die E-Mail-Client-Software sowie Plug-Ins, die die bestehende E-Mail-Client-Software um S/MIME- und OpenPGP-Funktionalitäten ergänzen, haben eine zentrale Funktionalität innerhalb der Architektur zur sicheren Nutzung von E-Mail.

Allgemeine Anforderungen

– Die Software muss die Erstellung und Anzeige von E-Mails im reinen Textformat unterstützen.

– Sofern Aktive Inhalte über die Vorschaufunktionalität (siehe Abschnitt 2.1.2) ausgeführt werden können, sollte diese Funktionalität ausschaltbar sein.

– Die E-Mail-Client-Software sollte HTML-Strukturelemente ohne die Ausführung Aktiver Inhalte anzeigen.

– Das zu verwendende Produkt sollte die Header-Informationen von E-Mails anzeigen können.

– Die Software sollte die Zeichensätze 7-Bit ASCII, UTF-812, ISO 8859-113 (Latin-1) und ISO-8859-1514 unterstützen (siehe Abschnitt 2.3.2).

– Wünschenswert ist bei HTML-E-Mails die Darstellung der tatsächlichen URL neben einem Hyperlink bzw. die ausschließliche Darstellung der URL.

– Die Liste von gefährlichen Dateianhängen (Blacklisting), die im E-Mail-Client blockiert werden, sollte erweiterbar sein. So kann auf spezifische (neue) Schwachstellen reagiert werden.

Sichere Kommunikation auf Protokollebene

– Die E-Mail-Client-Software muss die E-Mail-Protokolle (POP3S oder IMAPS sowie SMTPS, siehe Abschnitte 2.2.1, 2.2.2 und 2.2.3) für eine sichere Kommunikation auf Protokollebene unterstützen.

Sichere Kommunikation auf Anwendungsebene

– Um eine sichere Kommunikation auf Anwendungsebene zu ermöglichen, gibt es die Varianten S/MIME, OpenPGP und die Virtuelle Poststelle (siehe Abschnitt 2.5.1). Die E-Mail-Client-Soft-ware oder ein Plug-In sollte eine dieser Varianten unterstützen, so dass auch auf der Anwen-dungsebene sicher kommuniziert werden kann.

– Für die Nutzung von S/MIME gelten folgende Anforderungen:

• Es müssen starke Kryptoalgorithmen unterstützt werden. Im Bundesanzeiger werden geeig-nete Algorithmen für Verschlüsselung, für digitale Signatur und für das Hashen von Daten veröffentlicht15. Die Schlüssel müssen mit entsprechender Länge generiert werden können.

12 UTF-8: Unicode Transformation Format, 8-Bit13 ISO 8859-1 ist ein 8-Bit-Zeichensatz und enthält viele Sonderzeichen westeuropäischer Sprachen.14 ISO 8859-15 enthält auch das Eurozeichen und alle Zeichen der französischen und finnischen Sprache. Dies ist bei

ISO 8859-1 nicht gegeben.15 Die Bundesnetzagentur (http://www.bundesnetzagentur.de) veröffentlicht regelmäßig auf Basis der Angaben des

BSI im Bundesanzeiger eine Übersicht über Kryptoalgorithmen, die zur Erzeugung von Signaturschlüsseln, zum Hashen von Daten und zur Prüfung und Erzeugung von digitalen Signaturen als geeignet angesehen werden. Ent-sprechende aktuelle Informationen sind auch unter http://www.bsi.bund.de/esig/kryptoalg.htm zu finden.



• Eine sichere Aufbewahrung des privaten Schlüssels muss gewährleistet sein, d. h. der Schutz des privaten Schlüssels mittels Passwort und das Unterbinden des Exports des privaten Schlüssels müssen unterstützt werden.

• Das Zertifikatsformat X.509 muss unterstützt werden.

• Um die Einbindung von X.509-Zertifikaten auf Smart Cards zu ermöglichen, sollte das Pro-dukt Schnittstellen zu kryptografischen Token beinhalten, wie PKCS#11 oder das proprietäre Microsoft CSP.

• Das Sperrlistenformat ab CRLv2 muss unterstützt werden.

• Es sollten auch Zertifikate verwendet werden können, die keine E-Mail-Adresse enthalten16.

• Die S/MIME-Nachrichtenaustauschformate Signed-Data und Multipart-Signed für signierte E-Mails sowie Enveloped-Data für verschlüsselte E-Mails müssen unterstützt werden, auch um Interoperabilität zur Virtuellen Poststelle zu gewährleisten.

• Das nachträgliche Hinzufügen von Wurzelzertifikaten zum lokalen Zertifikatsspeicher sollte unterstützt werden.

• Für den Import von Zertifikaten und privaten Schlüsseln sollte das Format PKCS#12 unter-stützt werden.

• Für den Abruf von CRLs sollten HTTP oder LDAP unterstützt werden. Alternativ sollte OCSP unterstützt werden.

• Mehrfachsignaturen (mehrere Signaturen über die selbe E-Mail) sollten unterstützt werden.

• Das Produkt soll das Versenden von S/MIME-Quittungen unterstützen.

– Bei der Nutzung von OpenPGP werden folgende Anforderungen an den E-Mail-Client bzw. das Plug-In gestellt:

• Es müssen starke Kryptoalgorithmen unterstützt werden. Die Schlüssel müssen mit entspre-chender Länge generiert werden können.

• Der private Schlüssel muss sicher aufbewahrt werden können. Der Schutz des privaten Schlüssels durch ein Passwort und das Unterbinden des Exports des privaten Schlüssels müs-sen unterstützt werden. Das Sperren von OpenPGP-Schlüsselpaaren sollte unterstützen wer-den (key revocation certificate).

• Zum Abruf von öffentlichen Schlüsseln von Empfängern sollte eine Schnittstelle zu einem OpenPGP-Keyserver vorhanden sein.

• Zur Gewährleistung der Integrität muss eine digitale Signatur über den eigenen öffentlichen Schlüssel (Eigensignatur) erzeugt werden können. Mit der Eigensignatur bestätigt der Inha-ber, dass der öffentliche Schlüssel zu ihm gehört.

• Die Unterstützung einer Funktionalität zur Wiederherstellung von Schlüsseln (key recovery), die zur Verschlüsselung von Daten verwendet wurden, sollte vorhanden sein. Dadurch ist bei Verlust eines solchen Schlüssels eine Wiederherstellung gespeicherter, verschlüsselter Daten möglich und es wird einem Datenverlust vorgebeugt.

• Die Verwendung einer sogenannten Key ID (Schlüsselnummer, die einen Schlüssel eindeutig identifiziert) für die Bindung von öffentlichem Schlüssel zu einer Person sollte unterstützt werden.

16 In S/MIME v3 ist die Angabe einer E-Mail-Adresse im Zertifikat nicht erforderlich. Damit können diese Zertifikate auch unabhängig von Änderungen der E-Mail-Adresse verwendet werden.



Verzeichnisdienst

Für die sichere Anbindung des E-Mail-Clients an einen Verzeichnisserver bestehen folgende Anfor-derungen:

– Es sollten verschiedene Verzeichnisdienste im E-Mail-Client eingebunden werden können und die Verwendung von LDAP möglich sein.

– Die Benutzung eines sicheren SASL-Mechanismus (z. B. Kerberos V5) zur Authentisierung sollte möglich sein (siehe Abschnitt 2.2.7).

4.1.3 Virenschutzprogramm

Ein Virenschutzprogramm bietet Schutz vor Schadprogrammen wie Viren, Würmer, Trojanischen Pferden, Spyware und Adware (siehe Abschnitt 2.4.3). Für den Schutz von E-Mails müssen Viren-schutzprogramme speziellen Anforderungen gerecht werden.

An das Virenschutzprogramm werden folgende Anforderungen gestellt:

– Es muss mindestens einmal täglich (besser öfter) eine automatische Prüfung und Durchführung des Virenschutz-Updates erlauben.

– Das Virenschutzprogramm sollte verschlüsselte E-Mails unmittelbar nach dem Entschlüsseln auf Schadprogramme prüfen.

– Die Software muss über einen Quarantäne-Bereich für Schadprogramme verfügen.

– Eine auf Erkennungsmuster basierende Prüfung auf Schadprogramme sollte möglich sein.

– Das Produkt sollte eine heuristische Prüfung auf Schadprogramme unterstützen.

– Das Virenschutzprogramm sollte die Prüfung auf Schadprogramme bei den über TLS abgesi-cherten Verbindungen (POP3S, IMAPS und SMTPS) unterstützen.

– Sofern die E-Mail-Client-Software (selbst oder durch integrierten Browser) Aktive Inhalte aus-führen kann, sollte das Produkt Aktive Inhalte auf Schadprogramme (z. B. VBScript, JavaScript, ActiveX Controls und Java Applets) prüfen können.

– Das Produkt sollte es dem Nutzer ermöglichen eine Prüfung auf Schadprogramme selbst zu initi-ieren (on-demand).

– Es sollte eingestellt werden können, dass Dateien, die auf dem Client-Rechner gelesen oder geschrieben werden, sofort auf Schadprogramme geprüft werden (on-access).

– Das Durchführen einer Prüfung auf Schadprogramme sollte im Hintergrund ablaufen können.

– Das Virenschutzprogramm sollte eine Schnittstelle für die E-Mail-Client-Software bereitstellen, so dass der E-Mail-Client die Software integrieren und für eine Prüfung auf Schadprogramme aufrufen kann.

4.1.4 Anti-Phishing-Software

Wichtige Anforderungen an die Software zum Schutz vor Phishing-Angriffen sind:

– Die Software muss über einen Quarantäne-Bereich für E-Mails, die Phishing-Merkmale aufwei-sen, verfügen.



– Das Produkt sollte E-Mails auf Basis von Prüfsummen auf Phishing-Merkmale prüfen und ggf. die diesbezüglichen Inhalte blockieren können.

– Eine automatische Aktualisierung der Datei mit Prüfsummen für Phishing-Merkmale sollte mit dem Produkt möglich sein.

– Das Produkt sollte eine URL-Blacklist (siehe Abschnitt 2.4.2) für Phishing-Seiten unterstützen und ggf. die diesbezüglichen E-Mails blockieren können.

– Eine automatische Aktualisierung der URL-Blacklist sollte mit dem Produkt möglich sein.

– Das Produkt sollte eine Schnittstelle für den E-Mail-Client bereitstellen, so dass der E-Mail-Cli-ent diese Software integrieren und für eine Prüfung aufrufen kann.

4.1.5 Anti-Spam-Software

Wichtige Anforderungen bzgl. Sicherheit der Anti-Spam-Software sind:

– Spam-verdächtige E-Mails müssen in einen Quarantäne-Bereich verschoben werden können.

– Eine Sortierung von E-Mails auf der Basis von Blacklisting/Whitelisting von Wörtern sollte unterstützt werden.

– Die Filterung von E-Mails auf der Basis einer statistischen Inhaltsanalyse sollte möglich sein.

– Die Software sollte mit Spam und Ham trainiert werden können, um Spam-Filter für gewünschte und nicht gewünschte E-Mails zu konfigurieren.

– Einträge des Adressbuchs sollten in eine Whitelist aufgenommen werden können, um zu verhin-dern, dass E-Mails von diesen Absendern fälschlicherweise als Spam erkannt werden.

– Das Produkt sollte eine Schnittstelle für die E-Mail-Client-Software bereitstellen, so dass die E-Mail-Client-Software die Anti-Spam-Software integrieren und für eine Prüfung aufrufen kann.

– Zur Ermittlung von in Anhängen verstecktem Spam sollte die Software die Prüfung verschiede-ner Dateiformate (z. B. pdf, xls, rtf) unterstützen.


Alle Client-Rechner sollten mittels einer Personal Firewall geschützt werden. Es sind folgende Anforderungen zu erfüllen:

– Das Produkt sollte mindestens ein zustandsloser Paketfilter sein.

– Neben dem Schutz gegen Angreifer von außen, sollte das Produkt auch nicht gewollt ausgehende Pakete blockieren. Damit wird beispielsweise erschwert, dass der eigene Rechner ungewollt und unbemerkt Schadprogramme im Internet verbreitet.

– Für eine Aufzeichnung von Angriffsversuchen sollte das Produkt eine Protokollierung unterstüt-zen.



4.2 Sichere Grundkonfiguration der Komponenten

Die Identifizierung und Auswahl der Komponenten sind der erste Schritt zu einer sicheren Grundar-chitektur. Da es sich um komplex aufgebaute Programme mit in der Regel mannigfachen Optionen handelt, gilt der Konfiguration der Komponenten großes Augenmerk.

4.2.1 Client

Informationen zur sicheren Konfiguration der Clients sind im Detail in [ISi-Client] zu finden. In dieser Studie werden speziell jene Dinge beschrieben, die für eine sichere Nutzung von E-Mail not-wendig sind.

Betriebssystem

Bei der Konfiguration des Betriebssystems eines Clients im internen Netz ist das Minimalprinzip zu beachten. Dies bedeutet, dass nur Komponenten, die unbedingt benötigt werden, installiert werden dürfen (insbesondere auch in Bezug auf E-Mail-Software). Zudem sollte eine Authentisierung erzwungen werden, und Benutzer dürfen nur mit eingeschränkten Rechten (d. h. nicht mit Adminis-tratoren-Rechten) arbeiten. Eine Passwort-Richtlinie, die technisch erzwungen wird, sollte imple-mentiert werden.

4.2.2 E-Mail-Client-Software

Die sichere Grundkonfiguration von E-Mail-Client-Software umfasst allgemeine Aspekte der Kon-figuration, der Authentisierung, des Einsatzes von S/MIME und OpenPGP, des Schutzes vor Akti-ven Inhalten, der Verwendung von HTML-E-Mails, der Vorschaufunktionalität, des Umgangs mit Dateianhängen, der verwendbaren Zeichens sowie der Verbindung zu E-Mail-Servern und Ver-zeichnisservern.

Allgemein

– Das automatische Starten von Anwendungen, die mit Dateianhängen verknüpft sind (z. B. .doc mit Word), muss deaktiviert werden. Anwendungen sollen erst nach Abfrage und Bestätigung durch den Anwender gestartet werden.

– Der E-Mail-Client sollte so konfiguriert werden, dass bei Verweisen auf externe Dateien und Schriftarten diese nicht automatisch heruntergeladen werden. Auch eingebettete Schriftarten ermöglichen potenziell die Ausführung von Programmen von entfernten Standorten, sobald eine derartige E-Mail anzeigt wird.

– Manche E-Mail-Programme bieten anderen Programmen Schnittstellen, um über den E-Mail-Client auf das Adressbuch zuzugreifen. In diesem Fall darf ein automatischer Zugriff nicht erlaubt werden, da Würmer die Adressen aus dem Adressbuch als Empfängeradressen verwen-den, um sich weiter zu verbreiten.

– Es wird empfohlen, das automatische Versenden von Lesebestätigungen zu deaktivieren.

– Als Reply-Adresse einer E-Mail dürfen keine internen E-Mail-Adressen (z. B. [email protected]) angegeben werden. Für die Konfiguration wird empfohlen, stattdessen die Antwort an eine externe E-Mail-Adresse (z. B. [email protected]) zu senden.



– Die Konfiguration von Stellvertreterberechtigungen sollte restriktiv gehandhabt werden. Die Berechtigung des Zugriffs sollte nur erteilt werden, wenn es unbedingt notwendig ist. Dadurch soll verhindert werden, dass Benutzer infizierte E-Mails aus fremden Postfächern öffnen oder Schadprogramme auf E-Mail-Konten anderer Benutzer zugreifen können.

– Es wird empfohlen, die automatische Weiterleitung von E-Mails zu deaktivieren.

Authentisierung

– Der Benutzername und das Kennwort zur Anmeldung am E-Mail-Server darf bei einer lokalen Speicherung nicht unverschlüsselt abgelegt werden. Ansonsten könnten diese von Schadpro-gramme ausgelesen werden.

– Der E-Mail-Client soll so konfiguriert werden, dass dieser die Übermittlung der Authentisie-rungsdaten ablehnt, wenn keine Verschlüsselungsverfahren (also unverschlüsselt) oder kein geeigneter Verschlüsselungsalgorithmus vom internen E-Mail-Server verwendet wird.

S/MIME

– Für die Signierung von E-Mails mit S/MIME wird empfohlen das Nachrichtenaustauschformat „Clear Signed“ (auch als „Multipart-Signed“ bezeichnet) einzustellen.

S/MIME und OpenPGP

– Für Signatur und Verschlüsselung sollten standardmäßig starke Kryptoalgorithmen verwendet werden. Diese Voreinstellung sollte möglichst nicht vom Benutzer geändert werden können.

– Neue Schlüssel sollten standardmäßig mit entsprechender Länge generiert werden, damit eine sichere Signatur und Verschlüsselung möglich ist. Diese Voreinstellung sollte möglichst nicht vom Benutzer geändert werden können.

– Die Liste von vertrauenswürdigen Herausgebern von Zertifikaten (z. B. Trustcenter) sollte nur zentral vorgehalten werden, wie beispielsweise die Liste mit Zertifikaten vertrauenswürdiger Zertifizierungsstellen. Eine solche Liste wird auch als Trust Service Provider Status List (TSL) bezeichnet. So können Zertifikate von vertrauten Herausgebern auch ohne Aufbau einer komple-xen Infrastruktur verteilt werden.

– Der private Schlüssel (S/MIME und OpenPGP) muss mittels eines Passwortes geschützt und als „nicht exportierbar“ markiert werden, um einer missbräuchlichen Nutzung vorzubeugen.

Schutz vor Aktiven Inhalten

– Das Ausführen von Aktiven Inhalten sollte über die Browsereinstellungen des E-Mail-Clients ausgeschaltet werden, sofern die E-Mail-Client-Software (selbst oder durch integrierten Browser) Aktive Inhalte ausführen kann.

HTML-E-Mail

– Es wird empfohlen, das Erstellen und Lesen von E-Mails im HTML-Format auszuschalten und das Textformat zu wählen. Empfangene E-Mails sollten grundsätzlich nur als Text gelesen wer-den können. Sollte dies allerdings dazu führen, dass eine HTML-E-Mail durch die Darstellung als Text völlig unverständlich wird, sollte eine Möglichkeit bestehen HTML-E-Mails in „einfa-ches“ HTML umzuwandeln. Das bedeutet, dass nur reine HTML-Strukturelemente angezeigt und Aktive Inhalte (z. B. JavaScript) ignoriert werden.



– Das automatische Nachladen von „Inline Content“ wie Grafiken sollte deaktiviert werden (die z. B. sogenannte Web Bugs enthalten können, die wenige Pixel groß sind, von einem fremden Server aufgerufen werden und dem Transport von Informationen dienen).

– Falls möglich, sollte die E-Mail-Client-Software so konfiguriert werden, dass nicht nur Hyper-links angezeigt werden (mit denen eine Verschleierung der eigentlichen URL möglich ist), son-dern auch die tatsächliche URL.

E-Mail-Vorschau

– Bei E-Mail-Clients, die im Vorschaufenster Aktive Inhalte ausführen können, sollte die Vor-schaufunktion abgeschaltet werden

Dateianhänge

– Der E-Mail-Client muss so konfiguriert werden, dass Dateianhänge vor dem Öffnen auf Schad-programme geprüft werden. Dies kann durch vorherige Speicherung der Dateianhänge im Datei-system oder durch eine entsprechende Integration des Virenschutzprogramms in den E-Mail-Cli-ent erfolgen.

– Es wird empfohlen, das automatische Öffnen von Nachrichten in der E-Mail-Client-Software auszuschalten.

– Der E-Mail-Client sollte beim Öffnen einer E-Mail keine Dateianhänge automatisch Öffnen oder Speichern.

– Der E-Mail-Client muss alle Dateiendungen der Dateianhänge einer E-Mail in voller Länge anzeigen. Dazu ist eventuell auch eine entsprechende Konfiguration des Betriebssystems not-wendig.

– Der E-Mail-Client sollte mindestens so konfigurieren werden, dass ausführbare Dateianhänge (z. B. bat, vbx, chm, com) blockiert/ausgeblendet werden (Blacklisting). Sofern die E-Mail-Cli-ent-Software es erlaubt eine Liste mit zugelassenen Dateianhängen anzugeben (Whitelisting), die nur diese anzeigt, wird alternativ der Einsatz dieser Funktion empfohlen.

– Wenn der E-Mail-Client den Dateityp eines Dateianhangs nicht nur anhand der Dateiendung, sondern auf Basis des Dateiinhaltes erkennen kann (Magic-Byte17), sollte dies für das oben genannte Ausblenden von Dateianhängen genutzt werden.

Festlegung des Zeichencodes

– Es wird empfohlen, die E-Mail-Client-Software so zu konfigurieren, dass die 8-Bit Zeichencodes UTF-8, ISO 8859-1 (Latin-1) und und ISO-8859-15 unterstützt werden.

Kommunikation mit dem E-Mail-Server

– Die Kommunikation des E-Mail-Clients mit dem E-Mail-Server sollte verschlüsselt erfolgen. Es können die Protokolle POP3/IMAP und SMTP über SSL/TLS verwendet werden.

– Zur Aushandlung der Verschlüsselung über SSL/TLS sollte das Kommando STARTTLS auf den normalen Ports für POP3 (Port 110), IMAP (Port 143) und SMTP (Port 25) verwendet werden.

17 Beispielsweise beginnen typische EXE-Dateien für das Betriebssystem Windows mit dem Magic-Byte "MZ" (hexadezimal: 4D5A).



Von Benutzung separater Ports (z. B. SMTPS auf Port 465, IMAPS auf Port 993, POP3S auf Port 995) wird im [RFC 2595] abgeraten.

– Der E-Mail-Client sollte so konfiguriert werden, dass dieser beim Verbindungsaufbau mit dem E-Mail-Server eine schwache oder unverschlüsselte Verbindung ablehnt. Dazu gehören SSLv2 und SSL mit schwachen Verschlüsselungs- oder Hash-Algorithmen (z. B. 40-Bits RC4).

Kommunikation mit dem Verzeichnisserver

– Zur Anbindung eines E-Mail-Clients an Verzeichnisserver wird das Protokoll LDAP empfohlen.

– Die Authentisierung des E-Mail-Clients am Verzeichnisserver muss so erfolgen, dass die Über-mittlung von Benutzername und Kennwort nicht unverschlüsselt erfolgt. Dies kann beispiels-weise über SASL bzw. STARTTLS erfolgen. Es wird der Einsatz eines starken Verschlüsse-lungsverfahren empfohlen.

4.2.3 Virenschutzprogramme

Virenschutzprogramme bieten Konfigurationsmöglichkeiten, um das Programm an die individuel-len Bedürfnisse nach Sicherheit und Leistungsfähigkeit (Performance) anzupassen.

– Das Virenschutzprogramm muss so konfigurieren werden, dass ein Virenschutz-Update automa-tisch und mindestens einmal täglich (besser noch öfter) erfolgt, damit optimaler Schutz gewähr-leistet ist. Neben dem Update der Virenschutz-Signaturen und der Heuristiken sollte auch ein Update des Virenschutzprogramms automatisch erfolgen.

– Eingehende und ausgehende E-Mails einschließlich der Dateianhänge müssen mittels des Viren-schutzprogramms unmittelbar auf Viren, Würmer, Trojanische Pferde, Spyware und Adware geprüft werden.

– Es wird empfohlen, bei jeglichen Prüfungen deren Protokollierung zu aktivieren.

– Das Virenschutzprogramm muss so konfigurieren werden, dass beim Zugriff auf Dateien die Virenprüfung ausgeführt wird.

– Die Konfiguration des Virenschutzprogramms sollte berücksichtigen, dass E-Mails beim Emp-fang und vor dem Versand geprüft werden. Dabei sollte das Virenschutzprogramm bei der Über-tragung mit POP3, mit IMAP und mit SMTP über TLS integriert werden.

– Der E-Mail-Client sollte so konfiguriert werden, dass mittels S/MIME oder OpenPGP verschlüs-selte Nachrichten und Dateien zuerst entschlüsselt und unmittelbar danach mit dem Virenschutz-programm auf Schadprogramme geprüft werden.


Für eine sichere Grundkonfiguration von Anti-Phishing-Software wird empfohlen,

– das Programm so einzustellen, dass eingehende E-Mails unmittelbar auf Phishing-Merkmale geprüft werden,

– die Phishing-Datenbank, in der die Adressen betrügerischer Webseiten eingetragen sind, automa-tisch aktualisieren zu lassen,

– die Prüfsummen von Phishing-Merkmalen automatisch zu aktualisieren,



– Anti-Phishing-Software so einzustellen, dass die URL Blacklist automatisch aktualisiert wird,

– vorgenommene Prüfungen zu protokollieren.


Für eine sichere Grundkonfiguration der Anti-Spam-Software wird empfohlen

– einen separaten Ordner zu konfigurieren, in dem als Spam markierte E-Mails verschoben werden (Quarantäne),

– sie so zu konfigurieren, dass die Filterregeln für E-Mails, die als Spam markiert sind, aktiviert sind und diese in den Quarantäne-Ordner verschoben werden, damit false positives erkannt wer-den können,

– sie so zu konfigurieren, dass eine automatische Aktualisierung der statistischen Datenbank zur Erkennung von Spam erfolgt,

– sie so einzustellen, dass E-Mails von einem Absender, der im Adressbuch des Benutzers steht, nicht als Spam markiert werden.


– Die Personal Firewall muss so konfiguriert werden, dass grundsätzlich Zugriffe von außen auf den Client-Rechner unterbunden werden. Eine zulässige Ausnahme ist der Fernwartungszugang für Rechner, die zentral administriert werden.

– Der Datenverkehr nach außen darf nur über vordefinierte Ports und möglichst nur mit vordefi-nierten Programmen erfolgen.

– Es wird empfohlen, Angriffsversuche auf der Personal Firewall zu protokollieren und mindes-tens folgende Informationen aufzuzeichnen: IP-Adresse (Quelle/Ziel), Port, Dienst und Zeit/Datum unter Beachtung der für die Organisation geltenden Gesetze und Vorschriften wie beispielsweise die Telemediengesetz (TMG), das Telekommunikationsgesetz (TKG) und Daten-schutzbestimmungen.

– Die Personal Firewall sollte so konfiguriert werden, dass die vom Administrator festgelegten Fil-terregeln vom Benutzer nicht verändert werden können.



4.3 Grundvorgaben für einen sicheren Betrieb

Voraussetzung für den sicheren Betrieb einer E-Mail-Client-Architektur ist der sichere Betrieb der zugrunde liegenden IT-Systeme. Die Vorgaben für den sicheren Betrieb einer E-Mail-Server-Archi-tektur (siehe [ISi-Mail-Server]) und der Anbindung eines internes Netzes an das Internet (siehe [ISi-LANA]) werden für die folgenden Abschnitte vorausgesetzt.

4.3.1 Allgemein

Es wird empfohlen, die Überwachung von Exploits (die Ausnutzung von Schwachstellen) einzu-richten und eine Implementierung von Prozeduren festzulegen, wie auf Exploits zu reagieren ist. Eine Gegenmaßnahme könnte sein, dass bestimmte Dateiformate auf dem E-Mail-Client oder E-Mail-Server blockiert werden.

Es wird empfohlen, aktuelle Sicherheitswarnungen zu verfolgen und sicherheitsrelevante Updates und Patches nach vorherigem Test unverzüglich einzuspielen.

4.3.2 E-Mail-Richtlinie

Für die Nutzung von E-Mail in einer Institution wird die Festlegung einer E-Mail-Richtlinie emp-fohlen. In dieser Richtlinie sollten mindestens folgende Punkte beschrieben sein:

– wer innerhalb der Institution einen E-Mail-Anschluss erhält,

– Regelungen, die von E-Mail-Benutzern und E-Mail-Administratoren zu beachten sind, um einen sicheren Betrieb zu gewährleisten (z. B. das Verhalten beim Auftreten von Viren),

– Regelung, bis zu welchem Anspruch an Vertraulichkeit, Verfügbarkeit, Integrität und Verbind-lichkeit Informationen per E-Mail versandt werden dürfen,

– Regelung, dass schützenswerter Daten in E-Mails nur verschlüsselt übertragen werden dürfen,

– die Schulung der Benutzer,

– wie jederzeit technische Hilfestellung für die Benutzer gewährleistet wird,

– ob und in welchem Umfang der private Gebrauch von E-Mail erlaubt ist,

– welche Regelungen für den Zugriff auf den E-Mail-Dienst und entsprechende Protokollierung einzuhalten sind,

– wie die Abstimmung mit dem Betriebs-/Personalrat geregelt wird, wenn persönliche Daten von Arbeitnehmern verarbeitet werden und

– welche Regelungen im Hinblick auf die Zustimmungspflicht aller Mitarbeiter zur E-Mail-Richt-line gelten.

Ein Beispiel für eine E-Mail-Richtlinie ist in den Hilfsmitteln zum IT-Grundschutz unter Muster-richtlinien und Beispielkonzepte beschrieben.



4.3.3 E-Mail-Client-Software

Für den sicheren Betrieb der E-Mail-Client-Software sind folgende Vorgaben von Bedeutung:

– Implementierung von Prozeduren, die festlegen wie auf Schwachstellen ohne verfügbare Patches zu reagieren ist.

– Aufstellung von Verhaltensregeln zur sicheren Aufbewahrung des privaten Schlüssels bei der Verwendung von S/MIME oder OpenPGP.

– Verwendung von starken Kryptoalgorithmen. Im Bundesanzeiger werden geeignete Algorithmen für Verschlüsselung, für digitale Signatur und für das Hashen von Daten veröffentlicht. Die Schlüssel müssen mit entsprechender Länge generiert werden.

– Einrichtung einer (zentralen) E-Mail-Adresse, an die sicherheitsrelevante Vorkommnisse zu mel-den sind (z. B. [email protected]).

– Umgehende Aktualisierung (Erweiterung) der Blacklist bei Bekanntwerden „schädlicher“ Datei-anhänge.

– Aufstellen von Verhaltensregeln zum Öffnen von Dateianhängen, insbesondere zum Ausführen enthaltener Anwendungen.

– Aufstellen von (restriktiven) Verhaltensregeln zu Stellvertreterberechtigungen.

4.3.4 Virenschutzprogramm

– Es muss regelmäßig geprüft werden, ob der automatische Mechanismus des Virenschutz-Upda-tes auf allen E-Mail-Clients funktioniert. Dazu bieten zentrale Virenschutzlösungen entspre-chende Unterstützung.

– Bei Bedarf (z. B. bei Verdacht einer Infektion des PC mit Viren) ist durch den Administrator oder Benutzer selbst eine Prüfung auf Schadprogramme durchzuführen (on-demand).

– Die Logdaten und Fehlermeldungen des Virenschutzprogramms sollten kontinuierlich zentral überwacht werden.


Es wird empfohlen, die Logdaten und Fehlermeldungen der Anti-Phishing-Software kontinuierlich zentral zu überprüfen.


Es wird empfohlen,

– den Quarantäne-Ordner regelmäßig auf false positives zu prüfen.

– die Logdaten und Fehlermeldungen der Anti-Spam-Software kontinuierlich zu überwachen.


Es wird empfohlen, die Logdaten/Fehlermeldungen der Personal Firewall kontinuierlich zu prüfen.



5 Gefährdungen und Empfehlungen mit Varianten für normalen und hohen Schutzbedarf

Dieser Abschnitt analysiert die Gefährdungen, die mit einer Nutzung von E-Mail bei der Anbindung an das Internet verbunden sind. Er stellt dar, wie die Architektur- und Konfigurationsvorgaben der Abschnitte 3 und 4 diese Sicherheitsgefahren bei normalem Schutzbedarf abwehren. Darüber hinaus werden Varianten der Grundarchitektur vorgeschlagen, die mit höherem Aufwand höheren Schutz-bedarf abdecken oder die bei geringerem technischen Realisierungsaufwand ein höheres, in speziel-len Szenarien jedoch noch akzeptables Restrisiko mit sich bringen.

Lösungen, die sich mit weniger Hardware-Komponenten realisieren lassen, sind in der Beschaffung kostengünstiger. Mit der Vereinfachung steigen jedoch meist die Sicherheitsrisiken und erschwert unter Umständen die Konfiguration und den Betrieb der Komponenten. Der Benutzer muss daher von Fall zu Fall entscheiden, ob die Grundarchitektur in der Grundkonfiguration auf Dauer nicht doch wirtschaftlicher ist als die mit technischen Vereinfachungen einhergehenden Nachteile und Ri-siken. Vereinfachungsmaßnahmen müssen daher von Fall zu Fall genau abgewogen werden. In je-dem Fall eignen sie sich nur für Anwendungen mit höchstens normalem Schutzbedarf.

Mit dem Erreichen eines höheren Sicherheitsniveaus sind in der Regel auch höhere Kosten verbun-den. Zudem kann dies eine Beeinträchtigung des Benutzerkomforts zur Folge haben. Es entstehen Beschaffungskosten für zusätzliche Sicherheitskomponenten oder ein Mehraufwand für die Einrich-tung und den Betrieb einer anspruchsvolleren Architektur. Daher richten sich die Empfehlungen für hohen Schutzbedarf in erster Linie an besonders exponierte Institutionen und an die Nutzer und Ad-ministratoren von E-Mail-Clients, die besonderen Schutz der Verfügbarkeit, Vertraulichkeit und In-tegrität ihrer Daten benötigen.

Der folgende Abschnitt gliedert alle Gefährdungen, vor denen es sich zu schützen gilt, nach den un-terschiedlichen Bedrohungskategorien. Wenn Gefährdungen aus mehreren Bedrohungen unter-schiedlicher Kategorie resultieren können, wurden sie der primär auftretenden Klasse zugeordnet.

5.1 Gefährdungen durch Eindringen

Die erste Kategorie von Bedrohungen besteht darin, dass ein Angreifer versucht, in Systeme einzu-dringen. Dieses sogenannte Hacking erfolgt zumeist, um anschließend Sicherheitsgrundwerte zu beeinträchtigen. Es ist dann möglich die Vertraulichkeit zu kompromittieren (z. B. Tasten-Rekorder), die Verfügbarkeit zu bedrohen (z. B. Code Red, der eine Sicherheitslücke nutzte und Server zum Abstürzen brachte) und die Integrität und Authentizität zu verlieren (z. B. Klez-Wurm, der Dateien auf dem Computer zerstörte).

5.1.1 Computer-Viren und Würmer

Bedrohung: Eindringen in den E-Mail-Client.

Schwachstelle: Diese Bedrohung entsteht durch Schwachstellen in der technischen Realisierung (z. B. Buffer-Overflow-Schwachstelle in der Software), durch Konfigurationsfehler (z. B. fehlende Aktualisierung der Viren-schutz-Signaturen oder Ausführen von Aktiven Inhalten) oder durch Verhaltensfehler im Betrieb (z. B. Öffnen einer infizierten Dateianlage durch den Benutzer).



Viren

Ein Computer-Virus ist ein nicht selbstständiges Programm, das sich nach Ausführung selbst reproduziert und dadurch vom Benutzer nicht kontrollierbare Manipulationen in Systemberei-chen, an anderen Programmen oder deren Umgebung vornimmt. Zusätzlich können program-mierte Schadensfunktionen des Virus vorhanden sein.

Es gibt verschiedene Arten von Computer-Viren:

– Boot-Viren werden beim Start des Rechners aktiv, noch bevor das Betriebssystem vollstän-dig geladen ist.

– Datei-Viren greifen ausführbare Programmdateien an und infizieren sie, indem sie ihren eigenen Code in die Programmdateien kopieren. Wenn das infizierte Programm gestartet wird, wird zunächst der Virus aktiviert, der nun weitere Programme infizieren oder seine Schadensfunktion ausüben kann.

– Bei Makro-Viren handelt es sich nicht um eigenständige Programme, sondern um Makros, die in einem Dokument eingebettet sind.

Viren verbreiten sich durch E-Mail, über Webserver, FTP-Server, Peer-to-Peer-Netze usw.

Würmer

Im Gegensatz zu Viren versuchen Würmer aktiv in Systeme einzudringen. Sie verbreiten sich ohne oder mit wenig menschlicher Interaktion. Die Verbreitung von Würmern über E-Mail ist möglich. Sie nutzen Sicherheitsprobleme der Zielsysteme aus und benutzen beispielsweise Sicherheitslücken in nicht gepatchter Systemsoftware.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr von Viren und Würmern bei:

– Einsatz eines Virenschutzprogramms, sowie

– Einsatz einer Personal Firewall auf dem E-Mail-Client.

Folgende Aspekte der Grundkonfiguration tragen zur Abwehr von Viren und Würmern bei:

– Alle ein- und ausgehenden E-Mails werden inklusive der Dateianhänge mittels Virenschutzpro-gramm auf Schadprogramme untersucht,

– Integritäts-, Authentizitäts-Prüfungen bei Verwendung von S/MIME, OpenPGP und der Virtuel-len Poststelle,

– Blacklisting ausführbarer Dateianhänge,

– Speichern der Dateianhänge, bevor diese geöffnet werden dürfen,

– Ausschalten der E-Mail-Vorschau (sofern die E-Mail-Vorschau Aktive Inhalte ausführen kann),

– Deaktivieren des automatischen Nachladens von Dateien (wie Fotos),

– Ausschalten des automatischen Öffnens oder Speicherns von Dateien,

– Deaktivieren des automatischen Startens von Anwendungen,

– Abschalten des automatischen Zugriffs auf das Adressbuch von anderen Programmen außer dem E-Mail-Client selbst,



– Aktivieren der Anzeige aller Dateiendungen, um gefährliche Dateianhänge (wie z. B. ausführ-bare Dateien) besser erkennen zu können,

– Deaktivieren des automatischen Herunterladens von Dateien (sofern der E-Mail-Client das auto-matische Herunterladen unterstützt),

– Deaktivieren des Herunterladens von Schriftarten (sofern der E-Mail-Client das automatische Herunterladen unterstützt).

Folgende Grundvorgaben für einen sicheren Betrieb tragen zur Abwehr von Viren und Würmern bei:

– mindestens tägliches Virenschutz-Update (Signaturen, Heuristiken und Virenschutzprogramm) und

– aktuelle Patches des Betriebssystems und der Anwendungen.

Restrisiko: Ein Restrisiko besteht durch Angriffe, die Schwachstellen oder Sicherheitslücken ausnutzen, die noch nicht allgemein bekannt sind und/oder für deren Schließung noch keine Lösung vom Hersteller vor-handen ist.

Weiterhin besteht eine Gefahr durch die Ausnutzung von Schwach-stellen in zugelassenen Dateianlagen, also Dateianlagen, die der Benutzer erhalten und nutzen kann.

Ein anderes Risiko besteht darin, den Zeitraum zwischen Verbreitung der Viren und Würmer und dem Aktualisieren der Virensignaturen der Virenschutzprogramme auszunutzen. Hierzu werden Schadpro-gramme in immer kürzer werdenden Abständen verbreitet. Dabei han-delt es sich nicht immer um neue Viren und Würmer, sondern auch um Schädlinge, die nur in ihrer Struktur leicht verändert werden, ihre Funktion jedoch beibehalten. Auf diese Weise können auch signatur-basierte Virenschutzprogramme überlistet werden.

Angreifer versuchen – ähnlich der Umgehung bei der signaturbasier-ten Virenprüfung – mit immer neuen Methoden ihre Schadprogramme vor der Entdeckung zu verbergen. Damit kann ein Angreifer auch die heuristische Prüfungen des Virenschutzprogramms überwinden.

Die nachfolgend dargestellten Varianten ermöglichen es, dem Benutzer die Schutzwirkung der Grundarchitektur und den erforderlichen Realisierungsaufwand seinem individuellen Bedarf anzu-passen.

Variante 5.1.1 A Hoher Schutzbedarf: Host-basiertes Intrusion Detection System

Anwendungsbereich: hoher Schutzbedarf bezüglich Integrität

Phase im Ablaufplan: Konzeption

Ein Host-basiertes Intrusion Detection System (HIDS) analysiert verschiedene Daten um Missbrauch oder Einbruch in ein System festzustellen. Es nutzt Informationen aus Log-Dateien, Kernel-Daten sowie anderen Systemdaten (beispielsweise der Registrie-rungsdatei) und vergleicht deren Inhalte mit einer internen Datenbank, die Muster bekannter Angriffe enthält. Sobald es in den überwachten Daten einen vermeintlichen Angriff erkennt, wird ein Alarm ausgelöst.Ein HIDS kann verhaltensbasierte Angriffe ermitteln, wie z. B. das Versenden mehre-



rer (gleicher) E-Mails in kurzen Zeitabständen, was auf eine Infektion mit einem Schadprogramm hindeutet. Ferner ist es möglich, Änderungen der Prüfsumme der E-Mail-Client-Software zu ermitteln, um so eine Verseuchung der E-Mail-Client-Soft-ware mit Schadprogrammen zu erkennen. Um die Auswertung von Protokolldaten zu ermöglichen, wird empfohlen, diese (sicher) zu speichern bzw. an eine zentrale Management-Station zu übertragen. Die Grundarchitektur der E-Mail-Client-Software wird in Abbildung 5.1 dargestellt.

Restrisiko: Ein Restrisiko besteht durch Ausnutzen von Schwachstellen/Sicher-heitslücken, für die es noch keine Virenschutz-Signatur gibt und die nicht über die heuristische Funktionalität des HIDS ermittelt werden können.Ein weiteres Risiko besteht in der Manipulation der Protokolldaten durch den Angreifer.

Umsetzungsaufwand: Für die Beschaffung der HIDS-Software ist mittlerer Aufwand erfor-derlich. Konfiguration und Betrieb erfordern höheren Aufwand, weil die Meldungen ausgewertet werden müssen.


Abbildung 5.1: Alternative Empfehlung HIDS


Variante 5.1.1 B Normaler Schutzbedarf: Blacklisting gefährlicher MIME-Types

Anwendungsbereich: normaler Schutzbedarf bezüglich bezüglich Vertraulichkeit, Verfüg-barkeit oder Integrität


Bestimmte MIME-Types können dazu missbraucht werden, Schadprogramme herun-terzuladen. Beispielsweise zeigt der MIME-Type message/external-body auf eine Nachricht mit externem Inhalt. Dieser externe Inhalt kann Schadprogramme enthalten und beim Herunterladen den Rechner infizieren. Es empfiehlt sich, gefährliche MIME-Types in einer Blacklist zu führen, damit E-Mails mit derartigen MIME-Types ausgeblendet bzw. blockiert werden.

Restrisiko: MIME-Types, die nicht in der Blacklist geführt werden, können je nach Typ mit Viren oder Würmern infiziert sein.

Umsetzungsaufwand: Derzeit unterstützen die gängigen E-Mail-Clients ein Blacklisting gefährlicher MIME-Types nicht. Sofern E-Mail-Clients dieses unter-stützen, kann diese Variante mit niedrigem Aufwand realisiert werden.

5.1.2 Viren und Würmer in verschlüsselten E-Mails


Schwachstelle: Bei einer Ende-zu-Ende-Verschlüsselung (z. B. OpenPGP, S/MIME) gibt es auf den E-Mail-Servern keine Möglichkeit, Schadprogramme zu erkennen, sofern kein Schlüssel für die Entschlüsselung verfügbar ist.

Bei einer Ende-zu-Ende-Verschlüsselung kann die E-Mail nur vom Empfänger entschlüsselt werden. Somit erhält nur der Empfänger den tatsächlichen Inhalt der E-Mail. Ein E-Mail-Server hat daher keine Möglichkeit die E-Mail auf Schadprogramme zu prüfen und den Inhalt zu analysieren. Schadprogramme und nicht gewünschte Inhalte können daher ungehindert auf den Client-Rechner gelangen. Ist kein lokales Virenschutzprogramm auf dem E-Mail-Client-Rechner installiert oder die Virenschutz-Signatur nicht aktuell, können Schadprogramme dort ausgeführt werden. Diese Gefährdung besteht nicht beim Einsatz der Virtuellen Poststelle, da hierbei eine zentrale Entschlüsselung und Prüfung auf Schadprogramme möglich ist.

Folgende Aspekte der Grundkonfiguration tragen zur Abwehr von Viren und Würmern in ver-schlüsselten E-Mails bei:

– Einsatz eines im MUA integrierten Virenschutzprogramms, welches Schadprogramme auch bei Einsatz von S/MIME- und OpenPGP-Verschlüsselung untersucht und

– Einsatz der Virtuellen Poststelle (VPS).

Folgende Grundvorgabe für einen sicheren Betrieb trägt zur Abwehr von Viren und Würmern in verschlüsselten E-Mails bei:

– Mindestens tägliches Virenschutz-Update (Signaturen, Heuristiken und Virenschutzprogramm)

Restrisiko: Es erfolgt, außer beim Einsatz einer Virtuellen Poststelle, keine server-seitige Überprüfung der E-Mails auf Schadprogramme. Angriffe mit



Schadprogrammen, die in verschlüsselten E-Mails versteckt sind, wer-den derzeit jedoch nur gezielt eingesetzt.

Variante 5.1.2 A Hoher Schutzbedarf: Zusätzliche Verschlüsselung von E-Mails mit einem zentralen Unternehmensschlüssel

Anwendungsbereich: hoher Schutzbedarf bezüglich Verfügbarkeit oder Integrität


Damit verschlüsselte E-Mails auch auf schädliche Programme und Inhalte geprüft werden können, empfiehlt es sich – neben der Verschlüsselung an den eigentlichen Empfänger – eine Verschlüsselung mit einem zusätzlichen zentralen Unternehmens-schlüssel vorzunehmen. Dies kann dadurch erfolgen, dass der Absender in der E-Mail im Feld CC oder BCC eine zentrale E-Mail-Adresse des Unternehmens angibt, der ein entsprechender öffentlicher Schlüssel zugeordnet ist. Dadurch können diese E-Mails dann an zentraler Stelle mit einem Unternehmensschlüssel entschlüsselt und auf Schadprogramme geprüft sowie gefährliche Inhalte analysiert werden. Bei dieser Variante werden verschlüsselte E-Mails, die nicht zusätzlich für die zentrale Unter-nehmensadresse verschlüsselt werden, nicht akzeptiert. Dies gilt dabei sowohl für ein-gehende und ausgehende E-Mails.

Restrisiko: Ein Restrisiko besteht durch Ausnutzen von Schwachstellen oder Sicherheitslücken, die noch nicht allgemein bekannt sind und/oder für deren Schließung noch keine Lösung vom Hersteller vorhanden ist. Auch Angriffe, für die noch keine Virenschutz-Signaturen verfügbar sind, sind weiter möglich.

Umsetzungsaufwand: Der Realisierungsaufwand wird als mittel eingestuft. Es muss ein Pro-dukt server-seitig implementiert werden, das die Entschlüsselung durchführt. Das Produkt muss mit einem entsprechenden Unterneh-mensschlüssel und Zertifikat ausgestattet werden. Eine Alternative zu dieser Variante ist der Einsatz der Virtuellen Poststelle, bei der die E-Mail nur für den zentralen Unternehmensschlüssel verschlüsselt wird.

5.1.3 Nicht aktuelle Virenschutzprogramme


Schwachstelle: Schadprogramme werden ständig weiterentwickelt und die hinter die-sen Programmen steckende Logik kann nicht vorhergesagt werden. Demzufolge können Virenschutzprogramme nicht alle aktuellen Schadprogramme ermitteln.

Ein E-Mail-Client kann infiziert werden, wenn der Benutzer einen mit einem Schadprogramm infizierten Dateianhang öffnet, der vom Virenschutzprogramm jedoch nicht als Schadpro-gramm erkannt wird.

Folgende Grundvorgaben für einen sicheren Betrieb tragen zur Abwehr von Gefährdungen durch nicht aktuelle Virenschutzprogramme bei:

– mindestens tägliches Virenschutz-Update (Signaturen, Heuristiken und Virenschutzprogramm).



Restrisiko: Ein Restrisiko besteht durch Schadprogramme, die zwischen zwei Aktualisierungen der Virenschutz-Signaturen im Umlauf sind und durch das Virenschutzprogramm nicht erkannt werden.

Variante 5.1.3 A Hoher Schutzbedarf: Systeme ohne aktuellen Virenschutz dürfen nicht in das lokale Netz eingebunden werden

Anwendungsbereich: hoher Schutzbedarf bezüglich Vertraulichkeit, Verfügbarkeit oder Integrität

Phase im Ablaufplan: Konzeption, Betrieb

Nicht aktuelle Systeme bergen die Gefahr, mit schädlichen Programmen infiziert zu sein. Daher dürfen nur Systeme in das lokale Netz eingebunden werden, die den neuesten Stand der Virenschutzprogramme einsetzen.Für hohen Schutzbedarf wird empfohlen, zu überprüfen, ob die Virenschutzpro-gramme auf dem E-Mail-Client dem aktuellen Stand entsprechen.

Restrisiko: Ein Restrisiko besteht durch Ausnutzen von Schwachstellen oder Sicherheitslücken, die noch nicht allgemein bekannt sind und/oder für deren Schließung noch keine Lösung vom Hersteller vorhanden ist.

Umsetzungsaufwand: Es bestehen mittlere bis hohe Anschaffungskosten für ein System zur Überwachung der E-Mail-Client-Rechner. Ggf. müssen Netzkompo-nenten ausgetauscht werden, damit E-Mail-Client-Rechnern der Zugang zum Netz verweigert wird. Demzufolge ergeben sich auch mittlere bis hohe Realisierungs- und Betriebsaufwände.

5.1.4 Nachladen von Programmen über MIME-Types


Schwachstelle: Eine Schwachstelle entsteht in der Konfiguration der E-Mail-Client-Software, wenn Dateien (Schadprogramme) automatisch geladen und ausgeführt werden.

Durch MIME-Types werden die verschiedenen Komponenten einer E-Mail klassifiziert. Allerdings werden bestimmte MIME-Types von Angreifern missbraucht, um Schadpro-gramme beim Öffnen der E-Mail nachzuladen. Beispielsweise zeigt der MIME-Type mes-sage/external-body auf eine Nachricht mit externem Inhalt. Dieser externe Inhalt kann mit Schadprogrammen infiziert sein und beim Herunterladen den E-Mail-Client-Rechner verseu-chen.

Folgender Aspekt der Grundkonfiguration trägt zur Abwehr von Gefährdungen von spezifischen MIME-Typs bei:

– Deaktivieren des automatischen Herunterladens von Dateien.

Restrisiko: Ein Restrisiko besteht durch das manuelle Öffnen von Dateien durch den Benutzer.



5.1.5 HTML-E-Mail: Aktive Inhalte


Schwachstelle: Eine konzeptionelle Schwachstelle entsteht in E-Mail-Clients durch die Nutzung von Routinen eines Browsers zur Anzeige von HTML-E-Mails und der Ausführung Aktiver Inhalte.

E-Mail-Clients bieten zwar die Möglichkeit, Aktive Inhalte auszu-schalten. Fehler in der Realisierung und der Konfiguration können jedoch dazu führen, dass Aktive Inhalte während des Betriebs ausge-führt werden.

Für E-Mail-Clients, bei denen die Ausführung Aktiver Inhalte nicht möglich ist, gilt diese Schwachstelle nicht.

Aktive Inhalte stellen ein Sicherheitsrisiko dar, da die Ausführung der Inhalte wie ein lokales Programm aber unbemerkt vom Anwender erfolgt. Die Ausführung Aktiver Inhalte wird durch die Integration von Browser-Funktionen in der E-Mail-Anwendung ermöglicht. Die Browser-Funktionen übernehmen die Interpretation und damit die Darstellung der Aktiver Inhalte innerhalb der E-Mail-Anwendung. Im Gegensatz zu Dateianlagen werden Aktive Inhalte bereits beim Öffnen der E-Mail ausgeführt, wenn diese Funktion im E-Mail-Client oder Browser nicht deaktiviert wurde. So kann bereits die Anzeige solcher E-Mails auf dem Client ungewollte Aktionen auslösen, wenn HTML-E-Mails z. B. eingebetteten JavaScript-, VisualBasic-Skript-Code oder Flash-Objekte enthalten. Böswillig programmierte Aktive Inhalte können vollen Zugriff auf den Rechner erlangen und beispielsweise beliebige Dateien lesen, verändern, ins Internet übermitteln oder auch arglosen Benutzern Schadprogramme unterschieben, die unter deren Zugriffsrechten ausgeführt werden.

Java-Applets und ActiveX-Controls können auch auf einem Webserver im Internet abgelegt sein. Beim Öffnen einer E-Mail können beispielsweise Java Applets heruntergeladen und aus-geführt werden, ohne eine lokale Kopie abzulegen. Bei Windows-Rechnern mit ActiveX Con-trols kommt hinzu, dass ActiveX-Komponenten Zugriff auf die gesamte Windows- und Sys-tem-Funktionalität ermöglichen.

Folgende Aspekte der Grundkonfiguration tragen zur Abwehr von Gefährdungen durch Kompro-mittierung des E-Mail-Clients über Aktive Inhalte bei:

– Deaktivieren der Ausführung von Aktiven Inhalten,

– Lesen von E-Mails nur im Textformat,

Ausschalten der Anzeige von HTML-E-Mails. Sofern erforderlich, Umwandlung von HTML in „einfaches“ HTML.

Restrisiko: Fehlerhafte Implementierung der Umwandlung von HTML in „einfa-ches“ HTML.

5.1.6 HTML-E-Mail: IFrames


Schwachstelle: Die Schwachstelle bei der Verwendung von HTML-E-Mails.



Ein Angreifer benutzt (nicht sichtbare) IFrames innerhalb einer E-Mail mit einem Verweis auf eine (manipulierte oder mit Schadpro-grammen verseuchte) Webseite.

Bei IFrames handelt es sich um HTML-Elemente, die zur Strukturierung von Webseiten ver-wendet werden. Sie werden genutzt, um Webinhalte als eigenständige Dokumente in einem Frame des Browsers anzuzeigen. Es ist damit möglich ein HTML-Dokument in ein anderes HTML-Dokument einzubinden,beispielsweise über einen Verweis (üblicherweise eine URL) zu einer Datei (z. B. <iframe src=http://beispiel.de/frame.html>). Bei HTML-E-Mails können so mittels IFrames Daten und auch Schadprogrammen dynamisch geladen und ggf. ausgeführt werden.

Folgender Aspekt der Grundkonfiguration trägt zur Abwehr von Gefährdungen durch das Ausfüh-ren von Schadprogrammen über IFrames bei:

– Ausschalten der Anzeige von HTML-E-Mails. Sofern erforderlich, Umwandlung von HTML in „einfaches“ HTML.


5.1.7 HTML-E-Mail: OBJECT-Tags


Schwachstelle: OBJECT-Tags erlauben das Ausführen lokal gespeicherter Dateien.

Ein OBJECT-Tag fügt ein Objekt, wie z. B. ActiveX-Komponenten und Applets, in ein HTML-Dokument ein und stellt Informationen zur Ausführung des Objektes zur Verfügung. Beispielsweise können die Speicheradresse, der Typ des auszuführenden Objektes und der Speicherort angegeben werden.

In HTML-E-Mails können daher über OBJECT-Tags Schadprogramme ausgeführt werden. Außerdem ist es mittels OBJECT-Tags möglich, lokal gespeicherte Dateien auszuführen. Allerdings können nur (Schad-)Programme ausgeführt werden, die sich schon auf dem Client befinden.

Folgender Aspekt der Grundkonfiguration trägt zur Abwehr von Gefährdungen durch das Ausfüh-ren von Schadprogrammen über OBJECT-Tags bei:

– Ausschalten der Anzeige von HTML-E-Mails. Sofern erforderlich, Umwandlung von HTML in „einfaches“ HTML.




5.1.8 Exploits


Schwachstelle: Ein Angreifer kann Software-Schwachstellen oder auch Software-Feh-ler ausnutzen.

Software-Schwachstellen oder Software-Fehler sind Defekte in einem Programm, die zu uner-warteten Zuständen führen können. Sie sind meist durch Programmier- oder Designfehler ver-ursacht. Exploits sind spezielle Programme oder Befehlssequenzen, die diese Schwachstellen ausnutzen. Man unterscheidet hierbei zwischen Local Exploits, Remote Exploits, DoS-Exploits und Zero-Day-Exploits.

Ein Local Exploit benötigt einen lokalen Zugang zum System. Üblicherweise zielt er darauf ab, eingeschränkte Nutzerrechte zu erweitern und Systemrechte zu erhalten (engl. Privilege Escalation), sowie das Durchführen von DoS-Angriffen. E-Mails können für Local Exploits benutzt werden, indem E-Mails mit Schadprogrammen an einen Benutzer verschickt werden und der Benutzer diese mit lokalen Rechten ausführt.

Ein Remote Exploit ist ein Angriff, der eine Schwachstelle auf ein System über ein Netz aus-nutzt ohne dass der Angreifer vorher Zugriff auf das System haben muss. Remote Exploits sind im E-Mail-Bereich nicht relevant, weil diese Art Exploits nicht über E-Mails ausgenutzt werden können.

DoS-Exploits können die betroffene Anwendung überlasten, führen allerdings keinen fremden Programmcode aus und beinhalten keine Eskalation von Privilegien. Für E-Mail-Clients sind DoS-Angriffe relevant, weil ein DoS-Angriff z. B. durch das massenhafte Versenden von E-Mails ausgeführt werden kann.

Ein Exploit, der vor oder am selben Tag erscheint, an dem die Sicherheitslücke allgemein bekannt wird, nennt man Zero-Day-Exploit. Die besondere Gefahr besteht darin, dass kaum ein Hersteller bzw. Entwickler zeitlich in der Lage ist, die Sicherheitslücke umfassend durch einen Patch zu schließen. Die Gefährdung kann nur durch eine Übergangslösung verringert werden, indem z. B. Dienste auf einem System ausgeschaltet oder Dateianhänge blockiert werden. Diese Art Angriffe sind im E-Mail-Client Umfeld relevant, weil ein E-Mail-Client kompromittiert werden kann, indem ein Benutzer eine Datei öffnet, die einen Zero-Day-Angriff auslöst.

Folgende Grundvorgaben für einen sicheren Betrieb tragen zur Abwehr von Gefährdungen durch Exploits bei:

– Installieren aktueller Patches (Betriebssystem, Anwendungen),

– Blacklisting ausführbarer Dateianhänge,

– Überwachen von Exploits und eine Implementierung von Prozeduren wie auf Exploits zu reagie-ren ist,

– Gezieltes Blockieren von Anhängen zur Verhinderung von Exploits.Restrisiko: Für normalen Schutzbedarf werden Exploits nur innerhalb der gere-

gelten Bürozeiten überwacht. Es besteht daher ein Restrisiko durch Exploits, die außerhalb dieser Zeiten erfolgen. Es sind Angriffe durch



Zero-Day-Exploits möglich, die nicht durch das Blacklisting ausführ-barer Dateianhänge blockiert werden.

Ein weiteres Restrisiko besteht durch Exploits von Anwendungen, die nicht vom Unternehmen genehmigt sind – meistens vom Nutzer selbst installierten Anwendungen – und damit nicht überwacht werden.

Variante 5.1.8 A Hoher Schutzbedarf: Nur gepatchte Systeme dürfen in das lokale Netz einge-bunden werden



Damit nur gepatchte Systeme in das lokale Netz eingebunden werden, empfiehlt sich das sogenannte Network Admission Control (NAC). Bei dieser Technik werden Systeme während der Authentisierungsphase dahingehend geprüft, ob die aktuellen Patches eingespielt sind. Wenn beispielsweise auf dem Betriebssystem des Clients nicht das neueste Sicherheits-Update installiert ist, wird das System unter Quaran-täne gestellt und mit aktuellen Updates versorgt, so dass das System wieder den aktuellen Stand erreicht.

Restrisiko: Es sind Angriffe durch Zero-Day-Exploits möglich, die nicht durch das Blacklisting ausführbarer Dateianhänge blockiert werden.

Umsetzungsaufwand: Es bestehen mittlere bis hohe Anschaffungskosten für ein System zur Überwachung der E-Mail-Client-Rechner. Ggf. müssen Netzkompo-nenten ausgetauscht werden, damit E-Mail-Client-Rechnern der Zutritt zum Netz verweigert wird. Demzufolge ergeben sich auch mitt-lere bis hohe Realisierungs- und Betriebsaufwände.

Variante 5.1.8 B Hoher Schutzbedarf: „12x7“-Überwachung der Exploits und gezieltes Blo-ckieren von Anhängen


Phase im Ablaufplan: Betrieb

Es ist nicht vorher zu sagen, wann ein Exploit bekannt wird. Für normalen Schutz-bedarf werden Exploits nur innerhalb der geregelten Bürozeiten überwacht. Es besteht ein Risiko durch Exploits, die außerhalb der geregelten Bürozeiten stattfin-den. Für hohen Schutzbedarf empfiehlt sich eine „12x7“-Überwachung der Exploits. Bei einer Gefährdung sollten gezielt Anhänge blockiert werden .

Restrisiko: Exploits, die außerhalb der „12x7“-Überwachung stattfinden, können die IT-Infrastruktur gefährden. Es sind Angriffe durch Zero-Day-Exploits möglich, die nicht durch das Blacklisting ausführbarer Datei-anhänge blockiert werden.

Umsetzungsaufwand: Es entstehen hohe Betriebsaufwände für Personal, um Exploits zu überwachen und ggf. Maßnahmen einzuleiten.



5.2 Gefährdungen durch Täuschen, Fälschen und Betrügen

In der Informationstechnik stellen Versuche zur Verschleierung der eigenen Identität und zum Fäl-schen übertragener Daten eine Gefährdung der Integrität und Authentizität dar. Beim E-Mail-Spoof-ing versucht der Angreifer durch das Ändern der Absenderadresse oder der Header-Daten dem Empfänger einen anderen Absender vorzutäuschen. Auch der E-Mail-Body kann von einen Angrei-fer geändert werden. Wenn keine zusätzlichen Maßnahmen getroffen sind (wie z. B. eine digitale Signatur), werden Spoofing-Angriffe nicht bemerkt.

5.2.1 Trojanische Pferde

Bedrohung: Einschleusen von Schadprogrammen durch Täuschung der Benutzer

Schwachstelle: Schwachstellen können in der technischen Realisierung (z. B. eine Buffer-Overflow-Schwachstelle in der Software), bei Konfigurations-fehlern (z. B. fehlende Aktualisierung der Virenschutz-Signaturen, Erlauben von Aktiven Inhalten) und im Betrieb durch Verhaltensfehler (z. B. Öffnen einer Dateianlage durch einen Benutzer) entstehen.

Ein Trojanisches Pferd ist ein Programm mit einer verdeckten, nicht dokumentierten Funktion oder Wirkung. Trojanische Pferde sind als nützliche Programme getarnt und installieren Schadprogramme wie z. B. Backdoors oder Tastatur-Rekorder. Die Verbreitung findet übli-cherweise nicht automatisch wie bei einem Wurm statt, sondern setzt auf die Verleitung der Benutzer, das Programm zu installieren. Verbreitungsmechanismen sind z. B. E-Mail oder Tauschbörsen. In der Regel können Trojanische Pferde mittels Virenschutzprogrammen ermittelt und entfernt bzw. unschädlich gemacht werden.

Ein bekanntes Trojanisches Pferd ist der Storm Worm, der sich per E-Mail verbreitet. Dieses Schadprogramm erlaubt die unerwünschte Fernwartung eines Windows-PC über das Internet. Es können Daten gelesen und geschrieben sowie Programme ausgeführt werden. Der Empfän-ger einer E-Mail (mit dem Trojanischen Pferd als Anhang) wird veranlasst, den Anhang zu öffnen. Wird das Trojanische Pferd gestartet und besteht eine Netzverbindung, so kann ein Angreifer die Fernwartungsfunktion des Programms für den Benutzer unbemerkt ausführen.

Über Schadprogramme werden Rechner in Bots18 verwandelt und in einem Netz (Bot-Netz) verknüpft. Betreiber illegaler Bot-Netze installieren die Bots ohne Wissen der Inhaber vom Computern und nutzen sie für ihre Zwecke beispielsweise für DoS-Attacken, Phishing oder auch Spam-Mails.

Grundsätzlich tragen alle in den Abschnitten 5.1.1 (Computer-Viren und Würmer) und 5.1.2 (Com-puter-Viren und Würmer in verschlüsselten E-Mails) beschriebenen Empfehlungen bezüglich der Grundkonfiguration und der Grundvorgaben auch zur Abwehr von Trojanischen Pferden bei.

Restrisiko: Bezüglich dieser Gefährdung treffen die in den Abschnitten 5.1.1 (Computer-Viren und Würmer) und 5.1.2 (Computer-Viren und Wür-mer in verschlüsselten E-Mails) beschrieben Restrisiken zu.

18 Bot oder auch Robot ist eine Bezeichnung für ein kompromittiertes System, das über ein Kommunikationskanal ferngesteuert werden kann.



5.2.2 Fälschen von Header/Envelope-Daten (Spoofing)

Bedrohung: Täuschen oder Betrügen der Empfänger.

Schwachstelle: Die Schwachstelle ist eine konzeptionelle Schwachstelle des SMTP-Protokolls. Das SMTP-Protokoll bietet keine Möglichkeit, die Header/Envelope-Daten zu authentisieren. Damit sind die Header/Envelope-Daten vom Angreifer beliebig fälschbar.

Beim Versand von E-Mails können falsche Header/Envelope-Daten angegeben werden. Ein Beispiel ist die Fälschung des Absenders. Bei der Weiterleitung von SMTP-basierender E-Mail wird meist nicht überprüft, von welchem Absender die Nachricht stammt, sondern nur, wer der Empfänger der Nachricht sein soll. Darüber hinaus erlauben viele E-Mail-Clients das Eintragen beliebiger Absenderangaben. Schäden können entstehen, wenn der Empfänger die darin enthaltenen Informationen als authentisch und verbindlich ansieht. Aber auch andere Attribute sind beliebig fälschbar. So wird z. B. die „Received From:“-Angabe gefälscht, damit nicht mehr nachzuvollziehen ist, über welche E-Mail-Server die E-Mail geschickt wurde. Des-halb kann nur auf die „Received From:“-Angaben von eigenen E-Mail-Servern vertraut wer-den. Auch bei Lesebestätigungen können Probleme bei der Authentizität auftreten. Wenn keine zusätzlichen Schutzmaßnahmen getroffen werden, sind die Inhalte einer Lesebestäti-gung beliebig fälschbar.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr der Fälschung von Header/Envelope-Daten bei:

– Benutzung von S/MIME- und OpenPGP-Signaturen zur Authentizitätsprüfung und

– Einsatz einer Virtuellen Poststelle.

Restrisiko: Keine, sofern E-Mails mittels S/MIME, PGP oder VPS signiert wer-den.

5.2.3 Manipulation des Absenderfeldes einer Nachricht (Spoofing)

Bedrohung: Vortäuschen einer falschen Identität

Schwachstelle: Diese Schwachstelle entsteht durch die Anzeige der Beschreibung im Feld „From”. Diese Beschreibung kann beliebig gefälscht werden.

Neben dem Fälschen der Header/Envelope-Daten, kann ein Angreifer auch die Beschreibung des Absenderfeldes manipulieren. Der Header könnte z. B. so aussehen: From: „Geschäfts-führung“ <[email protected]>. Viele E-Mail-Clients zeigen dem Benutzer nur die Beschreibung des „From”-Feldes an, jedoch nicht zusätzlich die E-Mail-Adresse. Damit kann ein externer Angreifer vortäuschen, dass die E-Mail von einem internen vertrauenswürdigen Absender kommt. Ein Benutzer, der über die Identität seines Kommunikationspartners getäuscht wurde, kann leicht dazu gebracht werden schutzbedürftige Informationen zu offen-baren.

Serverseitig kann der E-Mail-Server so konfiguriert werden, dass die Beschreibung des Absenderfeldes bei aus dem Internet eingehenden E-Mails gelöscht wird. In diesem Fall wird



dann nur die E-Mail Adresse angezeigt. Siehe Studie „Sicherer Betrieb von E-Mail-Servern“ [ISi-Mail-Server].

Folgende Aspekte der Grundarchitektur tragen zur Abwehr von Spoofing mittels der Manipulation des Absenderfeldes bei:

– Benutzung von S/MIME- und OpenPGP-Signaturen zur Authentizitätsprüfung und

– Einsatz einer Virtuelle Poststelle.

Folgender Aspekt der Grundkonfiguration trägt zur Abwehr von Spoofing mittels der Manipulation des Absenderfeldes bei:

– Sofern konfigurierbar, sollte bei der Anzeige des Feldes „From“ zusätzlich zur Beschreibung die E-Mail-Adresse angezeigt werden.

Restrisiko: Keine, sofern E-Mails mittels S/MIME, PGP oder VPS signiert wer-den.

5.2.4 Fälschen von E-Mail-Inhalten (Spoofing)

Bedrohung: Verlust der Integrität oder Authentizität von E-Mail-Inhalten, während des Transports oder auf dem E-Mail-Client.

Schwachstelle: Schwachstellen können in der Konzeption (z. B. unverschlüsselte Speicherung von E-Mails), in der technischen Realisierung (z. B. feh-lende Zugriffskontrolle auf den E-Mail-Client), durch Konfigurations-fehler (z. B. keine Verschlüsselung des Datentransports zwischen Cli-ent und Server) oder durch Verhaltensfehler im Betrieb (z. B. Miss-brauch von Zugriffsrechten) auftreten.

E-Mail-Inhalte können auf vielfältige Weise manipuliert werden. Einerseits können sie während des Transports geändert werden. Ein Angreifer kann z. B. die Datenpakete zwischen E-Mail-Cli-ent und E-Mail-Server auf seinen eigenen Rechner umleiten, die E-Mail-Inhalte ändern und wie-der weiterleiten.

Anderseits können E-Mail-Inhalte lokal auf dem E-Mail-Client oder dem E-Mail-Server geän-dert werden. Wenn E-Mails nicht signiert wurden (z. B. mittels S/MIME, OpenPGP), kann diese Änderung nachträglich nicht eindeutig festgestellt werden.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr von Fälschungen der E-Mail-Inhalten bei:

– Verwendung der Protokolle POP3S, IMAPS oder SMTPS,

– Benutzung von S/MIME und OpenPGP und

– Einsatz der Virtuellen Poststelle.

Restrisiko: POP3S, IMAPS oder SMTPS werden nur zwischen E-Mail-Client und E-Mail-Server eingesetzt. E-Mails, die nicht mittels S/MIME oder OpenPGP signiert wurden, können nachträglich manipuliert werden.



Variante 5.2.4 A Hoher Schutzbedarf: Host-basiertes Intrusion Detection System

Zur Ermittlung von Manipulation von Daten oder Software kann Variante 5.1.1 A (Host-basiertes IDS) eingesetzt werden.

Variante 5.2.4 B Hoher Schutzbedarf: Verschlüsselung aller E-Mails mittels S/MIME, Open-PGP oder VPS

Anwendungsbereich: hoher Schutzbedarf bezüglich Vertraulichkeit oder Integrität


Um Manipulationen, der auf dem E-Mail-Client gespeicherten E-Mails auszuschlie-ßen, sollten E-Mails grundsätzlich mittels S/MIME oder OpenPGP übertragen und abgespeichert werden. Bei Einsatz einer virtuellen Poststelle (VPS) sollten alle von der VPS weitergeleiteten E-Mails von der VPS per S/MIME oder OpenPGP mit einem Unternehmensschlüssel neu verschlüsselt an das interne Netz weitergeleitet werden.

Restrisiko: Kompromittierung von privaten Schlüsseln zur Verschlüsselung mit-tels OpenPGP oder S/MIME.

Umsetzungsaufwand: Der Realisierungsaufwand wird als mittel eingestuft.

5.2.5 Verschleierung von Dateianhängen (Spoofing)

Bedrohung: Täuschen oder Betrügen der Empfänger, um Schadprogramme auf dem Zielsystem zu installieren.

Schwachstelle: Fehlerhafte Darstellung von Dateianhängen durch den E-Mail-Client als Folge von Softwarefehlern oder falscher Konfiguration.

Die Gefährdung besteht dadurch, dass Dateianhänge bzw. deren Endungen in dem E-Mail-Client dem Benutzer falsch angezeigt werden. Ein Benutzer der meint, dass es sich um einen legitimen (ungefährlichen) Dateianhang handelt, kann so leicht dazu gebracht werden, die Datei zu öffnen. Der Dateianhang kann vom Angreifer mit einem Schadprogramm verseucht sein. So hatte im Januar 2006 der E-Mail-Client Thunderbird eine Schwachstelle, über die durch Manipulation des Headers Content-Type und Verwendung sehr langer Dateinamen mit Leerzeichen die Darstellung des Dateianhangs in Thunderbird änderbar war. Über diese Schwachstelle war es möglich, beispielsweise den Dateianhang pdf.com mit einem pdf-Icon darzustellen. Durch fehlerhafte Konfiguration des E-Mail-Clients ist es möglich, dass die Dateiendungen ausgeblendet werden und der Benutzer damit den richtigen Dateityp nicht erkennt.

Folgender Aspekt der Grundarchitektur trägt zur Abwehr von Gefährdungen durch Verschleierung von Dateianhängen bei:

– Ausschalten des automatischen Öffnens oder Speicherns von Dateien,

– Anzeigen aller Dateiendungen bei Anhängen.

Restrisiko: Es besteht das Restrisiko, dass der Benutzer die Dateiendung trotzdem falsch interpretiert und daher die Datei öffnet.



5.2.6 Hoax

Bedrohung: Verbreitung von Panik, Fehlinformationen über Schadprogramme oder sonstige IT-Probleme.

Schwachstelle: Deutung der Informationen durch den Benutzer.

Ein Hoax (englisch für Streich, Trick, falscher Alarm) ist eine Nachricht, die eine Warnung vor neuen spektakulären Computer-Viren oder anderen IT-Problemen enthält und Panik ver-breiten soll, die aber nicht auf realen technischen Fakten basiert. Meist werden solche Nach-richten über E-Mails verbreitet. Ein Hoax wird von Spam-Filtern erkannt, sofern dafür eine entsprechende Signatur vorhanden ist.

Folgender Aspekt der Grundarchitektur trägt zur Abwehr von Gefährdungen durch Hoaxes bei:

– In der E-Mail-Richtlinie werden die Verhaltensregeln bei Auftreten eines Hoax festgelegt.– Einsatz eines Spam-Filters

Restrisiko: Die E-Mail-Richtlinie und damit die Verhaltensregeln bei Hoax müs-sen allen Mitarbeitern bekannt sein.

5.2.7 Nichtanerkennung einer Nachricht

Bedrohung: Im Falle einer Meinungsverschiedenheit kann der Empfänger den Empfang oder der Sender den Versand einer Nachricht abstreiten.

Schwachstelle: Keines der E-Mail-Protokolle ist für den Nachweis über Versand oder Empfang einer Nachricht konzipiert, so dass Versender den Versand oder Empfänger den Empfang einer E-Mail abstreiten können.

Bei jeder Art von Kommunikation kann ein Kommunikationsteilnehmer den Nachrichtenemp-fang abstreiten (Repudiation of Receipt). SMTP bietet die Möglichkeit einer Delivery Status Notification [RFC 3461]. Der sendende E-Mail-Server erhält die Notification nur, wenn die E-Mail nicht beim E-Mail-Server des Empfängers abgeliefert werden konnte. Eine fehlende Notification bedeutet hingegen nicht zwingend, dass die E-Mail vom Empfänger empfangen bzw. gelesen worden ist. Ebenso kann es passieren, dass ein Kommunikationsteilnehmer den Nachrichtenversand leugnet, z. B. eine getätigte Bestellung abstreitet (Repudiation of Origin). Auch auf Lese- oder Empfangsbestätigungen kann ohne zusätzliche Absicherung nicht ver-traut werden. E-Mail-Clients können nämlich so eingestellt sein, dass eine Lese- oder Emp-fangsbestätigung automatisch verschickt wird. Ferner sind diese Nachrichten beliebig fälsch-bar.

Folgende Grundvorgabe für den sicheren Betrieb aus [ISi-Mail-Server] trägt zur Abwehr bei:

– Protokollierung der erfolgreichen/fehlgeschlagenen Zustellung auf dem ALG/SMTP-Proxy.

Restrisiko: Es besteht das Restrisiko, dass die E-Mail zwar an den zuständigen E-Mail-Server zugestellt wurde, die E-Mail danach jedoch im Unterneh-men nicht dem Empfänger zugestellt wurde. Es wird daher empfohlen, den Empfänger aufzufordern manuell eine E-Mail mit einer Emp-fangsbestätigung zurückzusenden.



5.3 Gefährdungen durch Entwenden und Ausspähen

Da der E-Mail-Dienst auch für vertrauliche Geschäftsangelegenheiten genutzt wird, ist die Sicher-stellung der Vertraulichkeit sehr wichtig. Der folgende Abschnitt beschreibt Angriffe, die das Ent-wenden oder Ausspähen von internen oder vertraulichen Informationen ermöglichen.

5.3.1 Spyware/Adware

Bedrohung: Spyware: Ausspähen von Benutzerinformation.

Adware: Gezieltes Weiterleiten des Benutzers zu bestimmten (kom-merziellen) Webseiten.

Schwachstellen: Schwachstellen entstehen,

– wenn im E-Mail-Client das automatische Öffnen oder Ausführen von Dateianhängen erlaubt wird,

– wenn im E-Mail-Client das automatische Herunterladen von Dateien erlaubt wird,

– wenn uneingeschränkte Benutzerrechte konfiguriert sind, die eine Installation von Spyware/Adware ermöglichen und

– durch Bedienungsfehler des Benutzers in der Betriebsphase.

Als Spyware werden Programme bezeichnet, die heimlich Informationen über einen Benutzer bzw. die Nutzung eines Rechners sammeln und an den Urheber der Spyware weiterleiten. Die Merkmale dieser Programme sind: Diebstahl persönlicher Informationen (z. B. Kreditkarten-nummer) und das Überwachen des Benutzerverhaltens im Netz.

Fälschlicher Weise wird Adware oftmals auch als Spyware bezeichnet. Bei Adware handelt es sich um Software, die zusätzlich zur eigentlichen Funktionalität Werbung einblendet. Die Merkmale dieser Programme sind: Unerwünschte Pop-Up-Fenster und das Weiterleiten des Benutzers zu bestimmten kommerziellen Webseiten.

Spyware/Adware verbreitet sich typischerweise nicht automatisch auf andere Systeme, son-dern wird in der Regel durch den Benutzer installiert.

– Grundsätzlich tragen alle in den Abschnitten 5.1.1 (Computer-Viren und Würmer) und 5.1.2 (Computer-Viren und Würmer in verschlüsselten E-Mails) beschriebenen Empfehlungen bezüg-lich der Grundkonfiguration und der Grundvorgaben auch zur Abwehr von Spyware/Adware bei.

Restrisiko: Bezüglich dieser Gefährdung treffen die in den Abschnitten 5.1.1 (Computer-Viren und Würmer) und 5.1.2 (Computer-Viren und Wür-mer in verschlüsselten E-Mails) beschrieben Restrisiken zu. Bei Ad-ware besteht das zusätzliche Risiko, darin, dass es für den Benutzer schwierig ist zu erkennen, ob die Adware Schadfunktionen enthält.



5.3.2 Phishing: Ausspähen personenbezogener oder vertraulicher Daten

Bedrohung: Ausspähen personenbezogener oder vertraulicher Daten.

Schwachstelle: Eine Schwachstelle entsteht durch die E-Mail-Client-Software, falls diese nur den Hyperlink, nicht aber die dahinter verborgene URL anzeigt. (Verschiedene E-Mail-Client-Software-Produkte bieten die Möglichkeit, das Produkt so zu konfigurieren, dass die tatsächliche URL angezeigt wird.)

Mit Phishing werden Versuche eines Angreifers bezeichnet, über gefälschte WWW-Adressen an Daten eines Internet-Benutzers zu gelangen. Ziel ist das Ausspähen oder Ausnutzen von Passwörtern, Kreditkartendaten oder anderen vertraulichen Informationen. Vom Angreifer können verschiedene Methoden eingesetzt werden.

– Die Benutzung des @-Zeichen in der URL (z. B. http://[email protected]).

– Die Benutzung von ähnlichen Namen (z. B. http://www.meinebank-support.de).

– Die Weiterleitung zur Webseite der Angreifer über Bilder (HTML Image Mapping).

– Die Benutzung von URL-Redirects (z. B. http://www.meinebank.de?url=angreifer.de).

Durch die Verschleierung des tatsächlichen Links in HTML-E-Mails wird der Benutzer in der Überzeugung eine vertrauenswürdige Webseite zu besuchen, zur Webseite des Angreifers weitergeleitet.

Zusätzlich entstehen Probleme durch den Missbrauch von Internationalized Domain Names (IDN). Bei Phishing-Angriffen auf Basis von IDN nutzen Betrüger die Ähnlichkeit zwischen lateinischen ASCII-basierten Zeichen (a-z oder 0-9) und internationalen Zeichen, die außer-halb des ASCII-Bereichs liegen. Ein Beispiel ist das kyrillische Zeichen 'a', das optisch iden-tisch mit dem ASCII-Zeichen 'a' ist. Ein Angreifer kann beispielsweise eine E-Mail mit einem URL www.meinebank.de zum Opfer verschicken. In der Anzeige ist kein Unterschied zu der dem Benutzer vertrauten Webseite www.meinebank.de zu sehen.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr von Phishing-Angriffen bei:

– Integritäts-, Authentizitäts-Prüfungen bei Verwendung von S/MIME, OpenPGP und Virtueller Poststelle,

– Einsetzen von Anti-Phishing-Software.

Folgende Aspekte der Grundkonfiguration tragen zur Abwehr von Phishing-Angriffen bei:

– Anzeigen von E-Mails im Textformat, um das Verschleiern von Phishing-URLs aufzuzeigen.

Restrisiko: Gezielte Phishing-Angriffe, die beim Anti-Phishing-Software-Herstel-ler unbekannt sind, können nicht ermittelt werden.

Anti-Phishing-Software, die URLs in E-Mails prüfen, haben Probleme mit Weiterleitungen (URL-Redirects).



5.3.3 E-Mail-Protokolle ohne Verschlüsselung

Bedrohung: Ausspähen vertraulicher oder personenbezogener Daten

Schwachstelle: Die Schwachstelle entsteht, wenn bestimmte E-Mail-Protokollvarian-ten (z.B. proprietäre E-Mail-Protokolle) ohne Verschlüsselung konzi-piert sind.

Ein Angreifer kann an verschiedenen Stellen während der E-Mail-Kommunikation Benutzer-daten ausspähen:

– Im internen Netz durch Lesen unverschlüsselter Kommunikation.

– Im Internet durch Lesen unverschlüsselter Kommunikation (z. B. keine verschlüsselte Kommunikation zwischen sendendem und empfangendem E-Mail-Server).

Bei der Verwendung von POP, IMAP und SMTP über TLS/SSL tritt diese Schwachstelle zwischen E-Mail-Client und E-Mail-Server nicht auf.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr des Ausspähens von Benutzerdaten bei:

– Benutzen von POP, IMAP und SMTP über TLS/SSL,

– Verwenden von S/MIME- und OpenPGP-Verschlüsselung von E-Mails,

– Einsatz einer Virtuellen Poststelle.

Restrisiko: Die Virtuelle Poststelle bietet keine Ende-zu-Ende-Verschlüsselung. Ohne eine Verschlüsselung des lokalen Netzes oder eine neue Ver-schlüsselung der VPS mittels OpenPGP oder S/MIME können daher Nachrichten im internen Netz ausgespäht werden.

Variante 5.3.3 A Hoher Schutzbedarf: Verschlüsselung der Daten über Secure Shell (SSH) mit Portweiterleitung für das verwendete E-Mail-Protokoll

Anwendungsbereich: Hoher Schutzbedarf bezüglich Vertraulichkeit


Mit Secure Shell (SSH) wird sowohl ein Netzprotokoll als auch ein Programm bezeich-net, mit dem eine verschlüsselte Netzverbindung zu einem entfernten Computer herge-stellt werden kann. Die Daten, die zwischen dem E-Mail-Client und dem E-Mail-Server ausgetauscht werden, können mittels SSH verschlüsselt werden. Der Endpunkt der Ver-schlüsselung kann auf dem E-Mail-Server oder auf einem dediziert dafür eingerichteten Server eingerichtet werden. Bevor der E-Mail-Client eine E-Mail herunterladen oder ver-schicken kann, wird zuerst ein SSH-Tunnel aufgebaut, damit die Daten verschlüsselt über das interne Netz verschickt werden.

Restrisiko: Wenn der SSH-Tunnel nicht auf dem E-Mail-Server terminiert wird, ist eine durchgehende Verschlüsselung im internen Netz nicht gewähr-leistet.

Umsetzungsaufwand: Auf allen E-Mail-Clients muss SSH-Software installiert und konfigu-riert werden ebenso wie der SSH-Server. Abhängig von der techni-schen Realisierung (lokale Benutzerdatenbank oder zentrale Benutzer-



datenbank) muss mit einem hohen Aufwand für die Benutzerverwal-tung gerechnet werden.

Variante 5.3.3 B Hoher Schutzbedarf: Verschlüsselung der Daten über ein verschlüsseltes Virtual Private Network (VPN)



Die Daten, die zwischen dem E-Mail-Client und dem E-Mail-Server ausgetauscht werden, können mittels einer VPN-Verbindung verschlüsselt werden. Als VPN-Proto-koll kann beispielsweise IPSec eingesetzt werden. Der E-Mail-Client baut mittels VPN-Client-Software einen VPN-Tunnel zu einem VPN-Server auf. Der VPN-Server wird sinnvollerweise im Netzsegment des internen Mail-Servers platziert.

Restrisiko: Zwischen VPN-Server und dem internen E-Mail-Server erfolgt die Datenübertragung unverschlüsselt.

Umsetzungsaufwand: Auf allen E-Mail-Clients muss VPN-Software installiert und konfigu-riert werden ebenso wie der VPN-Server. Weiterhin muss für den Zugriff auf den VPN-Server eine Verwaltung der Benutzerdaten und der zugeordneten Zertifikate erfolgen.

Variante 5.3.3 C Hoher Schutzbedarf: Verschlüsselung von Verschlusssachen mittels zugelas-sener Produkte



Für den Schutz von eingestuften Verschlusssachen wird der Einsatz von zugelasse-nen Produkten gefordert. Für den Schutz von Verschlusssachen des Geheimhal-tungsgrades VS-NUR FÜR DEN DIENSTGEBRAUCH steht beispielsweise das Produkt „Chiasmus für Windows“ zur Verfügung.

Restrisiko: Ausspähen von Benutzerdaten durch Trojanische Pferde oder Compu-ter-Viren.

Bei Einsatz einer Verschlüsselung mit Ablage des privaten Schlüssels auf dem E-Mail-Client (also Einsatz ohne Chipkarte und sicherer Chipkarten-Leser) besteht das Risiko, dass der private Schlüssel kom-promittiert werden kann (z. B.: Keylogger, temporäre Ablage im Hauptspeicher).

Umsetzungsaufwand: E-Mail-Clients, die Verschlusssachen verarbeiten, müssen mit zusätz-licher Software ausgestattet werden. Diese Software muss konfiguriert und betrieben werden.



5.3.4 Gemeinsame Benutzung eines PCs

Bedrohung: Ausspähen von personenbezogenen oder vertraulichen Daten auf dem lokalen E-Mail-Client.

Schwachstelle: Durch fehlende oder unzureichende Konfiguration des E-Mail-Clients ist der Rechner nicht vor fremdem Zugriff gesichert.

Eine Gefährdung entsteht, wenn ein Rechner von mehreren Benutzern verwendet wird. Fehlende oder unzureichende Einschränkungen der Benutzerrechte ermöglichen den Zugriff auf lokal gespeicherte E-Mails der verschiedenen Benutzer, insbesondere bei Offline-Arbeit bzw. lokaler Speicherung von E-Mail.

Variante 5.3.4 A Hoher Schutzbedarf: Verschlüsselung lokal gespeicherter E-Mail

Anwendungsbereich: hoher Schutzbedarf bezüglich Vertraulichkeit


Für hohen Schutzbedarf wird empfohlen, lokal gespeicherte E-Mails zu verschlüs-seln. Dabei gibt es die Möglichkeit, verschlüsselte Ordner anzulegen oder die ganze Festplatte zu verschlüsseln. Letztere ist vorzuziehen, da keine unverschlüsselten Zwischenablagen entstehen.

Restrisiko: Der Verlust des kryptografischen Schlüssels macht verschlüsselte Objekte unbrauchbar.

Umsetzungsaufwand: Die E-Mail-Clients müssen ggf. zusätzlich mit Software zur Ver-schlüsselung ausgestattet werden. Es muss eine Architektur zur siche-ren Aufbewahrung der kryptografischen Schlüssel (Schlüsselhinterle-gung) entwickelt und betrieben werden, damit die Daten nach Verlust des privaten Schlüssels noch lesbar sind.

5.3.5 Automatisches Weiterleiten von E-Mails

Bedrohung: Ausspähen interner Informationen.

Schwachstelle: Der Benutzer konfiguriert seine E-Mail-Client-Software, so dass (interne oder vertrauliche) Informationen automatisch weitergeleitet werden.

Das (automatische) Weiterleiten von E-Mails durch den Benutzer an z. B. private E-Mail-Adressen kann die Vertraulichkeit der Daten gefährden. Weitergeleitete E-Mails können ver-trauliche Daten enthalten, die das interne Netz nicht verlassen dürfen.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr des Verlustes der Vertraulichkeit durch automatisches Weiterleiten von E-Mails bei:

– In der E-Mail-Richtlinie die automatische Weiterleitung von Nachrichten verbieten.

– Weitere Empfehlungen für das Unterbinden von automatischen Weiterleitungen siehe Studie „Sicherer Betrieb von Mail-Servern“ [ISi-Mail-Server].



Restrisiko: Auf der Benutzer-Ebene (E-Mail-Client) können ausschließlich orga-nisatorische Maßnahmen zur Unterbindung von E-Mail-Weiterleitun-gen realisiert werden. Technische Maßnahmen sind nur auf dem E-Mail-Server umsetzbar.

5.3.6 Web Bugs

Bedrohung: Ausspähen systemspezifischer Informationen.

Schwachstelle: Eine Schwachstelle entsteht, indem die Konfiguration der E-Mail-Cli-ent-Software das automatische Herunterladen von Inline Content (wie z. B. Fotos) erlaubt.

Ein Web Bug ist ein Objekt innerhalb einer E-Mail, mit dem ein Angreifer feststellen kann, ob die E-Mail vom Empfänger gelesen worden ist. Üblicherweise wird dazu ein Verweis auf Inhalte (z. B. Bilder) auf einem externen Server in die E-Mail eingefügt. Beim Anzeigen der E-Mail stellt der E-Mail-Client eine Verbindung zum Server her, so dass der Server weiß, dass die E-Mail-Adresse besteht. Wenn die Daten vom Browser beim Server abgefragt wer-den, kann der Angreifer auch Version und Patch-Level des Clients feststellen.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr des Ausspähens systemspezifischer Informationen durch Web Bugs bei:

– Anzeigen von E-Mails im Textformat,

– Automatisches Nachladen von „Inline Content“ wie Fotos (Web-Bugs) nicht erlauben.

Restrisiko: Durch die Umsetzung der Empfehlungen der Grundarchitektur ist der E-Mail-Client gegen Angriffe mittels Web-Bugs gesichert. Es werden keine weiteren Restrisiken identifiziert.

5.3.7 Automatische Lesebestätigungen

Bedrohung: Ausspähen von internen Informationen.

Schwachstelle: Die Schwachstelle resultiert aus der Konfiguration von automatischen Lesebestätigungen in der E-Mail-Client-Software.

Typischerweise verschickten Spammer massenhaft E-Mails an zufällig generierte E-Mail-Adressen. Mittels automatischer Lesebestätigungen kann ein Angreifer erfahren, ob die zufäl-lig generierten Zieladressen tatsächlich existieren. Automatische Lesebestätigungen können auch Vertraulichkeitsprobleme bei Verteilerlisten verursachen. Der Absender erfährt durch eine Lesebestätigung, welche Personen sich auf der Verteilerliste befinden. Zusätzlich können Header-Daten in der Lesebestätigung vertrauliche Informationen über die interne Netzinfra-struktur preisgeben, aber auch (vertrauliche) unverschlüsselte Daten aus der Originalnachricht enthalten.

Folgender Aspekt der Grundarchitektur trägt zur Abwehr des Ausspähens von internen Informatio-nen durch automatische Lesebestätigungen bei:

– Ausschalten automatischer Lesebestätigungen.



Restrisiko: Durch die Umsetzung der Empfehlungen der Grundarchitektur ist der E-Mail-Client gegen den Verlust der Vertraulichkeit durch automati-sche Lesebestätigungen gesichert. Die Existenz der E-Mail-Adresse kann auch über Delivery Status Notifications abgeleitet werden.

5.3.8 Kompromittierung privater Schlüssel (OpenPGP, S/MIME)

Bedrohung: Kompromittierung des privaten Schlüssels, d. h. die digitale Signatur und die Verschlüsselungder E-Mails sind nicht mehr gesichert.

Schwachstelle: Die Schwachstelle entsteht, wenn veraltete Software verwendet wird.

Bei Einsatz einer Verschlüsselung mit Ablage des privaten Schlüssels auf dem E-Mail-Client (also Einsatz ohne Chipkarte und sicherer Chipkarten-Leser) besteht das Risiko, dass der private Schlüssel kom-promittiert werden kann (z. B.: Keylogger, temporäre Ablage im Hauptspeicher). Außerdem kann beispielsweise, aus Versehen, durch einen Bedienungsfehler der private Schlüssel exportiert werden.

Die Gefährdung entsteht, wenn ein Angreifer z.B. durch Schadprogramme in einen E-Mail-Client-Rechner eindringt und diesen übernimmt. Der Angreifer kann den privaten Schlüssel auslesen und nutzen, wenn dieser nicht zusätzlich gesichert ist.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr der Kompromittierung der privaten Schlüssel (OpenPGP oder S/MIME) bei:

– Schutz der privaten Schlüssels mittels eines Kennwortes,

– Gültigkeit des Schlüssels und der Zertifikate nur für einen bestimmten Zeitraum

– Im Falle einer Kompromittierung: Sperren und Veröffentlichen des zugehörigen Zertifikats in einer Sperrliste (CRL und/oder OCSP).

Restrisiko: Wenn ein privater Schlüssel kompromittiert ist und das zugehörige Zertifikat gesperrt wurde, besteht das Restrisiko, dass andere E-Mail-Clients die Sperrung nicht rechtzeitig feststellen.

Variante 5.3.8 A Hoher Schutzbedarf: Sichere Speicherung privater Schlüssel auf Chipkarten

Anwendungsbereich: hoher Schutzbedarf bezüglich Vertraulichkeit


Für den hohen Schutzbedarf bezüglich der Vertraulichkeit des privaten Schlüssels wird die Speicherung auf einer Chipkarte empfohlen.

Restrisiko: Ein Restrisiko entsteht bei Verlust der Chipkarte oder Diebstahl der Chipkarte einschließlich PIN-Nummer. Ohne Schlüsselhinterlegung ist es nicht mehr möglich, auf die mit dem zugehörigen (öffentlichen) Schlüssel verschlüsselten Dateien zuzugreifen. Ferner besteht das Restrisiko, dass der Angreifer Chipkarte und PIN-Nummer miss-braucht (z. B. zur Erstellung einer digitalen Signatur).

Umsetzungsaufwand: Es ergeben sich mittlere bis hohe Realisierungs- und Betriebsauf-wände für die Chipkarteninfrastuktur.



5.4 Gefährdungen durch Verhindern und Zerstören

Als Denial of Service (DoS) bezeichnet man einen Angriff auf einen Rechner in einem Datennetz mit dem Ziel, einen oder mehrere seiner Dienste arbeitsunfähig zu machen und somit die Verfüg-barkeit von Systemen bewusst zu verringern. Beispielsweise können Software- oder Hardware-Schwächen genutzt werden, um den oder die Rechner des Systems zum Absturz zu bringen. Eine andere Angriffsvariante besteht darin, das System durch mutwillig erzeugte Rechen-, Speicher- oder Kommunikationslasten zu überfordern. Um entsprechende Lasten zu generieren, basieren sol-che Angriffe meist auf einen ferngesteuerten, koordinierten Angriff auf den Zielrechner, ausgehend von einer sehr großen Zahl von Angriffsrechnern; man spricht in diesem Falle von verteilten DoS-Angriffen (Distributed DoS, DDoS).

Ein Schutz gegen DoS-Angriffe ist nur bedingt möglich. Die grundlegende Maßnahme gegen mut-willige Systemabstürze besteht darin, das System in einer Minimalkonfiguration mit möglichst geringer Angriffsfläche zu betreiben und die aktuellen Korrekturen (Patches) der Systemhersteller unverzüglich einzuspielen, um bekannt gewordene Schwachstellen zu eliminieren.

Üblicherweise sind (D)DoS-Angriffe auf E-Mail-Server-Komponenten und nicht auf E-Mail-Cli-ents gerichtet. Der Grund hierfür ist, dass ein Angriff auf einen E-Mail-Server viel größeren Scha-den anrichtet als ein Angriff auf einen E-Mail-Client. Durch einen erfolgreichen (D)DoS-Angriff auf einen E-Mail-Server haben alle E-Mail-Clients der Domäne keine Verbindung mehr zum E-Mail-Server.

Spezifische (D)DoS-Angriffe auf E-Mail-Server werden in [ISi-Mail-Server] beschrieben.

5.4.1 Spam

Bedrohung: Einschränkung der Verfügbarkeit durch Eingang großer Mengen uner-wünschter E-Mails.

Schwachstelle: Die Schwachstelle entsteht durch Fehler bei der Konzeption (z. B. kein adäquater Spamfilter), durch Fehler in der technischen Realisie-rung (z. B. kein Spamfilter auf dem E-Mail-Client), durch Konfigura-tionsfehler (z. B. Fehler bei der Konfiguration des statistischen Spam-filters) und durch Verhaltensfehler im Betrieb (z. B. keine Aktualisie-rung des statistischen Spamfilters).

Spam wird definiert als jede Form von unerwünschter E-Mail. Im englischen Sprachraum wird Spam auch als Unsolicited Bulk E-Mail (UBE) gekennzeichnet, was unverlangte Mas-senmail bedeutet. Wenn Spam kommerzielle Werbung enthält, wird dies in englisch auch als Unsolicited Commercial E-Mail (UCE) definiert. Angreifer verwenden oft gefälschte Absen-deradressen und verschicken z. B. E-Mails an per Zufall generierte Empfängeradressen. Der empfangende E-Mail-Server verschickt eine Fehlermeldung (bounce) zur gefälschten Absen-deradresse (kollateraler Spam). Spam-E-Mails können auch mit Schadprogrammen verseucht sein oder werden vom Angreifer benutzt, um Phishing-Angriffe zu starten. Auch Kettenbriefe und Hoaxes können als Spam bezeichnet werden.

Zum Versenden von Spam benutzen Angreifer verschiedene Techniken. Häufig werden offene E-Mail-Relays (Open Relays) oder offene Proxys benutzt. Mittels dieser Systeme ist es



möglich, ohne Authentisierung E-Mails an beliebige Empfänger zu schicken. Zusätzlich kön-nen aber auch unsichere Skripte auf einem Webserver, Bot-Netze und Zombie-PCs19 für die Verbreitung von Spam benutzt werden.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr von Spam bei:

– Integritäts-, Authentizitäts-Prüfungen bei Verwendung von S/MIME, OpenPGP und Virtueller Poststelle,

– Statistische Inhaltsanalyse,

– Heuristische Inhaltsanalyse.

Restrisiko: Ein Restrisiko entsteht durch E-Mails, die versehentlich als Spam erkannt (false positives) und durch Spam-E-Mails, die nicht als Spam erkannt werden (false negatives).

5.4.2 In Anhängen versteckter Spam

Bedrohung: Eingang großer Mengen unerwünschter E-Mails.

Schwachstelle: Die Schwachstelle entsteht, wenn in der Realisierung keine Pro-gramme zur Ermittlung von in Anhängen verstecktem Spam auf dem E-Mail-Client installiert sind oder wenn neue Methoden das Umgehen der Spam-Überprüfungen ermöglichen.

Spammer suchen aktiv nach Möglichkeiten, Spam-Filter zu umgehen. Durch Verstecken der Spam-Nachrichten in Anhängen wird versucht, die Spam-Filter zu umgehen.

Es können Sicherheitsprobleme entstehen, indem Spam den Benutzer erreicht und den Benut-zer anreizt, personenbezogene oder vertrauliche Daten herauszugeben.

Vor einigen Jahren versuchten Spammer, unerwünschte Inhalte in Bildern zu verstecken. Die Anti-Spam-Software-Hersteller haben daraufhin ihre Spam-Filter-Techniken angepasst und neue Methoden entwickelt (z. B. OCR20-Scanning), um in Bildern versteckte Spam zu ermit-teln. Die Spammer haben dann Methoden entwickelt, die die OCR-Ermittlung aktiv umgeht. Dazu werden z. B. CAPTCHA21-Methoden eingesetzt. Abbildung 5.2 stellt beispielhaft ein CAPTCHA-Bild dar.

Die Aufgaben von CAPTCHAs (meist Texte) sind für Menschen leicht, jedoch von Compu-tern (Spam-Filtern) schwierig zu lösen. CAPTCHA-Methoden wurden ursprünglich entwi-ckelt, um Spam zu vermeiden. Mittels CAPTCHA ist es z. B. sehr viel schwieriger geworden, automatisch E-Mail-Adressen zu registrieren, um Spam zu verschicken.

19 Am Internet angeschlossene Computer, die durch Würmer, Viren, Trojanische Pferde, direkte Angriffe oder ähnli-ches unter die Kontrolle eines Angreifers gebracht worden sind, werden als Zombies oder Drohnen bezeichnet.

20 Optical Character Recognition21 CAPTCHA steht für Completely Automated Public Turing test to tell Computers and Humans Apart



Folgende Aspekte der Grundarchitektur tragen zur Abwehr von in Anhängen verstecktem Spam bei:

– Analyse von verschiedenen Dateiformaten auf Spam (z. B. pdf, xls, rtf, usw.).

Restrisiko: Inhaltsanalyse von verschiedenen Dateiformaten ist ressourcenintensiv und kann zu einem DoS führen. Ein weiteres Restrisiko entsteht durch E-Mails, die versehentlich als Spam erkannt (false positives) und durch Spam-E-Mails, die nicht als Spam erkannt werden (false negat-ives).

5.4.3 Joe-Job-Angriffe

Bedrohung: (Gezieltes) Fälschen von E-Mails zur Rufschädigung,

Belastung/Überlastung der E-Mail-Infrastruktur.

Schwachstelle: Das SMTP-Protokoll ist so konzipiert, dass die Absenderadresse fälschbar ist.

Ein Joe-Job-Angriff ist ein Spam-Angriff, bei dem mittels gefälschter Absenderadresse dem Ruf eines Individuums oder auch einer Firma geschadet oder ein DoS-Angriff ausgeführt.

Ein Angreifer nutzt die leichte Fälschbarkeit von E-Mails dazu, um Spam in fremdem Namen zu verschicken, in der Erwartung, dass viele Empfänger sich beim vermeintlichen Absender oder dessen Firma beschweren. Dadurch können Firmen auch auf Spam-Blacklists eingetra-gen werden, was die E-Mail-Erreichbarkeit stark einschränken kann.

Joe-Job-E-Mails können auch Schadprogramme enthalten.

Folgende Aspekte der Grundkonfiguration tragen zur Abwehr von Joe-Job-Angriffen bei:

– Verwenden von S/MIME oder OpenPGP,

– Einsetzen einer Virtuellen Poststelle.

Weitere Empfehlungen werden in der Studie „Sicherer Betrieb von E-Mail-Servern“ [ISi-Mail-Server] erörtert.

Restrisiko: E-Mails ohne digitale Signatur sind weiterhin nicht vertrauenswürdig.



5.4.4 Ausgehende DoS-Angriffe

Bedrohung: Überlastung eigener und/oder fremder E-Mail-Systeme,

Rufschädigung der Institution.

Schwachstelle: Die Schwachstelle entsteht durch Zombie-PCs im internen Netz, die zum Verschicken von Spam missbraucht werden.

Interne Systeme können mit Schadprogrammen verseucht sein. Besonders mobile Systeme (z. B. Laptops) sind gefährdet, weil diese auch an „unsichere“ Netze (z. B. direkt ans Internet) angeschlossen werden. Diese Systeme können vom Angreifer benutzt werden, um (D)DoS-Angriffe auszuführen (ausgehender (D)DoS-Angriff).

Folgende Aspekte der Grundarchitektur tragen zur Abwehr von ausgehenden DoS-Angriffen bei:

– Einsatz eines Virenschutzprogramms, sowie

– Einsatz einer Personal Firewall auf dem E-Mail-Client.

Folgende Aspekte der Grundkonfiguration tragen zur Abwehr von ausgehenden DoS-Angriffen bei:

– Alle ein- und ausgehenden E-Mails werden inklusive der Dateianhänge mittels Virenschutzpro-gramm auf Schadprogramme untersucht,

Restrisiko: Trotz ständiger Überwachung des Netzes ist es nicht möglich alle aus-gehenden DoS-Angriffe zu ermitteln.

Variante zur Abwehr von Gefährdungen durch ausgehende DoS-Angriffe

Zur Ermittlung von ausgehenden DoS-Angriffen kann Variante 5.1.1 A (Host-basiertes IDS) einge-setzt werden.

5.4.5 Verlust der Verfügbarkeit lokal gespeicherter E-Mails

Bedrohung: Verlust der Verfügbarkeit lokal gespeicherter E-Mails.

Schwachstelle: Die Schwachstelle entsteht durch eine unzureichende Datensicherung oder durch Verhaltensfehler im Betrieb (z. B. durch das unbeabsichtig-te Löschen von E-Mails).

Eine unzureichende Datensicherung kann aus verschiedenen Gründen entstehen:

– Schwachstellen in der Konzeption (z. B. E-Mails werden nur lokal gespeichert und auf dem E-Mail-Server gelöscht),

– Schwachstellen in der technischen Realisierung (z. B. Datensicherung wird nur über einen kurzen Zeitraum aufbewahrt),

– Konfigurationsfehler (z. B. die falschen Ordner werden auf dem E-Mail-Client gesichert).



Werden persönliche E-Mail-Ordner auf dem Benutzersystem abgelegt, muss gewährleistet sein, dass diese von der Datensicherung erfasst werden, um Datenverlust zu vermeiden. Dies gilt auch für Offline-Ordner.

Restrisiko: Durch Konfigurationsfehler kann z. B. bei POP3 die E-Mail beim Her-unterladen von dem E-Mail-Server gelöscht werden.

5.4.6 Verlust der privaten Schlüssel (VPS, OpenPGP oder S/MIME)

Bedrohung: Keine Möglichkeit, verschlüsselte E-Mails zu öffnen oder digital zu signieren.

Schwachstelle: Eine Schwachstelle entsteht, indem in der Realisierung keine Datensi-cherung des privaten Schlüssels des Verschlüsselungszertifikates um-gesetzt worden ist.

Die Gefährdung entsteht, wenn es nicht mehr möglich ist, auf verschlüsselte Daten zuzugrei-fen, da der private Schlüssel durch fehlende Datensicherung nicht mehr wiederherzustellen ist. Dies führt dazu, dass verschlüsselte E-Mails dauerhaft nicht gelesen werden können. Die Erstellung von signierten E-Mails ist temporär nicht möglich, bis ein neuer Schlüssel zur Ver-fügung steht.

Mögliche Gründe für den Verlust des privaten Schlüssels sind der Absturz des PCs, das verse-hentliche Löschen des privaten Schlüssels oder durch die Neuinstallation eines PCs.

Folgende Aspekte der Grundarchitektur tragen zur Abwehr von Verlust der privaten Schlüssel (OpenPGP oder S/MIME) bei:

– Schlüsselhinterlegung der privaten Schlüssel des Verschlüsselungszertifikats.

– Veröffentlichung auf einer Sperrliste (CRL und/oder OCSP).

Restrisiko: Verlust der privaten Schlüssel des Zertifikats für die digitale Signatur.

5.5 Gefährdungen auf einen Blick

Die nachfolgende Abbildung 5.3 zeigt einen Überblick der erkannten Gefährdungen bezüglich Grundwert, Phase und Aufwand. Mit dem Zeichen „x“ wird die Hauptkategorie der Gefährdung dargestellt. In manchen Fälle kann eine Gefährdung sich auf mehrere Grundwerte auswirken, dies wird dann mit dem Zeichen „(x)“ gekennzeichnet.



6 FazitDie Nutzung von E-Mails ermöglicht einen einfachen, schnellen und kostengünstigen Austausch von Informationen. Bei einer Verwendung zur externen Kommunikation über ein unsicheres Netz (wie beispielsweise das Internet) ergeben sich jedoch zahlreiche Bedrohungen für die Integrität, Vertraulichkeit und Verfügbarkeit.

In der vorliegenden Studie wurden Empfehlungen erarbeitet, um diesen Bedrohungen mit geeigne-ten Maßnahmen zu begegnen. Neben einer sorgfältigen Auswahl und Konfiguration der E-Mail-Cli-ent-Software sowie der sicheren Anbindung des E-Mail-Clients an den internen E-Mail-Server erhöhen zusätzliche Komponenten wie Virenschutzprogramm, Anti-Phishing-Software und Per-sonal Firewall die Sicherheit wesentlich. Die Verwendung einer E-Mail-Richtlinie kann den Benut-zer durch Hinweise zur Nutzung unterstützen.

Die Vertraulichkeit und die Integrität/Authentizität der E-Mail-Kommunikation kann über eine Rea-lisierung auf dem E-Mail-Client mittels der offenen Standards S/MIME oder OpenPGP sicherge-stellt werden. Eine gute Alternative ist die in der Studie [ISi-Mail-Server] vorgestellte Lösung der Virtuelle Poststelle (VPS). Damit kann diese Aufgabe über einen zentralen Server ohne Änderun-gen an den E-Mail-Clients und ohne zusätzlichen Aufwand für den Benutzer realisiert werden.

Diese Studie betrachtet in erster Linie Sicherheitsaspekte in Anwendungen und beschreibt entspre-chende Schutzmaßnahmen. Zusammen mit der Studie zum sicheren Betrieb von E-Mail-Servern [ISi-Mail-Server] sowie der Absicherung der unteren drei Schichten des TCP/IP-Referenzmodells gemäß dem Modul „Sichere Anbindung von lokalen Netzen an das Internet“ [ISi-LANA] wird eine sichere Nutzung und Bereitstellung des Dienstes E-Mail ermöglicht.



7 Literaturverzeichnis[Ägypten] Bundesamt für Sicherheit in der Informationstechnik (BSI): OpenSource

Projekt Ägypten; http://www.bsi.bund.de/ContentBSI/Themen/verwpki/OSSProjektAegypten/aegypten.html

[ISi-E] Bundesamt für Sicherheit in der Informationstechnik (BSI): BSI-Reihe zur Internet-Sicherheit, Internet-Sicherheit: Einführung, Grundlagen, Vorge-hensweise, http://www.isi-reihe.de, 2009

[ISi-LANA] Bundesamt für Sicherheit in der Informationstechnik (BSI): BSI-Reihe zur Internet-Sicherheit, Sichere Anbindung von lokalen Netzen an das Internet, http://www.isi-reihe.de, Januar 2008

[ISi-Mail-Server] Bundesamt für Sicherheit in der Informationstechnik (BSI): BSI-Reihe zur Internet-Sicherheit, Sicherer Betrieb von E-Mail-Servern, http://www.isi-reihe.de, März 2009

[ITGSK] Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grund-schutz-Kataloge. BSI, http://www.bsi.de/gshb/, 2008

[MailTrusT] TeleTrusT Deutschland e.V.: MailTrust Version 2; Jobst Biester, Fritz Bau-spieß, Dirk Fox, Secorvo Security Consulting GmbH; März 1999

[RFC 1939] Internet Engineering Task Force (IETF): Post Office Protocol - Version 3; RFC 1939/STD 53, http://www.ietf.org/rfc/rfc1939.txt, Mai 1996

[RFC 2015] Internet Engineering Task Force (IETF): MIME Security with Pretty Good Privacy (PGPOpenPGP); RFC 2015, http://www.ietf.org/rfc/rfc2015.txt, October 1996

[RFC 2045] Internet Engineering Task Force (IETF): Multipurpose Internet Mail Exten-sions (MIME) Part One: Format of Internet Message Bodies; RFC 2045, http://www.ietf.org/rfc/rfc2045.txt, November 1996

[RFC 2311] Internet Engineering Task Force (IETF): S/MIME Version 2 Message Spe-cification; RFC 2311, http://www.ietf.org/rfc/rfc2311.txt, March 1998

[RFC 2312] Internet Engineering Task Force (IETF): S/MIME Version 2 Certificate Handling; RFC 2312, http://www.ietf.org/rfc/rfc2312.txt, March 1998

[RFC 2440] Internet Engineering Task Force (IETF): OpenPGP Message Format; RFC 2440, http://www.ietf.org/rfc/rfc2440.txt, November 1998

[RFC 2445] Internet Engineering Task Force (IETF): Internet Calendaring and Schedul-ing Core Object Specification (iCalendar); RFC 2445, http://www.ietf.org/rfc/rfc2445.txt, November 1998

[RFC 2554] Internet Engineering Task Force (IETF): SMTP Service Extension for Au-thentication; RFC 2554, http://www.ietf.org/rfc/rfc2554.txt, March 1998

[RFC 2560] Internet Engineering Task Force (IETF): X.509 Internet Public Key Infra-structure Online Certificate Status Protocol – OCSP; RFC 2560, http://ww-w.ietf.org/rfc/rfc2560.txt, June 1999

[RFC 2595] Internet Engineering Task Force (IETF): Using TLS with IMAP, POP3 and ACAP; RFC 2595, http://www.ietf.org/rfc/rfc2595.txt, June 1999



http://www.ietf.org/rfc/rfc2595.txt









































http://www.bsi.de/gshb/



http://www.bsi.bund.de/ContentBSI/Themen/verwpki/OSSProjektAegypten/aegypten.html

http://www.bsi.bund.de/ContentBSI/Themen/verwpki/OSSProjektAegypten/aegypten.html


[RFC 2634] Internet Engineering Task Force (IETF): Enhanced Security Services for S/MIME; RFC 2634, http://www.ietf.org/rfc/rfc2634.txt, June 1999

[RFC 2821] Internet Engineering Task Force (IETF): Internet Protocol, Simple Mail Transfer Protocol; RFC 2821/STD 10, http://www.ietf.org/rfc/rfc2821.txt, April 2001

[RFC 2822] Internet Engineering Task Force (IETF): Internet Message Format; RFC 2822/STD 11, http://www.ietf.org/rfc/rfc2822.txt

[RFC 2849] Internet Engineering Task Force (IETF): The LDAP Data Interchange Format (LDIF) - Technical Specification; RFC 2849, http://www.ietf.org/rfc/rfc2849.txt, June 2000

[RFC 3156] Internet Engineering Task Force (IETF): MIME Security with OpenPGP; RFC 3156, http://www.ietf.org/rfc/rfc3156.txt, August 2001

[RFC 3207] Internet Engineering Task Force (IETF): SMTP Service Extension for Se-cure SMTP over Transport Layer Security; RFC 3207, http://www.ietf.org/rfc/rfc3207.txt, Februar 2002

[RFC 3280] Internet Engineering Task Force (IETF): Internet X.509 Public Key Infra-structure Certificate and Certificate Revocation List (CRL) Profile; RFC 3280, http://www.ietf.org/rfc/rfc3280.txt, April 2002

[RFC 3461] Internet Engineering Task Force (IETF):Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs); RFC 3461, http://www.ietf.org/rfc/rfc3461.txt, January 2003

[RFC 3501] Internet Engineering Task Force (IETF): Internet Message Access Protocol - Version 4rev1; RFC 3501, http://www.ietf.org/rfc/rfc3501.txt, March 2003

[RFC 3798] Internet Engineering Task Force (IETF): Message Disposition Notification; RFC 3798, http://www.ietf.org/rfc/rfc3798.txt, May 2004

[RFC 3850] Internet Engineering Task Force (IETF): Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling; RFC 3850, http://www.ietf.org/rfc/rfc3850.txt, July 2004

[RFC 3851] Internet Engineering Task Force (IETF): Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification; RFC 3851, http://www.ietf.org/rfc/rfc3851.txt, July 2004

[RFC 4409] Internet Engineering Task Force (IETF): Message Submission for Mail; RFC 4409, http://www.ietf.org/rfc/rfc4409.txt, April 2006

[RFC 4422] Internet Engineering Task Force (IETF): Simple Authentication and Secur-ity Layer (SASL); RFC 4422, http://www.ietf.org/rfc/rfc4422.txt, June 2006

[RFC 4510] Internet Engineering Task Force (IETF): Lightweight Directory Access Pro-tocol (LDAP): Technical Specification Road Map; RFC 4510, http://ww-w.ietf.org/rfc/rfc4510.txt, June 2006

[RFC 4513] Internet Engineering Task Force (IETF): Lightweight Directory Access Pro-tocol (LDAP): Authentication Methods and Security Mechanisms; RFC 4513, http://www.ietf.org/rfc/rfc4513.txt, June 2006





































































[RFC 4550] Internet Engineering Task Force (IETF): Internet E-Mail to Support Diverse Service Environments (Lemonade) Profile; RFC 4550, http://www.ietf.org/rfc/rfc4550.txt, June 2006

[RFC 4616] Internet Engineering Task Force (IETF): The PLAIN Simple Authentication and Security Layer (SASL) Mechanism; RFC 4616, http://www.ietf.org/rfc/rfc4616.txt, August 2006

[RFC 4791] Internet Engineering Task Force (IETF): Calendaring Extensions to Web-DAV (CalDAV); RFC 4791, http://www.ietf.org/rfc/rfc4791.txt, March 2007

[RFC 4954] Internet Engineering Task Force (IETF): SMTP Service Extension for Au-thentication; RFC 4954, http://www.ietf.org/rfc/rfc4954.txt, July 2007

[SPHINX] Bundesamt für Sicherheit in der Informationstechnik (BSI): SPHINX; http://www.bsi.bund.de/ContentBSI/Themen/verwpki/SPHINX/sphinx.html

[VPS] Bundesamt für Sicherheit in der Informationstechnik (BSI): Die Virtuelle Poststelle, http://www.bsi.bund.de/ContentBSI/Themen/vps/dieVPS.html


http://www.bsi.bund.de/ContentBSI/Themen/vps/dieVPS.html

http://www.bsi.bund.de/ContentBSI/Themen/verwpki/SPHINX/sphinx.html


















8 Anhang

8.1 Abdeckungsmatrix

Abschnitt 5 beschreibt die maßgeblichen Gefährdungen der Grundarchitektur, die im Zusammen-hang mit E-Mail zu erwarten sind. Die Abschnitte 3 bis 5 geben Empfehlungen,wie diesen Gefähr-dungen durch die besonderen Merkmale der Grundarchitektur, einer geeigneten Konfiguration ihrer Komponenten sowie durch ergänzende Maßnahmen begegnet werden kann. Die Empfehlungen decken normalen Schutzbedarf ab, verweisen aber auch auf Realisierungsvarianten und ergänzende Maßnahmen, die auch hohem Schutzbedarf genügen. Abbildung 8.1 zeigt in einer Übersicht den Zusammenhang zwischen Gefährdungen und Empfehlungen bei normalen Schutzbedarf. Für jede Gefährdung ist dargestellt, welche Empfehlungen umgesetzt werden müssen, um das Restrisiko der Bedrohung auf ein für einen normalen Schutzbedarf ausreichendes Niveau zu senken.

Umgekehrt ist der Tabelle zu entnehmen, gegen welche Gefährdungen sich die einzelnen Empfeh-lungen primär richten. Die Abdeckungsmatrix soll dem Benutzer helfen, diejenigen Maßnahmen zu ermitteln, die im Kontext seiner spezifischen Bedrohungslage relevant und angemessen sind.

In der Abdeckungsmatrix wird zwischen Empfehlungen unterschieden, wo die Umsetzung dringend empfohlen wird (mit „X“ gekennzeichnet), und optionalen Empfehlungen, die bei Bedarf zusätzlich umgesetzt werden können (mit „(X)“ gekennzeichnet). Alle Empfehlungen, die grau hinterlegt sind, beziehen sich auf normalen Schutzbedarf; es wird empfohlen diese in einem Anwendungskontext mit normalem Schutzbedarf umzusetzen.

Abbildung 8.2 zeigt eine entsprechende Abdeckungsmatrix für hohen Schutzbedarf. Die hier bezeichneten Empfehlungen ergänzen die Grundvorgaben dort, wo Grundarchitektur und Grund-konfiguration alleine nur einem normalen Schutzbedarf genügen.

Alle Empfehlungen, die nicht grau hinterlegt sind, beziehen sich auf normalem Schutzbedarf; sie genügen nicht den Anforderungen eines hohen Schutzbedarfs und sollten daher durch die bezeich-nete stärkere Variante ersetzt werden.



9 Glossar

ActiveX [engl.]

Software-Komponenten, die in verschiedenen Programmiersprachen für den Einsatz unter Microsoft Windows verwendet werden können. In Browsern führt ihr Einsatz sehr oft zu Sicher-heitsproblemen.

Administrator

Ein Administrator verwaltet und betreut Rechner sowie Computer-Netze. Er installiert Betriebssys-teme und Anwendungsprogramme, richtet neue Benutzer-Kennungen ein und verteilt die für die Arbeit notwendigen Rechte. Dabei hat er im Allgemeinen weitreichende oder sogar uneinge-schränkte Zugriffsrechte auf die betreuten Rechner oder Netze.

ALG (Application-Level Gateway [engl.])

Filterfunktionen oberhalb der Transportschicht werden von einem sogenannten Application-Level Gateway übernommen, auch Sicherheits-Proxy genannt. Ein Proxy ist eine Art Stellvertreter für Dienste in Netzen. Er nimmt Daten an seinem Eingang entgegen und leitet sie nach einer Prüfung an den eigentlichen Dienst weiter. Mittels eines Proxys lassen sich Datenströme auf der Anwen-dungsschicht verwerfen, modifizieren oder gezielt weiterleiten. Implizit nehmen ALGs auch Funk-tionen auf den darunter liegenden Schichten des TCP/IP-Modells wahr. ALGs unterbrechen den direkten Datenstrom zwischen Quelle und Ziel. Bei einer Kommunikationsbeziehung zwischen Cli-ent und Server über das ALG hinweg nimmt das ALG die Anfragen des Clients entgegen und leitet sie an den Server weiter. Bei einem Verbindungsaufbau in umgekehrter Richtung, also vom Server zum Client, verfährt das ALG analog. Diese Kommunikationsform ermöglicht es dem ALG bei-spielsweise, bestimmte Protokollbefehle auf der Anwendungsschicht zu filtern. Das ALG kann zudem die strikte Einhaltung von Anwendungsprotokollen erzwingen, unerwünschte Anwendungs-daten aus den Datenpaketen entfernen (bzw. austauschen) oder Verbindungen anwendungsspezi-fisch protokollieren.

Angriff (engl. attack)

Ein Angriff ist eine vorsätzliche Form der Gefährdung, nämlich eine unerwünschte oder unberech-tigte Handlung mit dem Ziel, sich Vorteile zu verschaffen bzw. einen Dritten zu schädigen. Angrei-fer können auch im Auftrag von Dritten handeln, die sich Vorteile verschaffen wollen.

Applet [engl.]

Applets sind kleine Module, die in Java programmiert sind und in HTML-Seiten eingebunden wer-den können. Das Programm wird ausgeführt, wenn der Browser java-fähig ist. Da die Java Virtual Machine nicht in allen Browsern integriert ist, muss sie für das Laufen von Applets erst installiert werden. Das Ausführen von Applets bringt nicht unerhebliche Sicherheitsrisiken mit sich.



Attribut (engl. attribute)

Befehle in Programmiersprachen können durch Attribute näher bestimmt werden. Durch Wertanga-ben werden wiederum die Attribute genauer definiert. Der IMAGE-Tag kann z. B. durch das ALT-Attribut ergänzt werden, das eine Beschreibung des Bildes (=Wert) liefert.

Authentisierung (engl. authentication)

Unter einer Authentisierung versteht man die Vorlage eines Nachweises eines Kommunikations-partners, dass er tatsächlich derjenige ist, der er vorgibt zu sein.

Authentizität (engl. authenticity)

Mit dem Begriff Authentizität wird die Eigenschaft bezeichnet, die gewährleistet, dass ein Kommu-nikationspartner tatsächlich derjenige ist, der er vorgibt zu sein. Bei authentischen Informationen ist sichergestellt, dass sie von der angegebenen Quelle erstellt wurden. Der Begriff wird nicht nur ver-wendet, wenn die Identität von Personen geprüft wird, sondern auch bei IT-Komponenten oder An-wendungen.

Bedrohung (engl. threat)

Eine Bedrohung ist ganz allgemein ein Umstand oder Ereignis, durch das ein Schaden entstehen kann. Der Schaden bezieht sich dabei auf einen konkreten Wert wie Vermögen, Wissen, Gegen-stände oder Gesundheit. Übertragen in die Welt der Informationstechnik ist eine Bedrohung ein Umstand oder Ereignis, das die Verfügbarkeit, Integrität oder Vertraulichkeit von Informationen bedrohen kann, wodurch dem Besitzer der Informationen ein Schaden entsteht.

Benutzer-Kennung (engl. user account)

Die Benutzer-Kennung ist der Name, mit dem sich der Benutzer einem IT-System gegenüber authentisiert. Dies kann z. B. der tatsächliche Name sein, ein Pseudonym, eine Abkürzung oder eine automatisch vergebene Kombination aus Buchstaben oder Ziffern.

Betriebssystem (engl. operating system)

Das Betriebssystem ist ein Steuerungsprogramm, das es dem Benutzer ermöglicht, seine Dateien zu verwalten, angeschlossene Geräte (z. B. Drucker, Festplatte) zu kontrollieren oder Programme zu starten. Weit verbreitet sind z. B. Windows, Linux oder MacOS.

Bot-Netz

Ein fernsteuerbares Rechnernetz, das für Spam-Verbreitung oder DDoS-Angriffe verwendet werden kann.

Browser [engl.]

Mit Browser (von "to browse", auf deutsch: schmökern, blättern, umherstreifen) wird Software zum Zugriff auf das World Wide Web bezeichnet. Das Programm interpretiert die ankommenden Daten und stellt sie als Text und Bild auf dem Bildschirm dar.



BSI (Bundesamt für Sicherheit in der Informationstechnik) (engl. Federal Office for Information Security)

Bundesbehörde im Geschäftsbereich des Bundesministerium des Innern.

Chiasmus

Ein vom BSI entwickeltes Ver- und Entschlüsselungstool für Windows.

Chipkarte (engl. smartcard)

Plastikkarte in EC-Kartengröße mit integriertem Miniaturrechner (Chip). Chipkarten werden über ein entsprechendes Lesegerät an den Computer angeschlossen.

Client [engl.]

Als Client wird Soft- oder Hardware bezeichnet, die bestimmte Dienste von einem Server in Anspruch nehmen kann. Häufig steht der Begriff Client für einen Arbeitsplatzrechner, der in einem Netz auf Daten und Programme eines Servers zugreift.

Content [engl.]

Bezeichnet den Inhalt einer Webseite. Content sind Beiträge, Informationen etc., die über das Web abgerufen werden können.

Datenschutz

Mit Datenschutz wird der Schutz personenbezogener Daten vor etwaigem Missbrauch durch Dritte bezeichnet (nicht zu verwechseln mit Datensicherheit).

Datensicherung (engl. backup)

Bei einer Datensicherung werden zum Schutz vor Datenverlust Sicherungskopien von vorhandenen Datenbeständen erstellt. Datensicherung umfasst alle technischen und organisatorischen Maßnah-men zur Sicherstellung der Verfügbarkeit, Integrität und Konsistenz der Systeme einschließlich der auf diesen Systemen gespeicherten und für Verarbeitungszwecke genutzten Daten, Programme und Prozeduren. Ordnungsgemäße Datensicherung bedeutet, dass die getroffenen Maßnahmen in Abhängigkeit von der Datensensitivität eine sofortige oder kurzfristige Wiederherstellung des Zustands von Systemen, Daten, Programmen oder Prozeduren nach erkannter Beeinträchtigung der Verfügbarkeit, Integrität oder Konsistenz aufgrund eines schadenswirkenden Ereignisses ermögli-chen. Die Maßnahmen umfassen dabei mindestens die Herstellung und Erprobung der Rekonstruk-tionsfähigkeit von Kopien der Software, Daten und Prozeduren in definierten Zyklen und Genera-tionen.

DDoS (Distributed Denial of Service [engl.])

Ein koordinierter DoS Angriff auf die Verfügbarkeit von IT mittels einer größeren Anzahl von angreifenden Systemen.



Digitale Signatur

Sicherungsmechanismus für elektronische Daten, bei dem aus der Information mittels eines gehei-men Schlüssels ein Wert erzeugt wird, der mithilfe eines zugehörigen öffentlichen Schlüssels verifi-ziert werden kann. Die digitale Signatur dient dem Schutz der Authentizität und der Integrität der Daten. Vgl. auch elektronische Signatur.

DoS (Denial of Service [engl.])

Angriffe, mit dem Ziel, die Verfügbarkeit von IT zu schädigen.

E-Mail (Electronic Mail)

Flash [engl.]

Mit dem Programm Flash können interaktive Vektorgrafik, Animation und Präsentation erstellt werden. Für die Betrachtung der Filme ist ein kostenloses Plug-In erforderlich. Flash zählt zu den Aktiven Inhalten.

Frame [engl.]

Eine Website kann aus mehreren HTML-Seiten, den Frames (Rahmen), bestehen. Frames können von älteren Textbrowsern und Screenreadern nicht interpretiert werden.

FTP (File Transfer Protocol [engl.])

Das File Transfer Protocol umfasst Funktionen, mit denen man Dateien auf einfache Weise zwi-schen zwei Rechnern austauschen kann.

Gefährdung

Eine Gefährdung ist eine Bedrohung, die konkret auf ein Objekt über eine Schwachstelle einwirkt. Eine Bedrohung wird somit erst durch eine vorhandene Schwachstelle zur Gefährdung für ein Objekt. So sind beispielsweise Computer-Viren eine Bedrohung oder eine Gefährdung für Anwen-der, die im Internet surfen. Nach der oben gegebenen Definition lässt sich feststellen, dass alle Anwender prinzipiell durch Computer-Viren im Internet bedroht sind. Der Anwender, der eine virenbefallene Datei herunterlädt, wird von dem Computer-Virus gefährdet, wenn sein Computer anfällig für diesen Typ Computer-Virus ist. Für Anwender mit einem wirksamen Schutzprogramm, einer Konfiguration, die das Funktionieren des Computer-Virus verhindert, oder einem Betriebssys-tem, das den Virencode nicht ausführen kann, bedeutet das geladene Schadprogramm hingegen keine Gefährdung.

Hacking [engl.]

Hacking bezeichnet im Kontext von Informationssicherheit Angriffe, die darauf abzielen, vorhan-dene Sicherheitsmechanismen zu überwinden, um in ein IT-System einzudringen, seine Schwächen offen zulegen und es gegebenenfalls - bei unethischem Hacking - zu übernehmen.



HTML (Hypertext Markup Language [engl.])

Für Web-Seiten verwendete Auszeichnungssprache, die von allen Browsern verstanden wird.

HTTP (Hypertext Transfer Protocol [engl.])

Das Hypertext Transfer Protocol dient zur Übertragung von Daten - meist Webseiten - zwischen einem HTTP-Server und einem HTTP-Client, also z. B. einem Browser. Die Daten werden über Uniform Resource Locators (URL) eindeutig bezeichnet. URLs werden meist in der Form Proto-koll://Rechner/Pfad/Datei angegeben. Protokoll steht dabei für Protokolle der Anwendungsschicht, Rechner für den Namen oder die Adresse des Servers und der Pfad der Datei gibt den genauen Ort der Datei auf dem Server an. Ein Beispiel für eine URL ist http://www.bsi.bund.de/fachthem/sinet/index.htm.

HTTPS (HTTP secure [engl.])

Protokoll zur sicheren Übertragung von HTML-Seiten im Internet. SSL/TLS dient dabei zur Absi-cherung der Client-Server-Kommunikation.

Hyperlink [engl.]

Kurz für Hypertext Link. Elektronischer Querverweis zwischen Dokumenten. Sind innerhalb von Textdokumenten meist farblich oder durch Unterstreichung hervorgehoben, verlinkte Dokumente lassen sich per einfachem Mausklick aufrufen.

Hypertext

Elektronisches Dokumentenformat, das Querverweise (Hyperlinks) zwischen unterschiedlichen Dokumenten vorsieht, die Standard-Darstellungsform im WWW.

IDS (Intrusion Detection System [engl.])

Ein Intrusion Detection System ist ein System zur Erkennung von Angriffen auf ein Rechnersystem oder Rechnernetz.

Integrität (engl. integrity)

Integrität bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Daten und der korrek-ten Funktionsweise von Systemen. Wenn der Begriff Integrität auf "Daten" angewendet wird, drückt er aus, dass die Daten vollständig und unverändert sind. In der Informationstechnik wird er in der Regel aber weiter gefasst und auf "Informationen" angewendet. Der Begriff "Information" wird dabei für "Daten" verwendet, denen je nach Zusammenhang bestimmte Attribute wie z. B. Autor oder Zeitpunkt der Erstellung zugeordnet werden können. Der Verlust der Integrität von Informationen kann daher bedeuten, dass diese unerlaubt verändert, Angaben zum Autor verfälscht oder Zeitangaben zur Erstellung manipuliert wurden. Integrität ist ein Grundwert der IT-Sicherheit.

Interoperabilität

Eigenschaft von IT-Systemen und -Anwendungen, plattformübergreifend miteinander zu kommuni-zieren.



Intranet (engl. intranet)

Ein Intranet ist ein internes Netz, das sich unter vollständiger Kontrolle des Netzbetreibers (also der jeweiligen Behörde oder des Unternehmens) befindet. Meist werden Zugriffe aus anderen Netze (wie dem Internet) durch ein Sicherheits-Gateway verhindert oder nur aufgrund spezieller Regeln zugelassen.

IP (Internet Protocol [engl.])

Verbindungsloses Protokoll der Internet-Schicht im TCP/IP-Referenzmodell. Ein IP-Header enthält in der Version IPv4 u. a. zwei 32-Bit-Nummern (IP-Adressen) für Ziel und Quelle der kommunizie-renden Rechner.

IPSec (Internet Protocol Security [engl.])

Erweiterung des Internet-Protokolls IP zur Sicherstellung von Integrität, Authentizität und Vertrau-lichkeit. IPSec ist in der Version 6 des Internet-Protokolls (IPv6) enthalten.

ISIS-MTT (Industrial Signature Interoperability and Maitrust Specification [engl.])

Gemeinsame Spezifikation der T7-Gruppe und TeleTrusT für elektronische Signaturen, Verschlüs-selung und Public-Key-Infrastrukturen. Sie besteht aus einer Basisspezifikation und einem optiona-len Profil gemäß Signaturgesetz (SigG).

IT-Grundschutz

IT-Grundschutz bezeichnet eine Methodik zum Aufbau eines Sicherheitsmanagementsystems sowie zur Absicherung von Informationsverbünden über Standard-Sicherheitsmaßnahmen. Außerdem wird mit IT-Grundschutz der Zustand bezeichnet, in dem die vom BSI empfohlenen Standard-Sicherheitsmaßnahmen für IT-Systeme mit normalem Schutzbedarf umgesetzt sind. Für Systeme mit hohem oder sehr hohem Schutzbedarf sind möglicherweise darüber hinausgehende Sicherheits-maßnahmen notwendig.

IT-Sicherheit (engl. IT Security)

IT-Sicherheit bezeichnet einen Zustand, in dem die Risiken, die beim Einsatz von Informationstech-nik aufgrund von Gefährdungen vorhanden sind, durch angemessene Maßnahmen auf ein tragbares Maß beschränkt sind. IT-Sicherheit ist also der Zustand, in dem Vertraulichkeit, Integrität und Ver-fügbarkeit von Informationen und Informationstechnik durch angemessene Maßnahmen geschützt sind.

IT-Sicherheitsbeauftragter

Personen mit eigener Fachkompetenz zur IT-Sicherheit in einer Stabsstelle eines Unternehmens oder einer Behörde, die für alle IT-Sicherheitsfragen, Mitwirkung im IT-Sicherheitsprozess und IT-Sicherheitsmanagement-Team zuständig sind, die IT-Sicherheitsleitlinie, das IT-Sicherheitskonzept und andere Konzepte z. B. für Notfallvorsorge koordinierend erstellen und deren Umsetzung planen und überprüfen.



Java

Java ist eine Programmiersprache. Häufig wird Java in Form von Java-Applets auf Web-Seiten genutzt. Damit Java-Programme funktionieren, muss auf dem betreffenden Rechner oder im Browser das Java Runtime Environment (JRE) installiert sein. Java zählt zu den Aktiven Inhalten.

JavaScript [engl.]

JavaScript ist eine Programmiersprache, die oft auf Webseiten eingesetzt wird. Mit ihr ist es z. B. möglich, Pop-Up-Fenster zu öffnen, Berechnungen durchzuführen oder Formulareingaben zu über-prüfen. JavaScript ist Bestandteil aller neuen Browser. JavaScript zählt zu den Aktiven Inhalten.

Kryptografie

Mathematisches Fachgebiet, das sich mit Methoden zum Schutz von Informationen befasst (u. a. mit Vertraulichkeit, Integrität und Authentizität von Daten).

Makro

Befehlsfolge oder kurzes Programm zur Vereinfachung für häufig benötigte Aufgaben.

Makro-Virus

Computer-Virus, der in einer Programmiersprache für Makros geschrieben wurde (z. B. Word-Basic).

MIME (Multipurpose Internet Mail Extensions [engl.])

Protokoll für die E-Mail-Kommunikation als Erweiterung zu SMTP. MIME ermöglicht die Übertra-gung von binären Dateien in E-Mails.

MTT (MailTrusT [engl.])

Standard für sicheren E-Mail-Austausch, deutsche Entwicklung des Vereins TeleTrusT, beruht auf internationalen Standards (PEM) und berücksichtigt auch S/MIME, X.509v3. Wurde inzwischen weiterentwickelt zu ISIS-MTT.

NAT (Network Address Translation [engl.])

Network Address Translation (NAT) bezeichnet ein Verfahren zum automatischen und transparen-ten Ersetzen von Adressinformationen in Datenpaketen. NAT-Verfahren kommen meist auf Routern und Sicherheits-Gateways zum Einsatz, vor allem, um den beschränkten IPv4-Adressraum möglichst effizient zu nutzen und um lokale IP-Adressen gegenüber öffentlichen Netzen zu verber-gen.

OpenPGP (Open Pretty Good Privacy [engl.])

Spezifikation für PGP-verwandte Verschlüsselungs- und Signatur-Software.



Paketfilter (engl. packet filter)

Paketfilter sind IT-Systeme mit spezieller Software, die den ein- und ausgehenden Datenverkehr anhand spezieller Regeln filtern. Ihre Aufgabe ist es, Datenpakete anhand der Informationen in den Header-Daten der IP- und Transportschicht (z. B. Quell- und Ziel-Adresse, -Portnummer, TCP-Flags) weiterzuleiten oder zu verwerfen. Der Inhalt des Pakets bleibt dabei unberücksichtigt.

Passwort

Geheimes Kennwort, das Daten, Rechner, Programme u. a. vor unerlaubtem Zugriff schützt.

Patch [engl.]

Ein Patch (vom englischen "patch", auf deutsch: Flicken) ist ein kleines Programm, das Software-Fehler wie z. B. Sicherheitslücken in Anwendungsprogrammen oder Betriebssystemen behebt.

PGP (Pretty Good Privacy [engl.])

Verfahren bzw. Anwendungsprogramm zur Verschlüsselung und Elektronischen Signatur von E-Mails, das auf der Basis eines Schlüsselpaares aus öffentlichem und privatem Schlüssel arbeitet.

Phishing [engl.]

Versuch von Betrügern, IT-Anwender irrezuführen und zur Herausgabe von Authentisierungsdaten zu bewegen. Dies wird in den meisten Fällen bei Online-Banking-Verfahren eingesetzt.

PKI (Public Key Infrastructure [engl.])

Sicherheitsinfrastruktur, die es ermöglicht, in nicht gesicherten Netzen (z. B. Internet) auf der Basis eines von einer vertrauenswürdigen Stelle ausgegebenen Schlüsselpaares (vgl. asymmetrische Ver-schlüsselung) verschlüsselt Daten auszutauschen bzw. Signaturen zu erzeugen und zu prüfen.

Plug-In [engl.]

Plug-Ins sind Zusatzmodule des Browsers, die erforderlich sind, um spezielle Multimedia-Fähigkei-ten einzubinden und nutzen zu können.

POP (Post Office Protocol [engl.])

Verbreitetes Protokoll für das Herunterladen von E-Mails von einem Mailserver auf einen PC.

Protokoll (engl. protocol)

Beschreibung (Spezifikation) des Datenformats für die Kommunikation zwischen elektronischen Geräten.

Proxy

Ein Proxy ist eine Art Stellvertreter in Netzen. Er nimmt Daten von einer Seite an und leitet sie an eine andere Stelle im Netz weiter. Mittels eines Proxys lassen sich Datenströme filtern und gezielt weiterleiten.



Prüfsumme (engl. checksum)

In der Informatik ist eine Prüfsumme eine einfache Maßnahme zur Gewährleistung von Dateninte-grität bei der Datenübermittlung oder -speicherung.

Restrisiko (engl. residual risk)

Risiko, das grundsätzlich bleibt, auch wenn Maßnahmen zum Schutz des IT-Einsatzes ergriffen worden sind.

RFC (Request for Comments [engl.])

In Request for Comments werden wichtige Internet-Standards festgelegt. RFCs können bei der Internet Engineering Task Force (IETF) eingereicht werden, die die Entscheidung trifft, ob der Vor-schlag zum Standard erhoben wird. RFCs werden nummeriert und nicht mehr verändert. Sollen bestehende RFCs verändert oder erweitert werden, so geschieht dies, indem ein neuer RFC mit einer neuen Nummer und mit den entsprechenden Neuerungen geschaffen wird.

Risiko (engl. risk)

Risiko ist die häufig auf Berechnungen beruhende Vorhersage eines möglichen Schadens im negati-ven Fall (Gefahr) oder eines möglichen Nutzens im positiven Fall (Chance). Was als Schaden oder Nutzen aufgefasst wird, hängt von Wertvorstellungen ab. Risiko wird auch häufig definiert als die Kombination aus der Wahrscheinlichkeit, mit der ein Schaden auftritt, und dem Ausmaß dieses Schadens.

RSA (Rivest, Shamir, Adleman Public Key Encryption [engl.])

Ein asymmetrisches Verfahren (Public-Key-Verfahren) zur Verschlüsselung und Signatur.

Schutzbedarf (engl. protection requirements)

Der Schutzbedarf beschreibt, welcher Schutz für die Geschäftsprozesse, die dabei verarbeiteten Informationen und die eingesetzte Informationstechnik ausreichend und angemessen ist.

Schwachstelle (engl. vulnerability)

Eine Schwachstelle ist ein sicherheitsrelevanter Fehler eines IT-Systems oder einer Institution. Ursachen können in der Konzeption, den verwendeten Algorithmen, der Implementation, der Konfi-guration, dem Betrieb sowie der Organisation liegen. Eine Schwachstelle kann dazu führen, dass eine Bedrohung wirksam wird und eine Institution oder ein System geschädigt wird. Durch eine Schwachstelle wird ein Objekt (eine Institution oder ein System) anfällig für Bedrohungen.

Server [engl.]

Als Server wird Soft- oder Hardware bezeichnet, die bestimmte Dienste anderen (Clients) anbietet. Typischerweise wird damit ein Rechner bezeichnet, der seine Hardware- und Software-Ressourcen in einem Netz anderen Rechnern zugänglich macht. Beispiele sind Applikations-, Daten-, Web- oder E-Mail-Server.



Sicherheits-Gateway

Ein Sicherheits-Gateway (oft auch Firewall genannt) gewährleistet die sichere Kopplung von IP-Netzen durch Einschränkung der technisch möglichen auf die in einer IT-Sicherheitsleitlinie als ordnungsgemäß definierte Kommunikation. Sicherheit bei der Netzkopplung bedeutet hierbei im Wesentlichen, dass ausschließlich erwünschte Zugriffe oder Datenströme zwischen verschiedenen Netzen zugelassen und die übertragenen Daten kontrolliert werden. Ein Sicherheits-Gateway für normalen Schutzbedarf besteht im Allgemeinen aus mehreren, in Reihe geschalteten Filterkompo-nenten. Dabei ist zwischen Paketfilter und Application-Level Gateway (ALG) zu unterscheiden.

Sicherheitsmaßnahme (engl. saveguard control)

Mit Sicherheitsmaßnahme werden alle Aktionen bezeichnet, die dazu dienen, Sicherheitsrisiken zu steuern und entgegenzuwirken. Dies schließt organisatorische, personelle, technische und infra-strukturelle Sicherheitsmaßnahmen ein. Synonym werden auch die Begriffe Sicherheitsvorkehrung oder Schutzmaßnahme benutzt.

SigG (Signaturgesetz)

Gesetz über Rahmenbedingungen für elektronische Signaturen.

Skript

Quelltextdatei eines Programmes in Skriptsprache. Skriptsprachen werden gewöhnlich für kleine, überschaubare Programmieraufgaben verwendet. Skripte benötigen vor der Ausführung keine Über-setzung in Maschinensprache.

SMTP (Simple Mail Transfer Protocol [engl.])

Das Simple Mail Transfer Protocol legt fest, wie E-Mails zwischen Servern zu übertragen sind. Auch für den Transport von E-Mails vom Mail-Client zum Server (und die umgekehrte Richtung) kann SMTP genutzt werden.

Spam [engl.]

Gängige Bezeichnung für unverlangt zugesandte Werbepost per E-Mail.

SPHINX [engl.]

Pilotversuch zur hersteller- und plattformübergreifenden Realisierung von E-Mail-Sicherheit zwi-schen Absender und Empfänger, basierend auf Verfahren zur digitalen Signatur und zur Verschlüs-selung.

Spoofing [engl.]

Spoofing (von to spoof, zu deutsch: manipulieren, verschleiern oder vortäuschen) nennt man in der Informationstechnik verschiedene Täuschungsversuche zur Verschleierung der eigenen Identität und zum Fälschen übertragener Daten. Das Ziel besteht darin, die Integrität und Authentizität der Informationsverarbeitung zu untergraben.



Spyware [engl.]

Software, die persönliche Daten des Benutzers ohne dessen Wissen oder Zustimmung an den Her-steller der Software oder an Dritte sendet.

SSL (Secure Sockets Layer [engl.])

Protokoll zur sicheren Kommunikation über das Internet, insbesondere zwischen Client und Server, basiert auf dem Verschlüsselungsalgorithmus RSA.

Tag [engl.]

Als Tag wird im Rahmen einer Auszeichnungssprache eine Bereichsmarkierung bezeichnet, die Beginn und Ende eines Dokumentabschnitts kennzeichnet und diesem eine Bedeutung zuweist.

TCP (Transmission Control Protocol [engl.])

Verbindungsorientiertes Protokoll der Transportschicht im TCP/IP-Referenzmodell, welches auf IP aufsetzt.

TLS (Transport Layer Security [engl.])

Protokoll zur sicheren Datenübertragung über das Internet. Nachfolger von SSL.

Triple-DES (Triple Data Encryption Standard [engl.])

Ein symmetrisches Verfahren zur Verschlüsselung, basierend auf DES, das die Hintereinander-schaltung dreier DES-Ausführungen mit unabhängigen Schlüsseln einsetzt.

Trojanisches Pferd (engl. trojan horse)

Programm, welches sich als nützliches Werkzeug tarnt, jedoch schädlichen Programmcode ein-schleust und im Verborgenen unerwünschte Aktionen ausführt.

URL (Uniform Resource Locator [engl.])

Adressierungsschema für Dokumente und sonstige Dateien im Internet, bestehend aus Protokoll und Adresse.

Verbindlichkeit (engl. accountability)

Unter Verbindlichkeit werden die IT-Sicherheitsziele Authentizität und Nichtabstreitbarkeit zusam-mengefasst. Bei der Übertragung von Informationen bedeutet dies, dass die Informationsquelle ihre Identität bewiesen hat und der Empfang der Nachricht nicht in Abrede gestellt werden kann.

Verfügbarkeit (engl. availability)

Die Verfügbarkeit von Dienstleistungen, Funktionen eines IT-Systems, IT-Anwendungen oder IT-Netzen oder auch von Informationen ist vorhanden, wenn diese den Benutzern stets wie gewünscht zur Verfügung stehen. Verfügbarkeit ist ein Grundwert der IT-Sicherheit.



Verschlüsselung (engl. encryption)

Verschlüsselung (Chiffrieren) transformiert einen Klartext in Abhängigkeit von einer Zusatzinfor-mation, die Schlüssel genannt wird, in einen zugehörigen Geheimtext (Chiffrat), der für diejenigen, die den Schlüssel nicht kennen, nicht entzifferbar sein soll. Die Umkehrtransformation - die Zurückgewinnung des Klartexts aus dem Geheimtext - wird Entschlüsselung genannt.

Vertraulichkeit (engl. confidentiality)

Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Vertrauliche Daten und Informationen dürfen ausschließlich Befugten in der zulässigen Weise zugänglich sein. Vertraulich-keit ist ein Grundwert der IT-Sicherheit.

Virenschutzprogramm

Ein Virenschutzprogramm ist eine Software, die bekannte Computer-Viren, Computer-Würmer und Trojanische Pferde aufspürt, blockiert und gegebenenfalls beseitigt.

Virus (engl. virus)

Ein Computer-Virus ist eine nicht selbstständige Programmroutine, die sich nach ihrer Ausführung selbst reproduziert und dadurch vom Anwender nicht kontrollierbare Manipulationen in Systembe-reichen, an anderen Programmen oder deren Umgebung vornimmt.

VPN (Virtual Private Network [engl.])

Ein Virtuelles Privates Netz (VPN) ist ein Netz, das physisch innerhalb eines anderen Netzes (oft dem Internet) betrieben wird, jedoch logisch von diesem Netz getrennt wird. In VPNs können unter Zuhilfenahme kryptografischer Verfahren die Integrität und Vertraulichkeit von Daten geschützt und die Kommunikationspartner sicher authentisiert werden, auch dann, wenn mehrere Netze oder Rechner über gemietete Leitungen oder öffentliche Netze miteinander verbunden sind. Der Begriff VPN wird oft als Bezeichnung für verschlüsselte Verbindungen verwendet, zur Absicherung des Transportkanals können jedoch auch andere Methoden eingesetzt werden, beispielsweise spezielle Funktionen des genutzten Transportprotokolls.

VPS (Virtuelle Poststelle)

Die Virtuelle Poststelle des Bundes stellt als Basiskomponente "Datensicherheit" ein zentrales Sys-tem für den Einsatz von Kryptografie zur Verfügung. Sie soll die sichere elektronische Kommuni-kation zwischen Behörden und externen Partnern auf Behördenseite praktisch erleichtern und unter-stützen. Als Middleware wickelt sie kryptografische Operationen ab, die mit dem Einsatz elektroni-scher Signaturen und Verschlüsselung verbunden sind.

Wurm

Selbstständiges, sich selbst reproduzierendes Programm, das sich in einem System (vor allem in Netzen) ausbreitet.

X.509

Spezifizierung des Zertifikatsformats im Rahmen der X.500-Standard-Serie der ITU-T.



XML (Extensible Markup Language [engl.])

Eine Erweiterung der für die Entwicklung von Web-Seiten standardisierten Programmiersprache HTML. Daten können hierin nach vom Programmierer frei zu definierenden Regeln sehr flexibel in bestimmten Formaten dargestellt und so z. B. als Input für eine weiterverarbeitende Software genutzt werden.



10 Stichwort- und AbkürzungsverzeichnisAC (Access Control)..........................................................................................................................16ACL (Access Control List).................................................................................................................16ActiveX........................................................................................................................25, 58, 74f., 103Administrator..............................................................................................................55, 60, 64ff., 103AES (Advanced Encryption Standard)...................................................................................13, 31, 33Aktive Inhalte.........................................................................................................................................

ActiveX....................................................................................................................25, 58, 74f., 103Flash.......................................................................................................................................74, 106Java....................................................................................................................25, 58, 74, 103, 109JavaScript.............................................................................................................25, 58, 61, 74, 109

ALG (Application-Level Gateway)....................................................................................82, 103, 112API (Application Programming Interface)...................................................................................12, 15Applet...................................................................................................................25, 58, 74f., 103, 109ASCII (American Standard Code for Information Interchange)........................12, 20, 22f., 26, 56, 84Auszeichnungssprache.............................................................................................................107, 113Authentisierung................................................4, 8, 12f., 15ff., 34f., 42, 58, 60f., 63, 77, 91, 104, 110Backdoor.............................................................................................................................................78BCC (Block Check Count)...........................................................................................................21, 72Bedrohung...................................................................3, 67, 71ff., 78ff., 87ff., 96, 100, 104, 106, 111Betriebssystem.......................................................................36, 55, 60, 62, 68f., 76f., 103f., 106, 110Bit (Binary Digit)..................................................................................................20ff., 31, 56, 62, 108Blacklist.............................................................................27f., 38, 56, 59, 62, 64, 66, 68, 71, 76f., 92Bot-Netz...............................................................................................................................78, 91, 104CC (Common Criteria).................................................................................................................20, 72Chiasmus....................................................................................................................................86, 105Chipkarte..............................................................................................................................86, 89, 105Content............................................................................................................21ff., 27, 62, 81, 88, 105CRL (Certificate Revocation List).....................................................................30f., 46, 57, 89, 94, 98CSP (Cryptographic Service Provider)........................................................................................30, 57DAP (Directory Access Protocol)..........................................................................................15, 31, 98Dateianhang..................................................................................................................................72, 81Datensicherung.........................................................................................................................93f., 105DDoS (Distributed Denial of Service).....................................................................................90, 104f.DES (Data Encryption Standard).........................................................................................13, 33, 113DIF (Data Interchange Format)....................................................................................................27, 98Digitale Signatur.........................................................................................................4, 30, 44, 50, 106DoS (Denial of Service)...................................................................................5, 76, 78, 90, 92f., 105f.DSA (Digital Signature Algorithm)...........................................................................13, 31, 33, 45, 51DSN (Delivery Status Notification).......................................................................................14, 82, 98E-Mail (Electronic Mail)...................................................1ff., 7ff., 20ff., 31ff., 96f., 99f., 106, 109ff.ECDSA (Elliptic Curve Digital Signature Algorithm).......................................................................33Exploit....................................................................................................................................5, 65, 76f.Flash...........................................................................................................................................74, 106Frame....................................................................................................................................5, 74f., 106FTP (File Transfer Protocol)......................................................................................................68, 106Gefährdung.............................................................................................................................................

DDoS (Distributed Denial of Service)................................................................................90, 104f.



DoS (Denial of Service)..............................................................................5, 76, 78, 90, 92f., 105f.Hacking..................................................................................................................................67, 106Phishing........................................................4f., 27, 37f., 40, 55, 58f., 63f., 66, 78, 84, 90, 96, 110Spam..............................................................4f., 27f., 37ff., 55, 59, 64, 66, 78, 82, 90ff., 104, 112Spoofing.........................................................................................................................5, 78ff., 112

Gesetz.....................................................................................................................................................SigG (Signaturgesetz)..............................................................................................31, 35, 108, 112TKG (Telekommunikationsgesetz)................................................................................................64

GmbH (Gesellschaft mit beschränkter Haftung)................................................................................97Grafik..................................................................................................................................................62Grafikformat...........................................................................................................................................

JPEG (Joint Photographic Experts Group)....................................................................................24Grundarchitektur......................................................4, 7, 37, 55, 60, 67ff., 79ff., 84f., 87ff., 91ff., 100Grundkonfiguration...................................................5, 60, 63f., 67f., 71, 73ff., 78, 80, 83f., 92f., 100Hacking.......................................................................................................................................67, 106Ham..............................................................................................................................................28, 59Hardware......................................................................................................................67, 90, 105, 111Hash........................................................................................................................................31, 33, 63HTML (Hypertext Markup Language)...................4f., 22, 24f., 39, 56, 60f., 74f., 84, 103, 106f., 115HTTP (Hypertext Transfer Protocol).......................................................................15, 34, 53, 57, 107HTTPS (HTTP secure).........................................................................................................34, 42, 107Hyperlink........................................................................................................................56, 62, 84, 107ICO (Icon)..........................................................................................................................................81ID (Identifikations-Nummer)...............................................................................................21f., 50, 57IDEA (International Data Encryption Algorithm).......................................................................13, 33IDS (Intrusion Detection System)..................................................................................69, 81, 93, 107IE (Internet Explorer).........................................................................................................................25IETF (Internet Engineering Task Force)..........................................................................12, 97ff., 111IMAP (Internet Message Access Protocol)......4, 10, 12f., 16, 18, 28, 32, 34, 39, 41, 44, 50, 62f., 85, 97f.Intranet........................................................................................................................................34, 108IP (Internet Protocol)........................................................7, 15, 17f., 28, 64, 96, 98, 103, 108ff., 112f.IPSec (Internet Protocol Security)..............................................................................................86, 108ISi (Internet-Sicherheit)..........................................................................................................................

ISi-Check (ISi-Checkliste)...............................................................................................................7ISi-E (ISi-Einführung).............................................................................................................55, 97ISi-L (ISi-Leitfaden)........................................................................................................................7ISi-Reihe......................................................................................................................................3, 7ISi-S (ISi-Studie).................................................................................................................7, 21, 55

ISIS (Industrial Signature Interoperability Specification).......................................................35, 108f.ISIS-MTT (Industrial Signature Interoperability and Maitrust Specification)........................35, 108f.ISO (International Organization for Standardization)..........................................................22f., 56, 62IT-Grundschutz.....................................................................................................................65, 97, 108

IT-Grundschutz-Katalog................................................................................................................97IT-Sicherheit....................................................................................................................7, 107f., 113f.

Verbindlichkeit................................................................................................................34, 65, 113Vertraulichkeit.......7, 12, 26, 30f., 34, 50, 65, 67, 71, 73, 77, 81, 83, 85ff., 89, 96, 104, 108f., 114

Java.........................................................................................................................25, 58, 74, 103, 109JavaScript.................................................................................................................25, 58, 61, 74, 109JPEG (Joint Photographic Experts Group).........................................................................................24



Kerberos.............................................................................................................................................58Keylogger.....................................................................................................................................86, 89Kryptografie...............................................................................12f., 15, 30f., 48, 53, 57, 87, 109, 114LDAP (Lightweight Directory Access Protocol).............15, 19, 27, 31ff., 42, 44, 47, 53, 57f., 63, 98LDIF (LDAP Data Interchange Format)....................................................................................26f., 98Link.................................................................................................................................10, 24, 84, 107LINUX (LINUX)................................................................................................................................36Magic-Byte.........................................................................................................................................62Mailbox...............................................................................................................................................13MailTrusT......................................................................................................................4, 35f., 97, 109Makro.........................................................................................................................................68, 109Makro-Virus...............................................................................................................................68, 109MAPI (Messaging Application Programming Interface)...................................................4, 12, 15, 42MD5 (Message Digest Algorithm 5)......................................................................................17, 31, 33MDA (Mail Delivery Agent)................................................................................10, 13, 46, 48, 51, 53MIME (Multipurpose Internet Mail Extensions). .4f., 15, 20ff., 27, 31ff., 43ff., 54, 56f., 60f., 63, 66, 68, 71, 73, 79ff., 84f., 89, 91f., 94, 96ff., 109MP3 (Moving Picture Expert Group 1.0 Layer 3).............................................................................24MRA (Mail Relay Agent)..........................................................................................................9f., 37f.MTA (Mail Transfer Agent).................................................................9ff., 13, 15, 21f., 46, 48, 51, 53MTT (MailTrusT)........................................................................................................4, 35f., 97, 108f.MUA (Mail User Agent)..............................................................................................9ff., 37f., 40, 71NAT (Network Address Translation).........................................................................................18, 109OCR (Optical Character Recognition)...............................................................................................91OCSP (Online Certificate Status Protocol)..........................................31, 33f., 44, 46f., 57, 89, 94, 97OpenPGP (Open Pretty Good Privacy)...4f., 15, 31, 33ff., 49ff., 56f., 60f., 63, 66, 68, 71, 79ff., 84f., 89, 91f., 94, 96ff., 109OSS (Open Source Software).............................................................................................................36Paketfilter................................................................................29, 39, 41, 43ff., 49ff., 53, 59, 110, 112Passwort........................................................................................................13, 15, 17, 42, 57, 60, 110Patch...............................................................................................................65f., 69, 76f., 88, 90, 110PC (Personal Computer)..............................................................................5, 66, 78, 87, 91, 93f., 110PEM (Privacy Enhanced Mail)...................................................................................................35, 109PGP (Pretty Good Privacy)..................................................................................33, 35, 79f., 97, 109f.Phishing.............................................................4f., 27, 37f., 40, 55, 58f., 63f., 66, 78, 84, 90, 96, 110PIN (Persönliche Identifikationsnummer)..........................................................................................89PKCS (Public Key Cryptography Standards)...............................................................................30, 57PKI..........................................................................................................................................................

Public-Key-Verfahren............................................................................................................33, 111PKI (Public Key Infrastructure).......................................................................12, 30ff., 35f., 97f., 110Plug-In..................................................................................................5, 27, 32, 39, 47, 56f., 106, 110POP (Post Office Protocol).............................................................................10, 12, 17ff., 85, 97, 110POP3 (Post Office Protocol Version 3)...........................4, 12, 16ff., 28f., 34, 41, 44, 50, 62f., 94, 97Protokoll.................................................................................................................................................

FTP (File Transfer Protocol)..................................................................................................68, 106HTTP (Hypertext Transfer Protocol)...................................................................15, 34, 53, 57, 107HTTPS (HTTP secure)....................................................................................................34, 42, 107IP (Internet Protocol)...................................................7, 15, 17f., 28, 64, 96, 98, 103, 108ff., 112f.IPSec (Internet Protocol Security).........................................................................................86, 108LDAP (Lightweight Directory Access Protocol).........15, 19, 27, 31ff., 42, 44, 47, 53, 57f., 63, 98



POP (Post Office Protocol)........................................................................10, 12, 17ff., 85, 97, 110SMTP (Simple Mail Transfer Protocol).....4, 12ff., 21, 28, 34, 39, 41, 44, 50, 62f., 79, 82, 85, 92, 97ff., 109, 112SMTPS (Secure SMTP over TLS).............................................................15, 18, 41, 56, 58, 63, 80SOAP (Simple Objekt Access Protocol).......................................................................................34SSL (Secure Sockets Layer)..........................................................12f., 15ff., 41, 62f., 85, 107, 113TCP (Transmission Control Protocol)..........................................12f., 18f., 96, 103, 108, 110, 113Telnet (Teletype Network).............................................................................................................14TLS (Transport Layer Security)......................................12f., 15ff., 41, 58, 62f., 85, 97f., 107, 113X.500 (CCITT Directory Services Protocol).........................................................................31, 114

Proxy.......................................................................................................31ff., 44, 47, 82, 90, 103, 110PS (PostScript).................................................................................................................................24f.PSH (Push).................................................................................................................................12f., 40Public-Key-Verfahren................................................................................................................33, 111RC2 (RC2-Algorithmus)..............................................................................................................13, 31RC4 (RC4-Algorithmus)..............................................................................................................13, 63Restrisiko.........................................................................................................67, 69ff., 91ff., 100, 111RFC (Request for Comments)........................12f., 15ff., 23, 25ff., 31, 33, 35, 41f., 63, 82, 97ff., 111RIPEMD (RACE Integrity Primitives Evaluation)............................................................................33Risiko.................................................................................3, 25, 55, 67, 69f., 77, 83, 86, 89, 108, 111Router...............................................................................................................................................109RPC (Remote Procedure Call)......................................................................................................15, 42RSA (Rivest, Shamir, Adleman Public Key Encryption).......................................13, 31, 33, 111, 113RTF (Rich Text Format).....................................................................................................................25SASL (Simple Authentication and Security Layer)........................................15f., 18, 42, 58, 63, 98f.Schadprogramm..............................3, 11, 28f., 39f., 54, 58f., 61ff., 66, 68ff., 78, 81f., 89f., 92f., 106

Backdoor........................................................................................................................................78Keylogger.................................................................................................................................86, 89Spyware.....................................................................................................5, 28, 39, 58, 63, 83, 113Trojanisches Pferd.........................................................................................5, 39, 63, 78, 86, 113f.Virus.......................................................5, 11, 28, 39, 58, 63, 65ff., 71, 78, 82f., 86, 106, 109, 114Wurm...............................................................................................................................67, 78, 114

Schutzbedarf.........................................4f., 7, 37, 55, 67, 69, 71ff., 76f., 81, 85ff., 89, 100, 108, 111f.Schwachstelle.........................................................................29, 56, 65ff., 69ff., 78ff., 87ff., 106, 111SHA (Secure Hash Algorithm).....................................................................................................31, 33SHA-1 (Secure Hash Algorithm 1)..............................................................................................31, 33Sicherheits-Gateway................................................................................41, 44ff., 50f., 53, 108f., 112

ALG (Application-Level Gateway)...............................................................................82, 103, 112Paketfilter...........................................................................29, 39, 41, 43ff., 49ff., 53, 59, 110, 112

Sicherheitsgrundwerte........................................................................................................................67SigG (Signaturgesetz)...................................................................................................31, 35, 108, 112Signatur...................................................................................................................................................

Digitale Signatur....................................................................................................4, 30, 44, 50, 106Skript....................................................................................................................................74, 91, 112SMTP (Simple Mail Transfer Protocol) 4, 12ff., 21, 28, 34, 39, 41, 44, 50, 62f., 79, 82, 85, 92, 97ff., 109, 112SMTP-Auth (SMTP-Authentifizierung)..........................................................................................17f.SMTPS (Secure SMTP over TLS).................................................................15, 18, 41, 56, 58, 63, 80SOAP (Simple Objekt Access Protocol)............................................................................................34Spam...................................................................4f., 27f., 37ff., 55, 59, 64, 66, 78, 82, 90ff., 104, 112



SPHINX.........................................................................................................................4, 35f., 99, 112Spoofing..............................................................................................................................5, 78ff., 112Spyware..........................................................................................................5, 28, 39, 58, 63, 83, 113SSH (Secure Shell).............................................................................................................................85SSL (Secure Sockets Layer)...............................................................12f., 15ff., 41, 62f., 85, 107, 113Tag................................................................................................................................5, 75f., 104, 113TCP (Transmission Control Protocol)...............................................12f., 18f., 96, 103, 108, 110, 113TCP Control Flags..................................................................................................................................

PSH (Push)............................................................................................................................12f., 40Telnet (Teletype Network).................................................................................................................14TKG (Telekommunikationsgesetz)....................................................................................................64TLS (Transport Layer Security)..........................................12f., 15ff., 41, 58, 62f., 85, 97f., 107, 113TMG (Telemediengesetz)...................................................................................................................64Transportschicht...............................................................................................................103, 110, 113Triple-DES (Triple Data Encryption Standard)...........................................................................31, 33Trojanisches Pferd..............................................................................................5, 39, 63, 78, 86, 113f.TSL (Tristate Logic)...........................................................................................................................61UBE (Unsolicited Bulk E-Mail).........................................................................................................90UCE (Unsolicited Commercial E-Mail).............................................................................................90URL (Uniform Resource Locator)...........................................27, 38, 56, 59, 62, 64, 75, 84, 107, 113Validierung..................................................................................................................30f., 41, 46f., 50Vektorgrafik.....................................................................................................................................106Verbindlichkeit.....................................................................................................................34, 65, 113Verschlüsselung......................................................................................................................................

Chiasmus................................................................................................................................86, 105Vertraulichkeit............7, 12, 26, 30f., 34, 50, 65, 67, 71, 73, 77, 81, 83, 85ff., 89, 96, 104, 108f., 114Virenschutz............................................................................................28f., 39, 58, 63, 66f., 69ff., 78Virenschutzprogramm.................4f., 27ff., 34, 37, 39f., 54f., 58, 62f., 66, 68f., 71ff., 78, 93, 96, 114Virtuelle Poststelle............................................................................31, 34, 54, 56, 80, 85, 96, 99, 114Virus......................4f., 11, 27ff., 34, 37, 39f., 54f., 58, 62f., 65ff., 78, 82f., 86, 93, 96, 106, 109, 114VPN (Virtual Private Network)..................................................................................................86, 114VPS (Virtuelle Poststelle).......................................5, 31, 34, 37, 54, 56, 71, 79ff., 85, 94, 96, 99, 114VS (Verschlusssache).........................................................................................................................86Webserver...............................................................................................................................68, 74, 91Whitelist.................................................................................................................................28, 59, 62Wurm....................................................................................................................................67, 78, 114WWW (World Wide Web).................................................................................................84, 104, 107X.500 (CCITT Directory Services Protocol)..............................................................................31, 114X.509............................................................................................................................31, 57, 97f., 114XML (Extensible Markup Language)..................................................................................26, 34, 115Zertifikat..........................................................................30ff., 42ff., 50ff., 57, 61, 72, 86, 89, 94, 114Zertifikatsspeicher................................................................................................................32f., 47, 57


sichere nutzung von e-mail (isi-s)

Documents