Internal Scanning for PCI Compliance – Not Sexy but Necessary

November 16, 2015  |  Branden Williams

Back when I ran a PCI consulting practice, I had this idea to go through all of our customers' Reports on Compliance and tell the world what the most failed PCI requirements were. We had grand plans of launching into discussions about advanced authentication methods or delving into why encryption is a big problem for big companies.

We were all very surprised when the quarterly scanning requirement turned out to be the number one failed PCI DSS requirement for our customers at the time. No sexy discussions about advanced encryption methods, just a head scratcher on why one of the (seemingly) easiest requirements tripped up retailers—big and small.

Internal scanning might be one of the least sexy things that security professionals do—especially when you consider the amazing set of tools available for us to use today. I can't think of anyone who would rather sit in front of some internal vulnerability data instead of playing with advanced security analytics or decoding some new variant of a prominent piece of malware. This very problem may be one of the biggest contributors in the struggle to manage internal vulnerability programs.

As we started digging into our data a little bit more and speaking with customers about the requirement, we quickly learned that scanning was not the problem. There are plenty of scanning tools available for a myriad of platforms, and detecting vulnerabilities is easier now than it ever was.

We play the role of the classic consultant perfectly here. We point out all of the problems fairly quickly and accurately, yet we are not great at solving the problem, i.e., managing those vulnerabilities to a fixed state. Some of these vulnerabilities will naturally fall through the cracks given that we have tens of thousands of lines of data shoved our way after each scan. Scanning on its own does no good if it's not followed up with tools and processes to eradicate an identified vulnerability, with positive confirmation of its demise.

As our environments grow in complexity, size, and geographical spread, we need to leverage tools that can help us manage our internal vulnerability data. Several new (and some not so new) entrants in the market such as, Kenna, and Digital Defense aim to tackle this very problem. They are designed to take data sets in multiple formats and make sense of them in a way that allows you to manage them to close. This is the real challenge with internal vulnerability management—making sure identified vulnerabilities die a justified death with no possibility of reincarnation.

PCI Compliance might be one of those few headaches that can actually drive you to better IT hygiene and operational excellence with respect to vulnerability management. The quarterly cadence is probably not frequent enough, but the mandate to have clean quarterly scans may provide enough motivation to truly attack the problem in a meaningful way.

I would be remiss if I discussed the tactical process of vulnerability management without a word of caution. These tools are great for closing vulnerabilities on specific endpoints; but unless you spend some time thinking about how the vulnerability was introduced into your environment, you may be doomed to see it pop up again in a future scan.

Patching does nothing if it is not managed at the top of the distribution chain. As we continue to virtualize our infrastructure, this problem compounds upon itself with ephemeral virtual machines or application stacks. We must consider these digital assets to be disposable—in a manner of speaking. I would recommend that you let the instances doing the processing die to ensure that fresh instances of these same systems are created from current "gold master" builds (understanding that this term is a bit passé).

As we move into the holiday freeze of 2015, you should take a few days to review your vulnerability management practices. Set yourself up to reduce the workload associated with internal scanning and vulnerability management in 2016 through automation and investment in the right tools. Check out a book or two about DevOps to see if there are ways you can tie into the deploy process earlier to prevent vulnerabilities from re-occurring in your infrastructure.

And don’t forget, 2016 is a release year for PCI DSS! It should be interesting to see what kinds of things get cooked up for the next version of PCI DSS!

About the Author

Branden is well known in the industry as a practitioner, consultant, and thought leader. He spent a number of years helping companies solve major security and compliance problems, including building PCI DSS compliance programs for some of the largest retailers around the globe. He recently sat on the PCI Board of Advisors and published the third edition of his book, PCI Compliance (Syngress, 2012) in August. Branden routinely speaks with organizations big and small with various levels of regulation to help them reduce their overall risk footprint and build safer and more efficient IT functions. A review of the book on PCI written by Branden and Anton Chuvakin is here.

Share this with others

Get price Free trial