pci dss: practical ways of achieving...

© 2012 Deloitte LLP. Private and confidential.

PCI DSSPractical ways of achieving compliance

Dariusz SadowskiINFOSEK Conference 2012


Requirement 1Install and maintain a firewall configuration to protect cardholder data

2 PCI DSS: Practical ways of achieving compliance

Detailed requirement (selection) Practical solutions1.1 Establish firewall and router configuration standards that include the following:-Formal change management process-Current network diagram with a) cardholder data b) wireless-Firewall at every Internet/DMZ/Internal network intersection-Network management roles & responsibilities-Business justification for firewall rules + insecure protocols-Semi-annual rule review

- Design and formalise change management process for network elements

- Create network diagram and ensure links to CDE and wireless are present + embed mandatory update stage in the change management process

- Redesign network or install missing firewalls- Embed business justification stage in change

management process- Retrospectively review all rules

1.2 Build firewall and router configurations that restrict connections:-Default deny-all-Synchronize network device configuration-Perimeter firewalls for wireless

- Review current configuration- Implement tools for automatic configuration

synchronization- Redesign network or install missing firewalls

1.3 Prohibit direct public access-Implement DMZ, packet filtering and SPI-Store cardholder data in internal network only

- Review current configuration, start using proper filtering + NAT

- Move all storage facilities to internal network (may require a lot of effort)

1.4 Install personal firewall software on any mobile and/or employee-owned computers.

- Use embedded Microsoft solution (cheapest)


Requirement 1Install and maintain a firewall configuration to protect cardholder data



Requirement 2Do not use vendor-supplied defaults for system passwords and other security parameters


Detailed requirement (selection) Practical solutions2.1 Always change vendor-supplied defaults before installing a system on the network-Passwords, SNMP community strings, encryption keys, parameters-Strong emphasis on wireless

- Configuration review- Get rid of WEP - the use of WEP as a security

control was prohibited by PCI DSS as of 30 June 2010

2.2 Develop configuration standards for all system components.-One primary function per server-Use only secure protocols; when not possible insecure protocols have to be secured-Configure security parameters-Remove unnecessary software

- Design formal configuration standards that are tailored to your IT environment

- No need to reinvent the wheel, use industry best practices by:

- Center for Internet Security (CIS)- International Organization for

Standardization (ISO)- SysAdmin Audit Network Security (SANS)- National Institute of Standards Technology

(NIST)- Decouple servers with more than one primary

function (may be challenging)- NetBIOS, file-sharing, Telnet, FTP are

examples of insecure protocols – those need to be secured

2.3 Encrypt all non-console administrative access using strong cryptography.

- Relates to the usage of insecure protocols


Requirement 2Do not use vendor-supplied defaults for system passwords and other security parameters



Requirement 3Protect stored cardholder data


Detailed requirement (selection) Practical solutions3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal p+p-Has to take into account a) legal and b) business requirements-On a quarterly basis delete all excessive data

- Gather requirements for data retention- Legal requirements always precede business

needs- Eliminate all gaps, business needs to confirm- Automatic deletion is more reliable but not

always possible- Consider all storage media (including backups)

3.2 Do not store sensitive authentication data after authorization

- Issuers are exempt but have to ensure protection nonetheless

- Ensure deletion when transmitting or processing

3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)

- Does not apply when there is a legitimate business need to see the PAN

- Modify IT systems to force masking- Manually mask on hard copies- Masking != truncation

3.4 Render PAN unreadable anywhere it is stored. Only 4 methods are allowed:-one-way hashes-Truncation-Tokens/pads-Strong cryptography

- Method selection depends on individual case- Each has its own pros and cons- Watch for “strong” when implementing

cryptography (AES 128 bit min)- One-off exercise v. continuous process


Requirement 3Protect stored cardholder data



Requirement 4Encrypt transmission of cardholder data across open, public networks


Detailed requirement (selection) Practical solutions4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

- Open network include: Internet, wireless, GSM and GPRS

- Limit usage of open networks- Security protocols include: SSL/TLS, IPSEC,

SSH

4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment us strong encryption for authentication and transmission.

- Wireless networks in scope do not need to be transmitting cardholder data – simply being connected to CDE counts too

- WEP is prohibited (since 30 June 2010)

4.2 Never send unprotected PANs by end-user messaging technologies

- Messaging technologies include e-mail, instant messaging, chat

- Unprotected means full PAN in plain text, requirement 3.4 should be used as a guidance


Requirement 5Use and regularly update anti-virus software or programs


Detailed requirement (selection) Practical solutions5.1 Deploy anti-virus software on all systems commonly affected by malicious software

- Mainframe and Linux/Unix are not considered to be in scope

5.2 Ensure that all anti-virus mechanisms are current, actively running, and generating audit logs:-Automatic updates and periodic scans are enabled-Log are generated and retained per requirement 10.7

- Design and implement a centralised process for antivirus management and monitoring

- Prohibit users and power users from disabling antivirus, implement exception process and review on an individual basis

- Act proactively on noncompliant instances


Requirement 6Develop and maintain secure systems and applications


Detailed requirement (selection) Practical solutions6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. -critical security patches have to be installed within one month of release

- Employ a risk-based approach- Responsibilities for identifying patches need to

be assigned- Can be implemented as part of a generic

change management process

6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities

- Responsibilities for identifying vulnerabilities need to be assigned

- At minimum, the most critical, highest risk vulnerabilities should be ranked as High

- Use external sources: CVE for example- Risk rating can be based on CVSS score

6.3 Develop software applications in accordance with PCI DSS and based on industry best practices.-Removal of custom application accounts, user IDs, and passwords before production release-Code reviews

- Verify if it’s really applicable to your case- Design, formalise and implement SDLC process- SDLC has to include information security

throughout the life cycle.




Detailed requirement (selection) Practical solutions6.4 Follow change control p+p for all changes to system components.-Separate development/test and production environments-SoD between development/test and production-Production PANs not used for testing-Test data removal before releasing into production-Impact analysis-Approvals-Functionality testing (UAT)-Back-out procedures

- This includes a) system modifications b) security patches

- Design, formalise and implement a change management process that will encompass all CDE

- Include mandatory tollgates and implement as much automatic controls as possible

- Many blueprints available – e.g. ITIL

6.5 Develop applications based on secure coding guidelines. Ensure protection against: Injections (SQL, OS, Xpath, etc.), Buffer overflows, Cryptographic flaws, Insecure communication, Improper error handling, XSS, Improper Access Control, CSFR

- Include as part of SDLC process (see 6.3)- Has to incorporate current best practices for

secure coding. Needs reviewing on a periodic basis.

- Industry sources can be used: OWASP Guide, CWE/SANS TOP 25, CERT Secure Coding

6.6 Public-facing web applications need to be either reviewed annually and after any change or have a web-application firewall installed

- Employ an automated vulnerability tool to do the review


Requirement 7Restrict access to cardholder data by business need to know


Detailed requirement (selection) Practical solutions7.1 Limit access to CDE to only those individuals whose job requires such access.-“least privileges necessary to perform job responsibilities” rule-Assignment of privileges is based on individual personnel’s job classification and function-Approvals-Automated access control

- Implement RBAC; does not have to be purely automated, can be a hybrid

- Ensure that automated access control is used everywhere

7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know.-Default rule has to be deny all

- Use an automated solution- Ensure link with job position


Requirement 8Assign a unique ID to each person with computer access


Detailed requirement (selection) Practical solutions8.1 Assign all users a unique ID before allowing them to access CDE

- Review for the usage of group and shared accounts and either remove them or employ measures ensuring non-repudiation

8.2 Authenticate users before allowing access. - Authentication can be done in 3 different ways:- Know- Have- Are

8.3 Incorporate two-factor authentication for remote access.

- Two-factor authentication requires usage of two of the three authentication methods. Same method cannot be used twice

8.4 Render all passwords unreadable during transmission and storage.

- Achieved using cryptographic measures- Can be a problem for legacy systems


Requirement 8Assign a unique ID to each person with computer access


Detailed requirement (selection) Practical solutions8.5 Ensure proper user access management:-Verify user identity before password resets-First-time use password must be unique and must enforce password change-Revoke access for any terminated users-Remove/disable inactive user accounts at least every 90 days-Enable vendor accounts only when needed. Monitor while in-use.-Change user passwords at least every 90 days-Minimum password length of at least seven characters.-Needs to contain both numeric and alphabetic characters.-Password history of 4-Lock-out after six unsuccessful attempts-Lock-out duration of 30 minutes-Re-authentication after 15 minutes of inactivity

- Remote identity verification can be a challenge- Dedicated tools on the market for vendor

account management - Preferred semi-automatic data reconciliation

process between systems and HR data- Most password policy requirements can be

implemented by a GPO- Problem is solved automatically for systems that

rely on domain authentication- Systems that use their own inner authentication

mechanism may meet only some requirements


Requirement 9Restrict physical access to cardholder data


Detailed requirement (selection) Practical solutions9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the CDE-Use video cameras and/or access control mechanisms

- Review collected data- Store for at least three months

-Restrict physical access to publicly accessible network jacks.-Restrict physical access to network devices (e.g. wireless access points, telecommunication lines)

- In scope facilities include: computer rooms, data centres and other physical areas with systems in the CDE

- Controls include badges, locks and keys- Sensitive areas exclude areas where only point-

of-sale terminals are present- Simple install of CCTV is not enough, one has

to actually monitor- Legal requirements may override 3-month

requirement- Implement NAC for network access control

9.2 & 9.3 Distinguish between onsite personnel and visitors. Ensure proper visitor handling.

- Control badge issuance- Apply clear markers to identify visitors- Same technique can be applied to enforce

visitor badge expiry

9.4 Use a visitor log to record visitor activity-retain this log for a minimum of three months

- 3 mandatory elements are: visitor’s name, the firm represented, and the person authorizing access

- Legal requirements may override 3-month requirement


Requirement 9Restrict physical access to cardholder data


Detailed requirement (selection) Practical solutions9.5 Store media back-ups in a secure location, preferably an off-site facility-review the location’s security at least annually

- Secure courier- Data mirroring- Third party outsourcing

9.6-9.9 Media handling (ex. destruction)-Classification-Distribution-Inventory maintenance at least annually

- Design, formalise and implement media handling process

- Rules for media handling should stem from media classification scheme

9.10 Media destruction-Destroy media when no longer needed-Destruction methods need to be secure

- Refers to data retention policy (see 3.1)- Media is considered no longer needed when it

carries data that do not meet any legal or business requirements for retention

- For hard copies: crosscut shredders- For electronic data: secure wipe, degaussing,

physical destruction


Requirement 10Track and monitor all access to network resources and cardholder data


Detailed requirement (selection) Practical solutions10.1 & 10.2 Establish a process for linking all access to individual users. Implement automated audit trails for:-Individual access to cardholder data-All actions by root / power user-Access to audit trails-Invalid logical access attempts-Use of identification and authentication mechanisms-Initialization of the audit logs-Creation and deletion of system-level objects

- Implement a comprehensive logging solution –SIEM

- Devote sufficient time for implementation- Capacity planning may be a problem

10.3 Record at least the following audit trail entries: user, type of event, date and time, result, affected resource name, etc.

10.4 Using time-synchronization technology, synchronize all critical system clocks-Time data is protected

- Use NTP- Either install your own time servers or use

publicly accessible ones- Enforce synchronization and prohibit users from

changing time data

10.5 Secure audit trails so they cannot be altered-Limited access, backup-Protect from unauthorized modification

- Use FIM solution- Offload audit trails to hardened server




Detailed requirement (selection) Practical solutions10.6 Review logs for all system components at least daily

- Needs to cover entire CDE- Employ the usage of automated tools e.g.

implement SIEM- Security-related network components (e.g. IDS,

AAA) take priority

10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis

- Capacity necessary to deal with the bulk of logs generated during the entire year

- Offloading of older logs to a less flexible media (i.e. to tapes)


Requirement 11Regularly test security systems and processes


Detailed requirement (selection) Practical solutions11.1 Test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis.

- Implement wireless scans or install a dedicated Wireless IDS solution (detective controls)

- Preventive methods include USB port control and usage of NAC

- Automated tool installation is not sufficient on its own – it has to be ensured that it generated alerts and somebody is responsible for receiving and reacting to those alerts

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network:-Internal (non-ASV)-External (ASV)

- 4 quarterly scans need to be performed over the period of last 12 months

- For internal scans deploy a dedicated tool and assign qualified and independent team (SoD)

- Internal scans: re-scans are mandatory if vulnerabilities found

- External scans have to be conducted by an ASV

11.3 Perform external and internal penetration testing at least once a year and after any significant change-Network-layer penetration tests-Application-layer penetration tests

- May be conducted by an internal or external resource

- Does not have to be an ASV- Scope matters




Detailed requirement (selection) Practical solutions11.4 Use IDS/IPS at the perimeter of the CDE. Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date.

- Again, simple installation of IDS won’t be sufficient – it needs to be properly configured so that it will alert personnel that will then react accordingly

- Ensure regular updating

11.5 Deploy file-integrity monitoring tools to alert personnel to unauthorized modification of critical files. -Configure the software to perform critical file comparisons at least weekly

- Implement a FIM solution- There is no clear guidance which files are

supposed to be monitored – safe bet is critical system files

- Reports need to be reviewed on a weekly basis- Designated personnel needs to be alerted




Detailed requirement (selection) Practical solutions12.1 Establish, publish, maintain, and disseminate a security policy-Addresses all PCI DSS requirements-Clearly defined roles and responsibilities-Includes an annual risk assessment process-Needs at least an annual review and updating when changes occur

- No gaps against PCI DSS requirements must be ensured

- use industry best practices for risk assessment: ISO 27005, NIST SP 800-30

12.3 Develop usage policies for critical technologies:-Authorisation process-Acceptable devices-Acceptable uses of technology

- General dos and don’ts – the idea is that it has to be documented and approved my management (used to establish tone at the top)

12.6 Implement a formal security awareness program-Educate personnel upon hire and at least annually-Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures.

- It needs to be formal i.e. evidence need to exist as a proof

- multiple methods should be employed: posters, letters, memos, web based training, meetings, promotions, etc.




Detailed requirement (selection) Practical solutions12.7 Screen potential personnel prior to hire - Background checks include previous

employment history, criminal record, credit history, and reference checks

- Subject to local law regulations, may be limited as a result

- For one-time access this is only a recommendation

12.8 Manage service providers in cases where cardholder data is shared with them:-list of service providers-written agreement acknowledging their responsibility for the security of cardholder data given to them-Due diligence prior to engaging-Monitor compliance and progress at least annually

- Service providers do not have to be all PCI DSS compliant but they have to be dully monitored

- Service providers may oppose to changing existing agreements, a good time would be a contract renegotiation

- No guidelines for due diligence, but this has to include a PCI DSS compliance check

- At least once per year all entities on the list must be queried about their PCI DSS compliance status

12.9 Create and implement an incident response plan in the event of system breach-Plan has to be tested at least annually-Designated personnel has to be available 24/7

- Basically, it’s a BCP requirement- Notification of the payment brands is mandatory- Analysis of legal requirements for reporting

compromises should be conducted- Must be continuously improved


Compensating controlsLast resort

• Sometimes it’s not possible or feasible to meet some PCI DSS requirements due to legitimate technical or documented business constraints (e.g. legacy applications, future changes)

• Compensating control is a substitute for an original control because it addresses the same risk


Compensating control worksheet

ConstraintsObjectiveIdentified RiskDefinition of compensating controlsValidation procedureMaintenance

• Major caveats:• Must provide similar level of defence• Existing PCI DSS requirements can’t be

compensating controls if they are already required for the item under review

• Must not create additional risk


Generic PCI DSS engagementFrom Deloitte perspective


Gap analysisScoping and planning

Requirements gathering

Roadmap to compliance Audit

Business process

diagramming

Control assessment

Gap identification

Remediationplanning

Deployment

Business process

reengineering

Post-implementation

review

QSA on-site assessment

Quarterly ASV scans

Compliance maintenance

Programme management and quality assurance


Sales – e-commerceAS-IS



Sales – e-commerceTO-BE



Sales – call centreAS-IS



Sales – call centreTO-BE



Sales – branch office channel (local)AS-IS



Sales – branch office channel (local)TO-BE



Sales – branch office (non-local)AS-IS



Sales – branch office (non-local)TO-BE


Same as AS-IS, no need to change


Sales – transaction settlementAS-IS



Sales – transaction settlementTO-BE


Acquirers

Agent A

Agent B

Agent C

HOT file

HOT file

HOT file

American Express

Diners

Internal HOT serverSales listing(HOT file)

Internal EPA server

Submissionapplications

EPA files

Loyality programme operator

Central submission

Sales data

New revenue recognition system

(SaaS)

Encrypter storage Internal server for cardholder data exchange

PAN removal tool

FA system


Sales – offlineAS-IS



Sales – offlineTO-BE



SAQOverview of options


SAQ DescriptionA • Card-not-present (e-commerce or mail/telephone-order) merchants, all

cardholder data functions outsourced. • No electronic cardholder data storage. • This would never apply to face-to-face merchants.

B • Imprint-only or dial-out terminal merchants• No electronic cardholder data storage. • This would never apply to e-commerce merchants.

C-VT • Merchants using only web-based virtual terminals• No electronic cardholder data storage. • This would never apply to e-commerce merchants.

C • Merchants with payment application systems connected to the Internet• No electronic cardholder data storage.

D • All other merchants not included in descriptions for SAQ types A through C above, and all service providers defined by a payment brand as eligible to complete an SAQ.

P2PE-HW • Merchants using only hardware payment terminals included in a PCI SSC-listed, validated, P2PE solution, no electronic cardholder data storage.

• This would never apply to e-commerce merchants.


Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited (“DTTL”), a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see www.deloitte.co.uk/about for a detailed description of the legal structure of DTTL and its member firms.

Deloitte LLP is the United Kingdom member firm of DTTL.

This publication has been written in general terms and therefore cannot be relied on to cover specific situations; application of the principles set out will depend upon the particular circumstances involved and we recommend that you obtain professional advice before acting or refraining from acting on any of the contents of this publication. Deloitte LLP would be pleased to advise readers on how to apply the principles set out in this publication to their specific circumstances. Deloitte LLP accepts no duty of care or liability for any loss occasioned to any person acting or refraining from action as a result of any material in this publication.

© 2012 Deloitte LLP. All rights reserved.

Deloitte LLP is a limited liability partnership registered in England and Wales with registered number OC303675 and its registered office at 2 New Street Square, London EC4A 3BZ, United Kingdom. Tel: +44 (0) 20 7936 3000 Fax: +44 (0) 20 7583 1198.

Member of Deloitte Touche Tohmatsu Limited

Dariusz SadowskiAssistant ManagerPMP, CIA, CISM, [email protected]+44 (0) 7768 947 617

PCI DSS: Practical ways of achieving compliance41

pci dss: practical ways of achieving...

Documents