Maybe it’s the excitement of getting re-Tweeted today, or maybe it’s just the outpouring of love and emotion I felt when I watched the video of the Mike+Josh hug, but I thought I’d provide a bit more thought around how to build these Control Objectives for PCI. That and the fact that I live by the motto of taking “Massive Action” whenever I sink my teeth into something…
My intent is to demonstrate three things:
a) Control Objectives can be linked to a business objective or goal
b) Prescriptive Controls can be abstracted to Control Objectives (with some effort)
c) There can be rational behind both Control Objectives and Prescriptive Controls that once explained can result in better management support, and potentially more creative design.
My objective is not to co-opt this discussion, but rather to feed the debate with ideas. It’s great to see this level of thought being spread in InfoSec, since I too often have listened to the bits and bytes battle in the boardroom, and that situation doesn’t end well. If we can create meaningful discussions around the end goals and spread the knowledge top-to-bottom, we can begin to socialize the objectives of PCI so that ideas can come not just from technologists and (shudder) vendors alone, but actually come from a much broader spectrum – which leads ultimately to greater support and buy-in at executive levels.
The Guinea Pig Control
I’d like to take a simple example since it is very fresh in my mind, and it allows me to demonstrate the technique. Let’s look at PCI Requirement 8.5.16. This control is oddly grouped with other 8.5.x requirements but create a pretty significant challenge for many organizations I’ve talked to.
8.5.16 “Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users. Restrict all direct access or queries to database to database administrators.”
Now in the PCIHugItOut they mentioned the document “Navigating the PCI DSS” document from the PCI SSC as a starting point, but rightfully point out that it doesn’t go far enough. The Guidance from the document states:
“Without user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except DBAs, who can have direct access to the database for their administrative duties.”
Unfortunately the statement is not particularly “guiding”. As a technologist you might look at it and say it is a great guiding statement. What you are doing is applying a priori assumptions about logging user access when theft occurs or for the purposes of forensics or theory about limitations of database select statements. What you are also doing is sidestepping the problem – management lacks that cognitive awareness, and it is highly unlikely they will care to invest their grey matter in changing that situation. Your assumptions will be left trampled in the boardroom floor. Trust me when I say that this one small control can create a firestorm when users (marketing, finance) are told that they cannot run their Crystal Reports or ODBC queries against their database that just happens to contain Payment Card Data.
The Control Objective Example
So let us give these people a reason why they can’t delve into the database ad-hoc. I am going to assume the same model that I have used for years when building SOX Control Matrices:
Threat: Theft of Payment Card Data
Vulnerability: Lack of controls that limit the ability of users to collect/transfer/misappropriate Payment Card Data from locations where it is appropriately (securely) stored.
Risk: Users may collect Payment Card Data from secured repositories (either one-by-one, or in significant quantities) and either (a) store it on insecure systems which exposes it to inappropriate activity, or (b) misappropriate the Payment Card Data it for nefarious purposes.
Outcome for the Business: if Payment Card Data is placed on unsecured systems, it increases the risk posture to the company, by creating in un-mitigated risk. Any compromise of this mismanaged data must be reported publicly (most state/local privacy disclosure laws) and can result in fines, and the company being on the evening news (or daily podcast for the technologically evolving masses). Because this “uncontrolled data” now becomes virtually impossible to manage and track, the likelihood that it is misplaced, and the company must report it publicly rises exponentially. Focus is not just on unauthorized data but data that is also accidentally misplaced (example – TSA laptop with personal information that created a stir when it couldn’t be found and the loss had to be disclosed by law).
Control Objective: Ensure that the ability to transfer Payment Card Data from databases is appropriately controlled in a manner that prevents the transfer of such Payment Card Data to unapproved and unsecured locations or environments.
Now, given this control objective companies could have the choice to either:
(A) Follow to the letter of the law DSS Requirement 8.5.16 (although this is a slightly less prescriptive control than others in the DSS).
(B) Present to the QSA the manner in which you feel you have met the Control Objective in a manner that achieves the same goal (to give you an idea – perhaps row level ACL’s that prevent access to actual PAN data by anyone who can log in directly, or tokenizing databases that users directly access, or completely eliminating the ability to store the data locally by using a terminal server for producing these types of reports or data).
The Outcome
What this has done is given a business view (Outcome for the Business) that most executives can understand. You might need to give some real-life examples from their personal lives to make it meaningful and associate it with concepts that are in their cognitive realm (have them think of handing out their credit cards to their kids, or car keys to a valet and the resulting risk they know exists for those “assets” to be misplaced when they are in someone else’s hands). You have also give an implementer a framework to evaluate how a control should fit, and decide if the PCI prescriptive controls are satisfactory for him. The implementer will have to justify to his management his choice of alternative controls, and depending upon his savvy or guile, he will either succeed in alternate (more effective, more efficient) controls, or he will find himself forced into the default PCI prescriptive control.
The Challenges in All of This
There are a few challenges here that we must face as well. Some can be easily overcome, but others will be subject to massive forces of economics and politics.
First, the Control Objectives will overlap with the prescriptive controls of the DSS. The example shown above overlays with 12.3.10, “personnel accessing cardholder data via remote access technologies”. This isn’t a problem for those of us who have played with Control Matrices for some time, so this can be easily overcome with good minds, careful thought and creative mapping.
Second challenge is that most companies and QSA’s will view this as a troublesome approach. The process proposed is no different than the current process of “mitigating controls” but this process currently has a culture around it of being discouraged. The cause for this is, in my mind, because it results in more work for the QSA’s. With QSA services becoming a commodity these days, it isn’t attractive to customers looking to save money on their assessment. Likewise QSA’s trying to increase profits will not likely steer from what will give them a price advantage when they can test against prescriptive controls. Like all good plans both parties will digress into the world of loopholes and exemptions to satisfy their own motivations. I don’t have a good plan for this except perhaps my original idea of encouragement and reward for maturity by the Card Brands which can potentially raise the interest of management.
Thirdly, there will be a challenge with the inevitable question or view “well, it hasn’t happened to us”, “how real is that”, “well TJMAXX did just fine after their break-in” (which from a shareholder point of view is actually pretty accurate). I love this one since I have faced it – especially a CEO who challenged me on TJMAXX’s stock price a year after the infamous break-in. My response is calculated but the same.
“We are discussing a balance between risks which could impact your company (paying $250M in fines which no CEO wants to shell out, no matter how much his stock price might stabilize or grow) and functionality which your users need to grow the company. If you will provide us with the support, we will design a set of controls that will achieve a balance between the two that we believe both sides will be happy with.”
Please note no effluence of FUD, no criticism of user’s desires or business goals. Just a confident statement that there is a need to balance the two demands, and to come up with a solution that works for both. Now, you just have to deliver on that promise…
