Author: David Froud

In my continuing struggle to prove once and for all that I am the saddest bastard alive, I have spent an inordinate amount of time performing a side-by-side comparison of the PCI DSS changes from v3.1 to v3.2.

Not just the DSS itself, oh no, that would be too simple and nowhere near as pathetic, I have actually taken the Report on Compliance Reporting Templates and compared them instead! All 1,359 lines of it! You can download my initial draft here: PCI DSS v3.1 – v3.2 Mapping of Changes_v160526

Impressed? No, me neither.

Self deprecating humour aside, I actually had a very good reason for this; Only the validation of compliance really matters, the standard itself is not where the rubber meets the road, the RoC Template is. Even the ‘Summary of Changes from PCI DSS Version 3.1 to 3.2‘ cannot match the level of detail you can obtain from comparing the individual ‘Report Findings’.

I have written frequently on the inadequacy of the PCI DSS, so what is my overall opinion of the changes to v3.2? Actually, they are not that bad. I’m not saying the standard is starting to look like real security, but as far as it CAN go, it’s heading on the right direction in terms of how to both validate and report compliance.

Aside from the new requirements (which I address below), to me the biggest change was the significant reduction in the number of Report Findings for which you need to “describe how”. The consolidation of these descriptions puts the onus back on the assessor to properly validate the requirement, instead of having to spell out everything they did to do so.

However, the issue I can see with constant change from version to version is that it becomes next to impossible to even partially automate validation in centralised tool-sets (like GRC) because the RoC Template still focuses more on WHAT is written than HOW to actually perform the validation itself.

So, to the significant changes for everyone:

  1. Requirement 3.3 – Not sure why anyone would want to see any of the ‘middle 6’ digits and not the full PAN, but this requirement now helps to clarify things for those who do. Basically, you need to put the same controls around the middle six as you would the full PAN.
    o
  2. Requirement 6.4.6 – It’s unfortunate that the SSC feels obligated to insist on validation that any changes to the CDE still conform to the PCI DSS, but it would not be have been added if organisations were actually doing it properly.
    o
  3. Requirement 8.3 – Change from 2-Factor Authentication (2FA) to Multi-Factor Authentication (MFA), and now EVERY form of administrative access to systems must be via MFA, not just remote access (this is by far the biggest ‘blanket’ change). This has always been a best practice as far as I’m concerned, and I’m glad that the SSC has finally written this into the standard. If this is difficult for an organisation, or something they want to avoid, I have to wonder what else they don’t have in place.

…and for the poor Service Providers who rightfully bear the brunt of the changes:

  1. Requirement 3.5.1 – SPs must now provide a ‘cryptographic architecture’, but it’s not clear if it’s only to be given to the the QSA validating the SP’s compliance, or if it’s for client consumption as well. Have to assume the former.
    o
  2. Requirement 10.8 – SPs must now detect and report on system failures. How this was not part of every organisation’s vendor due diligence process, and written into every SLA as a matter of course, is beyond me, but I know for a fact this stuff rarely is.
    o
  3. Requirement 11.3.4.1 – SPs must now perform semi-annual penetration testing on segmentation (if applicable). This should not be an issue for Cloud or VM providers IF, and ONLY if, they have configured their service correctly. However, this requirement does not cover those  SPs who have a bunch of servers on flat network and do not care about segmentation, which I would argue is far less secure.
    o
  4. Requirement 12.4 – Pushing SPs to make protection of CHD an Executive responsibility. Unless there are some kind of penalties attached, SPs will pay limited lip-service to this and just write some kind of charter or policy. Smoke and mirrors basically, but good for the SSC for even trying.
    o
  5. Requirement 12.11 – SPs must now perform QUARTERLY audits against several controls, which is a very good thing IF it’s done correctly. To perform this function well, SPs would need to institute some form of Internal Audit function, as well as a Governance-esque function to oversee it. Good luck with that.

So, overall, I’d say this was a pretty good change as the DSS goes, but with another 20 months until any of it is enforced, I sincerely doubt things will change for the better in the short-term.

 

 

In the digital age, the need to transform your business in the face of competition is only going to become more important, and more difficult. Start-ups can build all of this in from the beginning, and have a whole host of success and horror stories from which to choose their inspiration. Large organisations that have developed slowly over time do not have this luxury, but the fear of ‘disruption’ has them mad-scrambling looking for a way forward.

Increasingly, they are turning to Agile and Lean as ways to kickstart their business transformation efforts.

Let me be clear, I have nothing against either of these tools, but that is all they are; tools. They are a means to the end, not the end itself, and over-reliance ON the tools will eventually lead you astray. Unless the business goals drive the tool choice, and NEVER the other around, all the action items in the world won’t get you where you need to be.

This requires a Vision.

And not just one vision, you need a vision per department. There’s no point trying to promote change when your HR department still hires people in exactly the same way, and are looking for the exactly same ‘corporate fit’. What you’ve always had got you here, only something else will get you somewhere different.

IN security for example, an example of a vision statement goes something like; “We will provide world-class defence for all information assets to enable and optimise all corporate goals and exceed client expectations.”

There are millions of these vision STATEMENTS out there, but three things that a lot of organisation who tout them seem to lack are; a) an understanding of what “defence for information assets” actually entails, b) what the most important things are to the foundation of such an effort, and c) the ability to execute that plan at the right level.

For example; Everyone who’s been in security for more than 5 minutes should know that without a policy framework, you have nothing to build your security program on. You then work out very quickly that any policy framework not signed and evangelised from the highest levels of an organisation will be basically ignored. An information security policy framework (ISPF) signed by the CSO is unlikely to followed wholeheartedly by the the other C-levels, an ISPF signed by the CEO will.

Quick Advice: If you’re a security expert, never work for someone who is not prepared to at least ask the CEO to sign something, especially policies, it’s just not worth it.

It is very easy to bandy words like Agile and Lean around, especially if you’re the one doing the delegating, but it’s very difficult to LEAD a team when you yourself either haven’t defined what your vision looks like, or worse, you don’t have one and you simply regurgitate things you’ve just read in a book.

Frantic energy expended on a series of action items [Agile] assigned to a few key people [Lean] is one thing, doing this with a vision of what SHOULD be is quite another.

First, I have only been ‘doing’ Agile stuff for a little over 2 weeks, so this will be less about project management and more about how achieving PCI compliance should be done. Or or this case, could be done …potentially …unless I’m completely off the mark.

Like any project, PCI is just a whole bunch of action items, assigned to an individual, with a due date. That’s it. Unlike frameworks such as ISO 27001, PCI is written down for you, so it makes sense that a methodology like Agile would be well suited to keep a PCI project moving.

The reason that PCI compliance is so difficult for a lot of organisations, is that regardless of the seeming simplicity, determining what those actions ARE, or which to start first, or even knowing when to stop, can be more of an art form that a science. This is why there are so few good QSAs, as they are the ones who are supposed to be providing the guidance on every question you may have, even before you know enough to ask them.

We’ll leave, budget, resources, and having having management who give a crap aside.

So, if you agree that because the DSS is written down for you that you can determine the list of action items required to validate compliance WELL before you begin, then my theory makes a little more sense.

For example; for every operating system you have, the DSS requirements and the actions items are very clear:

  1. Requirement 2: Have a configuration standard, show evidence that your systems follow it
  2. Requirement 5: Have AV, show evidence that it’s running, or have a compensating control
  3. Requirement 6: Document your vulnerability management process, show evidence that your servers are patched accordingly
  4. Requirement 7: Have some form of LDAP, show evidence that access control lists are enforced accordingly
  5. Requirement 8: Extension of Req 7., show authentication and ID management are enforced
  6. Requirement 10: Turn logging on, demonstrate that your SIEM is reacting accordingly, and that all times are synched
  7. Requirement 11: Have FIM, show that’s running

So for an Agile project, you just create a series of issues in the backlog that correspond to the above, and duplicate EVERY issue for all subsequent operating systems in your environment. Simple huh?

And you don’t need a dedicated project manager, just a scrum master who can run all of the daily stand-ups and bi-weekly / monthly sprints. Of course, getting all of the action items right will take a significant PCI expertise, but once this is done for your environment, there’s really no excuse for a stalled project.

The benefits seem to be;

  1. The level of effort required to achieve compliance is obvious very quickly, so resources can be applied in the most efficient manner
  2. Those not pulling their weight become obvious to everyone from the very first sprint, and a determination of anything from individual employee overload to utter incompetence can be determined
  3. You have to think about PCI in the only way that makes sense, and keeps things moving forward; bite-sized chunks of action items
  4. Workloads can be spread around, with current print tasks reassigned to those with more available time
  5. The process becomes repeatable when every action is recorded during the project’s lifecycle.

Anyone who’s ever seen a PCI project drag on for years, or had people on whom you were dependant make excuse after excuse for months on end, something like Agile could be the edge you’re looking for.

Unless I’ve completely missed the point.

Internal Audit.

It’s right up there with Traffic Wardens, Used Car Salesman, and Lawyers, isn’t it? You get a phone call from Internal Audit (IA) and it feels like you’ve just been sent to the Head Master’s office!

But why? If you have been doing everything right, following appropriate policies and procedures, have ACTUALLY read the Acceptable Use / Code of Conduct, why would this be any different? I mean, even SECURITY winces at IA, and we’re total pariahs ourselves!

This is unfortunate, because like it or not, every department needs someone to provide checks and balances. Someone who can look at everything with a fresh and objective pair of eyes, someone not answerable to YOUR boss so can tell them how it is without repercussions, someone who can suggest changes that you know should happen, but fear / politics prevents you from saying anything.

Take your pick, regardless of how you view IA, they, like InfoSec, are an necessary evil in a world where both the threat and regulatory landscapes are spinning out of control.

Best practice frameworks like ISO 27001 call for Internal Audit by name, and an ever increasing number of regulators are requiring  evidence FROM IA processes so that organizations demonstrate that they are actually complying with their own policies. This should not be a hardship, if your corporate security culture was adequate, this would not be an issue. Look to the senior leadership, it they don’t care, no-one else will.

I have stated over and over again that if you were doing security properly, EVERY compliance regulation on the planet would fall out the back-end (plus or minus some customised reporting). Not one has ever, and likely WILL never go above industry accepted best practices, as no-one is looking for perfection, just risk-reduction enough.

It makes perfect sense to me therefore that you would put a watcher on the watchers. Security have their fingers in almost every business pie, just to make sure that proper security controls are built in from the beginning. Like Legal, security is there to save the business from itself, and done properly, it should NEVER get in the way.

This can lead to a certain complaisance, or blinkered view of the world, IA can provide the necessary perspective to continually test processes that that could potentially stagnate if not seen through an objective lens. And who knows, because IA generally have direct (if dotted line) access senior leadership, there is a very good chance your requests for budget/resources will be looked on favorably if supported by an entity mostly immune from repercussions.

In this context therefore, Internal Audit is the conscience of Security; Are the controls enough?; Are they too much?; Are they easily measured?; are they flexible enough to adapt to business goals?; etc…

From the very first policy draft, to the almost ubiquitous Plan, Do, Check, Act of ISO 2700X, security professionals need to look to IA for support and guidance, but the opposite is equally true. IA can tend to rely on their unassailable positions to hide behind lack of expertise in security subject matter, they need to work just as closely with security to make sure they are up to the task.

In all my years performing security assessments, and even providing my own policy and procedure service, somehow I have completely missed out on HOW to actually manage the polices, standards and procedures. Yet I have harped on about them incessantly.

Yes, I have mention a Document Management System (DMS) as a way of controlling and distributing documents, but I had never really given thought as to how you would go about maintaining a library of documents that almost all organisation collect over time.

It may not sound like an important subject, until you realise that no policy, standard, or procedure means anything unless it’s the RIGHT one. Is the procedure you’re working from the latest version? Are you in violation of a policy that can lead to you getting fired because you’re looking at a printed copy from 2014? Are you holding your vendors accountable to SLAs in the latest contract?

The first thing I have noticed is that it’s incredible easy to over-complicate the whole thing to the point it’s unsustainable. It must be intuitive for anyone to follow, and it must be easy to manage, or like everything else in security, it will be bypassed.

I would love to hear from true expert on how this is done, but for now, he is what I think is best:

  1. Document Numbering: Have enough information that you know at a glance what the document is, but not so much that it’s 100 characters long. For example;

    * First 2 characters is the company name, or a designation of external (e.g. CN, or EX)
    * Second 2 characters is the document type (e.g. PO = Policy, PR = Procedure etc.)
    * Third 2 characters is the applicable region (e.g. GL = Global, GB = United Kingdom, etc.)
    * Fourth 2 characters is the applicable department (e.g. XX = All departments, LG = Legal, SE = Security etc.)
    * Last 4 characters is the unique number (e.g. 0000 – 9999)

  2. Revision Number:  rX.0 for major release, and rX.1 for a minor release. So the first draft would be r1.0, a slight change would be r1.1, and a complete rewrite would be r2.0 and so on.
  3. Friendly Name: What’s the document title? e.g. “Access Control Policy”
  4. Document Status: One of only 3 things; DRAFT, RELEASED, or OBSOLETE, all self-explanatory

So, for Acme Rockets Ltd., a first draft of a global legal policy on access control would be; ‘AR-PO-GL-LE-0001-r0.1 – Access Control Policy-DRAFT‘, or a rewrite of a vendor contract related to  a firewall managed service procedure specific to the UK would be; ‘EX-PR-GB-SE-0003-r2.0 – Firewall Managed Service Procedure-RELEASED‘

Assuming I haven’t completely lost you, the next step is to work out how to get them into a centralised and access controlled library to which EVERYONE who needs access, has it. Every RELEASED version of the entire policy and procedure set needs to be online and the location of it familiar to the entire company. No printed version can ever be trusted unless the number, name, and status matches (these should be printed in the document header).

Finally, and here’s the real kicker; EVERY document in use in the organisation needs to be entered into a Master Documents Record (MDR) of some sort, and maintained to an extremely high degree of integrity. In theory you could use your Intranet or SharePoint for the central location and an Excel spreadsheet for your MDR, but best of luck keeping that up to date in a large org.

So, am I, David Froud, actually suggesting that larger organisations buy technology to solve a business problem despite my constant warnings not to do so?

Yes, yes I am.