PCI and Assessment Consistency

As many organizations that have hired QSAs recently have seen, the Report on Compliance (ROC) has changed quite dramatically for v1.2 of the PCI DSS standard from previous versions. Although previous versions of the DSS required that a QSA address all the controls and properly document them, in fact many ROCs failed to provide adequate documentation that could be upheld in court. In general, as many QSAs have seen, the quality of work being delivered has varied widely. The QA process and scoring matrix released by the PCI SSC for v1.2 even the playing field for all QSA firms and provide excellent guidance on documentation requirements. Some QSA firms were severely cutting their fees and providing sub-standard work. For example, two days onsite for an audit, in almost all circumstances, just do not give adequate time to understand and assess a complex environment. As a customer looking for a QSA firm, don’t be lured by price alone. Obviously, price is a factor, and the market is especially competitive in today’s economy. Ask the QSA firm you are looking at for sample reports. There should be fully documented answers that provide descriptive, stand-alone responses. Inquire about the skill sets of the QSAs that will be conducting the work; ensure that they have experience with your industry. Consider the talent of the QSA firm; remember that your business reputation is potentially at stake. With the amount and severity of breaches today, it is up to customers to ensure that they use a quality QSA to assess their environment. Unfortunately, many organizations just want to “pass”; and if they do, they think they are good for the year. That’s short-sighted. PCI compliance is a state-in-time assessment, but an organization must maintain compliance at all times. Good QSAs will establish ongoing relationships and offer assistance in maintaining compliance over time. We, as QSAs, are now being audited, and the PCI SSC QA team will be reviewing all of the QSA firms out there. This is a step in the right direction to ensure consistency among QSA firms and their associated deliverables. This is beneficial for the customer too, as the quality of work is improving and the customer can start comparing apples to apples.


Compliance vs. Risk

As a company, we’ve tried to understand which organizations are most likely to mature their information security programs. It seems that the answer should be obvious: organizations with valuable assets or the need to have data highly available should be very concerned about information security. This could translate into organizations that have a lot to lose, ones that have high profit margins, or those involved with the nation’s critical infrastructure. Interestingly, this is generally not the case. In fact, the primary drivers for maturing information security within an organization are regulations or contractual standards with strong penalties for non-compliance. Why is this? One problem is that risk is very subjective. In a downturn, the risk equation can change dramatically. If you are fighting for the survival of a firm, it’s easy to justify not investing in information security. Compliance, however, is not as subjective. While there is room for some interpretation, compliance regulations and standards are stable, detailed, and consistent. This means that compliance is easier to justify, easier to plan for, and easier to assess. But while meeting compliance standards can be a very good thing, it does create a problem: risk is often left out of the equation. For example, payment card industry (PCI) data often gets more attention at hospital systems than does protected health information (PHI). Based on risk, the patient-related data and services should be classified as at least as important as the credit card information. It usually is not, however. Without a risk-based approach or a strong compliance standard like PCI, PHI won’t get the attention it deserves. (The PHI standards are being tightened somewhat, by provisions of the American Recovery and Reinvestment Act, or ARRA, passed this year by Congress.) Compliance can help speed the maturation process, and it is valuable in other ways, but it lacks the depth and breadth of a risk-based approach. Additionally, creating regulations and standards for all things that should be secured just isn’t possible. In an ideal world, organizations will take a more holistic, risk-based approach that includes compliance, but this may have to wait until the economy turns around.


Is your Compliance Driven by More Than an Audit?

Preparing for an audit can be one of the best ways to fund and improve your security program, but this “stimulus package” for your compliance effort typically dwindles once an organization completes or passes an audit. I see this happen frequently in recurring or annual audits, but it is particularly relevant with the recent news of Merrick Bank. Specifically, Merrick Bank is suing Savvis for certifying CardSystems Solutions to be Visa CISP compliant prior to a breach that exposed some 40 million payment card records and resulted in $16 million in fines to the card brands. While this is the not the first breach of a PCI-audited company, it is the first one in which the auditor has been sued. The case raises an important question: Who is ultimately responsible for ensuring that a good security program is in place? Here are some simple, yet critical, points to ensure your security program is driven by something more than the audit itself.

  1. Understand the role of the auditor. When preparing or undergoing an information security audit, it’s critical for organizations to consider the role the auditor performs within a security program. This role should never be a member of your security team or a designer/implementer of your security systems; it must be strictly be a reviewer of your security state at a point in time. While some coaching and direction can be good, all decisions and program enhancements must be driven by the organization itself.
  2. An audit is not a design session. If your security program design is heavily based on the initial audit gap report, your program will not be sustainable. Although you and your auditor share the same goal, ensuring you are compliant, your auditor’s coaching will be targeted on one thing—meeting a specific requirement. Your program will then also be designed merely to meet the standard and not take into consideration sustainability, holistic approaches, and integration with existing business requirements.
  3. If you are not 100% ready for the audit, you should not be audited. Because an audit is intended strictly to be an independent review of the security program, if your organization does not feel it can meet all aspects of the audit, you should fix it first. Don’t consider your audit a pass/fail game between you and your auditor. That is not the point of being measured, nor is it a best practice. Plus, any audit that is worth something requires a joint attestation by you and your auditor; if you can’t sign off on it, neither should the auditor.
  4. Aim higher than the compliance requirements alone. Information security is one of those areas where going above and beyond the call of duty can be a good thing. Compliance requirements are meant to be the minimum standard by which you are allowed to operate; strive to exceed them. Don’t budget based on just meeting the requirement, but budget based on what you think is required for your organization to manage risk effectively. Yes, that’s risk, not compliance.

As an information security auditor and advisor, I have seen numerous organizations pour budget and resources into a compliance initiative and then literally stop everything after an audit has been conducted. By conveying the importance of building a program based on security that meets compliance, an organization will be better prepared to defend against breaches and satisfy its auditor at the same time.

Discover why security operations teams choose NetSPI.