Welcome!

Steve Caniano

Subscribe to Steve Caniano: eMailAlertsEmail Alerts
Get Steve Caniano via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Open Source Journal

Blog Feed Post

Hitchhiker’s Guide to PCI DSS 2.0 Scoping (Part 2)


Editor’s Note: In this post, Steve Levinson outlines strategies for cardholder data discovery to help determine where there is no cardholder data in your environment, along with strategies for selecting cardholder data scanning tools.  This post is the second in a series of four from the “Hitchhiker’s Guide to PCI DSS 2.0 Scoping.” The first post offered a step-by-step methodology, the third post offers a cardholder data discovery sampling strategy, and a fourth post will provide remediation guidelines for addressing issues with cardholder data.

As discussed in the first post, companies do not necessarily need to perform cardholder data discovery scans across their entire environment.  It is more important to chisel away the portions of your environment that are undoubtedly out of scope (i.e. do not store, process, or transmit cardholder data, nor are attached to these systems):

  • For some companies, a large percentage of their environment may be considered out of (PCI) scope because the systems, applications, and people have absolutely no means of accessing cardholder data.  Companies should thoroughly document each of these entities and prove how there is no logical means for these entities to access cardholder data.  If you are able to provide detailed descriptions that de-scope portions of your environment, you may have less of a burden of proof when it comes to cardholder data discovery exercises and tools.

  • Determine changes over time: As you go through this exercise, you should also do your best to determine what changes have taken place over time.  If your network architecture and systems have remained fairly static, you may not need to be too concerned about systems that have been recently de-scoped. On the other hand, if you just implemented network segmentation a few months ago, it is possible that systems now out of scope were in scope back then, and therefore they may have cardholder data on them.
  • Address the Null Hypothesis: Once you have corralled the possible systems, databases, applications, and people, you will need to develop a methodology to fail to disprove the null hypothesis. The null hypothesis is: “There’s no cardholder data here.” To fail to disprove this is to demonstrate that you have performed your due diligence to flip over the stones to show that you were unable to find any cardholder data.
  • Determine the Periodicity: In building out your cardholder data discovery methodology, you will need to determine the periodicity in which you search for unencrypted cardholder data. In some instances, you may run one discovery scan, and assuming that no data is found and that you have adequate controls to prevent cardholder data from appearing on that device, system, or application. In other instances, more frequent scans may be required.  There is no set rule as far as periodicity – it will vary from network to network or entity to entity, but make sure that you’ve included this in your methodology.

There is no silver bullet to defining your scoping methodology, but there are many possible solutions available to address your cardholder data discovery needs.  While AT&T Consulting is vendor neutral, we have seen a variety of tools help many of our clients with their discovery process, onmainframes, databases, spreadsheets, and flat files by using open source tools, commercial off-the-shelf tools (COTS), forensic analyzers, and outsourced cardholder data discovery solution providers. No one-size-fits-all approach exists, but a thorough examination can go a long way in helping you meet the spirit of the PCI standard.

  • Open source tools: these tools will potentially save you money, but you will need to have some degree of in-house expertise to run and/or fine-tune these tools. Examples are Spiderlabs, Nessus, and custom scripts.
  • COTS tools: if you are already using one of these providers’ products, there may be synergies in selecting their cardholder data discovery solution.  Many of our clients have implemented Symantec’s Vontu, RSA’s Tablus, Spyglass, and Websense.
  • Mainframes: just because they are big and scary does not mean they don’t have large potential repositories of cardholder data. We’ve seen clients implement Xbridge as well as write custom scripts.
  • Databases: there are times when companies are not fully aware of the content of their databases. (some companies write their own REGX discovery scripts while others use commercial database discovery tools)
  • Forensics analyzers: though this may be considered overkill as these tools do a lot more than just cardholder data discovery (i.e. enCase).
  • Outsourced cardholder data discovery solution providers:  there are reputable third parties who can perform your cardholder data discovery scans – either on a one-time basis or as a service. These providers include: forgenix FScout, Ensure Networks, iScan, and some of the QSA companies.

Out of the box?

Regardless of which tool(s) you implement, the outcome that you should expect is that cardholder data discovery is an imperfect process. Your tool will invariably stumble upon heaps of false-positive findings (data that appears to be cardholder data, but is not). You must be prepared to address these false positive findings and learn where they should be ferreted out and where they are valid. This is often a time-consuming exercise.

Do you have any cardholder data discovery processes that you’ve found successful? Have you been happy with your selection of cardholder data discovery tools? What have you done to reduce your false positive findings?

Read the original blog entry...

More Stories By Steve Caniano

Steve Caniano is VP, Hosting, Application & Cloud Services at AT&T Business Solutions. As leader of AT&T's global Hosting, Application and Cloud infrastructure business, he is instrumental in forging key partner alliances and scaling AT&T's cloud services globally. He regularly collaborates with customers and represents AT&T at key industry events like Cloud Expo.