Tag: Continuous Compliance

Just about everyone who writes on information security has had ample blodder from the Target / Neiman Marcus et al breaches, myself included. Some blame the PCI standards or the card brands themselves, some blame the retailers for not doing enough, and those that are a little more charitable, just blame the thieves.

In the end, it’s not about blame, it’s about learning the lesson, making the necessary adjustments, and moving on responsibly. Unfortunately, this will NOT include being able to move on from credit cards or from the PCI DSS v3.0 any time soon, so organisations wanting to avoid becoming the next Target (excuse the pun), had better pay more attention to their enterprise-wide security program, not just their annual compliance ‘projects’.

Just as importantly, they need to pay VERY close attention to innovation in the payment / authentication space, and advances in more real-time security measures / technologies.

Nothing in the PCI DSS is anything other than a bare minimum, and represents enough security for the card brands to say they are doing what they can. But any organisation who thinks this is enough will eventually lose data, and I for one have no sympathy.

You can look at every single requirement and come up with two choices: 1) Good enough for PCI, and 2) Appropriate for the business. 9 times out of 10, the second option is more difficult to implement, but in almost every instance, it is both easier to maintain, and more secure.

For example;

PCI DSS Requirements 1.X are all about networking, firewalls, segmentation and the like, and while it does stress that every service/protocol/port must have a business justification, it does not state specifically that every individual in-scope device must have least-privilege inbound and outbound rules applied.

  1. 1.1.6.a – Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each
  2. 1.2.1.a – Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.
  3. 1.2.1.b – Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Yes, we can imply it means each device (especially 1.2.1.b), and yes, it’s the right thing to do, but no QSA can enforce anything that is not specifically written within the standard. If they had just replaced “the cardholder data environment” with “each in-scope system” DSS Section 1 would be VERY different, and instil a significantly better security posture.

However, if they DID change it to least privilege for every device, is it actually possible to implement and maintain it? Same goes for more robust configuration standards (DSS Section 2), or real-time logging (DSS Section 10), what should be done is very different from what the DSS requires.

In answer to the question, yes, it is possible, and it all boils down to one thing; baselines

Security is not about crunching big data to determine patterns, that’s only truly relevant in forensics when it’s already too late. Real security is knowing exactly what something SHOULD look like performing normally, and reporting everything outside of that. Keep it simple, or it cannot be monitored, maintained, or measured, but the PCI DSS can never go this far.

Hypothetical: If you knew every running service, listening port, and permitted connections each in-scope device should maintain to perform its function, then anything NOT those things should be investigated. That’s a baseline. Security would dictate that you have alerts based on these anomalies for all systems, not a sample of them and certainly not once a year (point-in-time).

How difficult would it be to automate this process so that EVERY system (not just PCI ones) reports back on a daily/weekly/monthly – or ANY period of time less tun a year! – basis to a centralised management console to perform the baseline comparisons? Then what’s to stop you comparing the device’s listening ports to firewall rule sets to make sure they are properly defined? Or comparing them against enterprise policies and standards, or known business data flows?

Not one organisation or security vendor is doing this properly, at least not that I have seen, or not yet. Some vendors do bits of this, but the last thing you want to do is patch together a bunch of separate, non-integrated systems, as the effort to do so will usually outweigh the risk mitigation, or the cost-to-benefit ratio.

However, none of this can happen until you have centralised and accurate asset management, and seeing as the PCI DSS just added that as a requirement in v3.0, most organisations have a long way to go before they can ever achieve this ultimate in security; continuous compliance validation.

Truth be told, this post could be titled; ‘The Top Roadblock to Compliance, and The Other 9 That Result From It”, but per the excellent advice from a blogger far better than I “You can’t [stop readers cold] if you use cute, clever or confusing headlines.” I’m keeping it simple.

So what is this offending roadblock?

1. Lack of Management Buy-In

Sounds simple, in fact, it sounds like a cliche, and above all, it does not sound anywhere near as important as I’m making it out to be. But let me ask you this; If your manager doesn’t care about something, how much do YOU care about it?

Now extrapolate that from the CEO all the way down and you get something like this;

Management

If the CEO makes it clear that they don’t care about PCI, how much traction do you think achieving compliance is going to get? The project gets handed to the IT Manager (because it’s clearly an IT problem not a business one, right?), and PCI will receive no attention, very limited budget, and no respect.

That is, until they get breached and fined for the equivalent of gross negligence, and then the IT Manager gets blamed for slacking. Sounds familiar?

The CEO, as well as senior management, control the culture, and that culture had better include the importance of cybersecurity.

Let’s be very clear; The CEO sets the tone for the entire company; its vision, its values, its direction, and its priorities. If the organisation fails to achieve PCI compliance, it’s the CEOs fault, and no-one else’s.

And now for the other 9…

2. No Perceived Return on Investment (ROI)

While very closely tied to the 1st reason, this is distinct because it’s clear that few have accepted that there are actually benefits of PCI compliance (see Why PCI Isn’t ALL Bad). So even if the CEO does pretend to care, few will get behind the process in any meaningful way. Nor will they bother trying to fit PCI into their existing security program, which is the only way it makes sense.

3. No Dedicated PCI Project Manager

PCI compliance, like all security, is eventually a process, but achieving it for the first time should be a project with a dedicated internal resource. Ideally, that resource has nothing else to do except PCI, but that’s rarely practical. So until compliance is achieved, they will need considerable support from management, and some of their more mundane duties re-distributed.

4. Choosing the Wrong QSA 

Per my white paper on Selecting the Right QSA for Your Business, the choice of an assessor is extremely important. The right one can help you deal with almost all of these roadblocks, the wrong QSA may be the roadblock. It’s probably in your best interests to bring a security expert in first to prepare your security program and infrastructure for the QSAs visit. At the same time helping you to make not only PCI, but your entire security programme sustainable – and just as importantly – cost effective. And above all, appropriate to the value of the data to your business.

5. Thinking Policies & Procedures are Just Paperwork

Odd as it sounds, without solid documented and enforced policies, standards and procedures (Policy Set), there is no real way you can have the culture of security necessary to achieve the company wide backing necessary to run an effective PCI project. The Policy Set is a corner-stone of your security program and should received its due.

6. No Standardisation

This is a very broad subject, and includes configuration standards, change control, monitoring, patch management, the SDLC, vulnerability management etc. The PCI DSS allows sampling of systems during validation, but this must be earned. Without standardisation, there can be no sampling as there are no systems created and maintained identically.

7. No Centralisation

How organisations manage often hundreds of devices without some form of centralised management is beyond me. I have to assume it’s not done well. The QSA also has a very hard time granting the privilege of sampling if you cannot show centrally HOW you keep the systems the same. There are plenty of tools out there, and the benefits of them go way beyond PCI compliance.

8. Not Knowing Where to Start

At first this may seem obvious, and perhaps a little redundant, but bear with me. I have had a lot of experience with this little roadblock, so I know just how difficult it can be to overcome. The answer – as it was for me – is simple; Ask someone. Your QSA should be able to take you all the way through this process relatively seamlessly, but if you don’t have one yet, ask someone who has already achieved compliance for their organisation. I personally know dozens of people who are more than happy to spend time with PCI novices and share their experience and guidance. This is one of the easiest roadblocks to overcome if you keep your ego or shyness out of play.

9. “But we’ve always done it this way!”

Perhaps the most irritating phrase in the English language – with the possible exception of “What are you thinking?”, especially for a consultant. The business wants things to stay the same, they want the same access they’ve always had, and they want the same data. The fact remains that the vast majority of business processes have very short shelf-lives, so they should be reviewed regularly, and access to in-scope systems or data justified. I’ve found that adding PCI compliance expenses to their cost centres tends to get their attention.

10. No Budget

Not much you can do about this one, but it’s certainly worth trying to re-iterate that the security controls should be in place anyway, and that they fall firmly in the good practices introduced in my The 6 Security Core Concepts.

I didn’t know how to blog until I asked my wife, and I have no idea how to read legal-ese so I ask my Sister. If you want to be PCI complaint, or even better, be secure AND PCI compliant, ask someone who’s done it.

[If you liked this article, please share! Want more like it, subscribe!]

As you probably know, the PCI DSS is a minimum set of security controls that must be in place around anything that transmits, stores, or processes cardholder data. That’s probably why the card brands and the SSC get so irritated that even this basic set of good practices is so hard to achieve.

That said, unless you have a way of monitoring and maintaining your compliance within these baselines, it’s not only VERY difficult to stay compliant (let alone secure), it makes validation of your compliance an annual nightmare of gathering screenshots, log samples, and so on. I estimated that validation of controls can take up to 50% of the entire annual assessment cycle.

This is a tremendous loss of resource time, and does nothing for your ROI. So why DOES the PCI DSS only require an annual point-in-time validation and not validation of continuous compliance? Yes, you are accountable to stay compliant at all times, but you only have to validate it once a year, and – if you’ve earned it – on only a sample of your systems.

The answer is, they simply cannot go that far. Continuous compliance validation is far more difficult than achieving PCI compliance, and is firmly in the realms of good security practices. They can enforce minimums, they cannot enforce more than that and get the necessary acceptance.

So what IS Continuous Compliance Validation? “It is the near real-time notification of a variation from your baseline norms.” Or to put it another way; once you know what something should look like all day every day, you want to know if it changes from that.

For example, the PCI DSS specifies over 20 validation points for an operating system; e.g. business justification for all listening ports; access control; logging; FIM and so on. Once a year, you have to show your assessor that these validation points meet the DSS requirements, and that’s it for the YEAR! All too often, systems fall out of compliance within a matter of days.

Instead, what I propose, is that you should automate (as much as possible) the collection of that validation data, and compare it to not only the PCI DSS requirement minimums, but to ALL of your compliance / regulation / internal policies / standards. And not yearly, but hourly, daily, weekly, whatever makes sense. Wouldn’t you rather show your assessor a green checkmark for ALL of your systems than a dozen screenshots for a mere sample?

If this can be configured for just 50% of your in-scope devices, your entire annual validation burden will be enormously reduced. Plus, you also have a very convincing addition to your compensating controls for lack of FIM or AV (if applicable).

Best of all, you are now doing security as it was meant to be done; Enterprise wide, and Business As Usual.

Any operating system experts out there want to help me put this together?

[If you liked this article, please share! Want more like it, subscribe!]