Tag: PCI

This is often where an assessment starts going truly pear-shaped. Mostly because of assumptions, but a large chunk of what makes validation of compliance so difficult is the lack of mechanisms to make it anything other than a manual process. There is no requirement for automation in PCI, so going beyond the standard is very simple.

First, let’s start out with the worst assumption; that sampling is a right. It’s not, it’s a privilege, and one you have to earn. Until you can show your assessor that you have ALL of the following in place, sampling isn’t even an option:

  1. Formalised, and Robust Configuration Management – Unless you can show that you have a VERY good handle on configuring ‘like systems’ in an identical fashion, sampling cannot be performed. All web servers, app servers, DB servers etc must start out exactly the same. From installation from a known-good base image, to configuration of applications, to testing through change control prior to promotion into production, there is no room for ad hoc here.
    o
  2. Centralised Management and Maintenance –  You must be able to show your QSA that you have the ability to KEEP your like-systems identical, so if you have a centralised console where this can be displayed, so much the better. WSUS for Windows, or CiscoWorks for Cisco network devices for example, can centrally display pretty much all you need to know about the systems. OS, version, patches and so on.
    o
  3. Centralised Logging and Monitoring – An extension to management, log baselines, like-system thresholds, and incident response etc. must be centralised or every different monitoring process must be examined individually.

Of the three facets above, PCI does not require any of them to be centralised, not even logging, so if none of these things are in place, there is no sampling.

An operating system has 12 validation points (access control, password setting, logging and so), applications have 9, and a DB has 7. In theory, a single system could require 28 separate pieces of evidence to validate its compliance.

What if you had a 100 of these systems?

I have expounded many times the concept of security being simple, not easy, but simple. Well, there is no simple without centralisation, and it’s VERY difficult to achieve simple without some form of automation.

For PCI, a screen shot of the AV [for example] settings will suffice, but this can involved the collection of MANY screenshots. How much better to have a centralised management station that shows these settings against all systems in one place? The same applies to logging, access control mechanisms, FIM, running services / listening ports (i.e. configuration standards) and almost every other validation requirement at the system level.

In the hundreds of assessment with which I have in some way been involved, I would estimate that between 25% and 40% of an assessment’s effort is related to gathering of validation evidence. That’s in year one, it’s actually greater in subsequent years, but the effort to get to the point of validation SHOULD have been less.

But that’s really the point here, and the point of the SSC’s recent supplemental on staying compliant; if you treat validation of compliance as a project, you are wasting a significant amount of resources AND you are no closer to actually being secure.

Compliance requires no automation, but without it you have no continuous compliance validation. PCI requires no centralisation, but without that you simply cannot manage what you have efficiently and effectively.

Validation is easy when your security program is simple, because the management of your program is simple. Spending weeks collecting evidence for compliance could not be a more ridiculous use of your time.

Simple is cheaper, more efficient, easier to manage and measure, and above all, more secure. Validation of compliance falls out of the back of a security program done well, so work on that first.

 

 

[Apologies for the blank post yesterday, here is the real one]

The timing for this part of the Going Beyond the Standard series is almost perfect given the SSC’s release of their ‘Information Supplement: Third-Party Security Assurance‘. Which, despite it’s gratuitous use of the word ‘may’, and the ongoing generic-ness of the SSC supplements, is actually pretty good.

It has always irritated me that the phrase ‘third parties’ is now the established norm in these scenarios, when it’s actually SECOND parties that create the most challenges;

third party
[noun]
1. a person or group besides the two primarily involved in a situation

So third parties are the service providers that YOUR service provider hires to do [part of] the work for which you (the first party) hired the original provider. Third parties are fairly common, but not as common as second parties, and while third parties ARE an issue, they should be addressed in the same way as any other outsourced service; with proper due diligence.

Unfortunately, this due diligence is almost universally performed badly, or there would be no need for the SSC to issue an information supplement in the first place. Or course, if the requirements in the PCI DSS were written better perhaps there would be less confusion, but it’s too late now.

Because the supplement is quite good, I’ll not go into the nitty gritty of vendor management, but it is important to realise that the choice of an outsourced service does not start with vendor due diligence, it starts with a business need that has been PROPERLY analysed, and a risk assessment performed.

PCI itself has driven an enormous growth in outsourcing, and not because there was suddenly a need for more services, but because so many organisation wanted PCI to just go away. The thought was if you outsourced, you could just point at them and shirk all further responsibility.

In reality, you can outsource almost every function relevant to PCI, but you can NEVER outsource the responsibility for the protection of the cardholder data. Yes, you can throw financial liabilities into the contract, you can buy cyber-insurance, you can even drag your service provider down with you if things go horribly wrong, but it’s going to be YOUR name in the papers.

The other big mistake organisations make at the beginning phases of outsourcing is, as always, asking the wrong questions. While a service provider does not have to BE PCI compliant for the service they are providing, their services have to SUPPORT yours. Not only that, if they do not have a Report on Compliance backing up their services, they will have to be fully assessed and validated against yours.

I’ve had small clients whose PCI assessment costs and effort increased FIVE fold because they had not performed the correct due diligence.

Even if I assumed you are outsourcing for the right reasons, CHOOSING vendors is next step where things go wrong. DSS v3.0 has built in the requirement for  ‘third parties’ to qualify their services with detailed analysis of EXACTLY what is being provided against the requirements themselves. This was always a requirement in my mind, but rarely followed, and has led to significant gaps based on assumptions.

However, if if your chosen service provider is PCI compliant for the services, there is surprisingly little they can do in terms of reducing your effort;

1. DSS Requirement 1.x – You can outsource management, but you will always own the policies, the final configuration standard(s), and of course, the ruleset(s). About the only things that can be 100% outsourced is stageful packet inspection.

2. DSS Requirement 2.x – Again, you can have a service provider put together configuration standards for you, but you will always own them, the business justifications for every available service and listening port is yours to document, and insecure protocols are yours to fix or compensate for.

3. DSS Requirement 6.x – Outsourced development is great, but unless their SDLC supports your compliance, YOU won’t be.

4. DSS Requirement 10.x – The most egregiously overstated service provider coverage of them all. The issue is rarely in the collection of the events, it’s what events should be logged in the first place and how. And how ANY service provider dares to say they can cover a daily review without establishing a baseling is beyond me.

5. …and so on.

I’m already ay 700 words and I’ve barely starched the surface, but that should be an indication of just how messy this topic can be. It deserves a white paper, but that will have to wait.

Bottom line; If you don’t have a program for vendor selection and vendor management, get one, and make it retroactive. Get help if you need it, but in the end, if your service providers fail, YOU fail, and deservedly so.

Read the SSC supplement, implement what it says, they have not missed much.

First, you may be asking why this blog does not include Disaster Recovery (DR) and Business Continuity Management (BCM, which governs the entire IR / DR process). Because the PCI DSS section 12.10.x is almost entirely related to IR (with the exception of a VERY brief nod to DR / BCP, below in red), I will handle DR / BCP separately in the series (post 23 in fact).

“12.10.1 – Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:

    • Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum
    • Specific incident response procedures
    • Business recovery and continuity procedures [This is the only requirement in the DSS that goes beyond the protection of CHD.]
    • Data backup processes
    • Analysis of legal requirements for reporting compromises * Coverage and responses of all critical system components
    • Reference or inclusion of incident response procedures from the payment brands.“

With regard Incident Response, I put it this way; “What’s the point of being in business, if you don’t intend staying in business?”, and; “Good incident response is what prevents a security event from becoming a business crippling disaster.”

It makes absolutely no sense to me that organisations who basically depend on IT for significant chunks of income (which is most of them), have very little idea how to stop bad things from happening in the first place, let alone fix things when they go wrong. Of course, no incident response is going to predict an earthquake at the datacenter, but the organisations I’ve seen don’t even perform log monitoring properly, let alone consider the impact of acts of nature.

The development of a good incident response plan start with? Yep, a good policy, from there you agree on an appropriate Risk Assessment / Business Impact Analysis process, which in turn provides you everything you need to not only determine if you have any control gaps (after a gap analysis), but – if you’ve done it properly – a good indication of what your incident response and disaster recovery plans should entail.

There is no appropriate IR without an understanding of the business goals. If you have a 4 hour Recovery Time Objective (RTO), your IR will be significantly more robust than one where you can take a week to be back online. Yes, I know that RTOs (and RPOs (Recovery Point Objective for that matter) are DR terms, but if your incident response cannot detect a business crippling event in good time, then neither of those DR goals is an option for you.

When setting up your IR program, the most important word to keep in mind is ‘baseline’. Without a baseline, you don’t have much of a concept of what constitutes an incident in the first place. Only a baseline can give you both context and relevance.

From your baselined system configuration standards (DSS 2.x), to AV (DSS 5.x), to logging (DSS 10.x), to scanning (DSS 11.1.x, and 11.2.x), to FIM (DSS 11.5.x), you have many available inputs into your IR program, none of which will be of the slightest help if you don’t know what they SHOULD look like.

That’s all IR is;, a process whereby an exception to the norm is investigated, and appropriate action taken.

In each of my individual going-beyond-the-standard blogs related to the above DSS requirements, I have stressed the importance of baselining (well, except AV perhaps). The reason I did so was because they all lead up to this. I don’t care how well you have done ANY of the previous requirements, unless you can bring the outputs all together into a comprehensive process of taking action, all you have is a bunch of data to give to your forensics investigator.

You’ll notice though that I did not say a CENTRAL process, because while having a 24X7 Security Operations Centre t manage all of this, it’s rarely practical, even if it involves a outsourced managed service provider (MSP). However, having the correct assignments and procedures to MANAGE the response is of utmost importance, and the details of this plan will vary considerably from company to company.

No IR is not easy, but there is simply too much information and help out there for this difficulty to be any sort of excuse. And no, there is not much in this blog that actually provides guidance, but if this makes SENSE, then you at have at least got enough to begin to ask the right questions.

I don’t think anyone in the payments arena has any doubt that credit/debit cards, in their current form, will die over time in favour of mobile devices. It’s a natural next step to replace something ubiquitous with something even more ubiquitous.

So where does that leave the SSC, and the card schemes themselves for that matter?

You only have to look at Visa Europe’s website Visa Vision to see that they are moving towards mobile (and other innovations), and articles like The Revolution is Here, do not even mention EMV, and the only reference to plastic is in a future past-tense.

It also begs the question as to why the card schemes are pushing EMV when they themselves see an end to their reign-of-plastic. But the answer is obvious, the cost of fraud over the next 5 – 10 years far outweighs the cost of the transition. The US alone saw $7.1B in credit card fraud in 2013 (according to Business Insider), and I have estimated that the cost of EMV transition in the US is ‘only’ $12B (Why the US Will Not Adopt EMV (Chip & PIN), EMV in the US, a 12 BILLION Dollar Mistake).

So why am I so anti-EMV? Because there are technologies NOW that can replace it, are in more hands, and more widely distributed than cards ever were. Your mobile phones.

So back to my point; what WILL the cards brands and the SSC do once the plastic dies? Clearly the brands have an enormous leg-up on any new player in the cashless game, and have massive amounts of capital to invest in meeting every aspect of this [so-called] disruptive innovation; research on innovation, testing proofs-of-concept, garnering adoption within the finance community, and of course, rolling it out to end users.

Mobile phone companies made a small play, and missed, banks could have done it, and didn’t, and large retail could have had a huge impact, and haven’t. Probably because in these three case – even banks – payments is not a core function. Being PAID is core, making the payment is not, so only the card schemes have payments as their entire reason-to-be, and therefore the most motivation.

OK, so if we assume that the card schemes are going to make a huge play in every cashless payment innovation from this point forward, where does that leave the SSC? Probably in exactly the same place, with only one change in title; From Payment Card Industry Security Standards Council, to Payment Industry Security Standards Council.

Regardless of the form of payment there HAS to be a security standard around the protection of the data. Not that the current standards are anywhere near adequate, even for cardholder data, but the SSC has significant experience adopting and implementing standards globally. From mobile apps, to software PINs, to identity management (for KYC, AML etc.) to crypto-currencies, everyone developing technologies must adhere to a minimum set of protective baselines.

So am I really proposing, after so many less-than-positive blogs related to the PCI DSS and the SSC, that they be a standards body for every form of payment globally? Well, no, I’m not, but I think that if they don’t TRY to be just that (with the card brand’s backing), there is no-where else for them to go.

Despite my voluble criticisms of the card brands and the SSC alike, they ARE well placed to do good. I hope they take the opportunity now, because it won’t come again.

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

I really should give up being surprised when the most basic of information security fundamentals are performed poorly, but this one constantly amazes me. I guess it’s no different than a doctor being surprised at smokers, or the police surprised at repeat offenders, we can accept as common sense what others perceive as new concepts.

Education and Training is so important that I have listed it as one of The 4 Foundations of Security, along with Management Buy-In, Policies and Procedures, and Governance. The fact is that education is the best and cheapest way for an organisation to implement the desired organisational culture, and distribute the policies and procedures in a manner where they actually understood and followed.

The intent of PCI DSS Requirement 12.6.x is to ensure all employees are trained in their security responsibilities as they relate to the protection of cardholder data. That’s it, just cardholder data, so you can obviously ignore every other form of sensitive data in you environment, right? What about your financial data, or intellectual property, or personal data? Unfortunately you cannot go above and beyond in PCI unless it relates to the protection of cardholder data, so with the exception of perhaps frequency of training, there’s not a lot you can do here.

That’s for PCI though, for your BUSINESS it’s a very different matter, and there is a lot you can do to add true benefit across the organisation. Not just in terms of security either.

The mistake most organisations make is the assumption that security education and training only refers to things like keeping your passwords secret, or not lending out your swipe cards. Yes, training includes these things, but it starts with a thorough coverage of all relevant policies and procedures. I say relevant, because you’re not – for example – going to train your sale team on the proper implementation of firewall configuration standards.

Training is not just some paperwork exercise during on-boarding, then an annual obligation thereafter, it’s the way you bring someone into your organisation and have them up to speed and productive in the fastest time possible. It’s also how you begin to instil the corporate culture (i.e. your policies), and how you ensure that they are performing their duties in-line with standard practices (i.e. your procedures).

Once they have the basics, you can move on to role specific training, and then, if you’re REALLY doing this properly, you will have the individual job specifications detailed to the point where anyone being on-boarded can step straight into the leavers’ shoes with barely a backwards step.

That’s really the whole point; security awareness training is NOT just a compliance obligation, it’s an integral part of your business continuity and knowledge management processes. It can be the difference between a constant reinvention of the wheel every time you have a mover or leaver, and uninterrupted growth. You may argue that this is more than just security awareness education and training, but I will counter that without proper knowledge, there IS no security.

While I agree that every time there is a staff change, the training itself should be reviewed and revamped as appropriate (preferably by the person bringing the new pair of eyes to it), NO-ONE who is just starting should have to work out anything for themselves on how to perform the function to which they have been assigned. At least to a minimum standard. Unless of course it’s a brand new role, in which case they will be responsible to develop and document everything necessary to replace themselves in time.

Too often this is seen as making yourself replaceable, but if you can’t be replaced, how can you move up, or even across?

To perform security awareness and training properly, follow these steps:

1. Like access control, the best way to begin developing a good training program is to properly define the requirements, first at a ‘corporate’ level (everyone), then at a more granular ‘role’ level (sales, systems admins. etc.), and finally at an ‘individual’ level.

2. Once this matrix is complete, combine this ‘paperwork’ into an online delivery mechanism which is a combination Document Management System (DMS) and distribution method. That’s really all online training software is; content management.

3. Run everyone through the program, regardless of tenure, and regardless of when they last took it. Track all ‘signatures’ (an online ‘I Accept’ will suffice).

4. Run training again at a minimum annually, but preferably every 6 months. A good balance is full course annually, and Top 10 Things to Remember at the 6 month mark.

5. Throughout the year, use this distribution method to announce major changes to policies and procedures, as well as ‘zero day’ threats (new phishing techniques for example), for significant changes to relevant compliance regulations or laws, and any ad hoc matter for which you require – for liability purposes – a written confirmation of acceptance.

 6. Provide a robust feedback loop and standardised forms for all personnel to request policy / procedures changes, or to create new ones.

I’ve not touched here on the actual content of the security training, it’s too organisation / sector specific, but there are certainly some basics (101 stuff as the Americans would say). However, the development of a comprehensive and sustainable training program requires specialist skills and experience, so make the effort and expense, there’s not one investment you can make that has a greater ROI.