PCI – Going Beyond the Standard: Part 19, Security Awareness Training (SAT)

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.

Policies and Procedures

Want REAL Information Security? Start With Your Policies.

I am constantly surprised and disappointed that policies and procedures aren’t taken more seriously. They are the blueprint of your corporate culture, the single most important aspect of your security program, and by far the easiest and cheapest things to put together (in terms of capital costs anyway).

Even a ‘controls only’ standard like the PCI DSS is roughly 40%  ‘paperwork’, but, with the possible exception of the risk assessment, remains the most common tick-in-the-box exercise of them all. Which is a shame really, as it should be enough that thieves want to steal your data, why make things worse by not preventing your own employees from virtually giving it away?

Policies and procedures generally consist of 4 main types:

  1. Policies – the dos-and-don’ts of your entire organisation and use language like will / must / shall. e.g. Your password policy states that you MUST use strong authentication for access to systems containing data above a certain classification;
  2. Procedures – describe HOW you implement the policies in YOUR organisation. They are detailed, ‘living’ documents that prevent the constant re-inventing of the wheel when faced with performing standard functions. e.g. this is how you implement strong authentication for all relevant systems / applications etc.;
  3. Standards – A very detailed document that explains exactly HOW something is to be configured. From operating system hardening guides to firewall rulesets. e.g. the details the actual password elements that constitute ‘strong’ (7 characters, alpha-numeric, change every 90 days etc.).; and
  4. Guidelines – The only non-mandatory element of the policy and procedure framework, and provide good-practice guidance on how to implement a policy requirement. e.g. Don’t use birthdays, don’t use names of children, consider a pass-phrase as opposed to a password etc.

However, you can have the most polished documentation ever, and still completely miss the mark. It’s not about the paperwork itself, it’s about the enforcement of what’s IN the paperwork. A policy is only ever as good as the understanding of it, and the adherence to it.

Unfortunately, this is where most organisation fall down, and one or most of the following challenges apply:

  1. Policies not in-line with corporate culture or day-to-day business process – Policies should be owned, and even written BY the CEO / BoD, who else is responsible for the culture, direction, and future of an organisation more than them? Too often this is delegated to departments or individuals without the necessary authority or experience to perform the function properly. A document coordinator MUST be a subject matter expert.
  2. Undocumented procedures result in numerous (usually unintentional) breaches in policy outside of formal exception/variance processes – Just because a policy is in place, does not mean anyone knows how to implement it. Every department in an organisation is responsible to describe how each and every task is accomplished. Without procedures and standards, policies can become unenforceable, and every new employee has to reinvent the wheel every time they want to accomplish what should be a standard task.
  3. Policies are undistributed, unenforced, or mis-understood – Just because you HAVE policies, or even procedures, if no-one knows where they are, what they mean, or how to measure against them, they are just pieces of paper. Security Awareness Training programs should start with a comprehensive look at corporate policies.
  4. Poor document management or lack of integration with formalised training mechanisms – Without a robust document management system, it’s very difficult to both maintain the integrity of the policy and procedure documentation, and very difficult to distribute and enforce them.
  5. No feedback or measurement processes – Per the old misquoted cliche; you can’t manage what you can’t measure, and unless policies are seen as living documents with company wide feedback mechanisms in place, they can rapidly become obsolete.

I do not use the word ‘recommend’ lightly, but I HIGHLY recommend that before you implement ANY aspect of your security or compliance program, you get your policies in place. At the VERY least do this in parallel with a risk assessment and business process mapping exercise.

While most high profile breaches focus on what went wrong technically, I can almost guarantee the original failure was one of education in the most basic of all security foundations; policies, standards and procedures.

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

Stop Confusing PCI Compliance With Actual Security

To this day, people are surprised when an organisation is breached after having achieved PCI compliance.


The SSC has never claimed that PCI compliance ensured the protection of cardholder data, especially when you consider most organisations don’t DO PCI compliance for security, they do it to get their acquiring banks off their backs.  All the SSC have ever claimed is that it helps, and it does.

Security is not about being impenetrable, that’s impossible, it’s about knowing your two main enemies; thieves and ignorance.

Thieves are lazy. In fact, I’d go as far as to say that laziness, more than a desire to be bad, is the leading driver behind computer crime.  This drives them to steal first what is most easily available; the so called low hanging fruit.  So to avoid thieves, just have YOUR fruit higher up the tree.  That’s what PCI compliance does, and that’s all.

As for ignorance, my absolute favourite phrase right now is;

You are not entitled to your opinion. You are entitled to your informed opinion. No one is entitled to be ignorant.
― Harlan Ellison

Information Security Policies and Security Awareness Training are SUPPOSED to cure all employees of their ignorance as it relates to the protection of data in their possession, and they would if they were taken seriously. They are not.  Policies provide the dos-and-don’ts, training provides the why and wherefores, neither of which are given due care and attention.

Now combine those 2 and you can see why achieving PCI compliance means little to nothing if it’s not done PROPERLY! Even then, it will always fall short.

I have stated several times in my blogs that ALL compliance would automatically spit out the back end of a security program done well, and I have even defined what that is in my Security Core Concept series.  The 5 people who actually read them will understand the following, but for the rest, here’s 4 reasons why PCI compliance does not mean security;

  1. It does not start with a risk assessment relevant to YOUR organisation.  The controls of the Data Security Standard ARE the risk assessment.  Even if you were to perform your own at the beginning of your compliance project, you still have to do everything the DSS says as there is no ‘residual risk acceptance’ in PCI.
    It is FAR more difficult to implement the PCI DSS controls as stated, than it is to implement the controls relevant to your business.  Which is why it is never done properly.
  2. The focus of the DSS policies and procedures requirements is the paperwork, and not the enforcement OF those policies.  Having polices is meaningless if they are not read, understood, and followed.
  3. Once a YEAR validation of compliance is as pointless as hub-caps on a tractor.  Yes you are responsible to maintain your compliance throughout the year, and yes the DSS includes change control as a requirement (barely), but how exactly do you maintain compliance when the DSS provides no context or framework for a sustainable security program?
  4. Let’s take an actual control, logging; There is no PCI requirement for centralised logging (10.5.3 – “or media that is difficult to alter.”) meaning a daily retrieval will suffice for the daily review (10.6.X), which in turn can be manually performed. Show me how you can possibly perform adequate incident response in an environment that does not real-time stream logs to a centralised location that then performs the following automatically, and I’ll wash the crow down with a healthy serving of humble pie:- Real-time alerts based on ‘never-see’ events from every system component.
    – Real-time alerts based on violations of ‘threshold’ events baselined from every system component.
    – Alerts based on violation of ‘trending’ patterns (you have a year’s worth (10.7.X), use them).

    Logging is the core of incident response, which is the only way of preventing a security event from becoming a business crippling disaster. Logging is not just a collection of events to be used for in a forensic investigation.

Bottom line; PCI compliance is nothing more than an attempt to protect cardholder data better than it was done so previously, and in that it has only succeeded in the organisations who focused on security not compliance.

Everyone else threw good money after bad and kept the thieves from having to find their next low fruit.



The 4 Foundations of Security

So far I have focused on the Core Concepts of security, and how they are the basic building blocks of a security programme.  Well, – and to continue the cliched architectural analogy – these 4 things are the foundations on which those building blocks sit;

1. Management Buy-In / Culture – Hah, weren’t expecting that, were you!?  At least 3 of my posts have placed the vast majority of the responsibility – for everything from PCI compliance to customer service – firmly on the shoulders of the CEO (or equivalent).

Unless your company IS a security company of some sort, security is an expense, and whether or not that expense is seen as a business enabler (which it is) depends on the CEO’s attitude towards it.

Whether you’re starting an assessment at your client’s site, trying to implement a security program at your current employer, or interviewing for a job as a internal auditor, asking what the CEO’s attitude is toward security will determine the difference between success, and banging your head against the wall.

It may well be your JOB to change the CEO’s attitude toward security, if so, you’d better have a VERY good argument, and it had better involve making, or saving a ton a money (or making them look good …or both).

2. Policies & Procedures – Amazing how many people groan at this, and even security professionals cringe at the ‘paperwork’ they have to troll through.

That’s a shame really, because without that paperwork, you will never HAVE security. It’s your company’s instruction manual for how to do what you do, properly, responsibly, and securely.  Anyone who’s put together a chest of drawers from Ikea knows exactly what I mean; maybe, and I mean MAYBE, you could work it out for yourself, but how much more painful would that be?  It’s bad enough WITH the instructions!

Your policies and procedures let all employees know what to do, and as importantly, what NOT to do.  It’s enough that the thieves want to steal your data, why make things worse by not preventing your own employees from giving it away!?

3. Governance – As I have mentioned in previous articles, few phrases in security are perceived to be more ambiguous, open to interpretation, or complicated.

Wikipedia says; “Information Technology Governance is a subset discipline of corporate governance focused on information technology (IT) systems and their performance and risk management.”  It also says; “IT governance systematically involves everyone: board members, executive management, staff and customers. It establishes the framework used by the organization to establish transparent accountability of individual decisions, and ensures the traceability of decisions to assigned responsibilities.”

I can simplify this to; “IT Governance is the business side and the IT side having meaningful conversations.”  Group hug anyone?

It does not have to be complicated, it just has to be appropriate.  You don’t have to hire additional people to run it, you just have to assign the tasks, responsibilities, and accountability.  You don’t have to follow its decisions rigidly, all businesses have an exception processes (usually informal, and often consists of someone very high on the business side telling you to do something anyway).

IT, and especially IT security, are often seen as roadblocks to the business, and circumvented where possible.  The IT departments themselves are often just as much to blame for this.  IT’s job is to help the business do something right the first time, and they can only do this if they are in on the plans from the beginning.

4. Education & Training – While this is closely linked to policy and procedure, I’ve broken this out separately because of its importance.  You simply can’t expect non-security experts to keep up with the latest threats all by themselves, it’s not their job.  In the same way that I do not keep up with changes in the tax codes (that’s my account’s job), or the latest in social media advertising (that’s marketing’s job), everyone else relies on us to tell them what they need to know.

This training and ongoing education cannot become marginalised, and must be kept fresh and interesting.

If your security programme is not where you want it to be, or you are frustrated at the lack of progress, there is a very good chance that one or all of these foundations is missing.

I’m not saying you can’t hope to make ANY progress, but it will be needlessly inefficient, time consuming, and expensive.  Not to mention much harder to maintain.  I have only ever seen organisations achieve Business As Usual security when all 4 of these foundations is in place.

I will be individually expanding on the 6 Security Core Concepts, and putting them into context with these foundations.  Eventually I hope to provide more specific guidance on how to take this theory and put it practical use, but it’s time for dinner…

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