How Christmas Kills PCI Compliance

There’s a routine to every large company with a DevOps team; from Christmas to New Year’s, there’s going to be a production freeze. Everyone rushes project schedules through November into early December. Meetings go wild. Overtime runs rampant. Application development wraps every possible feature and bug fix into the final push, and the last of the new changes roll out on a Monday or Tuesday somewhere between December 15th – 20th.

Then, like winter, comes the inevitable cold spell: Nothing in the infrastructure can change. There are no change control meetings, because there are no new releases. This is the way of IT departments in every corporation. Step two of the cold spell, staff gets sent off on fairly mandatory vacations, stretching from Christmas to New Year’s. People make merry, drink too much egg nog, and come back to work the first week in January to pick at the mountain of emails in their inboxes. So what is the effect on PCI Compliance?

We at WhiteHat looked at the data from our own customers in the industries of Retail, Finance, and Healthcare, and noticed something statistically significant that has happened every December for the last decade: Everyone’s PCI DSS compliance scores dip. Every customer enjoys this phenomenon. We looked into other industries, and there were no exceptions. But for the purposes of Who Should Care Most over the Christmas holidays, I’m concentrated on the graphs for Retail, Finance, and Healthcare.

We can see the trend clearly, because the PCI DSS risk posture improves just about every year in February, as illustrated here:

Whether this means February is audit month or just represents the date when DevOps swings back into action and releases another set of bug fixes, I cannot say with the available data. All I can see is that PCI Compliance (which doesn’t have a great percentage) tends to improve by the February scans. (2015 is the only year where the difference was negligible.)

Hackers know about Christmas. They’ve worked for big corporations, or their friends have. So let’s look carefully at this scenario and what happens, in terms of risk analysis:

New features = new possible vulnerabilities.

Short staffing = only emergencies will be dealt with.

High and Critical findings = get reported as bugs to go into January/February releases.

While correlation does not equal causation, it seems like it would definitely be a good plan of action to review the November and December web application dynamic scan results carefully before telling the whole DevOps team they have to take their time off. Saving a few bucks on staffing can cost a whole lot of money in mandatory breach reporting.

Lest I be all Doom and Gloom about the Holidays, I wanted to offer a cheerful image as well. What does overall compliance and application scoring look like over years of using dynamic scanning and source code reviews? Does it actually improve an organization’s security posture and reduce risk? The proof, as it were, is in the pudding. Or a convenient graph of customer statistics and scoring comparison (by industry via WhiteHat’s Website Security Index and Peer Benchmarking) over the last 2 years. Over time, even with the thousands of new vulnerabilities found every year, the general web application score improves when you practice continual scanning, concentrate on fixing the biggest issues.

So enjoy your turkey, and if you’re an IT manager consider asking for final code revs and website application releases earlier in December, scan by the 10th, and get all the necessary findings into your bug tracking system before the break. And if you don’t currently do continuous web application scanning, maybe it’s time to start.

Cookie Use

We use cookies to store information on your computer that are either essential to make our site work or help us personalize and improve the user experience. By using this site, you consent to the placement of these cookies. To learn more, see our Cookie Policy.