Payment Card Industry Data Security Standard mit Microsoft Windows Server 2008 · 2013-03-30 · Auszug 1. ZUSAMMENFASSUNG Die Analyse, welche Anforderungen der PCI DSS Version 1.2

Florian Sailer

Payment Card Industry Data Security Standard

mit Microsoft® Windows Server® 2008

Verfügbar als Monographie ab November 2009

ISBN 978-3-639-20772-9

Auszug

Kurzbeschreibung

Die verpflichtende Einhaltung von Normen und Standards ist bei Entwick-

lung, Umsetzung und Betrieb eines IT Projektes oder Produktes keine Sel-

tenheit mehr. Der Umgang mit regulativen Anforderungen ist dem tägli-

chen Geschäft hinzuzufügen und als fester Bestandteil einer IT Service

Strategie zu betrachten.

Payment Card Industry (PCI) Data Security Standard (DSS) ist der Stan-

dard zur Aufrechterhaltung der Sicherheit bei Verarbeitung und Speiche-

rung von Kreditkarteninformationen. Gültig für alle Organisationen, die am

Transaktionsprozess beteiligt sind, werden, je nach Vorgabe des sich im

Einsatz befindlichen Kreditkarteninstituts, die getroffenen Maßnahmen zur

Umsetzung der Anforderungen durch Selbst-Audits oder unabhängige On-

Site-Audits, auf Konformität überprüft. Abweichungen können mit Bußgel-

dern oder Lizenzentzug geahndet werden.

Um Kosten und Aufwand einer PCI DSS-konformen Kreditkartenumge-

bung minimeren zu können, ist eine Evaluation und Auswahl adäquater

Sicherheitstechnologien-, Architekturen und Serverplattformen unabding-

bar.

Microsoft stellt mit seinem Produkt Windows Server 2008 kosteneffiziente

Technologien und Methoden zur Verfügung, die aufgrund ihrer sicherheits-

technischen Merkmale einzelnen PCI DSS Richtlinien entsprechen. Ein

detaillierter Vergleich der unterschiedlichen Anforderungen mit angebote-

nen Produktfeatures und Einstellungen ergibt, dass Windows Server 2008

als Basissystem zur Bereitstellung eines Payment-Service eingesetzt und

hinsichtlich PCI DSS optimal erweitert werden kann.

Auszug

1. ZUSAMMENFASSUNG

Die Analyse, welche Anforderungen der PCI DSS Version 1.2 mit Win-

dows Server 2008 Konfigurationsoptionen im Architektur-, Feature- und

Servicebereich umgesetzt werden können, ergibt folgendes Resultat:

Es wird keine von zwölf PCI DSS Anforderungen auf erster Ebene

mit Windows Server 2008 Enterprise ohne Installation zusätzlicher

Software abgedeckt.

Durch integrierte Windows Server 2008 Enterprise Konfigurations-

optionen werden in Summe elf von 62 PCI DSS Anforderungen auf

zweiter Ebene und 40 von 143 PCI DSS Anforderungen auf dritter

Ebene erfüllt.

Die einzelnen Requirements werden anhand der definierten Untersu-

chungsdimensionen Planung, Installation, Konfiguration und Betrieb

zugeordnet.

Die detaillierten Ergebnisse dazu sind dem Appendix zu entnehmen.

1.1. PLANUNG

Im Architekturbereich ist das Restricted-Access-Forest-Design und das

Single Domain Model bereits ohne zusätzliche Anpassung PCI DSS-

konform. Folgende Eigenschaften werden dabei verwendet:

Die zentrale Identitätssteuerung mit AD DS umfasst die Anforde-

rungen 8.1, 8.5.5 und 8.5.8.

Das AD DS Rechteverwaltungssystem und die AD Sicherheitsgrup-

pen erfüllen die rollenbasierte Zugriffssteuerung aus Anforderung

7.2.2.

Auszug

Mit NTLM und Kerberos werden die Anforderungen 8.2, 8.4 und

12.3.2 an Authentifizierungsmaßnahmen abgedeckt.

Durch LSASS wird die automatisierte Zugriffskontrolle der Anforde-

rungen 7.1.4 und 7.2.3 umgesetzt.

CNG Suite B ermöglicht den Einsatz starker Kryptographie Algo-

rithmen für Anforderung 3.6.1.

Durch vordefinierte EventLog-Details werden vollständige Prüfver-

fahrenseinträge für Anforderung 10.3 implementiert.

Der PDC Emulator ist mit der automatischen Systemuhrensynchro-

nisation für Anforderung 10.4 verantwortlich.

Multiple Kennwort- und Kontorichtlinien sowie ein einheitliches Ressour-

cen- und Berechtigungsschema basieren auf anerkannten und standardi-

sierten Technologien und vervollständigen die Lösung in der Konfigurati-

onsphase.

Mit Hilfe des MSF kann ein Projektplan zur Implementierung erstellt wer-

den, der die Besonderheiten der Microsoft Technologie berücksichtigt. Zu-

sätzlich werden durch den Infrastructure Planing and Design Guide Refe-

renzarchitekturen von Microsoft für Komplettsysteme vorgestellt, die her-

angezogen werden können.

1.2. INSTALLATION

Durch das neue Rollenkonzept kann die Installation von Funktionen ein-

zelner Server genau angepasst sowie die Steuerung mit Hilfe eines um-

fangreichen Server-Managers benutzerfreundlich verwaltet werden. Dies

wird zur Umsetzung der Anforderung 2.2.1 eingesetzt.

Eine Härtung der Systeminstallation erfolgt mittels ICT Manager, SCW und

veröffentlichten SSLF Vorlagen aus dem Security Compliance Toolkit, die

Auszug

als GPO zentral konfiguriert und automatisch verteilt und angewendet

werden können.

Features wie das SSLF Template fungieren als Konfigurationsstandard für

Anforderung 2.2 und 2.2.3, SCW dient als Systemhärtungsverfahren für

Anforderung 2.2.2.

Mit der Installationsoption Server Core existiert ein Feature, das die An-

griffsfläche auf ein Minimum reduziert und den Fokus auf eine unterbre-

chungsfreie Ausführung des Serverdienstes legt. Anwendung findet dies

bei der Anforderung 2.2.4.

Zur Bereitstellung einer verschlüsselten Fernwartung mit Zwei-Faktor-

Authentifizierung erlaubt AD CS den Aufbau einer vollwertigen internen

PKI mit X.509v3 Zertifikatausstellung für Benutzer und Computer. Verbin-

dungen über TS-Gateway oder SSTP unterstützen mit CNG, die in PCI

DSS definierte starke Verschlüsselung sowie ein Smartcard-basiertes

RBAC zur Durchführung administrativer Aufgaben.

Installierte Features und Services wie die Remote-Zugriff-Verschlüsselung

bei TS-Gateway und SSTP sind relevant für Anforderung 2.3. Mit Smart-

cards für zwei-Faktor-Authentifizierung werden die Anforderungen 8.3 und

8.5.8 ermöglicht.

Um den Ansprüchen einer individuellen Payment-Lösungs-Applikation hin-

sichtlich Stabilität, Skalierbarkeit und Ausfallssicherheit gerecht zu werden,

steht mit IIS 7.0 ein modular konfigurierbarer Webapplikationsserver be-

reit, der das .NET Framework nativ sowie SSL 3.0 implementiert und der

als Cluster installiert werden kann. Mit der einstellbaren Einschränkung auf

SSL Version 3.0 oder höher wird Anforderung 4.1 erfolgreich umgesetzt.

Auszug

1.3. KONFIGURATION

Konfiguration und Parametrierung sind über lokal oder remote installierte

Windows Administrationsprogramme möglich und mit einer Benutzerober-

fläche ausgestattet.

Durch DACL- und SACL-Einträge auf Objekte im NTFS und AD Verzeich-

nis ist eine granulare Rechtedelegation und Überwachung möglich. Sys-

temweite Audit-Richtlinien vervollständigen die Konfiguration und Aktivie-

rung eines Audit-Trails. In Kombination sind folgende Implementierungen

umsetzbar:

Das Privilegienmodell mit Lese-, Erstellungs- und Änderungsrech-

ten bietet Konformität mit Anforderung 8.5.1.

Eine kontinuierliche und systemweite Protokollierung nach Anforde-

rung 10.1 wird mit Audit-Policies erfüllt.

Bei Aktivierung der Audit-Policies Audit Account Logon Events, Au-

dit Logon Events, Audit Account Management, Audit Directory Ser-

vice Access, Audit Change Policy, Audit System Events, Audit Ob-

ject Access und Directory Service Changes werden die Anfor-

derungen 10.2.2, 10.2.3, 10.2.4, 10.2.5, 10.2.6 und 10.2.7 ab-

gedeckt.

Durch die dedizierte Privilegienvergabe SeSecurityPrivilege erfolgt

eine Audit-Log Zugriffsbeschränkung für Benutzer, die in den An-

forderungen 10.5.1 und 10.5.2 vorgeben sind.

Kennwort- und Kontorichtlinien können durch Anpassung der folgenden

Einstellungen PCI-DSS-konform gestaltet werden:

Die Password Properties Option User Must Change Password At

Next Logon erfordert eine sofortige Änderung des Passworts nach

erster Verwendung und ermöglicht damit Anforderung 8.5.3.

Auszug

Die Account Properties Optionen Account Expires, Account Is

Disabled, Logon Hours und Idle Session Limit erwirken direkte oder

zeitlich abhängige Begrenzungen der Anmeldung und erfüllen da-

mit die Anforderungen 8.5.4, 8.5.6, 8.5.15 und 12.3.8.

Die Password Policy Konditionen MaximumPasswordAge,

MinimumPasswordLength, PasswordComplexity und

PasswordHistorySize implementieren die Anforderungen 8.5.9,

8.5.10, 8.5.11 und 8.5.12.

Mit den Account Lockout Policy Richtlinien LockoutBadCount und

LockoutDuration werden die Anforderungen 8.5.13 und 8.5.14 um-

gesetzt.

Zugriff und Änderungen an systemgeschützten Dateien werden durch

WinRP verhindert oder aufgrund von Audit Policies-Einstellungen in den

EventLogs vermerkt. Dabei wird die betriebssystemspezifische Dateiinteg-

rität für Anforderung 11.5 abgedeckt.

Über HTTPS Event Forwarding erfolgt die Übertragung und Zusammen-

führung auf einen zentralen Protokollserver, der mittels Windows Server

Backup täglich gesichert wird. Dieses Feature erfüllt die Anforderung an

eine sofortige Sicherung der Audit-Trail-Daten für Anforderung 10.5.3.

1.4. BETRIEB

Das Best-Practice Verwaltungsmodel der Windows Server 2008 Server-

umgebung ist eine Fokussierung auf die Möglichkeiten, die zentrale GPOs

mit den Computer- und Benutzerrichtlinien anbieten. Mit einer enormen

Anzahl an vorgefertigten Einstellungsoptionen und einer uneingeschränk-

ten Erweiterung durch neue Werte für die Registrierungsdatenbank, zu-

sammengefasst in administrativen Vorlagen, sind komplette Konfigurati-

onsschemata auf Server und Clients im AD anwendbar. Angewendet wird

Auszug

dies bei der Konfiguration des RDP Parameters Device Redirection Clip-

board für Anforderung 12.3.10.

OUs und Gruppen erlauben eine Unterteilung anhand von Funktionen, die

nicht nur von sicherheitstechnischer Bedeutung sind, sondern auch den

Gültigkeitsbereich von GPOs festlegen.

Auch wenn das Privileg der Zuweisung von GPOs an spezielle Personen

delegiert werden kann, ist eine Nachvollziehbarkeit aller Änderungen des

Inhaltes nur mit formalen Prozessen und schriftlicher Dokumentation auf-

recht zu erhalten.

Auszug

2. LITERATURVERZEICHNIS

FACHLITERATUR

Davies, Joseph (2008): Windows Server 2008 TCPIP Protocols and Services. Redmond, Wash.: Microsoft Press.

Davies, Joseph; Tony Northrup (2008): Windows Server® 2008. Net-working and Network Access Protection (NAP). Redmond, Wash.: Microsoft Press (Windows Server 2008 Resource Kit / Microsoft, 5).

Holme, Dan (2008): Windows® Administration Resource Kit. Productivity Solutions for IT Professionals. Redmond, Wash.: Microsoft Press (Windows Server 2008 Resource Kit / Microsoft, 2).

Holme, Dan; Nelson Ruest; Danielle Ruest (2008): MCTS Self-Paced Training Kit (Exam 70-640). Configuring Windows Server 2008 Active Directory. Redmond, Wash.: Microsoft.

Johansson, Jesper M. (2008): Microsoft® Windows Server 2008 Security Resource Kit. Redmond, Wash.: Microsoft Press (Windows Server 2008 Resource Kit / Microsoft, 3).

Komar, Brian (2008): Windows Server 2008 PKI and Certificate Security. Redmond, Wash.: Microsoft Press.

Mackin, J. C.; Anil Desai (2008): MCTS Self-Paced Training Kit (Exam 70-643). Configuring Windows Server 2008 Applications Infrastructure. Redmond, Wash.: Microsoft Press.

Mackin, J. C.; Anthony Northrup (2008): MCTS Self-Paced Training Kit (Exam 70-642). Configuring Windows Server 2008 Network Infrastructure. Redmond, Wash.: Microsoft Press.

McLean, Ian; Thomas Orin (2008): MCITP Self-Paced Training Kit (Exam 70-646). Windows Server Administration. Redmond, Wash.: Microsoft Press.

Auszug

Reimer, Stan; Conan Kezema; Mike Mulcare (2008): Windows® Serv-er® 2008 Active Directory® Resource Kit. Redmond, Wash.: Microsoft Press (Windows Server 2008 Resource Kit / Microsoft, 4).

Stanek, William R. (2008): Windows Server 2008 Inside Out. Redmond, Wash.: Microsoft Press.

Thomas, Orin; John Policelli; Ian McLean (2008): MCITP Self-Paced Training Kit (Exam 70-647). Windows Server Enterprise Administration. Redmond, Wash.: Microsoft Press.

Tulloch, Mitch (2003): Microsoft Encyclopedia of Security. Redmond, Wash.: Microsoft Press.

Tulloch, Mitch (2007): Introducing Windows Server 2008. Redmond, Wash.: Microsoft Press.

Tulloch, Mitch (2008): Windows Vista Resource Kit, Second Edition. 2nd ed. Redmond, Wash.: Microsoft Press.

Volodarsky, Mike (2008): Internet Information Services 7.0 Resource Kit. Redmond, Wash.: Microsoft Press (Windows Server 2008 Resource Kit / Microsoft, 1).

Wilson, Ed (2008): Windows PowerShell Scripting Guide. Redmond, Wash.: Microsoft Press (Windows Server 2008 Resource Kit / Microsoft, 6).

INTERNETLINKS

Augsten, Stephan (2008): Warum Unternehmen den PCI Data Security Standard einhalten sollten. PCI-DSS-Compliance wird für Kreditkarten-Unternehmen zur Pflicht-Aufgabe. Online verfügbar unter http://www.searchsecurity.de/themenbereiche/sicherheits-management/compliance/articles/100998/.

Davies, Joseph (2007): The Cable Guy. The Secure Socket Tunneling Protocol. Online verfügbar unter http://technet.microsoft.com/ en-us/magazine/2007.06.cableguy.aspx.

Auszug

Dietrich, Michael W. (2001): Das Microsoft Solutions Framework. He-rausgegeben von Microsoft Corporation. Online verfügbar unter http://msdn.microsoft.com/de-de/library/bb979125.aspx.

Lyon, Gordon (2006): Top 10 Vulnerability Scanners. Online verfügbar unter http://sectools.org/vuln-scanners.html.

ICSA Labs (2007): ICSA Labs Certified Anti-Virus Products. Online ver-fügbar unter https://www.icsalabs.com/icsa/main.php? pid=b31a$6140dfe3-4a851ebd$eaa4-72b.

ISC2 (2008): CSSLP - Certified Secure Software Lifecycle Professional. Online verfügbar unter http://www.isc2.org/csslp-whitepaper.aspx.

Johansson, Jesper M. (2008): Microsoft TechNet - TechNet Magazine. Sicherheit auf dem Prüfstand. Verwenden des SCW unter Windows Ser-ver 2008. Online verfügbar unter http://technet.microsoft.com/ de-de/magazine/2008.03.securitywatch.aspx.

Lukawiecki, Rafal (2007): Microsoft Solutions Framework 4.0 Core and its Families. Herausgegeben von Microsoft Corporation. Online verfügbar unter http://download.microsoft.com/download/1/b/0/ 1b0d95a3-40be-41ce-a40d-512a5f869938/DEV210_Lukawiecki.pptx.

Microsoft Corporation (2005): The Trustworthy Computing Security De-velopment Lifecycle. Online verfügbar unter http://msdn.microsoft.com/ en-us/library/ms995349.aspx.

Microsoft Corporation (2007): Microsoft Knowledge Base: 187498. De-aktivieren von PCT 1.0, SSL 2.0, SSL 3.0 oder TLS 1.0 in Internet Infor-mation Services. Version: 7.2. Online verfügbar unter http://support.microsoft.com/kb/187498.

Microsoft Corporation (2007): Microsoft Malware Protection Center. Threat Research and Response. Online verfügbar unter http://www.microsoft.com/security/portal/default.aspx.

Microsoft Corporation (2008): IT Compliance Management Guide. Ver-sion 1.0. Online verfügbar unter http://go.microsoft.com/fwlink/?linkid=56419.

Auszug

Microsoft Corporation (2008): Microsoft TechNet. Online verfügbar unter http://technet.microsoft.com.

Microsoft Corporation (2008): Microsoft® Operations Framework. Versi-on 4.0. MOF Overview. Online verfügbar unter http://www.microsoft.com/downloads/details.aspx?FamilyId=457ED61D-27B8-49D1-BACA-B175E8F54C0C&displaylang=en.

Microsoft Corporation (2008): Windows Server 2008. Potenziale dyna-misch realisieren. Online verfügbar unter http://download.microsoft.com/download/1/b/7/1b70385b-246d-4c1d-a46a-9daaf93b3f7a/WS08_EndkBrosch%20SalesGuide.pdf.

Microsoft Corporation (2008): Windows Server 2008 Datenblatt. Online verfügbar unter http://go.microsoft.com/?linkid=8554744.

Microsoft Corporation (2008): Windows Server® 2008 Security Guide. Security Compliance Management Toolkit. Version 3.0. Online verfügbar unter http://www.microsoft.com/wssg.

Microsoft Corporation (2009): Infrastructure Planning and Design Guide Series. Version 1.0. Online verfügbar unter http://www.microsoft.com/ipd.

Microsoft Corporation (2009): Microsoft Developer Network. Online ver-fügbar unter http://msdn.microsoft.com.

Microsoft Corporation (2009): Microsoft Solution Accelerators. Online verfügbar unter http://technet.microsoft.com/ en-us/solutionaccelerators/default.aspx.

Microsoft Corporation (2009): Planungshandbuch zur Einhaltung des Payment Card Industry Data Security Standard (PCI DSS). Online verfüg-bar unter http://technet.microsoft.com/de-de/library/bb821241.aspx.

Microsoft Corporation (2009): What's New for Information Protection in Windows Server 2008. Online verfügbar unter http://technet.microsoft.com/de-de/library/cc732879.aspx.

Microsoft Corporation (2009): What's New for Security in Windows Server 2008. Online verfügbar unter http://technet.microsoft.com/ de-de/library/cc725998.aspx.

Auszug

Microsoft Corporation (2009): Windows Server 2008. Online verfügbar unter http://www.microsoft.com/germany/windowsserver2008/.

National Computer Emergency Reponse Team of Austria (2008): CERT.at. Online verfügbar unter http://www.cert.at.

National Institute of Standards and Technology (2007): Computer Se-curity Division. Computer Security Resource Center. Online verfügbar un-ter http://csrc.nist.gov/publications/PubsTC.html.

Open Web Application Security Project (2005): OWASP Development Guide 2.0. Online verfügbar unter http://www.owasp.org/index.php/Category:OWASP_Guide_Project.

PCI Security Standards Council LLC (2006): Payment Card Industry (PCI) Data Security Standard. Validation Requirements for Approved Scanning Vendors (ASV). Version 1.1. Online verfügbar unter https://www.pcisecuritystandards.org/pdfs/pci_dss_validation_ requirements_for_approved_scanning_vendors_ASVs_v1-1.pdf.

PCI Security Standards Council LLC (2008): Lifecycle Process for Changes to PCI DSS. Online verfügbar unter https://www.pcisecuritystandards.org/pdfs/OS_PCI_Lifecycle.pdf.

PCI Security Standards Council LLC (2008): Payment Card Industry (PCI) - Datensicherheitsstandard PCI-DSS-Navigation. Verständnis der Intention der Anforderungen. Version 1.2. Online verfügbar unter https://www.pcisecuritystandards.org/security_standards/docs/ navigating_dss_de.pdf.

PCI Security Standards Council LLC (2008): Payment Card Industry (PCI) - Datensicherheitsstandard Selbstbeurteilungs-Fragebogen. Anlei-tung und Richtlinien. Online verfügbar unter http://www.pcisecuritystandards.org/saq/index.shtml.

PCI Security Standards Council LLC (2008): Payment Card Industry (PCI) Data Security Standard. Attestion of Compliance for Onsite Assess-ments - Merchants. Version 1.2. Online verfügbar unter https://www.pcisecuritystandards.org/saq/docs/aoc_merchants.doc.

Auszug

PCI Security Standards Council LLC (2008): Payment Card Industry (PCI) Data Security Standard. Summary of Changes from PCI DSS Versi-on 1.1 to 1.2. October 2008. Online verfügbar unter https://www.pcisecuritystandards.org/pdfs/pci_dss_summary_of_changes_v1-2.pdf.

PCI Security Standards Council LLC (2008): Payment Card Industry (PCI) Data Security Standard Validation Requirements. For Qualified Se-curity Assessors (QSA). Version 1.1a. Online verfügbar unter https://www.pcisecuritystandards.org/pdfs/pci_dss_validation_requirements_for_qualified_security_assessors_QSAs_v1-1.pdf.

PCI Security Standards Council LLC (2008): Payment Card Industry (PCI) Datensicherheitsstandard. Anforderungen und Sicherheitsbeurtei-lungsverfahren. Version 1.2. Online verfügbar unter https://www.pcisecuritystandards.org/pdfs/pci_dss_german.pdf.

PCI Security Standards Council LLC (2008): Payment Card Industry (PCI)- Datensicherheitsstandard (DSS) und Payment Application (PA)- Datensicherheitsstandard (PA-DSS). Glossar für Begriffe, Abkürzungen und Akronyme. Online verfügbar unter https://www.pcisecuritystandards.org/pdfs/pci_dss_glossary.pdf.

PCI Security Standards Council LLC (2008): PCI Quick Reference Guide. Understanding the Payment Card Industry Data Security Standard version 1.2. Online verfügbar unter https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf.

PCI Security Standards Council LLC (2008): Ten Common Myths of PCI DSS. Online verfügbar unter https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf.

PCI Security Standards Council LLC (2009): The Prioritized Approach to Pursue PCI DSS Compliance. Online verfügbar unter https://www.pcisecuritystandards.org/education/docs/Prioritized_Approach_PCI_DSS_1_2.pdf.

SecurityFocus (2008): BugTraq. Online verfügbar unter http://www.securityfocus.com.

Auszug

Silver, Michael A.; Brian Gammage (2008): Quantifying the Value of Mi-crosoft's Desktop Optimization Pack. Herausgegeben von Gartner. (G00159236). Online verfügbar unter http://download.microsoft.com/download/3/E/F/3EF3E1DB-536B-4854-89D0-1D50D1A5FA3C/quantifying_the_value_of_mic_159236.pdf.

The SANS™ Institute (2000): SANS' Information Security Reading Room. Online verfügbar unter http://www.sans.org/reading_room/.

The SANS™ Institute (2000): SANS Internet Storm Center. Online ver-fügbar unter http://isc.sans.org.

Visa (2009): Merchants. Compliance validation details for merchants. On-line verfügbar unter http://usa.visa.com/merchants/risk_management/cisp_merchants.html.

Zetter, Kim (2009): PIN Crackers Nab Holy Grail of Bank Card Security. Online verfügbar unter http://blog.wired.com/27bstroke6/2009/04/pins.html.

Auszug

3. APPENDIX

Payment Card Industry Data Security Standard Version 1.2

Systemkomponente Windows Server 2008

Anforderung Anweisung Prüfverfahren Implementierung Kommentar

2.2 Entwickeln von Konfigu-

rationsstandards für alle

Systemkomponenten.

Gewährleisten, dass diese

Standards alle bekannten

Sicherheitslücken adressie-

ren und branchenweit

akzeptierten Standards zur

Systemstabilisierung ent-

sprechen.

Viele Schwachstellen von

Betriebssystemen, Daten-

banken und Unterneh-

mensanwendungen sind

bekannt. Doch es existieren

auch Methoden, um diese

Systeme so zu konfigurie-

ren, dass Sicherheitslücken

geschlossen werden. Um

Personen zu unterstützen,

die keine Sicherheitsexper-

ten sind, haben Sicher-

heitsunternehmen Empfeh-

lungen zur Systemstabilisie-

rung aufgestellt, die eine

Anleitung zur Behebung

dieser Schwachstellen

bieten. Werden die

Schwachstellen von Syste-

men nicht behoben – z. B.

schwache Dateieinstellun-

gen oder Dienst- und Pro-

tokollstandardeinstellungen

(für häufig nicht benötigte

Dienste oder Protokolle) –,

kann ein Angreifer mehrere,

bekannte Exploits nutzen,

um anfällige Dienste und

Protokolle anzugreifen und

so Zugang zu Ihrem Unter-

nehmensnetzwerk zu erhal-

ten. Auf den folgenden drei

Websites können Sie sich

über die branchenüblichen

bewährten Methoden infor-

mieren, die Sie bei der

Implementierung von Konfi-

gurationsstandards unter-

2.2.a Überprüfen Sie die

Systemkonfigurationsstan-

dards des Unternehmens

für alle Arten von System-

komponenten, und prüfen

Sie, ob die Systemkonfigu-

rationsstandards bran-

chenweit akzeptierten

Standards zur Systemstabi-

lisierung entsprechen, wie

z. B. SysAdmin Audit Net-

work Security (SANS),

National Institute of Stan-

dards Technology (NIST)

und Center for Internet

Security (CIS).

2.2.b Überprüfen Sie, dass


dards jedes der unten

(unter2.2.1 - 2.2.4) aufge-

führten Elemente enthalten.

2.2.c Überprüfen Sie, ob


dards angewendet werden,

wenn neue Systeme konfi-

guriert werden.

Windows Server 2008

Security Guide

Specialized Security –

Limited Functionality Tem-

plate

GPOAccelerator

http://www.microsoft.com/w

ssg

SSLF Template fungiert als

Basis für den Konfigurati-

onsstandard

stützen können:

www.nist.gov,

www.sans.org,

www.cisecurity.org.

2.2.1 Implementieren nur

einer primären Funktion pro

Server.

Damit soll sichergestellt

werden, dass die System-

konfigurationsstandards

Ihres Unternehmens sowie

damit verbundene Prozesse

Serverfunktionen angehen,

die über verschiedene

Sicherheitsstufen verfügen

müssen oder die Sicher-

heitsschwächen bei ande-

ren Funktionen auf demsel-

ben Server verursachen

können. Beispiel:

1. Eine Datenbank erfordert

starke Sicherheitsmaßnah-

men. Würde eine Daten-

bank einen Server mit einer

Webanwendung teilen, die

offen und unmittelbar an

das Internet angebunden

sein muss, wäre die Daten-

bank einem hohen Risiko

ausgesetzt.

2. Wird versäumt, einen

Patch für eine scheinbar

unwichtige Funktion anzu-

wenden, könnte dies zu

einem Sicherheitsangriff

führen, durch den andere,

wichtigere Funktionen (z. B.

eine Datenbank) auf dem-

selben Server beeinträchtigt

würden. Diese Anforderung

bezieht sich auf Server (in

der Regel Unix-, Linux-

oder Windows-basiert) und

nicht auf Mainframe-

Systeme.

2.2.1 Überprüfen Sie für

eine Stichprobe von Sys-

temkomponenten, dass nur

eine primäre Funktion pro

Server implementiert ist.

Webserver, Datenbankser-

ver und DNS sollten bei-

spielsweise auf separaten

Servern implementiert sein.

Windows Server 2008

Roles

Server Manager

Technische Lösung für den


dard

2.2.2 Deaktivieren aller

unnötigen und unsicheren

Dienste und Protokolle

(nicht direkt für die Ausfüh-

rung der spezifischen Gerä-

tefunktion erforderliche

Funktionen)

Wie unter 1.1.7 ausgeführt,

existieren viele Protokolle,

die ein Unternehmen mögli-

cherweise benötigt (oder

die standardmäßig aktiviert

sind), die jedoch häufig von

böswilligen Personen ge-

nutzt werden, um auf ein

Netzwerk zuzugreifen. Um

sicherzustellen, dass diese

Dienste und Protokolle stets



temkomponenten aktivierte

Systemservices, Daemons

und Protokolle. Überprüfen

Sie, dass nicht benötigte

oder unsichere Services

oder Protokolle nicht akti-

viert sind oder dass der

entsprechende Einsatz des

Service begründet und

Windows Server 2008

Security Guide

Windows Server 2008

Attack Surface Refer-

ence.xlsx

Security Configuration

Wizard


Technische Lösung für den

Konfigurationsstandard und

Prozess

deaktiviert sind, wenn neue

Server eingerichtet werden,

sollte diese Anforderung

Bestandteil der Konfigurati-

onsstandards Ihres Unter-

nehmens sowie damit

verbundener Prozesse sein.

dokumentiert ist. FTP wird

z. B. nicht verwendet oder

wird über SSH oder andere

Technologie verschlüsselt.

ssg

http://technet.microsoft.com

/de-

de/library/cc771492.aspx

2.2.3 Konfigurieren von

Systemsicherheitsparame-

tern, um Missbrauch zu

verhindern.

Hierdurch soll sichergestellt

werden, dass die System-

konfigurationsstandards

Ihres Unternehmens sowie

damit verbundene Prozesse

speziell auf Sicherheitsein-

stellungen und Parameter

ausgerichtet sind, für die

bekannte Sicherheitsprob-

leme bestehen.

2.2.3.a Führen Sie Gesprä-

che mit Systemadministra-

toren und/oder Sicherheits-

beauftragten, um zu über-

prüfen, ob diese die gängi-

gen Sicherheitsparameter-

einstellungen für System-

komponenten kennen.

2.2.3.b Überprüfen Sie, ob

gängige Sicherheitspara-

metereinstellungen in den


dards enthalten sind.

2.2.3.c Überprüfen Sie für


temkomponenten, dass

gängige Sicherheitspara-

meter entsprechend festge-

legt sind.

Windows Server 2008

Security Guide

Specialized Security –

Limited Functionality Tem-

plate


ssg

Unterstützt Systemkonfigu-

rationsstandards & Prozes-

se

2.2.4 Entfernen aller unnö-

tigen Funktionen, z. B.

Skripte, Treiber, Features,

Untersysteme, Dateisyste-

me und unnötige Webser-

ver.

Die Standards zur Server-

stabilisierung müssen

Prozesse beinhalten, die

auf unnötige Funktionen mit

speziellen Sicherheitsprob-

lemen ausgerichtet sind (z.

B. Entfernen/Deaktivieren

der FTP-Funktion oder der

Webserver-Funktion, wenn

der Server diese Funktio-

nen nicht ausführt).



temkomponenten, dass alle

unnötigen Funktionen (z. B.

Skripte, Treiber, Features,

Untersysteme, Dateisyste-

me usw.) entfernt werden.

Überprüfen Sie, ob aktivier-

te Funktionen dokumentiert

werden und die sichere

Konfiguration unterstützen

und ob in den Geräten, die

der Stichprobenkontrolle

unterzogen werden, nur

dokumentierte Funktionen

vorhanden sind.

Windows Server 2008

Roles & Features

Servermanager

Server Core Installation

Technische Lösung für

Standards und Prozesse

2.3 Verschlüsseln des

gesamten Nichtkonsolen-

Verwaltungszugriffs. Ver-

wenden von Technologien

wie SSH, VPN oder

SSL/TLS für die webbasier-

te Verwaltung und sonsti-

gen Nichtkonsolen-

Erfolgt die Remote-

Administration nicht über

eine sichere Authentifizie-

rung und eine verschlüssel-

te Kommunikation, können

vertrauliche Verwaltungs-

oder Betriebsinformationen

(z. B. Kennwörter des

Administrators) abgefangen

2.3 Überprüfen Sie für eine

Stichprobe von System-

komponenten, dass der

Nichtkonsolen-

Verwaltungszugriff durch

folgende Maßnahmen

verschlüsselt ist:

Beobachten Sie eine Admi-

TS Gateway:

NLA, CAPs/RAP, TS Set-

tings

SSTP


/en-

us/library/cc732122.aspx

Kombination mit NPS mög-

lich


/de-


Domain / Server Isolation

mit IPSEC

Verwaltungszugriff. werden. Eine böswillige

Person könnte diese Infor-

mationen nutzen, um ins

Netzwerk zu gelangen,

Administrator zu werden

und Daten zu stehlen.

nistratoranmeldung auf

jedem System, um zu

überprüfen, dass eine

starke Verschlüsselungs-

methode aufgerufen wird,

bevor das Administrator-

kennwort angefordert wird;

Prüfen von Services und

Parameterdateien auf

Dateien, um festzulegen,

dass Telnet und andere

Remote-Anmeldebefehle

nicht für die interne Nut-

zung verfügbar sind;

Überprüfen, dass der Ad-

ministratorzugriff auf die

webbasierten Manage-

mentschnittstellen mit

starker Kryptographie

verschlüsselt ist.


/en-

us/magazine/2007.06.cable

guy.aspx

3.6.1 Generierung starker

kryptographischer Schlüs-

sel

Die Verschlüsselungslö-

sung muss starke Schlüssel

generieren, wie unter „star-

ke Kryptographie“ im PCI-

DSS- und PA-DSS-Glossar

für Begriffe, Abkürzungen

und Akronyme definiert.

3.6.1 Überprüfen Sie, ob

Verfahren zur Schlüssel-

verwaltung implementiert

sind, die die Erstellung

starker Schlüssel erfordern.

Cryptographic Next Gen-

eration

Suite B


/de-


4.1 Verwenden von starker

Kryptographie und Sicher-

heitsprotokollen wie

SSL/TLS oder IPSEC, um

vertrauliche Karteninhaber-

daten während der Über-

tragung über offene, öffent-

liche Netzwerke zu schüt-

zen.

Beispiele für offene, öffent-

liche Netzwerke, die in den

Umfang des PCI-DSS

fallen, sind:

- Das Internet

- Drahtlose Technologien

- GSM-Kommunikationen

(Global System for Mobile)

und

- General Packet Radio

Service (GPRS)

Vertrauliche Informationen

müssen während der Über-

tragung über öffentliche

Netzwerke verschlüsselt

werden, da eine böswillige

Person Daten in dieser

Phase einfach und mühelos

abfangen und/oder umleiten

kann. Secure Sockets

Layer (SSL) verschlüsselt

Websites und auf ihnen

eingegebene Daten. Bei der

Verwendung von durch SSL

gesicherten Websites muss

sichergestellt werden, dass

„https“ Bestandteil der URL

ist.

Beachten Sie, dass die

SSL-Vorgängerversionen

der Version v3.0 nachge-

wiesene Schwächen auf-

weisen, z. B. Pufferüberläu-

fe, die ein Angreifer nutzen

kann, um Kontrolle über

4.1.a Überprüfen Sie die

Verwendung von Ver-

schlüsselung (z. B.

SSL/TLS oder IPSEC),

wenn Karteninhaberdaten

über offene, öffentliche

Netzwerke übertragen oder

empfangen werden.

Überprüfen Sie, ob wäh-

rend der Datenübertragung

starke Verschlüsselung

eingesetzt wird.

Für SSL-

Implementierungen:

- Überprüfen Sie, ob der

Server die neuesten Patch-

Versionen unterstützt.

- Überprüfen Sie, ob

HTTPS als Bestandteil der

Browser-URL (Universal

Record Locator) angezeigt

wird.

CNG Settings

Computer Configura-

tion\Administrative Tem-

plates\Network\SSL Confi-

guration Settings

SSL 3.0

HKLM

SYSTEM\CurrentControlSet

\Control\SecurityProviders\

SCHANNEL

das betreffende System zu

erlangen.

- Überprüfen Sie, dass

keine Karteninhaberdaten

erforderlich sind, wenn

HTTPS nicht in der URL

angezeigt wird.

Wählen Sie eine Stichprobe

aus Transaktionen bei

deren Eingang aus, und

beobachten Sie Transaktio-

nen während der Ausfüh-

rung, um zu überprüfen, ob

Karteninhaberdaten wäh-

rend der Übertragung

verschlüsselt werden.

Überprüfen Sie, dass nur

vertrauenswürdige

SSL/TLS-Schlüssel/-

Zertifikate akzeptiert wer-

den.

Überprüfen Sie, dass für die

verwendete Verschlüsse-

lungsmethode die richtige

Verschlüsselungsstärke

verwendet wird. (Prüfen Sie

Anbieterempfehlun-

gen/bewährte Verfahren.)

7.1.4 Implementierung

eines automatisierten Zu-

griffskontrollsystems

Je mehr Personen Zugriff

auf Karteninhaberdaten

haben, desto größer ist das

Risiko, dass ein Benutzer-

konto in böswilliger Absicht

genutzt wird. Durch die

Beschränkung des Zugriffs

auf Personen, die aus

wichtigen Geschäftsgrün-

den einen Zugriff benötigen,

kann Ihr Unternehmen den

aufgrund von Unerfahren-

heit oder in böswilliger

Absicht erfolgten falschen

Umgang mit Karteninha-

berdaten verhindern. Wer-

den die Zugriffsrechte nur

für die minimale Menge an

Daten und Berechtigungen,

die zur Durchführung einer

Aufgabe erforderlich sind,

erteilt, wird dies als „Infor-

mationsbedarf“ bezeichnet.

Werden Berechtigungen auf

der Grundlage der Tätig-

7.1.4 Bestätigen Sie, dass

Zugriffskontrollen über ein

automatisiertes Zugriffs-

kontrollsystem implemen-

tiert werden.

LSASS / Security Token

DACL / SACL

Local / Universal / Global /

Domain-Local Groups

keitsklassifizierung und –

funktion eines Mitarbeiters

zugewiesen, wird dies als

„rollenbasierte Zugriffssteu-

erung“ oder RBAC („role-

based access

control“)bezeichnet. Ihr

Unternehmen sollte anhand

des Merkmals „Informati-

onsbedarf“ eindeutige

Richtlinien und Prozesse

zur Datenzugriffssteuerung

und anhand des Merkmals

„rollenbasierte Zugriffssteu-

erung“ die Zugriffsart und

die Personen, denen Zugriff

gewährt wird, festlegen.

7.2.2 Zuweisung von Be-

rechtigungen zu einzelnen

Personen anhand der

Tätigkeitsklassifizierung

und –funktion

7.2.3 Standardeinstellung

„Alle

ablehnen“

Ohne einen Mechanismus

zur Beschränkung des

Zugriffs anhand des Infor-

mationsbedarfs eines Be-

nutzers kann einem Benut-

zer unwissentlich Zugriff zu

Karteninhaberdaten ge-

währt werden. Der Einsatz

eines automatisierten Zu-

griffskontrollsystems ist für

die Verwaltung mehrerer

Benutzer unerlässlich. Die

Einrichtung dieses System

sollte im Einklang mit den

Zugriffskontrollrichtlinien

und -verfahren Ihres Unter-

nehmens (einschließlich der

Berücksichtigung der

Merkmale „Informationsbe-

darf“ und „rollenbasierte

Zugriffssteuerung“) erfol-

gen. Zudem sollte dieses

System den Zugriff auf alle

Systemkomponenten ver-

walten und über die Stan-

dardeinstellung „Alle ableh-

nen“ verfügen, um sicher-

zustellen, dass einer Per-

son nur dann der Zugriff

erteilt wird, wenn der Zugriff

durch eine entsprechende

festgelegte Regel gewährt

wird.


Zugriffskontrollsysteme

konfiguriert sind, um Be-

rechtigungen durchzuset-

zen, die einzelnen Perso-

nen anhand der Tätigkeits-

klassifizierung und -funktion

zugewiesen sind.


die Zugriffskontrollsysteme

die Standardeinstellung

„Alle ablehnen“ aufweisen

Hinweis: Einige Zugriffs-

kontrollsysteme sind stan-

dardmäßig auf „Alle zulas-

sen“ gesetzt und lassen

dadurch den Zugriff zu, bis

eine Regel erstellt wird, die

den Zugriff ausdrücklich

ablehnt.

Built-In / Default Groups

Privilege Assignment

Interactive Group:

ANONYMOUS LOGON

8.1 Zuweisen einer eindeu-

tigen Benutzer-ID für alle

Benutzer, bevor diesen der

Durch die Zuweisung einer

eindeutigen Kennung für

jeden einzelnen Benutzer –

8.1 Stellen Sie sicher, dass

alle Benutzer eine eindeuti-

ge ID für den Zugriff auf

SID

Zugriff auf Systemkompo-

nenten oder Karteninhaber-

daten gestattet wird.

anstatt der Verwendung

einer ID für mehrere Mitar-

beiter – kann ein Unter-

nehmen sicherstellen, dass

jeder Einzelne für die eige-

nen Handlungen verant-

wortlich ist. Außerdem kann

es auf diese Weise einen

effektiven Audit-Trail für

jeden Mitarbeiter einrichten.

Dadurch lässt sich die

Problemlösung und -

begrenzung bei einem

Missbrauch oder einem

böswilligen Angriff be-

schleunigen.

Systemkomponenten oder

Karteninhaberdaten erhal-

ten.

8.2 Neben der Zuweisung

einer eindeutigen ID Ein-

setzen mindestens einer

der folgenden Methoden

zur Authentifizierung aller

Benutzer:

- Kennwort oder Kennsatz

- Zwei-Faktor-

Authentifizierung (z. B.

Token-Geräte, Smartcards,

biometrische Systeme oder

öffentliche Schlüssel)

Werden diese Authentifizie-

rungselemente zusätzlich

zu eindeutigen IDs verwen-

det, trägt dies dazu bei, die

eindeutigen Benutzer-IDs

vor Angriffen zu schützen

(da der Angreifer sowohl

die eindeutige ID als auch

das Kennwort oder das

Authentifizierungselement

kennen muss).

8.2 Gehen Sie wie folgt vor,

um zu überprüfen, ob sich

die Benutzer mittels einer

eindeutigen ID und eines

zusätzlichen Authentifizie-

rungsmerkmals (z. B.

Kennwort) für den Zugriff

auf die Karteninhaberdaten

authentifiziert haben:

Untersuchen Sie Dokumen-

te, aus denen hervorgeht,

welche Authentifizierungs-

methoden verwendet wur-

den.

Schauen Sie sich bei jeder

Authentifizierungsmethode

und jeder Systemkompo-

nente eine Authentifizierung

genauer daraufhin an, ob

diese in Übereinstimmung

mit den dokumentierten

Authentifizierungsmethoden

erfolgt.

LSA SSP

NTLMv2 (SAM) / Kerberos

(AD)

Smartcard (PKINIT)

8.3 Zwei-Faktor-

Authentifizierung beim

Remote-Zugriff (Netzwerk-

zugriff von außerhalb des

Netzwerks) von Mitarbei-

tern, Administratoren und

Dritten. Verwenden von

Technologien wie Remote-

Authentifizierung und

Einwähldienst (RADIUS)

oder Terminal Access

Controller Access Control

Die Zwei-Faktor-

Authentifizierung erfordert

zwei Arten der Authentifizie-

rung für Zugriffe mit einem

höheren Risiko, z. B. für

Zugriffe von außerhalb

Ihres Netzwerks. Um mehr

Sicherheit zu erreichen,

kann Ihr Unternehmen die

Zwei-Faktor-

Authentifizierung auch dann

einsetzen, wenn von weni-

8.3 Gehen Sie wie folgt vor,

um die Implementierung der

Zwei-Faktoren-

Authentifizierung für den

Remote-Netzwerkzugriff zu

überprüfen: Beobachten

Sie, wie ein Mitarbeiter (z.

B. ein Administrator) eine

Remote-Verbindung zum

Netzwerk herstellt, und

überprüfen Sie, ob hierfür

ein Kennwort und ein zu-

Smartcards

TS-Gateway

SSTP

EAP-TLS

EAP-Radius

System (TACACS) mit

Token bzw. VPN (basiert

auf SSL/TLS oder IPSEC)

mit individuellen Zertifika-

ten.

ger sicheren Netzwerken

auf stark gesicherte Netz-

werke zugegriffen wird, z.

B. von Unternehmenscom-

putern (geringe Sicherheit)

auf Produktionsserver/-

datenbanken mit Kartenin-

haberdaten (hohe Sicher-

heit).

sätzliches Authentifizie-

rungselement erforderlich

ist (z. B. eine Smartcard,

ein Token oder eine PIN).

8.4 Geschützte Übertra-

gung und Speicherung von

Kennwörtern auf sämtlichen

Systemkomponenten unter

Verwendung einer sicheren

Verschlüsselung (siehe

Glossar, Abkürzungen und

Akronyme zum PCI DSS).

Zahlreiche Netzwerkgeräte

und -anwendungen über-

tragen die Benutzer-ID und

das unverschlüsselte

Kennwort innerhalb des

Netzwerks und/oder spei-

chern die Kennwörter un-

verschlüsselt. Eine böswilli-

ge Person kann die unver-

schlüsselte oder lesbare

Benutzer-ID sowie das

Kennwort während der

Übertragung unter Verwen-

dung eines „Sniffers“ ab-

fangen oder unmittelbar auf

die Benutzer-ID und unver-

schlüsselten Kennwörter in

den Dateien, in denen sie

gespeichert sind, zugreifen

und diese gestohlenen

Daten anschließend nutzen,

um sich nicht autorisierten

Zugriff zu verschaffen.

8.4.a Testen Sie stichpro-

benartig die Kennwortdatei-

en von Systemkomponen-

ten auf die Verschlüsselung

von Kennwörtern bei Über-

tragung und Speicherung.

8.4.b Bei Dienstanbietern

müssen darüber hinaus die

Kennwortdateien daraufhin

geprüft werden, ob Kun-

denkennwörter verschlüs-

selt werden.

NTLM SSP: HMAC MD5 /

MD4 NTOWF

Kerberos SSP: AES 256

TS-Gateway / SSTP: SSL /

TLS

8.5.1 Kontrollieren der

Vorgänge zum Hinzufügen,

Löschen und Ändern von

Benutzer-IDs, Anmeldein-

formationen und anderen

Identifizierungsobjekten.

Um sicherzustellen, dass es

sich bei den zu Ihrem Sys-

tem hinzugefügten Benut-

zern um gültige und aner-

kannte Benutzer handelt,

sollte das Hinzufügen,

Löschen und Ändern von

Benutzer-IDs von einer

kleinen Gruppe von Perso-

nen mit spezieller Berechti-

gung verwaltet und gesteu-

ert werden. Die Berechti-

gung zur Verwaltung dieser

Benutzer-IDs sollte auf

diese kleine Gruppe be-

schränkt sein.

8.5.1.a Wählen Sie stich-

probenartig Benutzer-IDs

von Administratoren und

allgemeinen Benutzern aus.

Überprüfen Sie, ob die

einzelnen Benutzer ent-

sprechend den Richtlinien

des Unternehmens zur

Systemnutzung berechtigt

sind. Gehen Sie dafür wie

folgt vor:

Untersuchen Sie für jede ID

ein Autorisierungsformular.

Überprüfen Sie, ob die in

die Stichprobe aufgenom-

menen Benutzer-IDs in

Übereinstimmung mit dem

Autorisierungsformular

(inklusive der angegebenen

Delegation of Rights

Technische Lösung des

Prozesses

Rechte und sämtlicher

eingeholter Signaturen)

implementiert wurden,

indem Sie Informationen

aus dem Autorisierungs-

formular zum System nach-

verfolgen.

8.5.3 Festlegen eindeutiger

Werte für die anfänglichen

Kennwörter der einzelnen

Benutzer und sofortige

Änderung nach der ersten

Verwendung.

Wird für jeden neu einge-

richteten Benutzer dasselbe

Kennwort verwendet, könn-

te ein interner Benutzer, ein

ehemaliger Mitarbeiter oder

eine böswillige Person

dieses Kennwort entweder

bereits kennen oder leicht

herausfinden und es an-

schließend nutzen, um sich

Zugriff auf Konten zu ver-

schaffen.

8.5.3 Untersuchen Sie die

Kennwortverfahren, und

beobachten Sie das

Sicherheitspersonal. Achten

Sie darauf, dass neue

Benutzer eindeutige an-

fängliche Kennwörter erhal-

ten und dass diese Kenn-

wörter nach der ersten

Nutzung geändert werden.

User Must Change Pass-

word At Next Logon

Technische Lösung vor-

handen für das Kennwort-

verfahren

User Template

8.5.4 Sofortige Deaktivie-

rung des Zugriffs ehemali-

ger Benutzer

Hat ein Mitarbeiter, der das

Unternehmen verlassen

hat, über sein Benutzerkon-

to weiterhin Zugang zum

Netzwerk, könnte es zu

einem unnötigen oder in

böswilliger Absicht durchge-

führten Zugriff auf Kartenin-

haberdaten kommen. Die-

ser Zugriff könnte durch

einen ehemaligen Mitarbei-

ter oder eine böswillige

Person, die das ältere

und/oder ungenutzte Konto

missbraucht, erfolgen.

Ziehen Sie daher in Be-

tracht, gemeinsam mit der

Personalabteilung ein

Verfahren zur sofortigen

Benachrichtigung im Falle

der Kündigung eines Mitar-

beiters einzurichten, damit

das Benutzerkonto umge-

hend deaktiviert werden

kann.

8.5.4 Prüfen Sie stichpro-

benartig, ob die IDs von

Mitarbeitern, die in den

letzten sechs Monaten aus

dem Unternehmen ausge-

schieden sind, deaktiviert

bzw. aus den Zugriffslisten

der aktuellen Benutzer

gelöscht wurden.

Account Properties:

Account Expires

Account Is Disabled


handen für den Prozess

8.5.5 Entfernen bzw. Deak-

tivieren inaktiver Benutzer-

konten mindestens alle 90

Tage.

Mithilfe von inaktiven Kon-

ten kann ein nicht autori-

sierter Benutzer das unge-

nutzte Konto missbrauchen,

um sich möglicherweise

Zugriff auf Karteninhaber-

daten zu verschaffen.


seit mehr als 90 Tagen

inaktive Konten entfernt

oder deaktiviert werden.

Last Interactive Logon

Windows Logon Option:

Display information about

previous logons during user

logon

LDAP Query



8.5.6 Aktivieren der von

Anbietern/Lieferanten für

die Remote-Wartung ver-

wendeten Konten aus-

schließlich während der

erforderlichen Zeit.

Wenn Sie Anbietern (z. B.

POS-Anbietern) rund um

die Uhr Zugang zu Ihrem

Netzwerk gestatten, falls

Ihre Systeme einen ent-

sprechenden Support

benötigen, wächst die

Gefahr eines nicht autori-

sierten Zugriffs entweder

durch einen Benutzer in-

nerhalb der Anbieterumge-

bung oder durch eine bös-

willige Person, die diesen

stets verfügbaren externen

Zugriffspunkt zu Ihrem

Netzwerk entdeckt und

ausnutzt. Weitere Informa-

tionen zu diesem Thema

finden Sie unter 12.3.8 und

12.3.9.


die zur Unterstützung und

Wartung verwendeten

Konten im Regelfall deakti-

viert sind – d. h., sie sollten

nur dann aktiviert werden,

wenn der Anbieter sie

benötigt, und die Verwen-

dung sollte überwacht

werden.

Account Propterties;

Feature Logon Hours



User Template

8.5.8 Keine Vergabe von

Konten und Kennwörtern

für Gruppen bzw. mehrere

Personen oder die allge-

meine Nutzung.

Wenn mehrere Benutzer

dasselbe Konto und Kenn-

wort gemeinsam nutzen, ist

es nicht mehr möglich,

einen Einzelnen für seine

Handlungen verantwortlich

zu machen oder diese

Handlungen effektiv zu

protokollieren, denn jedes

Mitglied der Gruppe, die

das Konto und das Kenn-

wort gemeinsam nutzt,

hätte eine bestimmte Hand-

lung durchführen können.

8.5.8.a Zur Ermittlung einer

Stichprobe von System-

komponenten stehen die

Benutzer-ID-Listen zur

Verfügung. Prüfen Sie

Folgendes:

Allgemeine Benutzer-IDs

und -konten werden deakti-

viert und entfernt.

Es gibt keine gemeinsamen

Benutzer-IDs für System-

administrationsaufgaben

und andere wichtige Funk-

tionen.

Es werden keine gemein-

samen und allgemeinen

Benutzer-IDs zur Administ-

ration von Systemkompo-

nenten verwendet.

8.5.8.b Untersuchen Sie

Kennwortrichtlinien und -

verfahren, und sorgen Sie

dafür, dass Gruppenkenn-

wörter und gemeinsame

Kennwörter explizit unter-

sagt sind.

8.5.8.c Stellen Sie durch

Interviews mit Systemadmi-

nistratoren sicher, dass

Account Properties:

Smart Card is required for

Interactive Logon

Technische Lösung für die

Kennwortrichtlinie

User Template

selbst auf Anfrage keine

Gruppen- bzw. gemeinsa-

men Kennwörter vergeben

werden.

8.5.9 Ändern der Benutzer-

kennwörter mindestens alle

90 Tage.

8.5.10 Festlegen einer

Mindestlänge für Kennwör-

ter von 7 Zeichen.

8.5.11 Verwenden von

Kennwörtern, die sowohl

numerische als auch alpha-

betische Zeichen enthalten.

8.5.12 Festlegen, dass sich

ein neues Kennwort von

den letzten vier Kennwör-

tern unterscheiden muss.

Starke Kennwörter stellen

die erste Verteidigungslinie

für ein Netzwerk dar. Denn

eine böswillige Person wird

häufig zunächst versuchen,

Konten mit schwachen oder

nicht vorhandenen Kenn-

wörtern zu finden. Sind

Kennwörter kurz, leicht zu

erraten oder für eine lange

Zeit ohne Veränderung

gültig, hat eine böswillige

Person mehr Zeit, diese

schwachen Konten ausfin-

dig zu machen und, getarnt

durch eine gültige Benut-

zer-ID, ein Netzwerk zu

schädigen. Starke Kenn-

wörter können gemäß

diesen Anforderungen

verstärkt und gepflegt

werden, indem die Kenn-

wort- und Kontosicherheits-

funktionen, die in Ihrem

Betriebssystem (z. B. Win-

dows) sowie in Ihren Netz-

werken, Datenbanken und

anderen Plattformen enthal-

ten sind, aktiviert werden.

8.5.9 Überprüfen Sie stich-

probenartig bei bestimmten

Systemkomponenten die

Konfigurationseinstellungen

daraufhin, ob die Benutzer

mindestens alle 90 Tage ihr

Kennwort ändern müssen.

Bei Dienstanbietern sind

darüber hinaus interne

Prozesse und Kunden-

bzw. Benutzerdokumente

daraufhin zu überprüfen, ob

Kundenkennwörter regel-

mäßig geändert werden

müssen und ob die Kunden

Hinweise dazu erhalten,

wann und unter welchen

Umständen die Kennwörter

geändert werden müssen.

8.5.10 Überprüfen Sie

stichprobenartig bei be-

stimmten Systemkompo-

nenten die Konfigurations-

einstellungen daraufhin, ob

die Kennwörter mindestens

sieben Zeichen lang sein

müssen. Bei Dienstanbie-

tern müssen zusätzlich

interne Prozesse und Kun-

den-/Benutzerdokumente

daraufhin überprüft werden,

ob es Mindestlängen für

Kennwörter gibt.






die Kennwörter numerische

und alphabetische Zeichen

enthalten müssen. Bei

Dienstanbietern müssen

zusätzlich interne Prozesse

und Kunden-

/Benutzerdokumente da-

raufhin überprüft werden,

ob darin gefordert wird,

dass Kennwörter numeri-

Computer Configura-

tion\Policies\Windows

Settings\Security Set-

tings\Account Poli-

cies\Password Policy

MaximumPasswordAge

MinimumPasswordLength

PasswordComplexity

PasswordHistorySize

Password Setting Object

(PSO)


Kennwortrichtlinie

SSLF Template

sche und alphabetische

Zeichen enthalten.






gefordert wird, dass sich ein

neues Kennwort von den

letzten vier Kennwörtern

unterscheidet. Bei Dienst-

anbietern müssen zusätz-

lich interne Prozesse und

Kunden-

/Benutzerdokumente da-

raufhin überprüft werden,

ob darin gefordert wird,

dass sich ein neues Kenn-

wort von den letzten vier

Kennwörtern unterscheidet.

8.5.13 Begrenzen der

wiederholten Zugriffsversu-

che durch Sperren der

Benutzer-ID nach spätes-

tens sechs Versuchen.

Sind keine Kontosperrver-

fahren eingerichtet, kann

ein Angreifer laufend versu-

chen, ein Kennwort mithilfe

von manuellen oder auto-

matisierten Tools (z. B.

Knacken des Kennwortes)

so lange zu erraten, bis er

Erfolg hat und Zugriff auf

ein Benutzerkonto erlangt.






gefordert wird, dass ein

Benutzerkonto nach spätes-

tens sechs ungültigen

Anmeldeversuchen ge-

sperrt wird. Bei Dienstan-

bietern müssen zusätzlich

interne Prozesse und Kun-

den-/Benutzerdokumente

daraufhin überprüft werden,

ob ein Benutzerkonto nach

spätestens sechs ungülti-

gen Anmeldeversuchen

gesperrt wird.

Computer Configura-



tings\Account Poli-

cies\Account Lockout Policy

Settings LockoutBadCount

Password Setting Object

(PSO)


Kennwortrichtlinie

SSLF nicht konform (10)

8.5.14 Festlegen einer

Aussperrdauer von mindes-

tens 30 Minuten, innerhalb

derer die Benutzer-ID nur

durch den Administrator

reaktiviert werden kann.

Ist ein Konto infolge des

fortlaufenden Versuchs, ein

Kennwort zu erraten, ge-

sperrt, hindern Verfahren

zur Steuerung der Ver-

schiebung einer Reaktivie-

rung dieser gesperrten

Konten die böswillige Per-

son daran, weiterhin das

Kennwort zu erraten (sie

muss mindestens 30 Minu-

ten warten, bis das Konto

reaktiviert wird). Darüber

hinaus kann der Administra-






eine mindestens 30-

minütige Aussperrdauer gilt,

innerhalb derer das Konto

nur durch den Administrator

zurückgesetzt werden kann.

Computer Configura-



tings\Account Poli-

cies\Account Lockout Policy

LockoutDuration


Kennwortrichtlinie

SSLF nicht konform (15

Minuten)

tor oder das Helpdesk,

wenn eine Reaktivierung

angefordert werden muss,

überprüfen, ob der Kontoin-

haber die Sperrung (durch

Fehler bei der Eingabe)

verursacht hat.

8.5.15 Festlegen, dass die

Benutzer nach mehr als 15-

minütiger Inaktivität das

Kennwort erneut eingeben

und das Terminal reaktivie-

ren müssen.

Wenn sich ein Benutzer von

einem öffentlichen Compu-

ter mit Zugang zu wichtigen

Netzwerk- und Karteninha-

berdaten entfernt, kann

dieser Computer in der

Abwesenheit des Benutzers

von anderen Personen

genutzt werden. Dies kann

zu einem nicht autorisierten

Zugriff auf das Konto

und/oder Missbrauch des

Kontos führen.






die Benutzer nach mehr als

15-minütiger Inaktivität das

Kennwort erneut eingeben

und das Terminal reaktivie-

ren müssen.

TS Session Settings

Idle Session Limit

10.1 Einrichten eines Pro-

zesses zur Verknüpfung

des gesamten Zugriffs auf

Systemkomponenten (ins-

besondere des Zugriffs mit

Administratorberechtigun-

gen wie root) mit den ein-

zelnen Benutzern.

Die Einrichtung eines Pro-

zesses oder Systems zur

Verknüpfung des Benutzer-

zugriffs auf Systemkompo-

nenten, insbesondere für

Benutzer mit Administrator-

berechtigungen, ist von

außerordentlicher Bedeu-

tung. Dieses System er-

zeugt Audit-Protokolle und

bietet die Möglichkeit,

verdächtige Aktivitäten auf

einen bestimmten Benutzer

zurückzuführen. Forensik-

Teams, die nach einem

Vorfall eingesetzt werden,

benötigen diese Protokolle

dringend zur Einleitung

einer Untersuchung.

10.1 Prüfen Sie durch

Befragung des Systemad-

ministrators und durch

eigene Beobachtung, ob

Audit-Trails für die System-

komponenten vorhanden

und aktiv sind.

Audit-Policy

Policies/Windows Set-

tings/Security Set-

tings/Local Policies

Granular Audit Policy (GAP)

AuditPol.exe


Audit-Prozesses

10.2.2 Alle von einer Ein-

zelperson mit root- oder

Administratorrechten vor-

genommene Aktionen

10.2.3 Zugriff auf alle Audit-

Trails

10.2.4 Ungültige logische

Zugriffsversuche

10.2.5 Verwendung von

Identifizierungs- und Au-

thentifizierungsmechanisme

Böswillige Personen im

Netzwerk unternehmen

häufig mehrere Versuche,

um Zugang zu den anvisier-

ten Systemen zu erhalten.

Durch die Generierung von

Audit-Trails für verdächtige

Aktivitäten wird nicht nur

der Systemadministrator

gewarnt, sondern es wer-

den auch Daten an andere

Überwachungssysteme

gesendet (z. B. Systeme

zur Erkennung von Ein-

10.2.2 Prüfen Sie, ob alle

von einer Einzelperson mit

root- oder Administrator-

rechten vorgenommenen

Aktionen protokolliert wer-

den.

10.2.3 Prüfen Sie, ob der

Zugriff auf alle Audit-Trails

protokolliert wird.

10.2.4 Prüfen Sie, ob ungül-

tige logische Zugriffsversu-

che protokolliert werden.

Audit Account Logon

Events

Audit Logon Events

Audit Account Management

Audit Directory Service

Access

Audit Change Policy

Audit System Events


Audit-Prozesses

n

10.2.6 Initialisierung der

Audit-Protokolle

10.2.7 Erstellung und Lö-

schen von Objekten auf

Systemebene.

dringversuchen) und Ver-

laufsdaten für eine Nach-

verfolgung nach dem Vorfall

bereitgestellt.

10.2 5 Prüfen Sie, ob die

Verwendung von Identifizie-

rungs- und Authentifizie-

rungssystemen protokolliert

wird.

10.2.6 Prüfen Sie, ob die

Initialisierung der Audit-

Protokolle protokolliert wird.

10.2.7 Prüfen Sie, ob das

Erstellen und Löschen von

Objekten auf Systemebene

protokolliert wird.

Audit Object Access

SACL

Directory Services Changes

(AuditPol)

SACL

10.3 Aufzeichnen mindes-

tens der folgenden Prüfver-

fahrenseinträge für alle

Systemkomponenten zu

jedem Ereignis:

10.3.1 Benutzeridentifizie-

rung

10.3.2 Ereignistyp

10.3.3 Datum und Uhrzeit

10.3.4 Erfolg oder Fehler

10.3.5 Ereignisursprung

10.3.6 Identität oder Name

der betroffenen Daten,


Ressourcen

Durch Aufzeichnen dieser

Einträge für prüfbare Ereig-

nisse unter 10.2 kann eine

potenzielle Gefährdung

schnell ausgemacht wer-

den, mit detaillierten Infor-

mationen zum „wer, was,

wo, wann und wie“.

10.3 Führen Sie durch

Gespräche und eigene

Beobachtung zu jedem zu

protokollierenden Ereignis

(aus 10.2) Folgendes

durch:


Benutzer-ID in den Proto-

kolleinträgen enthalten ist.


Art des Ereignisses in den

Protokolleinträgen enthalten

ist.


Datums- und Zeitangabe in

den Protokolleinträgen

enthalten ist.


Hinweis auf die erfolgreiche

oder fehlgeschlagene

Ausführung in den Proto-



Ursprung des Ereignisses

in den Protokolleinträgen

enthalten ist.


die Identität oder der Name

der betroffenen Daten,


Ressourcen in den Proto-


EventLog Details

10.4 Synchronisation aller

kritischen Systemuhren und

-zeiten.

Personen, die mit böswilli-

gen Absichten auf Netzwer-

ke zugreifen, versuchen oft,

die Zeitangaben ihrer Akti-

onen innerhalb der Prüfpro-

tokolle zu ändern, um zu

vermeiden, dass ihre Aktivi-

tät entdeckt wird. Für Fo-

rensik-Teams, die nach

einem Vorfall eingesetzt

werden, ist der Zeitpunkt

jeder Aktivität äußerst

wichtig, um erkennen zu

können, wie die Systeme

beeinträchtigt wurden.

Unter Umständen versu-

chen böswillige Personen

auch, direkt die Uhr auf

einem Zeitserver zu ändern,

und setzen die Zeit bei

mangelhaften Zugriffsbe-

schränkungen auf einen

Zeitpunkt vor dem eigentli-

chen Zugriff der böswilligen

Person zurück.

10.4 Prüfen Sie den Pro-

zess zum Ermitteln und zur

Weitergabe der richtigen

Zeit innerhalb der Organisa-

tion sowie

stichprobenartigdie zeitbe-

dingten Systemparameter-

einstellungen bei System-

komponenten. Überprüfen

Sie, ob folgende Elemente

im Prozess enthalten und

implementiert sind:

10.4.a Überprüfen Sie, ob

eine bekannte und stabile

Version des Network Time

Protocol (NTP) oder einer

ähnlichen Technologie

entsprechend den PCI DSS

Anforderungen 6.1 und 6.2

für die Zeitsynchronisierung

verwendet wird.

10.4.b Achten Sie darauf,

dass interne Server keine

Zeitsignale von externen

Quellen empfangen. [Inner-

halb der Organisation

empfangen zwei oder drei

zentrale Zeitserver externe

Zeitsignale [entweder über

ein spezielles Funksignal,

per GPS-Satellit oder aus

einer externen Quelle auf

der Grundlage der Interna-

tionalen Atomzeit bzw. der

Koordinierten Weltzeit

(UTC; früher GMT)] und

sorgen im Austausch unter-

einander für eine

höchstmögliche Genauig-

keit. Darüber hinaus leiten

sie die Zeitinformationen an

andere interne Server

weiter.]

10.4.c Überprüfen Sie, ob

spezielle externe Hosts

vorhanden sind, von denen

die Zeitserver NTP Zeitak-

tualisierungen empfangen

(und verhindern, dass die

Uhr von einer Einzelperson

manipuliert werden kann).

Diese Zeitaktualisierungen

PDC Time Master

Win32Time Service

w32tm.exe

können mit einem symmet-

rischen Schlüssel ver-

schlüsselt werden. Außer-

dem können Zugriffssteue-

rungslisten erstellt werden,

aus denen die IP-Adressen

der Clients hervorgehen,

die den NTP-Dienst nutzen.

Hierdurch wird die Nutzung

nicht autorisierter interner

Zeitserver verhindert. Wei-

tere Informationen finden

Sie unter www.ntp.org.

10.5.1 Beschränken der

Anzeige der Prüfverfahren

auf Personen mit arbeits-

bedingtem Bedarf.

10.5.2 Schutz von Audit-

Trail-Dateien vor nicht

autorisierten Änderungen.

10.5.3 Sofortige Sicherung

von Audit-Trail-Dateien auf

einem zentralen Protokoll-

server oder auf Medien, die

sich nur schwer ändern

lassen.

Zu einem angemessenen

Schutz der Prüfprotokolle

gehören eine starke Zu-

griffskontrolle (beschränken

Sie den Zugriff auf Protokol-

le auf die Personen, die sie

wirklich lesen müssen) und

die Nutzung interner Tren-

nung (damit die Protokolle

schwerer zu finden und zu

ändern sind). Durch Schrei-

ben von Protokollen über

nach außen gerichtete

Technologien wie Drahtlos-

technologie, Firewalls,

DNS- und Mailserver lässt

sich das Risiko eines Ver-

lusts bzw. einer Änderung

dieser Protokolle senken,

da diese Technologien

innerhalb des internen

Netzwerks sicherer sind.


Einzelpersonen nur mit

arbeitsbedingtem Bedarf

auf Audit-Trail-Dateien

zugreifen können.


die Dateien des aktuellen

Audit-Trails mit Zugriffs-

steuerungssystemen, räum-

licher Trennung und/oder

Netzwerktrennung vor

unbefugten Änderungen

geschützt werden.


Dateien des aktuellen

Audit-Trails sofort auf ei-

nem zentralen Protokollser-

ver oder auf Medien, die

sich nur schwer ändern

lassen,gesichert werden.

Audit Settings: SeSecurity-

Privilege

Audit Read: Built-In Gruppe

Event Log Readers

SSL Event Forwarding /

Push

11.5 Bereitstellen von

Software zur Überwachung

der Dateiintegrität, die

einen Alarm ausgibt, wenn

es zu nicht autorisierten

Änderungen an wichtigen

System-, Konfigurations-

oder Inhaltsdateien kommt,

und Konfiguration der

Software für einen mindes-

tens einmal pro Woche

durchzuführenden Ver-

gleich wichtiger Dateien.

Hinweis: Für die Dateiinteg-

ritätsüberwachung sind

wichtige Dateien in der

Regel Dateien, die sich

Systeme zur Überwachung

der Dateiintegrität überprü-

fen wichtige Dateien auf

Änderungen und benach-

richtigen den Benutzer, falls

Änderungen gefunden

wurden. Es sind sowohl

Standard- als auch Open-

Source-Tools für die Über-

wachung der Dateiintegrität

erhältlich. Bei nicht ord-

nungsgemäßer Implemen-

tierung und Überwachung

der Ausgabe von Systemen

zur Dateiintegritätsüberwa-

chung könnten böswillige

Personen den Inhalt der

11.5 Überprüfen Sie die

Nutzung von Produkten zur

Überwachung der Dateiin-

tegrität innerhalb der Um-

gebung mit Karteninhaber-

daten, indem Sie die Sys-

temeinstellungen und die

überwachten Dateien sowie

Ergebnisse aus der Aktivi-

tätsüberwachung untersu-

chen. Beispiele für Dateien,

die überwacht werden

sollten:

Ausführbare Systemdateien

Ausführbare Anwendungs-

Windows Resource Protec-

tion

http://msdn.microsoft.com/e

n-

us/library/cc185681(VS.85).

aspx

Windows Reliability Monitor

Lösung nur für das Be-

triebssystem

nicht regelmäßig ändern,

deren Änderung aber auf

eine Sicherheitsverletzung

im System oder das Risiko

einer Verletzung hinweisen

könnte. Produkte zur Datei-

integritätsüberwachung sind

in der Regel mit wichtigen

Dateien für das jeweilige

Betriebssystem vorkonfigu-

riert. Andere wichtige Da-

teien wie solche für benut-

zerdefinierte Anwendungen

müssen von der jeweiligen

Stelle (Händler oder

Dienstanbieter) beurteilt

und definiert werden.

Konfigurationsdatei, von

Betriebssystemprogram-

men oder Anwendungsda-

teien ändern. Solche nicht

autorisierten Änderungen

können, wenn sie nicht

entdeckt werden, dazu

führen, dass bestehende

Sicherheitskontrollen wir-

kungslos werden oder dass

Karteninhaberdaten ohne

nachweisbare Beeinträchti-

gung der normalen Verar-

beitung gestohlen werden.

dateien

Konfigurations- und Para-

meterdateien

Zentral gespeicherte Proto-

koll- und Audit-Dateien (alt

oder archiviert)

12.3.2 Authentifizierung zur

Verwendung der Technolo-

gie

Wenn eine Technologie

ohne ordnungsgemäße

Authentifizierung (Benutzer-

IDs und Kennwörter, Token,

VPNs usw.) implementiert

wird, können böswillige

Personen diese unge-

schützte Technologie leicht

nutzen, um Zugriff auf

wichtige Systeme und

Karteninhaberdaten zu

erlangen.


die Technologie laut Ver-

wendungsrichtlinie nur nach

Authentifizierung durch eine

Benutzer-ID und ein Kenn-

wort oder ein anderes

Element (z. B. ein Token)

genutzt werden kann.

LSASS / Security Token

DACL / SACL

Local / Universal / Global /

Domain-Local Groups


Verwendungsrichtlinie

12.3.8 Automatisches

Trennen von Remote-

Zugriffstechnologien nach

einer bestimmten Zeit der

Inaktivität

Remote-

Zugriffstechnologien bieten

häufig „Hintertüren“ zu

wichtigen Ressourcen und

Karteninhaberdaten. Durch

Trennen der Remote-

Zugriffstechnologien bei

Inaktivität (etwa der Tech-

nologien, die Ihr POS- oder

ein anderer Anbieter für

Serviceleistungen an Ihren

Systemen nutzt) werden

der Zugriff auf und damit

das Risiko für Netzwerke

minimiert. Es empfiehlt sich,

Geräte nach 15 Minuten

Inaktivität zu trennen. Wei-

tere Informationen zu die-

sem Thema finden Sie

unter Anforderung 8.5.6.


in der Verwendungsrichtli-

nie eine automatische

Trennung von Remotezu-

griff-Sitzungen nach einer

bestimmten Zeit der Inakti-

vität festgelegt ist.

Terminal Server / RDP

Settings – Connection

Configuration



12.3.10 Karteninhaberdaten

können bei einem Remote-

Zugriff nicht auf lokale

Festplatten und elektroni-

Um sicherzugehen, dass

Ihre Mitarbeiter sich über

ihre Verantwortung, Karten-

inhaberdaten nicht auf ihren


in der Verwendungsrichtli-

nie festgelegt ist, dass

Karteninhaberdaten bei

Client Settings Register:

Device Redirections

Clipboard



sche Wechselmedien ko-

piert oder verschoben

werden.

PCs oder anderen Medien

zu speichern oder zu kopie-

ren, im Klaren sind, sollte

eine Unternehmensrichtlinie

existieren, in der derartige

Aktivitäten klar verboten

werden.

einem Remotezugriff nicht

auf lokale Festplatten und

elektronische Wechselme-

dien kopiert oder verscho-

ben werden dürfen.

Windows Server 2008

Security Guide

Device and Resource

Redirection Policy Settings

GPO

Do not allow clipboard

redirection

Do not allow drive redirec-

tion

Durchsetzbar nur mit RDC

12.9.1 Erstellen des Vorfall-

reaktionsplans, der im Fall

einer Sicherheitsverletzung

im System umgesetzt wird.

Der Plan umfasst mindes-

tens die folgenden Punkte:

Rollen, Verantwortungsbe-

reiche und Kommunikati-

ons- sowie Kontaktstrate-

gien bei einer Verletzung

der Systemsicherheit,

einschließlich Benachrichti-

gung der Zahlungsmarken

Konkrete Verfahren für die

Reaktion auf Vorfälle

Verfahren zur Wiederauf-

nahme und Fortsetzung des

Geschäftsbetriebs

Verfahren zur Datensiche-

rung

Analyse der gesetzlichen

Bestimmungen hinsichtlich

der Offenlegung von

Sicherheitsverletzungen

Abdeckung sämtlicher

wichtigen Systemkompo-

nenten

Verweis auf oder Einbezie-

hung von Verfahren der

Zahlungsmarken zur Reak-

tion auf Vorfälle

Der Vorfallreaktionsplan

sollte umfassend sein und

sämtliche Schlüsselelemen-

te enthalten, die Ihrem

Unternehmen eine effektive

Reaktion im Falle von

Angriffen, die Karteninha-

berdaten gefährden könn-

ten, ermöglichen.


der Vorfallreaktionsplan

Folgendes umfasst:

Rollen, Verantwortungsbe-

reiche und Kommunikati-

onsstrategien bei einer

Verletzung der Systemsi-

cherheit, einschließlich

Benachrichtigung der Zah-

lungsmarken

Konkrete Verfahren für die

Reaktion auf Vorfälle

Verfahren zur Wiederauf-

nahme und Fortsetzung des

Geschäftsbetriebs

Verfahren zur Datensiche-

rung

Analyse der gesetzlichen

Bestimmungen hinsichtlich

der Offenlegung von

Sicherheitsverletzungen (z.

B. das California Bill 1386,

in dem vorgeschrieben

wird, dass Unternehmen bei

einer tatsächlichen oder

mutmaßlichen Sicherheits-

verletzung die Betroffenen

benachrichtigen müssen,

falls sich in der Datenbank

Bürger des Staates Kalifor-

nien befinden).

Abdeckung sämtlicher

wichtigen Systemkompo-

nenten

Verweis auf oder Einbezie-

hung von Verfahren der

Windows Server 2008

Backup & Recovery

System State Backup

Full System Backup

wbadmin.exe

Windows Recovery Envi-

ronment (WinRE)

Technische Lösungen

(Datensicherung, Wieder-

aufnahme und Fortführung

des Betriebes) für den

Vorfallreaktionsplan

Zahlungsmarken zur Reak-

tion auf Vorfälle

Documents

Payment Card Industry Data Security Standard mit Microsoft Windows Server 2008 · 2013-03-30 · Auszug 1. ZUSAMMENFASSUNG Die Analyse, welche Anforderungen der PCI DSS Version 1.2