Category: PCI

The physical security requirements of the PCI DSS are by far the easiest to meet to the letter, but even these cause an inordinate amount of pain. This pain is rarely caused by the requirements themselves, but by the interpretation of them.

For example, if you were in-scope for the physical aspects, and I was to ask you if you HAD to have cameras to achieve PCI compliance, what would you say?

I you said something like “Not necessarily.”, “That depends.” or even a simple “No.”, you are correct. And if you don’t agree with that, just read the DSS;

“9.1.1 Use video cameras and/or access control mechanisms to monitor individual physical access to sensitive areas.”

I’ve used the word ‘intent’ many times in my blogs about PCI, because the intent of a requirement is always more important than the words written. Unfortunately, a lot of my clients, or even their QSAs, don’t even read the words, let alone interpret the language into something the business side can understand.

The intent of the physical requirements is that you restrict access to only those who need it, and that you keep record of who was where, when. That’s it, and if THIS is too much, you have more problems than PCI.

Above and beyond is very simple, but there are too many options to go into here. Decide via your risk assessment process what is appropriate, get the relevant guidance if you don’t have it in-house and stick with that.

For back-ups, this is just as simple, and the requirements are written down for you. However, there are some gotchas that I will address here;

1. “9.6.1 Classify media so the sensitivity of the data can be determined.” does NOT mean that you have to LABEL the media AS sensitive, it just means that you have to have a way of distinguishing the media that may contain sensitive data so that you can protect it accordingly.

2. If you do have physical media that contains cardholder data, the decryption keys are not included, and the offsite facility has no means to GET access to the decrypt function, this media can be reasonably classified as out-of-scope for the same reasons P2PE is a de-scoping option for retail.

3.  Far more prevalent these days is some form of network access storage (NAS) where the data is ‘striped’ across many disks. From my perspective, because the theft of any one (or even several) disks does not constitute the theft of reconstitutable cardholder data, only the management station used to control the access to the data and NAS functions is relevant. Here all PCI controls relevant to a server would apply.

4. You must make sure you have a well defined Data Classification Policy or the data retention and destruction requirements have no context, and cannot be properly validated. You will probably end with a ton of data you don’t need and your overall risk will steadily increase over time.

5. Go back over all of your business processes that could have ever resulted in the retention of cardholder data and deal with the resulting media accordingly. This includes paper.

Finally, the new-to-v3.0 requirements for the protection of “devices that capture payment card data” (DSS Reqs. 9.9.X). Bottom line; if you don’t have this stuff in place already, I can’t help you, and you may want to consider alternate employment options.

Not much more to say here, but I don’t want to underplay this too much and make the mistake of the curse of knowledge.  knowing where your sensitive data is in ALL it’s forms is critical, and both your physical access to it, and the protection / destruction of it, are extremely important concepts.

There is no going above and beyond the PCI standard in this one, as every definition of Role Based Access Control (RBAC) is what is required. i.e. You must reduce the access to any system / location / data to only that required, based on the job responsibilities of the individual accessing it. Period / full stop.

So why doesn’t the PCI DSS just come out and SAY it must be RBAC? Because there are other ways of doing this that fall outside of the pure definition (a combination of Mandatory Access Control (MAC) and Discretionary Access Control (DAC) for example), and the SSC can never insist on something that may not be appropriate for all sizes of merchant and service provider alike. Just look at logging; you don’t HAVE to have a centralised logging mechanism (e.g. SIEM), but try performing the 10.5.X and 10.6 requirements without it.

The fact that there are not separate PCI standards for merchants and service providers, as well as separate standards for types of business (retail, e-comm, micro-merchant etc.) is why there is so much confusion, and why almost every self-assessment is BS. Yes, there are Self Assessment Questionnaires (SAQs), but these are reporting mechanisms only. Regardless of which SAQ you are asked to complete, you are still responsible for compliance to all DSS requirements. Combining all requirements, regardless of business, into one standard is like trying to describe an average human being. It’s the nuances that matter.

But I digress.

In practice, access control is almost universally performed badly, as it is seen as inefficient in terms of work product, too complicated to set-up, too labour intensive to maintain, or a combination of those three. Then there are the organisations who consider themselves too small to bother, or the ones for whom this is an alien concept. Yes, there are still some of those out there.

While you cannot go above and beyond this ultimate in security baselining, you can perform the function in a way that ensures that it automates much of the enforcement of RBAC, as well as produces the management information required to measure the appropriateness of the implementation.

Step 1 – Paperwork: Un-surprisingly enough, good access control starts with a Policy, is included in all relevant procedures, and is appropriately defined in relevant standards. Other than the Access Control policy itself, the most important paperwork foundation is the Data Classification Policy. RBAC should be tied to the level of the data involved, and without an understanding of data classification, this determination cannot be made. For example; a DBA who manages all financial or intellectual property, should have far more restricted access, and exponentially more applied oversight, than should the guy in charge of your public data.

Note: Steps 2 and 3 should be performed in parallel, and combined into an overarching management process that is managed though an Asset Management System (AMS);

Step 2 – Human Resources (or equiv.): Whatever unit in your organisation manages what has – until fairly recently anyway – been called HR, should have a complete understanding of the on-boarding procedures for every role within the organisation. While every employee begins with the exact same core procedures (paperwork, corporate training, assign email / domain access etc.), well defined roles will then continue along functional on-boarding road-maps. Depending on the organisation, there can be few or many of these, but either way, this needs to be generic enough to manage, but detailed enough to reduce the burden of requesting the remaining individual privileges required. For example; a Windows admin may be granted access to all Windows desktops on joining, but will have to earn the right to access critical Windows servers, and make a separate request through channels.

Step 3 – Asset Management: Asset Management is a critical aspect of access control. Well, asset management done correctly, gives you the ability to effect proper change control, because nowhere else in your organisation does the mapping of data / application / system to data classification occur to such an extent. Seeing as access control is enormously impacted by data classification, the only place where system / data / process ownership is fully defined is the asset register / database.

Step 4 – Enforcement: For every asset type, you need an enforcement mechanism around it. This will ideally be centralised (Active Directory, TACACS, RADIUS etc.), but sometimes local access lists are appropriate. 2 factor authentication (2FA) and/or separation of duties may be appropriate for critical systems, but not for guest wireless access, but whatever is chosen must be [yet again] appropriate in terms of sustainability, and security level.

Step 5 – Ongoing Management & Review: Over 90% of all processes fail because the necessary mechanisms were not put in place to sustain them. From management buy-in, to process definition, to initial implementation, to employee training, to culture shift, unless the process is part of an ongoing and enforceable life cycle it will die on the vine.

There are as many ways of effecting appropriate access control as there are organisations requiring it, so the above is as specific as I can get. How you implement this is your organisation WILL require a significant expertise, so if you don’t have that in-house, go find it.

If you don’t know what questions to ask, ask someone who does.

Once again, my ability to help out with this stuff is limited, but even my knowledge of what constitutes a good coding practice exceeds that of most organisations with whom I’ve worked.

The best phrase I’ve heard about the need for security relevant skills in coding is; “Applications are the gateways to your data.” So no matter how much network security you have, no matter how many controls you have in place, if your applications are insecure the bad guys get what they are after.

Functionality, and sometimes just appearances, often wins over the needs to build in security from the ground up. This is especially true with organisations who do not have the necessary skill-set in-house and are forced to outsource. The inability to conduct the right due diligence, as well as the usual budget constraints, combine to perpetuate the same vulnerabilities for quite literally decades.

Cross-Site Scripting (XSS) for example, has remained in the OWASP Top 10 since its first release back in 2004 (according to this site anyway), and has never dropped below 4th. How is that possible? With the enormous amount of information out there about how to code against this flaw, the answer is not that the bad guys are getting smarter (which they are), it’s that we are staying ignorant.

Ignorance is a choice.

As much as spending money on security is the last resort (in my opinion), few organisations have the luxury of maintaining a secure coding skill-sets in-house, meaning this must be outsourced. This is simple for web-hosting, just find a compliant provider for the services, custom apps however require a little more due diligence. Luckily all you have to do is ask the right questions. Oh, wait…

In a perfect world, your security needs would drive your budget, in reality, your budget determines what quality of service you can afford. To once again quote the cliche; You get what you pay for. Unfortunately, the competition in this field is so fierce, that organisation are almost forced to provide a crap service just to break even. It used to be that security testing involved a human being skilled in the arts of ethical hacking, now price compression is pushing everyone down the road of automation and good-enough-for-PCI-work.

So regardless of which development life cycle forms the foundation of your coding practices, it must include security at all stages. Let’s take the waterfall method as an example;

waterfall

 

Security is built into no less than FIVE separate phases; Requirements, Design, Development, Testing and Monitoring, and this is in no way overboard.  Spiral, RAD, and Agile are no different, it’s just effected slightly differently.

In the end your WRITTEN life cycle must be taught to all parties, and followed explicitly, and strict separation of duties put in to place. This is not to say that you now need to hire ten more developers to meet the intent, but your checks and balances between the FUNCTIONS of the process need to show due care and attention.

Again, I’m no expert in this stuff, and there is really no way of going above and beyond here (not that going too far has EVER been an issue I’ve come across), but there is simply too much information out there, and too many talented security professionals, for there to be any excuses for not building appropriate security into your development life cycle.

Oh, and if you don’t use a code builder software (GitHub for example) to enforce the appropriate phases and authorisations, as well as effect the separation of test and production, you are already way behind the curve.

Finally, if all you use is the OWASP Top 10 as a checklist to test your web facing apps, you will be breached, it’s just a matter of time.

Not sure how to proceed? Ask.

This may be the 12th post in my series, but I cannot stress the importance of good change control enough. I have said [too] many times that maintaining a good security posture is difficult enough, but to make things easier for bad guys from the INSIDE is just plain dumb.

If nothing in your environment changes, the only way risk can increase is by a change in the external threat landscape. Your Vulnerability Management processes should have this mostly covered.

Like almost every other process in security, change control should start with robust policy and procedure, and a well designed and up-to-date, Asset Management system. If you have not only a complete listing of your physical assets, but your business processes, data stores, system and data ownership, personnel & skill-sets, regulatory dependencies, and system criticality mapped out, you have the foundation for very effective change management. Difficult to create?; yes, difficult to maintain?; only if you don’t do it properly.

Speaking of change management, if you don’t have a change control board, get one. It does not matter what you call it, but it should contain enough of the right people to ensure that both the IT and the business side of the organisation can have full insight into the risk management process, and the upcoming changes to the environment, AND to make sure these changes are in-line with the business’s goals.

Good change control starts with a policy, is clearly explained in procedures, and is central to ANY changes that can affect the continued security of your information assets. From patching, to firewall rules, to application upgrades, to server on-boarding, everything must be reviewed and approved by the APPROPRIATE level of authorisation channel. Change control can never be seen as a bottle-neck or it will be bypassed, so unless you are able to rank your changes into distinct approval channels you will end up doing too much, or too little, neither of which is sustainable.

As far as PCI is concerned, you could email your change requests to whomever is responsible, and maintain the list on a spreadsheet. For small organisations this may be appropriate, but of all things to put online, standardise, and at least partial automate, change control is way up at the top of the list. Right next to your Asset Management System itself in fact. Or even better, PART of it!

Here’s how I think Change Control should be done;

  1. The ‘Paperwork’: You will need a –

 i.   Change Control Policy – Keep it simple, even something like; “All changes to IT systems (including, but not limited platforms, application, and data) will be subject to an appropriate review and approval process as determined by the highest data classification.”, is better than most organisations have in place.

ii.  Data Classification Policy – Without a data classification policy there is no way to determine the correct level of review and authorisation required. Patching will not go to your review board, but major application upgrades certainly will. Only appropriate processes are sustainable.

iii. Change Control Procedure – Specific and easy to follow instructions enabling EVERYONE in the organisation to request a change in a uniform manner.

  1. Change Control Board – It does not matter what you call this, Change Control Board (CCB), Change Advisory Board (CAB) or Rumpelstiltskin, the charter is the same; Bring to bear all relevant resources from the business and IT sides (and SMEs if appropriate) to review and approve all changes that meet the established criteria. This should include relevant system / data / process owners where appropriate.
    o
  2. Integrated Asset Management System (AMS) – Without an integrated AMS you lose the ability to add a second layer of criticality rating to your change requests (Data Classification being your first). A proper entry into the asset register will include process dependencies, regulatory implications, max. data classification, and a system ‘importance’ rank. When these assets are available to the change control requester as a drop-down list, the full impact of the requested change is immediately apparent, and the correct level of review and approval automatically assigned. If each asset also had the system / data / process owners assigned, the review board can be built and perhaps even alerted automatically.
    o
  3. Change Closure Checklist – Too often changes are closed before the correct testing is performed, but again, what testing and approval is appropriate should be tied to the importance of the change. Vulnerability scan results, penetration testing results, user testing input, and so on are just a sample of the things that could / should be done before any change is closed.
    o
  4. Periodic Review Against Management Metrics – The change was made for the benefit of the business in some fashion, right? How do you measure success? The answer of course is; “That depends.”, but a specific date / time should be set to review the changes made to ensure that all success criteria are met. This should not be complicated or labour intensive, ever, but the review process is the only way to feed back efficiency improvements into the risk management process. Nothing is perfect.

The above list assumes you have included the basic information required to request a change (Documentation of Impact, Back-Out Procedures etc.), but the PCI minimums are rarely sufficient for an organisation that really cares about this stuff. Again, you don’t want the request process to be ridiculously long or complex, but if you don’t provide enough information up-front, you cannot perform the correct review process, nor can you measure success of the results.

Finally, if your change control process is not owned by your Governance function, you will never be able to bring the correct business oversight to bear. IT and IT Security are only ever enablers, it’s the business side that needs to own the goals.

Another crazy long blog, apologies, but change control is just that important.

For those of you errr… fortunate enough to be have been performing PCI assessments as long as I have, you will have noticed the ‘progress’ the DSS has made in terms of turning ‘just patching’ into more of a risk based approach to threats. Yes, it’s about time, and no, it has not gone far enough to be truly effective, but it should go to show just how important this subject is.

v1.1 of the DSS didn’t contain the phrase ‘risk-based’ at all, v1.2 and v2.0 say that organisations “MAY consider applying a risk-based approach to prioritise their patch installations.”, then finally in v3.0 says; “6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.”

This only took 8 years.

Unfortunately, it’ll be 3 more years before they can make any additional improvements, and when you consider how far they are already behind, and the rapidly worsening threat landscape, you simply cannot afford to do the PCI minimums here.

Vulnerability Management is the overarching process whereby a significant number of other processes are combined into a method for the never-ending examination and remediation of threats to your business. Everything from risk assessment, to asset management, to configuration standards, to change control, to patching, to vulnerability scanning to penetration testing, to monitoring and incident response, all combine into a life cycle of knowing your business goals, and enabling both IT and the business side to get there safely.

REAL Governance in other words.

I have already explained [hopefully] why Risk Assessment s and Asset Management are the starting points for a proper vulnerability management program. The rest of my list below will get their own post in due course, but here’s why they are included here:

  1. Configuration Standards – No point trying to manage risk on something that is fundamentally flawed. Don’t get these right and all the vulnerability scanning and penetration testing in the world isn’t going to help. Not to mention your logging and monitoring would be so inundated with false positives as to be rendered ineffective;
    o
  2. Change Control – Without VERY robust change control even the best initial set-ups can become rapidly insecure. Why make things easier for the bad guys?;
    o
  3. Patching – For the longest time the PCI DSS focused on the patching of systems, and insisted that all relevant, critical security patches be installed within 30 days. This completely missed the point, and while patching is an important aspect of vulnerability management, relying on reactive security measures is like taking aspirin for a broken leg;
    o
  4. Vulnerability Scanning & Penetration Testing – I lump these two together not because they are so similar (they aren’t), but because they are complimentary and fall within the same category; Testing. The cycle of constant improvement cannot be maintained if you aren’t testing your security controls and processes in some way. Test, fix, test again, repeat forever;
    o
  5. Monitoring – For every second of the day, your systems are providing information relevant to their health and security. Ignore these events, or fail to properly interpret these events and you have negated any ability you have to prevent a minor incident from becoming a worse. Unless you are able to baseline a ‘known-good’ environment, you have no idea what ‘bad’ is;
    o
  6. Incident Response (and Disaster Recovery) – In theory, you should never need Disaster Recovery if your Incident Response is as good as it should be. Without all of the above in place, you don’t have the ability to perform either well.

One of the most common complaints I get from clients is that previous QSAs have insisted that relevant, critical security patches are installed within 30 days. Yes, that’s what the PCI DSS says, but the only reason I can see that this should be a problem is if your Vulnerability Management process is so poor that you cannot show your QSA how installation within one month is actually MORE risky than to not.

There can be many reasons for this, but the inability to test patches and/or get them rolled-out in time are not excuses I would accept.

I have yet to see Vulnerability Management done well, in ANY organisation I have assessed. The pro-active life cycle approach to security, while very difficult to set-up, is nevertheless very simple and far cheaper in the long run that a reactive one. My analogy for this is that it will take me a year before I’m fit enough to ever run a marathon again, but if I had just MAINTAINED my fitness from the last one, it would be a hundred times easier.

The only things in security that stay the same are the basic good practices, vulnerability management is one of those basics.

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