When PCI Compliance meets real world security: Part 1 of 3

Having worked directly with PCI Compliance and merchants for a few years before joining AlgoSec, I’ve had a lot of opportunity to see where PCI DSS requirements were useful and realistic, as well as where they weren’t. This isn’t to say that of the 12 requirements they don’t all have some usefulness, but I think it’s safe to say that not all requirements apply to all merchants.

That being said, there is a rarely looked at overview of a security plan that comes directly from the PCI Council that makes a lot of sense. It’s a simple 3-step process:

1. Assess
2. Remediate
3. Report

While this might be a “no brainer” type of security plan, it’s often not followed. There are too many tools and people involved, too much manual intervention needed, etc. These simple “rules to live by” in security often get too confusing to actually live by!

In thie 3-part blog series, I will examine how each of these steps can apply to you, your organization and your firewalls. Firewalls are a primary gateway into your company and therefore are a great place to start. For the purposes of this specific blog post, we’ll dig into step one.

Step One – Assess

The PCI Council describes Step One as the following:

“The primary goal of assessment is to identify all technology and process vulnerabilites that pose risks to the security of cardholder data that is transmitted, processed or stored by your business.”

When it comes to security, the old saying “what you don’t know can’t hurt you” is dead wrong.

I recently worked with a company that has over 200 firewalls. We assessed the risk on one of those firewalls that had over 3000 lines of rules. For the math challenged, three thousand rules per firewall multiplied by 200 firewalls equals 600,000 lines of rules. There’s no way in the world any person or even team of people can go through that much code, especially considering the change requests that occur everyday, and expect there not to be missed vulnerabilities. Throw in the fact that a vulnerability may not actually be a vulnerability until correlated together with another vulnerability and you’re talking nearly impossible.

Add to this the silos between IT and Security personnel. You know the situation… Someone’s boss runs to IT at ten minutes to five on a Friday and screams “I need to give access to our new paycheck company into our internal HR systems!!!! If you want to get paid next week, you’ll make sure this happens ASAP!” Not wanting to cause trouble, IT tries to respond as fast as it can and in doing so, makes an out-of-band change to grant that requested access. Oftentimes in this situation the security team doesn’t know this has happened… until something goes wrong.

This happens all the time and without assesssing and auditing your firewalls these situations turn into serious threats.

In the next installment of this series, we’ll look at Step Two and the best ways to approach remediation.