View
0
Download
0
Category
Preview:
Citation preview
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
Systemkonfigurationsstan-
dards jedes der unten
(unter2.2.1 - 2.2.4) aufge-
führten Elemente enthalten.
2.2.c Überprüfen Sie, ob
Systemkonfigurationsstan-
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
Systemkonfigurationsstan-
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
2.2.2 Überprüfen Sie für
eine Stichprobe von Sys-
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
http://www.microsoft.com/w
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
Systemkonfigurationsstan-
dards enthalten sind.
2.2.3.c Überprüfen Sie für
eine Stichprobe von Sys-
temkomponenten, dass
gängige Sicherheitspara-
meter entsprechend festge-
legt sind.
Windows Server 2008
Security Guide
Specialized Security –
Limited Functionality Tem-
plate
http://www.microsoft.com/w
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).
2.2.4 Überprüfen Sie für
eine Stichprobe von Sys-
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
http://technet.microsoft.com
/en-
us/library/cc732122.aspx
Kombination mit NPS mög-
lich
http://technet.microsoft.com
/de-
de/library/cc754634.aspx
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.
http://technet.microsoft.com
/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
http://technet.microsoft.com
/de-
de/library/cc730763.aspx
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.
7.2.2 Bestätigen Sie, dass
Zugriffskontrollsysteme
konfiguriert sind, um Be-
rechtigungen durchzuset-
zen, die einzelnen Perso-
nen anhand der Tätigkeits-
klassifizierung und -funktion
zugewiesen sind.
7.2.3 Bestätigen Sie, dass
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
Technische Lösung vor-
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.
8.5.5 Überprüfen Sie, ob
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
Technische Lösung vor-
handen für den Prozess
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.
8.5.6 Überprüfen Sie, ob
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
Technische Lösung vor-
handen für den Prozess
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.
8.5.11 Überprüfen Sie
stichprobenartig bei be-
stimmten Systemkompo-
nenten die Konfigurations-
einstellungen daraufhin, ob
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)
Technische Lösung für die
Kennwortrichtlinie
SSLF Template
sche und alphabetische
Zeichen enthalten.
8.5.12 Überprüfen Sie
stichprobenartig bei be-
stimmten Systemkompo-
nenten die Konfigurations-
einstellungen daraufhin, ob
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.
8.5.13 Überprüfen Sie
stichprobenartig bei be-
stimmten Systemkompo-
nenten die Konfigurations-
einstellungen daraufhin, ob
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-
tion\Policies\Windows
Settings\Security Set-
tings\Account Poli-
cies\Account Lockout Policy
Settings LockoutBadCount
Password Setting Object
(PSO)
Technische Lösung für die
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-
8.5.14 Überprüfen Sie
stichprobenartig bei be-
stimmten Systemkompo-
nenten die Konfigurations-
einstellungen daraufhin, ob
eine mindestens 30-
minütige Aussperrdauer gilt,
innerhalb derer das Konto
nur durch den Administrator
zurückgesetzt werden kann.
Computer Configura-
tion\Policies\Windows
Settings\Security Set-
tings\Account Poli-
cies\Account Lockout Policy
LockoutDuration
Technische Lösung für die
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.
8.5.15 Überprüfen Sie
stichprobenartig bei be-
stimmten Systemkompo-
nenten die Konfigurations-
einstellungen daraufhin, ob
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
Technische Lösung des
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
Technische Lösung des
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,
Systemkomponenten oder
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:
10.3.1 Prüfen Sie, ob die
Benutzer-ID in den Proto-
kolleinträgen enthalten ist.
10.3.2 Prüfen Sie, ob die
Art des Ereignisses in den
Protokolleinträgen enthalten
ist.
10.3.3 Prüfen Sie, ob die
Datums- und Zeitangabe in
den Protokolleinträgen
enthalten ist.
10.3.4 Prüfen Sie, ob der
Hinweis auf die erfolgreiche
oder fehlgeschlagene
Ausführung in den Proto-
kolleinträgen enthalten ist.
10.3.5 Prüfen Sie, ob der
Ursprung des Ereignisses
in den Protokolleinträgen
enthalten ist.
10.3.6 Überprüfen Sie, ob
die Identität oder der Name
der betroffenen Daten,
Systemkomponenten oder
Ressourcen in den Proto-
kolleinträgen enthalten ist.
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.
10.5.1 Überprüfen Sie, ob
Einzelpersonen nur mit
arbeitsbedingtem Bedarf
auf Audit-Trail-Dateien
zugreifen können.
10.5.2 Überprüfen Sie, ob
die Dateien des aktuellen
Audit-Trails mit Zugriffs-
steuerungssystemen, räum-
licher Trennung und/oder
Netzwerktrennung vor
unbefugten Änderungen
geschützt werden.
10.5.3 Überprüfen Sie, ob
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.
12.3.2 Überprüfen Sie, ob
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
Technische Lösung für die
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.
12.3.8 Überprüfen Sie, ob
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
Technische Lösung für die
Verwendungsrichtlinie
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
12.3.10 Überprüfen Sie, ob
in der Verwendungsrichtli-
nie festgelegt ist, dass
Karteninhaberdaten bei
Client Settings Register:
Device Redirections
Clipboard
Technische Lösung für die
Verwendungsrichtlinie
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.
12.9.1 Überprüfen Sie, ob
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
Recommended