Category: Core Concepts

If you have ever been on the receiving end of a PCI assessment, you had one of two reactions to this blog’s title. You said;

  1. “Yes it is, that’s what I hired you for!”, or;
  2. “Damned right it’s not yours, the QSA is only here to validate it.”

95% of you are likely in the first group, unless you had someone like me as your assessor. It is not the QSA’s report, it is yours! The QSA is only there to:

  1. confirm that you have completed your parts of the Report on Compliance’s (RoC) Executive Summary (Sections 1 – 5) correctly;
  2. edit the QSA relevant sections;
  3. document the validation results in Section 6 – Findings & Observations; and
  4. validate the evidence you provide, and for which you are entirely responsible.

A QSA will likely never know your environment as well as you. So if you don’t take FULL responsibility for the contents of your RoC it will be your organisation that it liable for any mistakes, not the QSA. You will also then have absolutely no remedy if you are breached, as your forensic investigation will expose significant differences between the RoC and reality. This is also why you should never, EVER, hide anything from your QSA.

PCI is too often seen as an audit (it’s an assessment), and the QSA an auditor (s/he’s an assessor) and volunteering information is considered a no-no. I have actually had a client say; “But you didn’t ask me about that!”. I always try to explain that I’m a consultant first and there to help. I can’t help if I don’t have all the information. But if I do find out that they’re hiding something from me, any sampling privileges are now out the window.

That’s one of the differences between clients who use their PCI budgets to spend on securing the business, and those who only care about tick-in-the-box compliance. The first type will spend far less in the long run, even if the process does take longer. Not only that, they will likely not only STAY compliant, they will have actually protected their business …their ENTIRE business.

Setting PCI compliance as the end goal is like telling your kids to aim for a C average in school. Even the Card Brands and the SSC themselves have only ever said the DSS is a “minimum set of security controls”. So why would a QSA, whom you have hopefully chosen well (see Selecting the Right QSA for Your Business), take any ownership in a process where the goal is almost never fit for purpose?

Anyone who thinks that the PCI assessment process is structured, formal, and conducted using well established parameters has never been through one. Every good QSA does their own internal Risk Assessment from day 1, and based on their gut instinct, will determine whether or not validation sampling is even an option. If I don’t trust you, you stay at 100%.

Want to get some benefit from a PCI assessment?:

  1. Choose the right QSA;
  2. Tell them EVERYTHING; and
  3. Take FULL ownership of both the process and the output.

It’s your RoC, accept it.

[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.

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.

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!]