really enjoyed reading the verizon pci report

I previously mentioned Verizon’s new DBIR supplement related primarily to compliance (PCI) efforts they see, and I’ve finally gotten to read this very fine piece of work. So, my thoughts follow! If the report is too wordy for some reason, skip to page 10 and read the 12 requirement sections. (I had some PCI-related reactions to the DBIR already.) I really think this PCI Report (PCIR) is well-written and contains some very realistic and practical observations and information.

Requirement 1 (firewall configuration) – The PCIR sounds pretty accurate in why orgs don’t meet req 1: poor reviews of firewall/router rules, proving those reviews take place, documenting business cases, and poor egress filtering. Poor documentation could be *greatly* helped if firewall products allowed any sort of comment/description field with enough space to be useful. As it is, it seems rare that firewall rules can begin to be documented inside the actual tools. Tracking and reviewing this sort of documentation becomes a huge task when talking about more than a few firewalls/networks.

Requirement 2 (vendor defaults) – I’m not surprised by the 2 of the 3 big reasons for challenges here: harden systems by turning off unneeded services/functions and document why some can’t be turned off. These go into having a very mature system build and configuration process. It’s way too common for people to say, “I’ll harden this system,” but then just look for some magical checklist somewhere that says what to turn off. This is a beast to tackle for the first time.

Requirement 3 (stored data) – Also am not surprised here that the big hang-ups are key management and the encryption of things outside the static databases. Key management is probably foreign to most teams, and not something anyone wants to handle, especially if encryption is done inside the tools and maybe not easily changed. I really think Verizon hit on one issue in the PCI DSS: there is data in transit and data at rest, but I believe there are two subsets of data at rest: data not in use and data actively in use. Obviously the latter is the problem child.

Requirement 4 (encrypted transmission) – I am glad the PCIR mentioned 4.2. I imagine that one is very often compensated for and/or over-looked (or just flat-out specifically ignored as being too small a trickle to be impacting!), despite actually being violated. It is hard to test for, and is entirely encumbent on the host org to expose this. Even an internal IT team can’t really answer this alone without DLP-scanning-type technology, let alone a time-bound/access-bound auditor.

Requirement 5 (AV software) – I’m still partly surprised this isn’t higher, but also surprised this isn’t lower. While everyone should have AV everywhere, I’d be curious how many shops really are staying on top of any systems that get stood up without it being installed or systems with broken agents or outdated sigs for whatever reason…

Requirement 6 (dev and maintenance) – Patching. I wonder how much subjectivity still goes into this? Quarterly updates may be too long for some auditors to recommend. And what about applications, pieces of web applications, and network gear? It is not uncommon for a networking guy to only do updates when necessary as opposed to having an outage every 2 weeks for a new Cisco IOS version actoss 100 switches. Developing web apps securely is something I would still consider a foreign concept to most developers and development teams (inclusive of mgmt/leaders). It is even more foreign for said teams to update third-party pieces *inside* the apps. Hell, most don’t even document their presence! On the flip side, I think this is very hard for an auditor to be truly thorough in checking out.

Requirement 7 (logical access) – I agree with what the Verizon PCIR discussed on this topic. Beware anyone who bandies about the term RBAC. It’s easy on paper, but difficult in practice. Anyone who has managed accounts or Active Directory knows this requirement is nasty if someone gets serious about it. But it is oh-so-refreshingly easy when in place and enforced.

Requirement 8 (unique IDs) – I think the challenge in this item is likely all the web apps and other things with unique IDs, like the PCIR mentions for networking devices. That, and the regular rotation of things like service account passwords. Such tasks are almost always outage-inducing, and business/IT tends away from outages.

Requirement 10 (tracking and monitoring) – I think this whole requirement is often foreign to IT teams. Sure, some do figure out central logging, but that’s really just for operations and troubleshooting. Everything else can be a huge new capital expense or ongoing budget item. And application logging is often done only insomuch as it helps a developer troubleshoot something, and does not adhere to any standard. FIM is also new, and again, a huge beast if someone takes it properly seriously.

Requirement 11 (regular testing) – This requirement falls back into the category: new expense. Not easy for teams to swallow. Even a FIM is not something you just find a checklist for, buy a tool, turn on, and forget. Vuln scans are not turn on and forget. Show me a clean vuln scan and I’ll show you how it is misconfigured. You should have pages upon pages of false positives to deal with, or real issues that need addressed.

Requirement 12 (security policies) – Incident Response is a new item in many SMBs. Likewise, there may be a discrepancy in policy and actual practice partly because of who writes them. Policies can be often written by auditors, management, and outside parties paid to craft them. But they need to be made by, or in close association to, actual IT workers who do the work. I think req 12 is very often just outsourced and then never really followed. Even my own organization falls into this trap with some policies that make me wonder if anyone understands exactly how much work it is for me to ethically adhere to some policies while balancing business needs.