EMC Smarts Network Configuration Manager Compliance Advisor · EMC® Smarts® Network Configuration...

EMC® Smarts®

Network Configuration Manager Compliance AdvisorVersion 9.2

Payment Card Industry Data Security Standard Requirements and Best PracticesP/N 300-999-879REV 01

EMC Smarts Network Configuration Manager PCI DSS Requirements and Best Practices2

Copyright © 2009 - 2013 EMC Corporation. All rights reserved. Published in the USA.

Published March, 2013

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners.

For the most up-to-date regulatory document for your product line, go to EMC Online Support (https://support.emc.com).

http://support.emc.com

CONTENTS

Preface

Chapter 1 Introducing the Network Configuration Manager Compliance Advisor

What is the Network Configuration Manager ................................................ 14 What is the Network Configuration Manager Compliance Advisor? ............... 14 What is Payment Card Industry Data Security Standard (PCI DSS)?............... 14 About this Manual ...................................................................................... 15

Chapter 2 System Requirements

Compatibility .............................................................................................. 18Network Configuration Manager Compliance Advisor and Network Configuration Manager Network Advisor................................................ 18

Hardware Requirements.............................................................................. 18 Software Requirements............................................................................... 18

Chapter 3 PCI DSS Requirements

PCI DSS Requirements ................................................................................ 20

Chapter 4 Best Practices for (1.1.1)

PCI DSS Requirement (1.1.1)—Best Practices .............................................. 36Recording Change Information .............................................................. 36Scheduled Jobs, Cut-Throughs, and External Changes ........................... 38Security and Reliability.......................................................................... 39Formal Change Approval Process........................................................... 40

PCI DSS Requirement (1.1.1)—Reports ........................................................ 44Change Approval Summary ................................................................... 44Unapproved and Cut-Through Changes ................................................. 44List of jobs with same Approver or Submitter......................................... 44Job Summary......................................................................................... 45Pending Jobs......................................................................................... 45Credential Usage Summary ................................................................... 45


PCI DSS Requirement (1.1.2)—Best Practices .............................................. 48 Building and Validating Network Diagrams........................................... 48Using the Diagram View ........................................................................ 48Using the Connection Report ................................................................. 48

PCI DSS Requirement (1.1.2)—Reports ........................................................ 48Device Connections............................................................................... 48


PCI DSS Requirement (1.1.3)—Best Practices .............................................. 50Viewing Firewall Compliance Status ...................................................... 50

EMC Smarts Network Configuration Manager PCI DSS Requirements and Best Practices 3

Contents


PCI DSS Requirement (1.1.4)—Best Practices .............................................. 52Permissions .......................................................................................... 52Basic Group Setup ................................................................................ 53

PCI DSS Requirement (1.1.4)—Reports ........................................................ 53Group Report......................................................................................... 53User Report ........................................................................................... 53Approval Permissions ........................................................................... 53


PCI DSS Requirement (1.1.5)—Best Practices .............................................. 56Documenting Port and Service Requirements ........................................ 56Template and Test Properties ................................................................ 57

PCI DSS Requirement (1.1.5)—Reports ........................................................ 57Compliance Policy Definition Report...................................................... 57


PCI DSS Requirement (1.1.6)—Best Practices .............................................. 60Using Review Comments for Quarterly Reviews...................................... 60

Chapter 10 Best Practices for (1.2)

PCI DSS Requirement (1.2)—Best Practices ................................................. 62


PCI DSS Requirement (1.2.1)—Best Practices .............................................. 64 PCI DSS Requirement (1.2.1)—Reports ........................................................ 64

Compliance Summary ........................................................................... 64Non-Compliant Devices ......................................................................... 64



Device State Report............................................................................... 66





PCI DSS Requirement (1.3)—Best Practices ................................................. 70Using Network Configuration Manager Policies to Detect and Remediate Policy Violations ................................................................................... 70

PCI DSS Requirement (1.3)—Reports ........................................................... 71Compliance Score Card ......................................................................... 71Policy Summary Report ......................................................................... 71

4 EMC Smarts Network Configuration Manager PCI DSS Requirements and Best Practices

Contents




















PCI DSS Requirement (2.1)—Best Practices ................................................. 88 PCI DSS Requirement (2.1)—Reports ........................................................... 88






Contents


PCI DSS Requirement (2.2)—Best Practices ................................................. 92





PCI DSS Requirement (2.2.3)—Best Practices .............................................. 96


PCI DSS Requirement (2.2.4)—Best Practices .............................................. 98


PCI DSS Requirement (2.3)—Best Practices ............................................... 100Network Configuration Manager to Devices ......................................... 100Selecting Secure Protocols .................................................................. 100Insecure Protocols............................................................................... 100Protocols between Network Configuration Manager Servers ................ 101

PCI DSS Requirement (2.3)—Reports ......................................................... 101Compliance Summary ......................................................................... 101Non-Compliant Devices ....................................................................... 101


PCI DSS Requirement (4.1)—Best Practices ............................................... 104 PCI DSS Requirement (4.1)—Reports ......................................................... 104

Compliance Summary ......................................................................... 104Non-Compliant Devices ....................................................................... 104



OS Version Inventory........................................................................... 106


PCI DSS Requirement (6.4.1)—Best Practices ............................................ 108


PCI DSS Requirement (6.4.2)—Best Practices ............................................ 110





Contents


PCI DSS Requirement (8.5.13)—Best Practices .......................................... 114Native Registry .................................................................................... 114TACACS+ ............................................................................................. 114RADIUS> .............................................................................................. 114LDAP ................................................................................................... 114


PCI DSS Requirement (8.5.14)—Best Practices .......................................... 116




PCI DSS Requirement (10.1)—Best Practices ............................................. 120










PCI DSS Requirement (10.2.7)—Best Practices .......................................... 130Security System-level Objects ............................................................. 130Device and Credentials System-level Objects ...................................... 130Device Containment System-level Object ............................................ 130Automation Library (Compliance and Standardization) System-level Objects ............................................................................................... 131








Contents








PCI DSS Requirement (10.4)—Best Practices ............................................. 146 PCI DSS Requirement (10.4)—Reports ....................................................... 146














Glossary

Index


PREFACE

As part of an effort to improve its product lines, EMC periodically releases revisions of its software and hardware. Therefore, some functions described in this document might not be supported by all versions of the software or hardware currently in use. The product release notes provide the most up-to-date information on product features.

Contact your EMC technical support professional if a product does not function properly or does not function as described in this document.

Note: This document was accurate at publication time. Go to EMC Online Support (https://support.emc.com) to ensure that you are using the latest version of this document.

Revision History

AudienceThis document is part of the EMC Smarts Network Configuration Manager documentation set, and is intended for use by those individuals who have the responsibility of installing and deploying EMC Smarts Compliance Advisor.

Readers of this document are expected to be familiar with the following topics:

◆ Linux operating systems

◆ Database architecture and concepts

◆ Security management

◆ Internet protocols, including HTTP, TCP/IP, File Transfer Protocol (FTP), and Telnet

◆ Lightweight Directory Access Protocol (LDAP) and directory services

◆ Authentication and authorization

Related documentationRelated documents include:

◆ EMC Smarts Network Configuration Manager Release Notes

◆ EMC Smarts Network Configuration Manager Installation Guide

◆ Smarts Network Configuration Manager EMC Data Access API (EDAA) Programmer Guide

◆ EMC Smarts Network Configuration Manager Applicaton Program Interface (API) Javadoc Reference Guide

◆ EMC Smarts Network Configuration Manager Device Access Scripting Language (DASL) Specifications Guide

Date Revision Description

March, 2013 01 GA release

Preface 9


Preface

◆ EMC Smarts Network Configuration Manager Documentation Portfolio

◆ EMC Smarts Open Source License and Copyright Information

◆ EMC Smarts Network Configuration Manager Online User Guide

◆ EMC Smarts Network Configuration Manager System Management Console Guide

◆ EMC Smarts Network Configuration Manager Attributed Model User Guide

◆ EMC Smarts Network Configuration Manager Security Configuration Guide

◆ EMC Smarts Network Configuration Manager User Guide

◆ EMC Smarts Network Configuration Manager Troubleshooting Guide

◆ EMC Smarts Network Configuration Manager Device Driver Toolkit Technical Notes

DisclaimerEMC emphasizes that there is no PCI compliance certification that can be associated to a product. Experience demonstrates that regulatory compliance is achieved through a structured approach to network security and business process continuity. This must be closely aligned with defined and documented best practices and business operations.

The included PCI documentation sections describe the PCI Data Security Standard requirements, suggested how to's for optimizing existing Network Configuration Manager Compliance Advisor capabilities to meet best practices, associated samples, and reporting options. EMC has responded to the technology requirements. Please note that the application of best practices as outlined by the PCI Standard is a critical component.

Conventions used in this documentEMC uses the following conventions for special notices:

NOTICE is used to address practices not related to personal injury.

Note: A note presents information that is important, but not hazard-related.

IMPORTANT

An important notice contains information essential to software or hardware operation.

Typographical conventions

EMC uses the following type style conventions in this document:

Bold Use for names of interface elements, such as names of windows, dialog boxes, buttons, fields, tab names, key names, and menu paths (what the user specifically selects or clicks)

Italic Use for full titles of publications referenced in text

Monospace Use for:• System output, such as an error message or script• System code• Pathnames, filenames, prompts, and syntax• Commands and options

Monospace italic Use for variables.


Preface

Where to get helpEMC support, product, and licensing information can be obtained as follows:

Product information — For documentation, release notes, software updates, or information about EMC products, go to EMC Online Support at:

https://support.emc.com

Technical support — Go to EMC Online Support and click Service Center. You will see several options for contacting EMC Technical Support. Note that to open a service request, you must have a valid support agreement. Contact your EMC sales representative for details about obtaining a valid support agreement or with questions about your account.

Your commentsYour suggestions will help us continue to improve the accuracy, organization, and overall quality of the user publications. Send your opinions of this document to:

[email protected]

Monospace bold Use for user input.

[ ] Square brackets enclose optional values

| Vertical bar indicates alternate selections — the bar means “or”

{ } Braces enclose content that the user must specify, such as x or y or z

... Ellipses indicate nonessential information omitted from the example

11


Preface


CHAPTER 1Introducing the Network Configuration Manager Compliance Advisor

This chapter presents these topics:

◆ What is the Network Configuration Manager ............................................................ 14◆ What is the Network Configuration Manager Compliance Advisor? ........................... 14◆ What is Payment Card Industry Data Security Standard (PCI DSS)?........................... 14◆ About this Manual .................................................................................................. 15

Introducing the Network Configuration Manager Compliance Advisor 13

Introducing the Network Configuration Manager Compliance Advisor

What is the Network Configuration Manager◆ The Network Configuration Manager is a network configuration management tool that

gives you the power to quickly, easily, and accurately design, modify, and maintain networks, using an intuitive graphical network view.

◆ The Network Configuration Manager automates complex and routine engineering tasks, such as adding devices and connections, with drag-and-drop simplicity.

◆ Via real-time auto discovery of network devices and logical and physical topology information, the Network Configuration Managerprovides a proactive configuration management approach.

What is the Network Configuration Manager Compliance Advisor?The Network Configuration Manager Compliance Advisor is the first product in a new Advisory Series. The Network Configuration Manager Compliance Advisor removes guesswork associated with ensuring network devices adhere to the PCI Industry Data Security Standard (DSS), a set of best practices, which mandate that companies must enhance data security and proactively protect customer account information at all points in the payment process.

New changes to compliance regulations coupled with the size and distributed nature of today’s networks have complicated IT personnel’s ability to secure corporate and personal data. The Network Configuration Manager Compliance Advisor maps change and configuration data directly into embedded DSS mandates to help ensure network devices stay compliant with repeatable processes and dynamic dashboard displays.

This new offering also eases audits with in-depth reports detailing how network devices adhere to each The Network Configuration Manager Compliance Advisor DSS requirement.

What is Payment Card Industry Data Security Standard (PCI DSS)?The Payment Card Industry Data Security Standard (PCI DSS) is a set of best practices that require companies to enhance data security, and proactively protect customer account information at all points in the payment process. It consists of twelve principles for which detailed requirements are then provided. Two of these top-level principles, “Build and Maintain a Secure Network” and “Regularly Monitor and Test Networks,” are clearly focused on network compliance.

Without compliance to appropriate best practices and standards, such as PCI DSS, the potential impact to those involved with PCI are clear – loss of revenue, loss of customers, loss of good will, law suits, fines, penalties and more!

The costs associated with a data security breach can far outstrip the costs of compliance management, enforcement, and reporting. And the possibility of becoming involved in such an event is real. IT organizations should work to reduce the probability of this happening to them.



About this ManualAll PCI DSS requirements are listed, in detail, along with the corresponding EMC response and steps needed to address each requirement.

About this Manual 15

CHAPTER 2System Requirements


◆ Compatibility .......................................................................................................... 18◆ Hardware Requirements.......................................................................................... 18◆ Software Requirements........................................................................................... 18

System Requirements 17

System Requirements

Compatibility

Network Configuration Manager Compliance Advisor and Network Configuration Manager Network Advisor

Upgrading to Network Configuration Manager 9.2 will make Network Advisor and Compliance Advisor inoperable until a compatible release is installed. The following are the compatible versions for Network Configuration Manager 9.2:

◆ Network Advisor version 9.2

◆ Compliance Advisor version 9.2

Hardware RequirementsFor a detailed list of Hardware Requirements for Compliance Advisor, see EMC Smarts Network Configuration Manager Installation Guide.

Software RequirementsFor a detailed list of Software Requirements for Compliance Advisor, see EMC Smarts Network Configuration Manager Installation Guide.


CHAPTER 3PCI DSS Requirements


◆ PCI DSS Requirements ............................................................................................ 20

PCI DSS Requirements 19

PCI DSS Requirements


Note: Click on the page numbers provided in the Valid for Network Configuration Manager column to quickly review the Best Practices for a specific requirement.

PCI DSS Requirement Number Requirement

Valid for Network Configuration Manager

1.1 Establish firewall and router configuration standards that include the following:

1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations

Yes.See page 35

1.1.2 Current network diagram with all connections to cardholder data, including any wireless networks

Yes.See page 47

1.1.3 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone

Yes. See page 49

1.1.4 Description of groups, roles, and responsibilities for logical management of network components

Yes.See page 51

1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure

Yes.See page 55

1.1.6 Requirement to review firewall and router rule sets at least every six months

Yes.See page 59

1.2 Build a firewall configuration that restricts connections between untrusted networks and any system components in the cardholder data environment.

Yes.See page 61

1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.

Yes.See page 63

1.2.2 Secure and synchronize router configuration files. Yes.See page 65

1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

Yes.See page 67

1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.

Yes.See page 69

1.3.1 Implement a DMZ to limit inbound and outbound traffic to only protocols that are necessary for the cardholder data environment.

Yes.See page 73

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. Yes.See page 75

1.3.3 Do not allow any direct routes inbound or outbound for traffic between the Internet and the cardholder data environment.

Yes.See page 77



1.3.4 Do not allow internal addresses to pass from the Internet into the DMZ.

Yes.See Page 79

1.3.5 Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ.

Yes.See page 81

1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only ”established” connections are allowed into the network.)

1.3.7 Place the database in an internal network zone, segregated from the DMZ.

1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies—for example, port address translation (PAT).

Yes.See page 83

1.4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.

2.1 Always change vendor-supplied defaults before installing a system on the network—for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.

Yes.See page 87

2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Ensure wireless device security settings are enabled for strong encryption technology for authentication and transmission.

Yes.See page 89

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Yes.See page 91

2.2.1 Implement only one primary function per server.

2.2.2 Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the device’s specified function).

Yes.See page 93

2.2.3 Configure system security parameters to prevent misuse. Yes.See page 95

2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

Yes.See page 97

2.3 Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

Yes.See page 99

2.4 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.





3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.

3.2 Do not store sensitive authentication data after authorization (even if encrypted).Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:

3.2.1 Do not store the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Note: Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:

• The cardholder’s name,• Primary account number (PAN),• Expiration date, and• Service codeTo minimize risk, store only these data elements as needed for business.

Note: Note: See PCI DSS Glossary of Terms, Abbreviations, and Acronyms for additional information.

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions. Note: See PCI DSS Glossary of Terms, Abbreviations, and Acronyms for additional information.

3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.

3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). Notes:• This requirement does not apply to employees and other

parties with a legitimate business need to see the full PAN.• This requirement does not supersede stricter requirements in

place for displays of cardholder data—for example, for point-of-sale (POS) receipts.





3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:• One-way hashes based on strong cryptography• Truncation• Index tokens and pads (pads must be securely stored)• Strong cryptography with associated key-management

processes and proceduresThe MINIMUM account information that must be rendered unreadable is the PAN.Notes:• If for some reason, a company is unable render the PAN

unreadable, refer to Appendix B: Compensating Controls.• “Strong cryptography” is defined in the PCI DSS Glossary of

Terms, Abbreviations, and Acronyms.

3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.

3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse:

3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.

3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.

3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:

3.6.1 Generation of strong cryptographic keys

3.6.2 Secure cryptographic key distribution

3.6.3 Secure cryptographic key storage

3.6.4 Periodic cryptographic key changes• As deemed necessary and recommended by the associated

application (for example, re-keying); preferably automatically• At least annually

3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys

3.6.6 Split knowledge and establishment of dual control of cryptographic keys

3.6.7 Prevention of unauthorized substitution of cryptographic keys

3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities





4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.Examples of open, public networks that are in scope of the PCI DSS are:• The Internet,• Wireless technologies,• Global System for Mobile communications (GSM), and• General Packet Radio Service (GPRS).

Yes.See page 103

4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission.• For new wireless implementations, it is prohibited to

implement WEP after March 31, 2009.• For current wireless implementations, it is prohibited to use

WEP after June 30, 2010.

Yes.See page 103

4.2 Never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat).

5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.

5.2 Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.

6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.

Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.

Yes.See page 105

6.2 Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues.

6.3 Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices, and incorporate information security throughout the software development life cycle. These processes must include the following:





6.3.1 Testing of all security patches, and system and software configuration changes before deployment, including but not limited to the following:• 6.3.1.1: Validation of all input (to prevent cross-site scripting,

injection flaws, malicious file execution, etc.)• 6.3.1.2: Validation of proper error handling• 6.3.1.3: Validation of secure cryptographic storage• 6.3.1.4: Validation of secure communications• 6.3.1.5: Validation of proper role-based access control (RBAC)

6.3.2 Separate development/test and production environments

6.3.3 Separation of duties between development/test and production environments

6.3.4 Production data (live PANs) are not used for testing or development

6.3.5 Removal of test data and accounts before production systems become active

6.3.6 Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers

6.3.7 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability

Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle required by PCI DSS Requirement 6.3. Code reviews can be conducted by knowledgeable internal personnel or third parties. Web applications are also subject to additional controls, if they are public facing, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

6.4 Follow change control procedures for all changes to system components. The procedures must include the following:

6.4.1 Documentation of impact Yes.See page 107

6.4.2 Management sign-off by appropriate parties Yes.See page 109

6.4.3 Testing of operational functionality

6.4.4 Back-out procedures





6.5 Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include the following:

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current in the OWASP guide when PCI DSS v1.2 was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements.

6.5.1 Cross-site scripting (XSS)

6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws.

6.5.3 Malicious file execution

6.5.4 Insecure direct object references

6.5.5 Cross-site request forgery (CSRF)

6.5.6 Information leakage and improper error handling

6.5.7 Broken authentication and session management

6.5.8 Insecure cryptographic storage

6.5.9 Insecure communications

6.5.10 Failure to restrict URL access

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:• Reviewing public-facing web applications via manual or

automated application vulnerability security assessment tools or methods, at least annually and after any changes

• Installing a web-application firewall in front of public-facing web applications

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following:

7.1.1 Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities

7.1.2 Assignment of privileges is based on individual personnel’s job classification and function

7.1.3 Requirement for an authorization form signed by management that specifies required privileges

7.1.4 Implementation of an automated access control system





7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.This access control system must include the following:

7.2.1 Coverage of all system components

7.2.2 Assignment of privileges to individuals based on job classification and function

7.2.3 Default “deny-all” setting

8.1 Assign all users a unique ID before allowing them to access system components or cardholder data.

8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:• Password or passphrase• Two-factor authentication (for example, token devices, smart

cards, biometrics, or public keys)

8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS); terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.

Yes.See page 111

8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography (defined in PCI DSS Glossary of Terms, Abbreviations, and Acronyms).

8.5 Ensure proper user authentication and password management for non-consumer users and administrators on all system components as follows:

8.5.1 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

8.5.2 Verify user identity before performing password resets.

8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use.

8.5.4 Immediately revoke access for any terminated users.

8.5.5 Remove/disable inactive user accounts at least every 90 days.

8.5.6 Enable accounts used by vendors for remote maintenance only during the time period needed.

8.5.7 Communicate password procedures and policies to all users who have access to cardholder data.

8.5.8 Do not use group, shared, or generic accounts and passwords.

8.5.9 Change user passwords at least every 90 days.

8.5.10 Require a minimum password length of at least seven characters.





8.5.11 Use passwords containing both numeric and alphabetic characters.

8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.

8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts.

Yes.See page 113

8.5.14 Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Yes.See page 115

8.5.15 If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal.

Yes.See page 117

8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.

9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.

9.1.1 Use video cameras or other access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.

Note: “Sensitive areas” refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes the areas where only point-of-sale terminals are present, such as the cashier areas in a retail store.

9.1.2 Restrict physical access to publicly accessible network jacks.

9.1.3 Restrict physical access to wireless access points, gateways, and handheld devices.

9.2 Develop procedures to help all personnel easily distinguish between employees and visitors, especially in areas where cardholder data is accessible. For purposes of this requirement, “employee” refers to full-time and part-time employees, temporary employees and personnel, and contractors and consultants who are “resident” on the entity’s site. A “visitor” is defined as a vendor, guest of an employee, service personnel, or anyone who needs to enter the facility for a short duration, usually not more than one day.

9.3 Make sure all visitors are handled as follows:

9.3.1 Authorized before entering areas where cardholder data is processed or maintained

9.3.2 Given a physical token (for example, a badge or access device) that expires and that identifies the visitors as non-employee

9.3.3 Asked to surrender the physical token before leaving the facility or at the date of expiration





9.4 Use a visitor log to maintain a physical audit trail of visitor activity. Document the visitor’s name, the firm represented, and the employee authorizing physical access on the log. Retain this log for a minimum of three months, unless otherwise restricted by law.

9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location’s security at least annually.

9.6 Physically secure all paper and electronic media that contain cardholder data.

9.7 Maintain strict control over the internal or external distribution of any kind of media that contains cardholder data, including the following:

9.7.1 Classify the media so it can be identified as confidential.

9.7.2 Send the media by secured courier or other delivery method that can be accurately tracked.

9.8 Ensure management approves any and all media containing cardholder data that is moved from a secured area (especially when media is distributed to individuals).

9.9 Maintain strict control over the storage and accessibility of media that contains cardholder data.

9.9.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.

9.10 Destroy media containing cardholder data when it is no longer needed for business or legal reasons as follows:

9.10.1 Shred, incinerate, or pulp hardcopy materials so that cardholder data cannot be reconstructed.

9.10.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed.

10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

Yes.See page 119

10.2 Implement automated audit trails for all system components to reconstruct the following events:

10.2.1 All individual accesses to cardholder data

10.2.2 All actions taken by any individual with root or administrative privileges

Yes.See page 121

10.2.3 Access to all audit trails Yes.See page 123

10.2.4 Invalid logical access attempts Yes.See page 125

10.2.5 Use of identification and authentication mechanisms Yes.See page 127





10.2.6 Initialization of the audit logs

10.2.7 Creation and deletion of system-level objects Yes.See page129

10.3 Record at least the following audit trail entries for all system components for each event:

10.3.1 User identification Yes.See page 133

10.3.2 Type of event Yes.See page 135

10.3.3 Date and time Yes.See page 137

10.3.4 Success or failure indication Yes.See page 139

10.3.5 Origination of event Yes.See page 141

10.3.6 Identity or name of affected data, system component, or resource

Yes.See page 143

10.4 Synchronize all critical system clocks and times. Yes.See page 145

10.5 Secure audit trails so they cannot be altered. Yes.See page 147

10.5.1 Limit viewing of audit trails to those with a job-related need. Yes.See page 149

10.5.2 Protect audit trail files from unauthorized modifications. Yes.See page 151

10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN.

10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).

Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6

Yes.See page 153





10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).

11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV) qualified by Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by the company’s internal staff.

11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following:

11.3.1 Network-layer penetration tests

11.3.2 Application-layer penetration tests

11.4 Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines up-to-date.

11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Note: For file-integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

12.1 Establish, publish, maintain, and disseminate a security policy that accomplishes the following:

Yes.See page 155

12.1.1 Addresses all PCI DSS requirements. Yes.See page 157

12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.





12.1.3 Includes a review at least once a year and updates when the environment changes.

12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures).

12.3 Develop usage policies for critical employee-facing technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, personal data/digital assistants (PDAs), e-mail usage and Internet usage) to define proper use of these technologies for all employees and contractors. Ensure these usage policies require the following:

12.3.1 Explicit management approval

12.3.2 Authentication for use of the technology

12.3.3 A list of all such devices and personnel with access

12.3.4 Labeling of devices with owner, contact information, and purpose

12.3.5 Acceptable uses of the technology

12.3.6 Acceptable network locations for the technologies

12.3.7 List of company-approved products

12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity

12.3.9 Activation of remote-access technologies for vendors only when needed by vendors, with immediate deactivation after use

12.3.10 When accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media.

12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all employees and contractors.

12.5 Assign to an individual or team the following information security management responsibilities:

12.5.1 Establish, document, and distribute security policies and procedures.

12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel.

12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.

12.5.4 Administer user accounts, including additions, deletions, and modifications

12.5.5 Monitor and control all access to data.





12.6 Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.

12.6.1 Educate employees upon hire and at least annually.

12.6.2 Require employees to acknowledge at least annually that they have read and understood the company’s security policy and procedures.

12.7 Screen potential employees (see definition of “employee” at 9.2 above) prior to hire to minimize the risk of attacks from internal sources.

Note: For those employees such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.

12.8 If cardholder data is shared with service providers, maintain and implement policies and procedures to manage service providers, to include the following:

12.8.1 Maintain a list of service providers.

12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.

12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status.

12.9 Implement an incident response plan. Be prepared to respond immediately to a system breach.

12.9.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:• Roles, responsibilities, and communication and contact

strategies in the event of a compromise including notification of the payment brands, at a minimum

• Specific incident response procedures• Business recovery and continuity procedures• Data back-up processes• Analysis of legal requirements for reporting compromises• Coverage and responses of all critical system components• Reference or inclusion of incident response procedures from

the payment brands

12.9.2 Test the plan at least annually.

12.9.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts.





12.9.4 Provide appropriate training to staff with security breach response responsibilities.

12.9.5 Include alerts from intrusion-detection, intrusion-prevention, and file-integrity monitoring systems.

12.9.6 Develop process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.




CHAPTER 4Best Practices for (1.1.1)


◆ PCI DSS Requirement (1.1.1)—Best Practices .......................................................... 36◆ PCI DSS Requirement (1.1.1)—Reports .................................................................... 44

Best Practices for (1.1.1) 35

Best Practices for (1.1.1)

PCI DSS Requirement (1.1.1)—Best PracticesEstablish firewall and router configuration standards that include the following: A formal process for approving and testing all network connections and changes to the firewall and router configurations.

Recording Change Information

The Network Configuration Manager can audit and monitor a network for configuration changes. This section describes the best practices and methods available for implementing change control using the Network Configuration Manager.

Syslog and TrapsThe Network Configuration Manageris capable of accepting Syslog and Trap information from devices. These notification events can be used to trigger an automated collection of configurations as changes occur to the network. The primary goal of monitoring Syslog and Traps notifications is to monitor the network for changes completed outside of the configuration management system.

For the Auditor: Some examples of changes completed outside of the configuration management system are:

◆ " Using Telnet to directly access a router, and making a configuration change

◆ "Using the auxiliary console to make changes using a terminal server

Not all devices are capable of notifying the configuration management system when changes occur. Those devices that are capable of change notifications should have the feature enabled. There are Saved Commands available that can help configure the equipment to send Syslog or Traps notifications to the Network Configuration Manager device server.

Using Saved Commands to Setup NotificationsThe Network Configuration Manager contains Saved Commands to setup the Syslog or Trap host for your device.

Use the right-click menu of a Network or Site Workspace to access the Saved Commands within the Network Configuration Manager. The Saved Commands (Setup Trap Host or Setup Syslog Host) are used to configure the device to direct the configuration change events to the device server managing the device.

Once a device is discovered, the administrator of the workspace should enable Syslog or Traps messages to monitor the devices for change. There are trade-offs when using Syslog or Traps, summarized as follows.

◆ "Syslog notifications are generally more CPU intensive because they have to be parsed for content before the device server can determine the source or nature of the trap.

◆ "Traps notifications are generally less CPU intensive because the information is encoded, and the SNMP protocol identifies the nature of the trap.

◆ "Syslog is transmitted in plain text, and does not accept any inbound communications or allow access to read.



◆ "Traps generally require the device to be configured with an SNMP community string.

◆ "Some network operations groups prefer not to use SNMP because it is generally insecure; however, SNMP traps are generally preferred over Syslog messages.

In both Syslog and Traps you must have UDP ports open between the network device and the device server. The following UDP ports are used:

Verifying Syslog or Trap ConfigurationsThe Network Configuration Manager allows you to run a compliance test against a device to ensure they are configured to issue Syslog or Traps notifications. A compliance test needs to test for the IP address of the device server in the configuration, and the configuration commands for the desired notifications. If the device server is behind a firewall or another system of Syslog, or Trap forwarding is used, the compliance audit should also verify this configuration.

Note: The IP address of the device server can be seen in the System Administration window of the Network Configuration Manager under Global -> Access -> Device Servers.

Using other Syslog or Trap MonitorsWhen a device server is already configured to send Syslog or Traps messages to another system, the system should be configured to forward the Syslog or Traps messages to the device server managing the device.

If the system is not capable of forwarding the Syslog or Traps messages to the device server managing the device, the system should forward the notification or trap to all device servers.

This is not the most desirable configuration, since it requires the device server to drop messages for all other devices, and can cause a performance issues. When possible the devices should be configured to send traps to both the device server and the other external system.

Note: A device server will disregard any notifications for a device it is not currently managing.

What if Syslogs and Traps are not possible?The Network Configuration Manager allows for scheduling jobs at reoccurring intervals when Syslog and Traps are not an option for monitoring out of process changes on certain networks or devices without the capability.

Use the right-click menu to schedule a pull on a network or site container to set a reoccurring schedule.

Type Protocol Port

Trap UDP 162

Syslog UDP 514

PCI DSS Requirement (1.1.1)—Best Practices 37


To ensure there are no unauthorized changes, the network should be polled, by scheduling a reoccurring pull. Reoccurring pulls can be scheduled as frequently as hourly, or as often as monthly. The frequency should be based on your policy and proportional to the amount of tolerance for unauthorized network changes.

Note: The frequency of polling should not be shorter than daily to reduce stress on larger networks.

Scheduled Jobs, Cut-Throughs, and External Changes

Schedule changes are generally used as a means of configuring a device.

Scheduled JobsA scheduled job is a task that is scheduled to run using the Network Configuration Manager Schedule Manager. Schedule jobs:

◆ Provide the most accountability and auditing within the system.

◆ Can be queried from the Schedule Manager and are tracked in the Event Manager.

◆ Have the ability to be scheduled by a junior operator, and approved by a senior operator or manager.

◆ Can email status to operators upon failure or success, and can provide event notifications to third party systems.

Scheduled Jobs Name and DescriptionsTo better track scheduled jobs, users should give the jobs clear and well defined names. For example, if your company uses an order tracking system, use the order number or tracking number in the job name.

The Schedule Manager allows you to order and filter the job view by the name used when scheduling the job. The job name is used in the description of the event log, and can be searched for later to see who and when an order was approved and executed.

Cut-ThroughsCut-Throughs are an encrypted proxy connection to the devices throughout the Network Configuration Manager. Cut-through connections are configured to issue a configuration poll after the user terminates the cut-through connection. By default this poll occurs 20 minutes after the last cut-through terminates. Multiple cut-throughs, in succession, will pull the configuration only once if they fall between the 20 minutes.

In the System Administration Window there is a timer for each device server which controls the delay between the cut-through termination and the device poll. Setting this time lower may result in a higher number of revisions if cut-throughs are used in frequent succession.

The resulting revision from a cut-through poll will be marked as being created by the user who executed the cut-through. This mechanism is provided to track unscheduled changes as made using a cut-through connection.


Configuring Cut-ThroughsCut-throughs can be configured to ask for a reason or comment for the cut-through request. These comments are stored against the device comments in the network workspace, and can be accessed from the Device Properties.

To turn on the cut-through comment request window:

External ChangesExternal changes are changes that are detected outside of a scheduled job or cut-through. When it can be determined from the header of the configuration or from device records, these external changes are noted as EXTERNAL: user.

When a Syslog or Trap is received from a device it is examined to see if it matches a configuration change notification.

The system will perform a device configuration poll if the Syslog and Traps indicate a configuration change may have occurred on a device. Device configuration polls will detect if there has been a configuration change by retrieving the current device configuration and comparing it against the last known configuration.

If provided by the devices Syslog or Trap notification, the user name is collected and associated with any configuration revision collected during the poll. The user name for the revision history will be recorded as the user who executed the login on the device. If the user name does not match the Network Configuration Manager username, the user will be shown as EXTERNAL: <username> within the Network Configuration Manager.

Security and Reliability

To successfully maintain history and validate changes in your network, you need to consider the security and reliability of your management network.

Protocol ConsiderationsIf security is a focus of your network operations, you may consider using Secure Shell protocol (SSH) for managing and configuring devices. This protocol provides encrypted communications between the device server and devices for issuing configuration updates, and polling configuration changes.

Step Task

1 Locate the powerup.jnlp on the Application server. The default location is $VOYENCE_HOME/ui/html/powerup.jnlp.

2 Find the line feature.cutThroughComment.required within the powerup.jnlp.

3 Change false to true.

JNLP Modification

<property name="feature.cutThroughComment.required" value="false"/>

<property name="feature.cutThroughComment.required" value="true"/>


In addition, many devices are capable of using SNMP V3 for network management. The Network Configuration Manager provides SNMP V3 manageability using authorization and privacy protocols.

SNMP V3, in conjunction with SSH, provides the highest level of security available to manage network devices.

Password and SNMP Community RollsThe Network Configuration Manager provides the ability to centrally roll and maintain device login and privilege level passwords. The facilities to roll a single device or to roll all devices using one password to another are accessible from the System Administrator window.

You should periodically roll passwords using a strong password containing a combination of letters, numbers, and special characters to prevent password guessing or brute force attacks against network devices.

The Network Configuration Manager also provides tools to roll SNMP community strings and SNMP V3 configurations. Similar community string rolling policies should be in place to secure SNMP access from guessing and intrusion.

The Network Configuration Manager can be used to configure SNMP V3 configurations on these devices that permit SNMP V3. By rolling standard SNMP communities to SNMP V3 communities, the Network Configuration Manager will configure and remove un-secure SNMP communities, and replace them with secure SNMP V3 configurations.

Recording the User Who Last Changed the DeviceThe Network Configuration Manager contains a feature that displays the last user to change the configuration of the router on Cisco IOS devices running 12.2 or later. This feature is enabled when Syslog messages are enabled for the device. If enabled, the Network Configuration Manager will set the user to EXTERNAL:<username> of the user listed on the header line of the configuration.

Formal Change Approval Process

Enforcing the appropriate standards in a network begins with defining and implementing a formal change approval process. Formal change approval allows the enforcement of best practices on network devices by providing a means of eliminating non-standard configuration changes before they are introduced to the network.

The Network Configuration Manager delivers three methods for providing the right formal change approval process for your network. Users can choose from:

◆ Implementing the built-in change approval workflow within the Network Configuration Manager

◆ Integrating with a third-party change approval solution

◆ Using the Network Configuration Manager API to construct links to create custom change processes

Each solution provides the necessary tools to detect compliance violations before they affect the network.



User and Group PermissionsA change approval process uses a special permission system to define and enforce the roles of users submitting or approving changes in the network, and establishes custom roles for groups within the network.

A change approval must apply the permission system across the network to any geographical, organizational, or logical domain to be effective.

The Network Configuration Manager provides a full-featured authorization infrastructure for assigning permissions to users and groups that allows for access control to network devices at the system, network, and device level.

For example:

◆ An operations engineer in charge of network devices could be given permissions to create and schedule changes, view configuration information on all devices in their management domain, and have changes approved through the managers.

◆ The security team could be given access to all firewall devices in the network for the purpose of scheduling change, but are not permitted access to other device types within the network.

Job ApprovalOnce the correct user and group authorizations are in place, the Network Configuration Manager provides a job approval environment that enforces single-level approval of scheduled jobs.

When a submitter introduces a change into the Schedule Manager a notification is sent to all users and groups with the appropriate approval credentials.

The submitter (someone who has the ability to schedule a job in the network but cannot provide approvals) determines the run time of the job, and the job is sent to the approver.

The approver reviews the job, and either approves the job, updates the job, rejects the job, leaves the job in a pending state, or cancels the job before the job gets sent to the execution stage.

Job ExecutionThe Network Configuration Manager offers a variety of execution options for delivery of an approved change into the network, once a job and its associated tasks have received final approval. This allows organizations to decide how much control they need over job execution post-approval.

The Network Configuration Manager allows the execution preference for a job to be set by the submitter, the approver, or it can also be changed during the approval phase.

Jobs can be set to run using the following options:

◆ Run upon approval: The job is run as soon as approval is complete

◆ Run in next maintenance window: For environments where maintenance windows are enforced, the job is run depending on end-customers Service Level Agreement

◆ Run upon operator initiation: The job is monitored and run by an operator when jobs are received from users and groups, who may have no authorization to submit or approve changes



◆ Run at scheduled date/time: The job is run based on a one-time execution window set by a submitter or approver

◆ Run as a recurring job: The job is run based on a recurring execution window set by a submitter or approver

Jobs that do not complete the approval process before the execution time are expired, and must be resubmitted into the workflow system.

Job ConflictJob conflict is when two configuration change jobs affect the same device. Job conflict is normally acceptable, because the two updates often deal with different sections of a devices configuration. To prevent errors, it is useful to know if there are existing configuration change jobs scheduled for the device during the approval process.

The Network Configuration Manager offers a conflict notification option within the scheduler that is used during the submission and/or approval process to flag any device where a scheduled change job already exists.

The Network Configuration Manager will also notify the owner of an existing job (via email) if a new change job is scheduled which conflicts with any devices from the existing job.

Using Fault Management to Enhance Change NotificationThe Network Configuration Manager, a Network Configuration Management (NCM) system, once successfully implemented, quickly becomes the database of record for the network. One of the most important features of a NCM application is its ability to integrate with other third-party and corporate applications to provide updated network information and status.

The Network Configuration Manager provides integration points to all critical applications in the network and data center, such as Help Desk systems, Asset Management systems, Configuration Management Databases (CMDBs), and Fault Management Systems (FMS).

Fault Management SystemsFMS provides detection of network and device outages, fault isolation, and alarm notification.

Integration with the corporate FMS is generally the first integration requested for the Network Configuration Manager.

Integrating the Network Configuration Manager with FMS solutions provides extended alarm capabilities and fault isolation to provide comprehensive root cause analysis, and to reduce the time needed for full restoration of services.

The Network Configuration Manager provides integration modules for the following common FMS products:

◆ EMC Smarts

◆ HP Network Node Manager

◆ IBM NetCool

◆ Many other popular vendors



In cases where an integration module does not exist, the Network Configuration Manager provides customers with the ability to use the integrated event framework and public API to deliver network data and status to any external source or application.

Fault Management System IntegrationsMost outages in a network are introduced by unapproved changes in the network. Outages can still occur, even with all the right change processes in place, because change management is a human process and susceptible to human error.

Defining, implementing, and enforcing appropriate change approval and compliance audit processes in the network to reduce the number of outages due to non-standard and unapproved configuration changes is critical.

The Network Configuration Manager greatly enhances Fault Management System capabilities by providing notification for both approved and unapproved configuration changes in the network. This provides the Network Operations Center (NOC) with the ability to immediately correlate a configuration change on a device with a network outage.

An example of how Network Change Management could reduce the restoration time of a network outage due to change, could be as follows.

◆ A network engineer needs to add an IP address to a new interface on an internal router (X). The engineer creates the appropriate change in the Network Configuration Manager, and retrieves the next available IP address for the network. The engineer submits the job for approval.

◆ The approver reviews the job, and also verifies the IP address. The job is approved and runs at the scheduled time of 2:00 a.m.

◆ At 2:01 a.m. the change is revisioned in the Network Configuration Manager, and using the event framework and FMS integration, the Network Configuration Manager notifies the alarm console that an approved change for the device has just been implemented.

◆ At 2:02 a.m. an alarm notifies the NOC that traffic is unreliable on a WAN segment connected to another router (Y) in the network. The NOC views the alarm console, and notices that two minutes before the errors began on router Y, there was an approved change on router X. Closer investigate shows that Router X received a new IP address, but that address was already in use on Router Y.

◆ Assuming there was an error when a new IP address was selected, the NOC enters an emergency change request and rolls back the configuration on Router X, which removes the duplicate IP problem on Router Y, repairing the traffic reliability problem. The total time to restoration is less than ten minutes.

Event FrameworkThe Network Configuration Manager integration engine contains a configurable event framework, allowing for the enablement of over 115 different events. These events are generally passed through a FMS in the form of a SNMP trap. The integration module then translates the trap into the appropriate alarm for the FMS console.

The Network Configuration Manager also offers integration enablers for the event framework that allows notification of events via SMTP email, or by appending to log files.



Installing integration modules activates the event framework, enabling it to send notifications through a variety of mechanisms to the configured FMS, third-party application, or corporate system. The event framework also provides Java Message Service (JMS) event subscription capabilities to other JMS-enabled applications.

Application Programming Interface (API)The Network Configuration Manager event framework only supplies a fixed amount of information to the receiving process, and is often sufficient enough to make an informed decision. When additional information from an event or data from external systems are needed to populate the NCM database, the Network Configuration Manager provides customers with an open read-write API.

The Network Configuration Manager allows for the use of custom created integrations using WebServices or J2EE programming toolkits. The API integration capabilities provide methods for activities, such as:

◆ Approving a job within the Network Configuration Manager from an external trouble ticket system

◆ Populating an external CMDB with new device information on discovery

◆ Creating a new device change from an external customer portal

For additional information on the Network Configuration Manager API, see the EMC Smarts Network Configuration Manager Integration Modules Installation and Configuration Guide and the EMC Smarts Network Configuration Manager Applicaton Program Interface (API) Programmer’s Guide.

PCI DSS Requirement (1.1.1)—Reports

Change Approval Summary

The Change Approval Summary represents the total changes within the report scope (i.e. network, customer, or across entire infrastructure) that were approved or not approved, including out of solution and cut-through changes. This report is useful for demonstrating how many changes enacted/detected by the Network Configuration Manager followed the approved changed process.

Unapproved and Cut-Through Changes

The Unapproved and Cut-Through Changes report represents a detailed view of what unapproved changes occurred, by whom, and includes specific change detail information. This report is useful for identifying the specific changes which did not follow the change approval process.

List of jobs with same Approver or Submitter

This report lists specific details for each job the user has permission to view, where the approved and submitted are the same person. Details include the job status, job name, id number, submitter, approver, and approval state. This report is useful for identifying changes where the separation of duties was not maintained.



Job Summary

The Jobs Summary Report represents the number of jobs where the approvers are the same as the submitter and where the approver is different than the submitter for each network within the scope of the report. This provides the high level evidence for tracking and reporting on operational separation of duties.

Pending Jobs

This report provides a sampling of jobs that are currently staged to be pushed out to the network, so that the auditor can see the type and approval status of each job.

Credential Usage Summary

The Credential Usage Summary report list each device associated with a given credential and its last date of change. This report is useful because demonstrates both the age of the credentials, as well as whether each credential is being managed by an external server.

PCI DSS Requirement (1.1.1)—Reports 45


PCI DSS Requirement (1.1.2)—Best PracticesEstablish firewall and router configuration standards that include the following: Current network diagram with all connections to cardholder data, including any wireless networks.

Building and Validating Network Diagrams

The Network Configuration Manager can provide valuable information related to layer 3 connectivity between network devices, which can be used to build and validate network diagrams.

Using the Diagram View

The Network Configuration Manager network diagram displays layer 3 connectivity between network devices based on connections discovered when performing a configuration pull of the devices. Since the diagram does not display server or workstation information it most likely will not be used as your final diagram, but by arranging and saving the layout of the diagram of a network, site, or view, you will be able to continuously refer back to the diagram to learn whether layer 3 connectivity has changed.

Using the Connection Report

The connection report displays the same information as displayed in the diagram, but additionally shows the IP addresses of each endpoint. When preparing or validating your network diagram, you can print out the connection report and walk through the connections on the report to validate that the diagram is accurate.


Device Connections

The Device Connections Report represents for the selected networks, all connections between devices and interfaces. The report also defines for each connection what technology is in place such as ATM, Frame relay, and Point-to-Point. This report is useful both for creating and validating network diagrams. For performance reasons this report is not included in the auditor's report functionality, but is accessible in the menu under 'Reports'.



This chapter presents this topic:

◆ PCI DSS Requirement (1.1.3)—Best Practices .......................................................... 50



PCI DSS Requirement (1.1.3)—Best PracticesEstablish firewall and router configuration standards that include the following: Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone.

Viewing Firewall Compliance Status

Please refer to Chapter 6, “Best Practices for (1.1.3),”for information on how to use the diagram and connection report to validate a diagram. An accurate diagram, coupled with a process to ensure that it stays accurate, is the best way to ensure that a firewall is in place in the correct locations.

To view the compliance status of these firewalls for this requirement, follow these steps.

For information on how to ensure that the configuration of the firewall is in compliance, see PCI DSS requirement 1.3, it's sub-requirements, and the associated Network Configuration Manager best practices.

Step Task

1 Create a policy in the Network Configuration Manager.

2 Include all firewalls in that policy.

3 Apply keyword PCI-DSS-1.1.3 to the policy.



PCI DSS Requirement (1.1.4)—Best PracticesEstablish firewall configuration standards that include the following: Description of groups, roles, and responsibilities for logical management of network components.

Permissions

The Network Configuration Manager user access to secured resources are constrained by access-lists, which record specific permissions which have been allocated to each principal (user or group) for the specified resource. By carefully designing the permissions scheme in the Network Configuration Manager, users can be limited to only the resources and operations they need to access for their job function.

System PermissionsSystem Permissions are permissions which apply not to specific resources, but to actions users can perform on the system itself. These permissions provide users with the ability to operate on user security, the automation library, events, the OS inventory, networks, and jobs, as well as full system administration permissions.

Network PermissionsNetwork permissions provide permissions to operate on specific networks. Users cannot access a specific network unless the user or his group has been explicitly associated with the network's access-list. Permissions can be assigned either based on a default set of permissions, or overridden on a specific network. Users can be assigned the rights to manage user access to networks, templates and compliance standards, workspace permissions, device permissions, job permissions, and view permissions.

Workspace PermissionsWorkspaces are used to stage and model changes in the Network Configuration Manager. Permissions for a workspace are governed by the containing network's permissions, but additionally the user can be granted permissions to manage the workspace, devices in the workspace (including changes to the underlying device), and jobs associated with the workspace.

Device PermissionsBy default, users are granted permissions to devices based on the permissions assigned to the containing networks or devices. If a specific device should be more tightly controlled, device-level permissions for that device may be assigned to a user or group. This will automatically exclude all other users and groups from accessing that device, even if they have permissions to devices in the containing network.

GroupsGroups can contain both users and other groups, and provide a means of centrally controlling the permissions which should be assigned to users.



Basic Group Setup

Using group descriptionsIn order to demonstrate compliance with PCI 1.1.4, groups should be well thought out and documented. The description field can be used to document these functions, and will appear in the group report so that the auditor can verify permissions.

Setting permissions on groups, not individualsIn order to more efficiently manage permissions, permissions should be assigned to groups instead of individuals. Users will inherit permissions from their groups in an additive fashion. This inheritance works both for groups, as well as groups within groups.


Group Report

The Group Report details the list of users and their contact information for each group the user has permissions to view. This report is useful for ensuring that only the appropriate, approved users are a member of each group.

User Report

The User Report represents by user, what current group associations exists for that user. This report provides the opposite view from the group report, making it easier to ensure that a specific user has only been assigned to the groups which are necessary for his job function.

Approval Permissions

The User System Permission Report lists per user, what the current enabled or disabled permissions are for each group and user. This report can be used in association with the group or user reports to ensure that users only have the permissions necessary for their job function.



PCI DSS Requirement (1.1.5)—Best PracticesEstablish firewall configuration standards that include the following: Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.

Documenting Port and Service Requirements

Firewall rule sets and router access-lists (ACLs) are used to filter non-critical data in a network. Rule sets and ACLs are built by default to deny all traffic, except those that are explicitly required to conduct business across the network.

It is difficult to know by looking at a rule set or ACL why specific services and ports are open, and many times there is no way to determine why an ACL or firewall rule set is permitting certain traffic on the network.

Comments can be added to a configuration file, but are easily deleted as the configuration changes, because only small amounts of documentation can be stored on a firewall or router.

PCI requires network managers to have a mechanism that can reliably document the port and service needs of the network, as well as an easy way to report on these requirements.

The Network Configuration Manager offers several ways in which the PCI required ports and services can be documented and reported on a Network, Policy, or Device level.

Network and Device PropertiesThe Network Configuration Manager supports the creation of network and device objects. Network objects (or containers) provide security segmentation of device data across the application environment.

Device objects are the objects in which specific device details are stored, including configuration, hardware, and interface information.

As documentation requirements dictate, each of these objects support the addition of attachments and comments in the database.

Comments are text content that can be pulled from device configurations, job results, and other sources, and then stored with either the device or network object.

Attachments are http links to specific documents on a documentation server, and provide a way for network users to access and update documentation for the network.

The comment and attachment areas of device and network properties provide a reportable mechanism for storing, reviewing, and maintaining documentation on port and service requirements for firewall rule sets and router ACLs.

Device properties allow for the localization of device specific requirements, while the Network properties area provides a common location where requirements are consistent across a defined network domain.



Template and Test Properties

The Network Configuration Manager Automation Library offers a way to document and report on port and service requirements in the network through the use of template and test properties.

Templates are used for defining best practice configuration standards to be deployed in the network. Tests provide the compliance equivalent of a template to enforce best practice standards within the security policy. Templates and tests provide property area where port and service requirements for the rule sets or ACL’s are defined.


Compliance Policy Definition Report

The Compliance Policy Definition Report details the pertinent information required for each Policy in use in the system. This information includes the following.

◆ Date created

◆ Creator of the Policy

◆ Auto-Schedule Status

◆ Keywords

◆ Policy Associations

◆ Device Class Associations

This information accompanied by the compliance result reports, can be used to understand how a particular device is in or out of compliance.



PCI DSS Requirement (1.1.6)—Best PracticesEstablish firewall configuration standards that include the following: Requirement to review firewall and router rule sets at least every six months.

Using Review Comments for Quarterly Reviews

The review comments feature on the PCI DSS Review Screen provides a convenient mechanism for recording six-month reviews of firewall rule sets. When you hold a six-month review, record a review comment which states whether the policies were modified or simply approved, and then during an audit your auditor will be able to see evidence of the reviews.


CHAPTER 10Best Practices for (1.2)


◆PCI DSS Requirement (1.2)—Best Practices................................................................. 62

Best Practices for (1.2) 61

Best Practices for (1.2)

PCI DSS Requirement (1.2)—Best PracticesBuild a firewall configuration that restricts connections between untrusted networks and any system components in the cardholder data environment.

To facilitate management of and reporting on a specific set of firewalls and routers, the devices should be placed into a view in the Network Configuration Manager. Views are logical containers which can be created by statically choosing a list of devices, or by filtering on a specific attribute. By placing the firewalls and choke, DMZ, and perimeter routers into a specific view, configuration, change, and compliance reports can be focused on those devices.

For a more detailed explanation of how to create configuration policies and associate them with specific PCI requirements, see Chapter 10, “Best Practices for (1.2),”



PCI DSS Requirement (1.2.1)—Best PracticesRestrict inbound and outbound traffic to that which is necessary for the cardholder data environment.

The following provided samples can be found in the Network Configuration Manager automation library, under Samples>Compliance>Regulatory>PCI>1.2.

◆ PCI-DSS-1.2.2—Test That Denies Traffic On ALL Ports Other Than Port 23

◆ PCI-DSS-1.2.2—Test That Allows Traffic On No Other Open Port Than Port 23

◆ PCI-DSS-1.2-1.3—Cisco IOS - Named Ingress Access List - By ACL Name

◆ PCI-DSS-1.2-1.3—Cisco IOS - Numbered Ingress Access List - By ACL Number

For a more detailed explanation of how to create configuration policies and associate them with specific PCI requirements, see the Chapter 14, “Best Practices for (1.3),”


Compliance Summary

The Compliance Summary summarizes the number of devices which are compliant or not compliant with each of the tests, standards, or policies associated with this specific PCI requirement.

Non-Compliant Devices

The Non-Compliant Devices report shows a breakdown of the devices which are non-compliant with this specific PCI requirement. This report is useful both as a "punch-list" for diagnosing and remediating compliance violations, as well as a list of specific policy violations for an auditor.



PCI DSS Requirement (1.2.2)—Best PracticesSecure and synchronize router configuration files.

When the Network Configuration Manager retrieves the running configuration of network devices, it also retrieves the startup configuration and compares it with the running. If the startup and running configurations differ, the devices are flagged with a Run/Start Out of Sync condition. The devices which are in this state can be viewed in the 'Device State Report'.

In order to remediate this condition, a configlet push can be done and the push type can be set to 'Push to Run, Copy to Start'. The configlet can be a single comment line, as the important part is that the running configuration is copied to the startup configuration.


◆ PCI-DSS-1.2.2 - Stateful Inspection of Firewall



Device State Report

The Device State Report represents the total devices that are out of sync (run vs. start), have no stored configuration, and/or are unreachable, along with the list of devices and their respective state. Each of these states represents a problem which could lead to a vulnerability, and should be resolved immediately.



PCI DSS Requirement (1.2.3)—Best PracticesInstall perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.


◆ PCI-DSS-1.2-1.3 - Cisco IOS - Named Ingress Access List - By ACL Name

◆ PCI-DSS-1.2-1.3 - Cisco IOS - Numbered Ingress Access List - By ACL Number



Compliance Summary







◆ PCI DSS Requirement (1.3)—Best Practices ............................................................. 70◆ PCI DSS Requirement (1.3)—Reports ....................................................................... 71



PCI DSS Requirement (1.3)—Best PracticesProhibit direct public access between the Internet and any system component in the cardholder data environment.

Using Network Configuration Manager Policies to Detect and Remediate Policy Violations

Whether a device is newly deployed in the network, or an existing device already in production, it needs to be under the control of security policy management. If not, it might easily contain one or more vulnerabilities, which could render it and the network, susceptible to attack.

Policy management allows network engineers to enforce best practice security standards within the network. The Network Configuration Manager not only provides near real time notifications of security policy violations, but it can also provide automated remediation for the violation.

Network Configuration Manager PoliciesPolicies within the Network Configuration Manager are rules that are applied to enforcement areas, such as network containers, in an automated way so as to enable the application to capture and remediate security violations in near real time.

A policy is invoked when a new revision (a configuration change event, for example) is detected on a network device. The rules of the policy, which are created from best practice standards, are compared against the new revision.

Any violations of the rules may trigger a remediation job in the scheduling system. Approvers are notified of the pending remediation job, and the violation can be repaired in mere minutes from the original change event.

Structuring Policies, Standards, and Tests for PCIThe PCI DSS requirements include both high level requirements (such as the requirement to have configuration standards for your firewalls), and low level requirements (such as the requirement to use NTP to synchronize time across devices). The Network Configuration Manager provides three levels of compliance, which are assembled together to form configuration policies.

◆ Tests - Tests are the lowest level of compliance, and allow the user to specify one or more discrete rules for how a device should be configured. Tests are vendor-specific, as they perform regular expression-based logic on the actual text of the configuration in order to make a pass/fail decision.

◆ Standards - Standards can be described as the aggregation of tests into a set of related rules which can be enforced on one or more classes of device. Standards can include filters, which when run against a device will decide whether or not to run the tests. Devices which fail the filter will not be included in the compliance results.

◆ Policies - Policies are the association between an aggregation of standards, and a specific set of devices or containers which should conform to the standards. Policies are automatically enforced on device configurations as configuration changes are detected, providing the near real-time compliance necessary to maintain PCI compliance.



PCI Advisor allows the user to associate specific policies, standards, or tests with specific PCI requirements. This allows the user to access summary compliance data for a specific PCI requirement, as well as a detailed list of compliance failures to begin remediation. In the example above, the configuration standard (standard here being the PCI DSS term) for firewalls would most likely be implemented as a Network Configuration Manager policy, while the NTP requirement would be implemented as a test. Both items can be associated with their respective PCI requirements, providing the detailed information where it's needed.

In order to associate a policy, standard, or test with a specific PCI requirement, the user should use the automation library to edit the compliance item and add a keyword. For example, to associate the test NTP Server Test with PCI requirement 10.4, the keyword v1.2::PCI-DSS-10.4 would be associated with the test. The specific keywords to use can be found on the PCI specification screen by clicking on the individual requirement and looking in the 'Compliance' section.

PCI DSS Requirement (1.3)—Reports

Compliance Score Card

The Compliance Score Card represents the total devices within the report scope (i.e. network, customer, or across entire infrastructure) that are compliant or non-compliant with the standards or policies in effect. This is useful for demonstrating the overall compliance of the devices within the report's scope.

Policy Summary Report

The Policy Summary Report represents which standards/policies are currently enforced and have compliant or non-compliant devices. This report is useful for viewing at a high level the compliance status of each policy across the report scope.

PCI DSS Requirement (1.3)—Reports 71


PCI DSS Requirement (1.3.1)—Best PracticesImplement a DMZ to limit inbound and outbound traffic to only protocols that are necessary for the cardholder data environment.


◆ PCI-DSS-1.3.1 - Restrict Unauthorized Traffic



◆ PCI-DSS-1.3.1 - Check For Approved Static Routes Only



Compliance Summary






PCI DSS Requirement (1.3.2)—Best PracticesLimit inbound Internet traffic to IP addresses within the DMZ.






Compliance Summary






PCI DSS Requirement (1.3.3)—Best PracticesDo not allow any direct routes inbound or outbound for traffic between the Internet and the cardholder data environment.


Compliance Summary






PCI DSS Requirement (1.3.4)—Best PracticesDo not allow internal addresses to pass from the Internet into the DMZ.

An auditable record that this requirement has been met can be obtained by adding a diagnostic command to the DMZ routers. This diagnostic command will be a ping command which pings from the inside interface of the DMZ router to the internal database IP address. The ping results should show that the IP address is unreachable.

In the Network Configuration Manager, diagnostic commands are created at the device class level either globally or per network. In order to facilitate adding this diagnostic command to only the DMZ router, the DMZ router can be placed in its own network. Then, once the diagnostic command has been associated to the router, every time the configuration is pulled the results of the diagnostic command will be revisioned along with it. The results of this diagnostic command can then be provided as auditable proof that the IP is unreachable.


Compliance Summary






PCI DSS Requirement (1.3.5)—Best PracticesRestrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ.


◆ PCI-DSS-1.2-1.3 - Cisco IOS - Named Egress Access List - By ACL Name

◆ PCI-DSS-1.2-1.3 - Cisco IOS - Numbered Egress Access List - By ACL Number



Compliance Summary






PCI DSS Requirement (1.3.8)—Best PracticesImplement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies—for example, port address translation (PAT).


◆ PCI-DSS-1.3.8 - Inside NAT Setup

◆ PCI-DSS-1.3.8 - Outside NAT Setup



Compliance Summary







◆ PCI DSS Requirement (2.1)—Best Practices ............................................................. 88◆ PCI DSS Requirement (2.1)—Reports ....................................................................... 88



PCI DSS Requirement (2.1)—Best PracticesAlways change vendor-supplied defaults before installing a system on the network—for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.


◆ PCI-DSS-2.1 - Detecting Default Password

Note: The Network Configuration Manager does not decrypt passwords in the configuration, so encrypted default passwords will not be detected.



Compliance Summary






PCI DSS Requirement (2.1.1)—Best PracticesFor wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Ensure wireless device security settings are enabled for strong encryption technology for authentication and transmission.


◆ PCI-DSS-2.1 - Detecting Default Password

Note: The Network Configuration Manager does not decrypt passwords in the configuration, so encrypted default passwords will not be detected.



Compliance Summary







◆ PCI DSS Requirement (2.2)—Best Practices ............................................................. 92



PCI DSS Requirement (2.2)—Best PracticesDevelop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Provided Samples (found in the Network Configuration Manager automation library under Samples>Compliance>Regulatory>PCI>1.2.

◆ Please view the templates provided in the Network Configuration Manager automation library under Samples>Compliance>Regulatory>PCI>1.2.



PCI DSS Requirement (2.2.2)—Best PracticesDisable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the device’s specified function).


◆ PCI-DSS-2.2.2 - Disable Per Interface Services



Compliance Summary






PCI DSS Requirement (2.2.3)—Best PracticesConfigure system security parameters to prevent misuse.

No specific samples have been provided for this requirement, however the general principles applied in other requirements for chapters 1 and 2 can be applied to this requirement to create configuration policies for specific security attributes.




PCI DSS Requirement (2.2.4)—Best PracticesRemove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

No specific samples have been provided for this requirement, however the general principles applied in other requirements for chapters 1 and 2 can be applied to this requirement to create configuration policies for specific security attributes.





◆ PCI DSS Requirement (2.3)—Best Practices ........................................................... 100◆ PCI DSS Requirement (2.3)—Reports ..................................................................... 101



PCI DSS Requirement (2.3)—Best PracticesEncrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

Network Configuration Manager to Devices

The Network Configuration Manager allows a wide variety of communications protocols including SSH, SCP, Telnet, SNMP V1, SNMP V2c, SNMP V3, modems, and terminal servers. It is recommended that whenever a device supports the secure protocols SSH, SCP, and SNMP V3, they should be used.

Using Secure Shell protocol (SSH) for network device communication provides encrypted communications between the device server and devices for issuing configuration updates, and polling configuration changes.

Many devices are also capable of using SNMP V3 for network management. The Network Configuration Manager provides SNMP V3 manageability using authorization and privacy protocols. SNMP V3 in conjunction with SSH, provides the highest level of security available to manage network devices.

Selecting Secure Protocols

The Network Configuration Manager can be prevented from using any other protocols by setting the protocol preferences, per device class, within the System Administration window. From the System Administration window in the Network Configuration Manager, users can globally, or from a network, specify the protocols.

The Device Class Configuration section of System Administration allows the Network Configuration Manager administrator to select and apply protocol preferences to each device class. To select and apply protocol preferences to each device class, follow these steps:

Insecure Protocols

Some devices and vendors do not provide secure protocols, requiring the use of insecure communications to the device, such as Telnet or SNMP V1. Precautions should be made to avoid using the same community strings and accounts on these insecure devices as are used on the ones using secure protocols, such as SNMP V3 and SSH.

Step Task

1 Select the Device Classes Note from the System Administration tree.

2 Click the Manage List button to remove or add entire device classes.

3 Choose a specific device class, and click the Specify Protocol button to disable or order the preference for protocol selection.

4 The Enabled and Disabled Protocol windows show the protocol selection for each device class. Using this window. Modify each of the device classes to only use SSH or SSH/SCP, as they are available

5 If there are devices that do not support SNMP V3, uncheck the Use SNMP to Increase Manageability checkbox in the Specify Protocol window.



Protocols between Network Configuration Manager Servers

The Network Configuration Manager uses secure SSL protocols to encrypt and transmit information to remote systems and between servers. Cut-through connections are made using an encrypted channel using the blowfish cipher and a 1024-bit encryption key. Encryption keys and SSL certificates are created during installation, and signed using a Network Configuration Manager Certificate of Authority Key. All SSL and encryption keys are validated as being signed against this root certificate.


Compliance Summary




PCI DSS Requirement (2.3)—Reports 101


PCI DSS Requirement (4.1)—Best PracticesUse strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.

Examples of open, public networks that are in scope of the PCI DSS are:

◆ The Internet,

◆ Wireless technologies,

◆ Global System for Mobile communications (GSM), and

◆ General Packet Radio Service (GPRS).


◆ PCI-DSS-4.1 - VPN Encryption



Compliance Summary






PCI DSS Requirement (6.1)—Best PracticesEnsure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.

Note: Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months..

The Network Configuration Manager can be used to prepare for OS upgrades by providing OS Inventory reports, and by providing hardware reports for verifying memory prerequisites. The Network Configuration Manager OS Manager can be used to deploy new OS versions to many types of network devices, including some wireless access points. For more information, see the EMC Network Configuration Manager – Online User's Guide.


OS Version Inventory

The OS Version Inventory report provides the use visibility into the total number of devices by operating system. This report can be consulted to ensure that network devices have the appropriate OS versions applied.




◆ PCI DSS Requirement (6.4.1)—Best Practices ........................................................ 108



PCI DSS Requirement (6.4.1)—Best PracticesFollow change control procedures for all changes to system components. The procedures must include the following: Documentation of impact.

The Network Configuration Manager job description field should be used to reference change tickets and/or include full change descriptions.




◆ PCI DSS Requirement (6.4.2)—Best Practices ........................................................ 110



PCI DSS Requirement (6.4.2)—Best PracticesFollow change control procedures for all changes to system components. The procedures must include the following: Management sign-off by appropriate parties.

See Chapter 4, “Best Practices for (1.1.1),”for change approval summary reports.



PCI DSS Requirement (8.3)—Best PracticesIncorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS); terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.


◆ PCI-DSS-1.1.1 - TACACS Server

◆ PCI-DSS-1.1.1 - RADIUS Server



Compliance Summary







◆ PCI DSS Requirement (8.5.13)—Best Practices ...................................................... 114



PCI DSS Requirement (8.5.13)—Best PracticesEnsure proper user authentication and password management for non-consumer users and administrators on all system components as follows: Limit repeated access attempts by locking out the user ID after not more than six attempts.

The Network Configuration Manager contains four different types of authentication, each of which allows the administrator to control the number of logins which a user can attempt before the account is locked.

Native Registry

With this authentication mechanism, user accounts are authenticated against an internal database in the Network Configuration Manager. Administrators can set an explicit limit to the number of authentication attempts a user can have before the account is locked. The administrator should set this to less than six.

TACACS+

With this authentication mechanism, user accounts are authenticated against an external TACACS+ server. Administrators can control the number of attempts before lockout both in the Network Configuration Manager and on the TACACS+ server. The administrator should set this to less than six.

RADIUS>

With this authentication mechanism, user accounts are authenticated against an external RADIUS server. Administrators can control the number of attempts before lockout both in the Network Configuration Manager and on the RADIUS server. The administrator should set this to less than six.

LDAP

With this authentication mechanism, user accounts are authenticated against an external LDAP server. Administrators can control the number of attempts before lockout both in the Network Configuration Manager and on the LDAP server. The administrator should set this to less than six.



PCI DSS Requirement (8.5.14)—Best PracticesEnsure proper user authentication and password management for non-consumer users and administrators on all system components as follows: Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

When a user session is locked out in the Network Configuration Manager, the user account will not be unlocked until explicit action is taken by the administrator to unlock the user ID.



This chapter present this topic:




PCI DSS Requirement (8.5.15)—Best PracticesEnsure proper user authentication and password management for non-consumer users and administrators on all system components as follows: If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal.

The default user session timeout in the Network Configuration Manager is thirty minutes, after which the user's session will automatically timeout and require a login to continue. This can be controlled through the JMX console, which can be accessed by your system administrator.

Inside the JMX console, the administrator needs to follow these instructions:

Step Task

1 Locate the section labeled: vc, near the bottom of the console.

2 Click service=VoyenceControlConfig.

3 Scroll down to find the operation labeled java.lang.String setConfigItem().

4 Enter the following values (p3 is the number of seconds for the timeout, so 900 for 15 minutes):• p1: config.server• p2: com.powerup.configmgr.server.security.login.authentication_cache_timeout• p3: 900

5 Click the Invoke button.

6 Click the Back button.

7 Click on the item labeled: java.lang.String saveAll() to save over server reboots.




◆ PCI DSS Requirement (10.1)—Best Practices ......................................................... 120



PCI DSS Requirement (10.1)—Best PracticesEstablish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

The Network Configuration Manager maintains an audit log of all device accesses made, as well as any device change events detected on the device via notification from the device (Syslogs or Traps), or timed configuration pull.



PCI DSS Requirement (10.2.2)—Best PracticesImplement automated audit trails for all system components to reconstruct the following events: All actions taken by any individual with root or administrative privileges.

The Network Configuration Manager logs all accesses to protected resources through the user interface or API, regardless of whether the user is a system administrator or not.



PCI DSS Requirement (10.2.3)—Best PracticesImplement automated audit trails for all system components to reconstruct the following events: Access to all audit trails.

Access to the Network Configuration Manager Event Manager is logged in the voyence-audit.log file. This file can be found in $VOYENCE_HOME/cm/vc-server/log/voyence-audit.log. The entry will appear as follows.

2008-01-24 18:44:24,615 INFO [VOYENCE-AUDIT]

User=mclark, Resource=null, Action=getEvents, Result=Access Allowed, Comments=User:mclark authorized to perform action - getEvents



PCI DSS Requirement (10.2.4)—Best PracticesImplement automated audit trails for all system components to reconstruct the following events: Invalid logical access attempts.

The Network Configuration Manager exposes all of the following events for access to device related data.

◆ AuthorizationFailedEvent

◆ AuthorizationSucceededEvent



PCI DSS Requirement (10.2.5)—Best PracticesImplement automated audit trails for all system components to reconstruct the following events: Use of identification and authentication mechanisms.

The Network Configuration Manager exposes all of the following events for access to device related data.

◆ UserLockedOutEvent

◆ UserLoginEvent

◆ UserLoginExpiredEvent

◆ UserLoginFailedEvent

◆ UserLogoutEvent



PCI DSS Requirement (10.2.7)—Best PracticesImplement automated audit trails for all system components to reconstruct the following events: Creation and deletion of system-level objects.

The Network Configuration Manager exposes all of the following events for access to device-related data:

Security System-level Objects

◆ GroupCreateEvent

◆ GroupDeleteEvent

◆ GroupImportedEvent

◆ GroupModifyEvent

◆ UserCreateEvent

◆ UserDeleteEvent

◆ UserImportedEvent

◆ UserModifyEvent

Device and Credentials System-level Objects

◆ DeviceCreateEvent

◆ DeviceDeleteEvent

◆ CredentialsCreateEvent

◆ CredentialsDeleteEvent

◆ CredentialsModifyEvent

Device Containment System-level Object

◆ NetworkAutoDiscCreateEvent

◆ NetworkAutoDiscDeleteEvent

◆ NetworkAutoDiscModifyEvent

◆ NetworkCreateEvent

◆ NetworkDeleteEvent

◆ NetworkModifyEvent

◆ SiteCreateEvent

◆ SiteDeleteEvent

◆ SiteModifyEvent

◆ ViewCreateEvent

◆ ViewDeleteEvent

◆ ViewModifyEvent



◆ WorkspaceCreateEvent

◆ WorkspaceDeleteEvent

◆ WorkspaceModifyEvent

Automation Library (Compliance and Standardization) System-level Objects

◆ AutomationLibraryImportEvent

◆ PolicyCreateEvent

◆ PolicyDeleteEvent

◆ PolicyModifyEvent

◆ SavedCommandCreateEvent

◆ SavedCommandDeleteEvent

◆ SavedCommandModifyEvent

◆ StandardCreateEvent

◆ StandardDeleteEvent

◆ StandardModifyEvent

◆ TemplateCreateEvent

◆ TemplateDeleteEvent

◆ TemplateModifyEvent

◆ TestCreateEvent

◆ TestDeleteEvent

◆ TestModifyEvent

◆ DataFileCreateEvent

◆ DataFileDeleteEvent

◆ DataFileModifyEvent



PCI DSS Requirement (10.3.1)—Best PracticesRecord at least the following audit trail entries for all system components for each event: User identification.

The Network Configuration Manager records the user identification in association with every audit event. In addition, every recorded change in the Network Configuration Manager has both the user who made the change and the user who approved the change in its revision history, as detected either from the scheduled job, the change notification, or the device itself.



PCI DSS Requirement (10.3.2)—Best PracticesRecord at least the following audit trail entries for all system components for each event: Type of event.

The Network Configuration Manager records the user identification in association with every audit event. The events are named according to their content, as can be seen in Chapter 36, “Best Practices for (10.1),”



PCI DSS Requirement (10.3.3)—Best PracticesRecord at least the following audit trail entries for all system components for each event: Date and time.

The Network Configuration Manager records the event date and time stamp in association with every audit event.



PCI DSS Requirement (10.3.4)—Best PracticesRecord at least the following audit trail entries for all system components for each event: Success or failure indication.

The Network Configuration Manager records success and failure status for the following event types.

◆ DeviceRevChangeFailedEvent

◆ DeviceRevCreateFailedEvent

◆ DeviceRevPolicyCheckFailedEvent

◆ DeviceRevPolicyCheckSuccessEvent

◆ CommunicationRestoredEvent

◆ FailedCommunicationEvent

◆ JobFailedEvent

◆ JobPartiallyFailedEvent

◆ JobWarningEvent

◆ JobCompletedEvent

◆ TaskFailedEvent

◆ TaskCompletedEvent

◆ AuthorizationSuceededEvent

◆ AuthorizationFailedEvent

◆ UserLoginFailedEvent



PCI DSS Requirement (10.3.5)—Best PracticesRecord at least the following audit trail entries for all system components for each event: Origination of event.

The Network Configuration Manager categorizes each event by action type, event type, severity type, and source type. The action type is the actual type of event, such as JobFailedEvent. The available values for event type, severity type, and source type are:

◆ Event Type

• All

• Device

• Security

• System

◆ Severity Type

• Fatal

• Error

• Warning

• Info

◆ Source Type

• Application Server

• Device Server



PCI DSS Requirement (10.3.6)—Best PracticesRecord at least the following audit trail entries for all system components for each event: Identity or name of affected data, system component, or resource.

The Network Configuration Manager records the name of the affected resource along with each event.




◆ PCI DSS Requirement (10.4)—Best Practices ......................................................... 146◆ PCI DSS Requirement (10.4)—Reports ................................................................... 146



PCI DSS Requirement (10.4)—Best PracticesSynchronize all critical system clocks and times.


◆ PCI-DSS-10.4 - Test For Network Time Protocol



Compliance Summary






PCI DSS Requirement (10.5)—Best Practices Secure audit trails so they cannot be altered.

The Network Configuration Manager contains a system-level permission named View Audit,

which controls whether a user may see event logs. In addition, users are constrained to only see

events for resources to which they have view permissions



PCI DSS Requirement (10.5.1)—Best PracticesLimit viewing of audit trails to those with a job-related need.

The Network Configuration Manager contains a system-level permission named View Audit, which controls whether a user may see event logs. In addition, users are constrained to only see events for resources to which they have view permissions.



PCI DSS Requirement (10.5.2)—Best PracticesProtect audit trail files from unauthorized modifications.

The Network Configuration Manager users may not modify or delete event records within the Network Configuration Manager application.



PCI DSS Requirement (10.6)—Best PracticesReview logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).

Note: Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6.

The Network Configuration Manager Event Manager contains dynamic filters, which may be used to parse through the events. Administrators should filter for Security Events to monitor for authentication and logical access failures.



PCI DSS Requirement (12.1)—Best PracticesEstablish, publish, maintain, and disseminate a security policy that accomplishes the following.

The PCI Advisor Process Document Generator can be used to publish the process documentation written by the user. This process documentation is useful not only for dissemination across the group in hard-copy form, but also for daily review by engineers responsible for certain aspects of PCI.



PCI DSS Requirement (12.1.1)—Best PracticesEstablish, publish, maintain, and disseminate a security policy that accomplishes the following: Addresses all PCI DSS requirements.

The purpose of PCI Advisor is to provide users and auditors with a focused view of the requirements, best practices, samples, and reports to help engineers address each requirement. By using the PCI Advisor functionality, engineers can stay well informed as to the requirements of PCI and the compliance status of the network.


GLOSSARY

This glossary details the terms and acronyms related to Compliance Advisor that you may encounter while using this document.

A

Auto Discovery The process by which devices are entered into the application for management is known as Auto Discovery. Auto Discovery associates network devices with a Network Configuration Manager device server and your networks. A type of discovery where a program automatically detects the resources that were not previously known.

Automation Library Where the user creates and saves standardized templates, commands, or engineering data files used to enforce policy standards within a network.

C

Compliance Audit You can determine which of the configurations are Compliant or Non-Compliant using this audit.

Configlet A snippet of device configuration code equaling one or more configuration commands, but less than a complete config file. Configlets can be scheduled for push to one or more devices in the network.

Configuration ChangeManagement System

(CCMS)

A data store of profiles that contain configuration data that is used by system management applications to make configuration changes on networks.

ConfigurationManagement Database

(CMDB)

A database that contains details about the attributes and history of each configuration item and the details about the relationships between configuration items.

Configuration Pull When you select this Pull Config option, what you are pulling is the running volatile configuration, and then storing that configuration onto the database.

CS Combination Server

Cut-through A terminal session initiated through the Network Configuration Manager that utilizes assigned system credentials and maintains a log of keystrokes. Cut-through sessions can be initiated using telnet, SSH or via a modem. The user must have the View Passwords and Modify Device permissions to enter in Privilege mode, and Edit Device and View Password permissions to enter in User mode.

D

Device class The generic name for a group of device types. Each device class has a unique name and represents a device type.

Device name The symbolic name of an individual device.


Glossary

Device Properties A tabbed display of device-specific information, including History, Hardware, Communications, Interfaces, General device information, Configuration files, and more. Accessed from the Devices View.

E

Event Manager The Event Manager feature allows you to view activities that have transpired on the network. For example, you can access the log and view the Event, the Owner (or user), the Network that was accessed, the Date/Time the event was logged, and more!

N

Network Within the Network Configuration Manager a network is defined as a logical partitioning of the devices that are in a physical network. Networks can be created to best model your business environment. For example, networks can be created and defined by customer, region, subsidiary, or responsibility. For example, they can be defined at corporate vs. division. Within networks, devices can be further organized logically and physically. In addition, you can design and stage modifications to the devices in user-defined workspaces.

Network Administrator Any user that has Network Management permissions in the Network Configuration Manager. Network Admin's can create, manage, and delete networks and network properties within the application. A person who defines the network configuration and other network-related information. This person controls how an enterprise or system uses its network resources.

O

Out-of-Band Servers The Network Configuration Manager provides an option for setting up alternative communication methods using out-of-band servers. For example, if there is a problem with a device and traffic cannot flow through the network, an alternate path can be set using a terminal server to reach the network nodes, even when the network is down.

P

Policy A policy is a set of user-define guidelines for any device configuration change. These guidelines can only be defined by a Network or System Administrator.

Q

Quick Commands The Quick Commands option allows you to access quick commands, including Ping, Trace route, assorted Views, and more. Quick Commands can be used with Devices, Sites, and Workspaces.

S

Scheduler The Scheduler allows you to designate when jobs are pushed to the network.

Schedule Manager Where the user reviews, approves, rejects, cancels, holds, and checks job status and history.


Glossary

Sites Sites allow users to segment devices into a physical hierarchical structure that is user-defined and managed. Sites are viewed and updated in the Site View of a network by authorized users only.

Standards A Standard allows you to set up filters and tests that are run against specific device classes.

T

Templates During installation, you can access folders with examples of Templates and Tests containing pre-loaded data. These can be used as examples to create your own Templates and Tests to use in your network.

Tests Tests allow you to set preconditions and check patterns that validate the config file. Tests are then linked to Standards. Tests must be linked to a Standard to run. When the criteria for a Standard is met by a config, the Test validates against the content of the config.

V

Views User-defined, logical segmentations of devices in a network. The devices contained in a view may be specified through an explicit device list, and/or by specifying a filter on device attributes. Views are non-hierarchical, and may be managed using folders.


Glossary


INDEX

AApproval Permissions 53Automation Library (Compliance and Standardization)

System-level Objects 131

BBasic Group Setup 53Building and Validating Network Diagrams 48

CCompatibility 18Compliance Policy Definition Report 57Compliance Score Card 71Compliance Summary 64, 68, 74, 76, 78, 80, 82, 84, 88, 90,

94, 101, 104, 112, 146

DDevice and Credentials System-level Objects 130Device Connections 48Device Containment System-level Object 130Device Permissions 52Device State Report 66Documenting Port and Service Requirements 56

EEvent Type 142

GGroup Report 53Groups 52

HHardware Requirements 18

IInsecure Protocols 100

LLDAP 114Linux 9, 37

NNative Registry 114Network and Device Properties 56Network Configuration Manager Policies 70Network Configuration Manager to Devices 100Network Configuration Managere 14Network Permissions 52

Non-Compliant Devices 64, 68, 74, 76, 78, 80, 82, 84, 88, 90, 94, 101, 104, 112, 146

OOS Version Inventory 106

PPCI Advisor 14Permissions 52Policies 70Policy Summary Report 71Protocols between Network Configuration Manager Servers

101

RRADIUS> 114

SSecurity System-level Objects 130Selecting Secure Protocols 100Setting permissions on groups, not individuals 53Severity Type 142Software Requirements 18Source Type 142Standards 70Structuring Policies, Standards, and Tests for PCI 70System Permissions 52

TTACACS+ 114tasks 14Template and Test Properties 57Tests 70

UUser Report 53Using group descriptions 53Using Network Configuration Manager Policies to Detect and

Remediate Policy Violations 70Using Review Comments for Quarterly Reviews 60Using the Connection Report 48Using the Diagram View 48

VViewing Firewall Compliance Status 50

WWorkspace Permissions 52


Index


EMC Smarts Network Configuration Manager Compliance Advisor · EMC® Smarts® Network Configuration...

Documents

Transcript of EMC Smarts Network Configuration Manager Compliance Advisor · EMC® Smarts® Network Configuration...