Open Mobile Menu


Filed In: InfoSec, PCI DSS, Risk and Compliance, Security

Risk And Compliance: Check Your Blind Spots

Views: 3606

Written By: Tony Fulda February 04, 2015

As a QSA company with deep experience in assessing and interpreting the PCI Data Security Standard, we get front row seats and season tickets to the data security show.  We constantly see the good and bad sides of how compliance and security work (or don’t work) together, and the pros and cons of following a compliance vs. risk-based approach to securing systems and data.

As consultants and auditors, we often see organizations using annual compliance as a penultimate goal with no context for understanding how risk fits into their information security landscape.  The following observations outline a few of the problems we see when an organization follows a “compliance-centric” mindset:

Chasing after compliance can be ineffective (and expensive):  Organizations with tunnel vision related to compliance often focus more on implementing controls to check a box than real-world security issues or the return on IT investments. The organization who just wants to check the ‘yes’ box often ends up throwing money at a silver bullet application/GRC tool/magic security appliance/service provider that could be much more effectively spent in improving their overall InfoSec program.  Rigidly adhering to a framework without identification and analysis of real-world risk all but guarantees an organization will allocate IT resources ineffectively and increase effort and cost with no real benefit to security.  Use a risk assessment to determine the real cost and security benefits offered by any tool or solution.

Frameworks such as PCI are not meant to serve as an effective risk indicator: Following a prescriptive/binary model encourages assigning an equal rank to all controls and security projects - I’m going out on a limb here, but I’m going to say that having secure baseline configuration standards, a strong vulnerability management program, and a process to encrypt sensitive data should rank as a higher priority than writing The World’s Best Network Time Protocol PolicyTM.  Recognize frameworks for what they are: a collection of best practices and a minimum set of controls that need to be met that shouldn’t be confused with a security strategy.

An audit reflects a point in time, and many organizations are just trying to “get it over with”: We often see companies who use compliance instead of security as their primary driver wait until the last minute to assess security controls and then have to play catch up right before an annual audit; it’s pretty hard to pull off 4 quarterly vulnerability scans in the same month.  While the current DSS talks about ongoing compliance in the “Business as Usual” section of the Executive Summary, this language is provided as guidance and best-practice.  If your organization can’t legitimately track and generate evidence showing that daily, weekly, monthly, quarterly, bi-annual, and annual requirements are being followed consistently then security is not “Business as Usual”.  Find opportunities to operationalize the good parts of the Standard, and try not to treat compliance as an onerous once-per-year cram session.

Cherry picking QSAs based on cost or the guarantee of compliance doesn’t improve your security:  There are many QSA firms that cater to the “get-compliant-in-24-hours-or-triple-your-money-back” service model.  Checkbox firms have commoditized the compliance space and push legitimate security-focused QSA companies to cut corners to win business in a race to the bottom. 

While there has been a significant effort to standardize and elevate the QSA program through improved training and guidance, there are still plenty of checkbox auditors with no real-world experience who are technically “qualified” to sign off on an organization’s compliance and security posture.  I promise you, inexperienced QSAs are not fun to work with and will make your job even harder in the long run as they miss obvious issues or adamantly enforce a made up requirement. 

True story: I recently talked to a company whose previous QSA (bet you can guess which firm) spent 4 hours onsite their first year of a Report on Compliance audit for validation activities. That’s right, 4 whole hours.  The next year, the same auditor was onsite for 30 minutes.

Pro tip: If your ROC audit takes less time than an oil change your assessor might be missing something that hackers won’t.  Look out for your shareholders/customers/employees and find internal and external security staff and vendors who take security/risk seriously and aren’t just phoning it in. Look for security companies with experience assessing your type of environment, and realize that cheapest usually doesn’t equate to “best”.

Just checking boxes only improves your box checking skills: Organizations that blindly check boxes during their self-assessment or cherry pick QSAs are likely to just say “yes” to ambiguous requirements and ignore the intent in order to get a “gold star” on their paper.  Without understanding the intent and context of a control you can’t understand the associated risk of an incorrect implementation. In far too many cases we see organizations wasting money on unused/mismanaged “solutions” and tools just so that they can check an “in-place” box, or wasting effort on processes that don’t actually meet a requirement.  In the worst cases, some organizations just check the box (or hire someone else to) because it’s easy.

Compliance frameworks are not always comprehensive or relevant to the threat landscape: The DSS is fairly static and slow to evolve (a new version is released every three years), and doesn’t always address emerging threats – as an example, BlackPOS, vSkimmer, and similar memory malware have been a painfully successful attack vector for several years yet are still not addressed in the new DSS outside of now requiring developers to “understand” how data is stored in memory (extra bad news: this only applies to internally-developed applications and doesn’t address commercial point of sale solutions).  There are always gaps between actual security and any compliance framework that need to be identified and understood before you can protect assets and data in an intelligent, cost effective manner.

Take a close look at your current processes and controls and make a resolution to perform a comprehensive risk-based assessment of your security program above and beyond what is required for any regulatory or compliance framework. Consider expanding your assessment approach to include multiple control frameworks in order to evaluate asset values and risk, and be aware of how easy it is to get a case of tunnel vision while chasing only compliance. 

A good assessment should take the entirety of the risk environment into consideration (think about supporting systems, vendor management, emerging malware, etc.) and not focus narrowly on one type of data, environment, or system.  Bottom line: Use compliance to steer your IT direction, but always check your blind spots.

Tony Fulda

Tony Fulda has over fifteen years of information technology, information system security and technology training experience, performing technical and enterprise risk assessments and consulting for clients in the higher education, hospitality, healthcare, service provider, and retail industries. As AppSec Consulting’s Managing Director of Strategic Advisory Services, Tony is responsible for driving the strategic direction of the assessment team and ensuring that AppSec Consulting’s clients receive exceptional service and maximum return on investment.

Tony has assisted hundreds of clients achieve their security and compliance goals through scope reduction, process improvement, and strategic technology integration.  He has led or participated in a multitude of remediation projects and has performed US-based and International Level 1 Report on Compliance audits for some of the largest organizations in the world.

read more articles by Tony Fulda