Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
Echelon1_PCI

Echelon1_PCI

Ratings: (0)|Views: 5 |Likes:
Published by Anton Chuvakin

More info:

Published by: Anton Chuvakin on Jul 27, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

07/10/2013

pdf

text

original

 
Date: 1/11/2010Title: How to make PCI DSS a friend and not an enemy of securityWritten by: Dr. Anton Chuvakin
Summary
Since most direct-to-consumer businesses accept payment cards today, PCI DSS getsa lot of attention. Such attention is further boosted by massive data breaches of cardholder data. Businesses should use the requirements of PCI DSS to reduce their information risk and not simply focus on reducing the compliance burden.
The Issue
Payment Card Industry Data Security Standard or PCI DSS was created by the cardBrands in order to reduce the risk of payment card transactions. Due to popularity of payment cards as a payment method for most direct-to-consumer transactions, theapplicability of PCI DSS is nearly universal. At the same time, PCI DSS is one of themost descriptive and specific security guidance documents and available today.Moreover, in addition to security guidance, there is a regulatory regime of enforcementand validation. QSAs, ASVs and acquiring banks serve to ³keep honest merchantshonest ³ and to ³motivate³ other merchants to improve their security. While compliancevs. security debate rages on, PCI continues to move downmarket, affecting smaller andsmaller merchants. As a result, there are calls to use PCI DSS as an underlying security framework, beyondconfidentiality of credit card data. At the same time, the calls I heard that PCI DSSdistracts some organizations from improving their security by focusing on hard-codedcontrols from the document. How should enterprises deal with such dual identity of PCI? How to settle the direct demands of assessors and implicit demands of securitythreats factors?
Discussion
Before any further discussion of PCI DSS, we have to separate between PCI DSS, thesecurity guidance document, and PCI, the regulatory regime. The former contains 12domains of security recommendations, controls and practices which are mandatory tofollow for those organizations that accept payment cards, process, store or transmitspecific types of cardholder data. The DSS document defines what it means to be PCIcompliant. On the other hand, PCI regulatory regime includes brand specific merchantlevels, defines PCI compliance validation requirements for each level, creates entitieswhich are used for compliance validation (Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASV)) and defines fines and other punishments for merchants who . It is also the worthwhile to separately mention ³PCI security
 
philosophy´ that, for example, calls for not storing certain types of data despite thesafeguards.In this note to we intend to provide guidance on how to use the above components of PCI to improve security as well as to make sure that no compliance dollar is wasted onefforts which do not enhance information security. In other words, we intend to avoid³compliance for compliance sake´ at all cost.The first and the most obvious use of PCI for security is to use it as a powerful motivator and driver of security budgets; every Chief Security Officer (CSO) nowadays knows howto do it. It is worthwhile to add that over-using the compliance sledgehammer leads todecreased budgets and inability to pass critical security improvements through theprocess. Specifically, it is sadly known in our industry that sometimes´the wrath of theQSA´ motivates security improvement more than all Chinese hackers combined. At therecent security conference, the presenting CISO has noted that in his 30 year career hehas never seen anything as motivating the security as PCI DSS. Along the same lined,sometimes it is not the threat of fines, but a real possibility of being caught in a databreach and then found to be non-compliant that does the trick for many senior managers in control of budgets. This key benefit is a more applicable for securityleaders, organizations that sit above the average on security program maturity curve.For less mature organizations or relative ³laggards´, DSS guidance itself from is a usefuland widely tested pool of security knowledge as it is well-known across a wide range of organizations. PCI cover as many of the domains also found in security programs. For example:
‡
Security policy and procedures
‡
Network security
‡
Malware protection
‡
Application security (and web)
‡
Vulnerability scanning and remediation
‡
Logging and monitoring
‡
Security awarenessThus DSS guidance can be used to quickly ramp up a security program where noneexisted before. Even though PCI DSS is meant to protect primarily the confidentiality of a particular type of data (payment card data), many of its provisions may be used byorganizations to quickly ramp up their security programs, especially if none existedbefore. While doing so, it makes sense to be mindful of the limited mission of the DSSguidance. Specifically, if using PCI DSS as a core for a new security program, allmeasures to protect the availability of data (for example, PCI DSS doesn¶t cover DoSattacks) and all measures to protect the productivity of employees (DSS definitely doesnot cover filtering of P2P and non-work related IM communication) need to be built ontop of the PCI DSS derived program. Admittedly, many other standards (ISO2700x andNIST 800 guidance comes to mind) are more comprehensive, but they appear to go³over the heads´ of less enlightened organizations.
 
 Finally, PCI DSS philosophy can be used for reducing the risk across other types of information. The best example is PCI concept of ³scope´ and its reduction or ³scopeshrink.´ PCI scope covers systems that touch card data or those ³directly connected tothem´ (as defined in PCI DSS v 1.2.1). As described in our book ³PCI Compliance´,reducing the scope of PCI DSS applicability by making sure that card data is notpresent on too many systems, does not traverse (unencrypted) many systems, etcserves not just to ³make PCI DSS compliance easier´ , but appears to genuinely reducethe risk of payment transactions. Thus picking such ideas from PCI DSS contributes toimproving data security across other types of data. Another useful lesson from PCI DSS (and, admittedly, other regulatory audits) is thattime spent on ³proving´ or validating security is not time wasted. Building and runningsecurity seem more important than proving security, but time and efforts spent ondocumenting controls and outcomes of their application does make your securityprogram more resilient against not just auditors, but also malicious hacker attacks andsenior management attention«
C
onclusion and next steps
One of the easiest things to make the experience running a security program lesspainful is to stop complaining about compliance. Harnessing the power of regulations toreduce the information risk and improve security is an essential activity for any CSO andone that has a potential of helping his or her mission significantly. However, as weshared in this note, this utility of regulations does not just come from their ³budgetbusting´ power. An organization can and must use PCI DSS for its budget-releasingpower, control guidance, security education as well as for building validates for asecurity program. On top of this, you can use what we called ³PCI philosophy´ and aimto reduce scope of regulation applicability, which also reduces risk. Some of theexample tasks around that area are adjusting business processes to avoid or reducestorage of regulated data, discovering and deleting confidential data on non-essentialsystems, isolating payments networks that handle card data from the rest of theenvironment, etc. Finally, a CSO can use regulatory compliance tasks, such as PCIDSS compliance in order to build a comprehensive program of validating or proving thesecurity program.
 ABOUT THE AUTHOR:
This is an updated author bio, added to the paper at the time of reposting in 2011.
Dr. Anton Chuvakin (www.chuvakin.org
 
) is a recognized security expert in the field of logmanagement and PCI DSS compliance. Anton leads his security consulting practicewww.securitywarriorconsulting.com, focusing on logging, SIEM, security strategy andcompliance for security vendors and Fortune 500 organizations.He is an author of books "Security Warrior" and "PCI Compliance"(www.pcicompliancebook.info) and a contributor to "Know Your Enemy II", "Information

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->