Policies & Procedures

Information Security Policy Set: It All Starts Here

Information Security Policies, or more accurately; Policies, Standards, & Procedures (a Policy Set) are the cornerstone of every security program. It is therefore rather odd, that not one client I have ever helped started with any of them in place. While not everyone is a security expert, everyone can be security savvy enough if, and ONLY if, what they are supposed to do is written down!

That’s what a good Policy Set is; an instruction manual on what to do, what not to do, why, and how.

I have written too many many times on why a good Policy Set is important, and have used the term ‘baseline’ more times than I’ve had hot dinners. I have described what a Policy Set consists of, and even how to manage one, but what I have not do up till now was to describe how to find a Policy Set that’s right for your business.

First, you may be wondering what’s so hard about finding policies. And I agree; type “information security policy example” into Google and you’ll get tens of millions of hits. Universities readily publish theirs for the world to see (e.g University of Bristol), and a whole host of organisations even make editable versions freely available. On top of that, online services with ridiculous promises like “THE ONLY WAY TO GET AN INFORMATION SECURITY POLICY CUSTOMIZED FOR YOU IN AN HOUR, GUARANTEED.” are depressingly common.

The challenge is that if you’re looking for information security policies in this fashion you clearly have no experience implementing them, let alone actually writing one yourself. An overly-dramatic analogy; I found thousands of instructions on emergency appendectomies, would you now trust me to perform one on you? A good Policy Set is one that is appropriate to your business. Not your industry sector, not the prevailing regulatory requirement, your business!

Therefore, if you don’t have security expertise in-house, it is very unlikely that you know the right questions to asks providers of Policy Sets. The vast majority of vendors will sell you what you ask for (can’t really blame them for this), so ensuring you get what you actually need is entirely based on the homework you performed beforehand.

To that end I have written something vaguely resembling a white paper to help you. In the imaginatively named ‘Choosing the Right Policy Set‘ I have broken the choosing of a policy set vendor into 15 Questions. These could easily form the core of an RFI or RFP if you were taking this seriously enough.

Simple questions like; “Can you provide a Document Management Standard and Procedure?” or “Does your service include a mapping of policy statements to the PCI DSS?” are sometimes not even considered. But when you consider that the choosing of a policy set can be the difference between compliance and non-compliance, it makes sense to ask them. Up front!

90% of organisation will end up either throwing something together themselves, or buying the cheapest option available. That’s fine, when regulatory fines start getting handed out they will realise just how expensive their choice was.

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

Document Management System, How’d I Miss That!?

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.

Policies and Procedures

PCI – Going Beyond the Standard: Part 3, Policies & Procedures

Of the roughly 400 separate requirements in the PCI DSS, 46% of them require the review or examination of some form of documentation. From policy, to procedure, to configuration standard to diagram, a very significant chunk of achieving PCI compliance starts with paperwork.

How is it then that in the 10 years I’ve been performing PCI and PCI-esque assessments the ‘paperwork’ is almost invariably the last thing to close? I’ve seen large organisations get centralised logging in place before they managed to get their policies and procedures in order.

In Want REAL Information Security? Start With Your Policies I have already gone into why organisations should take polices and procedures more seriously, so I’m not going to repeat myself. But I will just say now that if you didn’t start your project to formalise your policies and procedures at the beginning of your assessment, stop, go back, and start there. A good QSA will fail you for crap policies just as quickly as they would for lack of encryption on stored card holder data.

All too often the client response to a request for documentation is to provide a handful of polices taken from the internet with the company name changed, but no effort whatsoever to customise the content in line with reality. Procedures are virtually non-existent, everything is in unprotected Word docs, several years old, and in no way standardised. The look on the faces of those being asked to provide just the location of the official copies is usually one of confusion, or worse, blank incomprehension.

The worst thing you can do is hand your QSA a bunch of crappy docs and say “You tell me what’s missing.” It does not work that way, and all you’ve done is thoroughly irritate someone who should be on your side. It is YOUR job as the client to tell the QSA which documents and specific language YOU think meets the intent of the DSS requirement testing procedures. The best way to do this (if you don’t have access to a GRC tool with DMS built-in, see below) is just to start with the DSS on a spreadsheet and map your existing documents to it. Your QSA will tell you the gaps, which gives you the necessary action items to begin your remediation.

Here’s the one I give my clients, help yourself; PCI DSS v3.0 – Document Mapping Matrix

Other stuff:

  • Policy Content – In terms of policies, procedures and standards, these are the major headings I generally expect to see; PCI DSS v3.0 – Policy & Procedure Checklist.
  • Document Management System (DMS) – This does not have to be a major expense, a folder on an intranet share will suffice, but the point is to have a centralised location to place all of your latest approved documents. They should however have access control mechanisms in place to ensure only those with a real need to see them, can. Some of the more elaborate DMSs will take care of version control, ownership, review cycles and so on, as well as automated mappings to regulatory compliance regimes like PCI. Choose what’s right for your business, and look at the Governance Risk & Compliance tools that may have this built-in.
  • Pre-Packaged Templates – There are many organisations that can offer pre-packaged policy templates, but none that can provide pre-packaged procedures. Best practice policies are numerous and can be customised to suit your business, but procedures are written by your organisation and are necessarily specific to it. Don’t buy anything claiming policies AND procedures out of the box, and don’t buy anything specific to PCI. Cover your business, and if you have to spend money to get your ‘paperwork’ together, focus more on expert guidance. Avoid policies that match the next two points.
  • Monolithic vs. Modular – It is generally best to have each of your separate policies as stand alone documents with their own version history and ownership, a single policy document is very hard to maintain.
  • PCI Relevance – The phrase ‘card holder data’ should appear only once, maybe twice, in all of your policies; in the Data Classification Policy. Every other policy refers to the classification in which card holder data was contained (e.g. Highly Confidential).

Like everything in security, getting policies right is not easy, but it is simple. There are many people out there who can help you if you don’t know where to start, and this is not something you should do half-arsed.

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

Policies and Procedures

Want REAL Information Security? Start With Your Policies.

I am constantly surprised and disappointed that the Policy Set (policies, standards, 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, to make things worse by not preventing your own employees from virtually giving it away is just plain dumb?

A Policy Set generally consist of 4 main components:

  1. Policies – the dos-and-don’ts of your entire organisation and use language like will / must / shall. e.g. Your authentication policy states that you; ‘MUST use strong authentication for access to systems containing data above a certain classification.’;
  2. 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.).;
  3. 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 long into X system using 2-factor authentication.; and
  4. Guidelines – The only non-mandatory element of the Policy Set,they provide good-practice guidance on how to implement a policy or standard requirement. e.g. For passwords, don’t use birthdays, don’t use names of children, consider a pass-phrase instead 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 everyone 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 Set, and very difficult to distribute and enforce it.
  5. No feedback or measurement processes – Per the old misquoted cliché; you can’t manage what you can’t measure, 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 Policy Set 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.