If Your Policies Aren’t Aspirational, Why Bother Having Any?

It is with some surprise (and frankly, confusion) that I now realise not all security professionals think information security policies (ISPs) should [must!] be aspirational in nature.

By ‘aspirational’, I mean that at least some aspects of your ISPs require a greater degree of control / implementation / assurance etc. than you are currently capable of achieving in reality.

The ‘accurate policy’ proponents feel that if the policies do not reflect exactly what you are doing, then what you are doing is in violation of your own policies, thereby effectively rendering those policies useless. I assume, by extension, that they consider compliance with any regulatory regime is also nullified.

Continue reading
Information Security Policies

Why Information Security Policies are Pointless

The title should be; Why YOUR Information Security Policies (ISP) are Pointless, but I figured this title was far more contentious/click-worthy.

If you’ve come this far, you’re in one of two groups:

  1. You’re horrified at my ignorance and want to rip me a new one (good for you by the way); or
  2. You’re thinking the equivalent of “I knew it!”, in which case you need this more than anyone.

When I say that your ISPs are pointless, it’s because in all likelihood they are. Assuming you even have a policy set (policies, standards and procedures), ~20 years of consulting experience has shown that they invariably:

  1. are not sponsored/supported/signed-off by the highest levels within and organisation – does anyone really care about something their bosses don’t visibly to care about?;
  2. are not managed by a governance function to ensure adherence to business goals / regulatory compliance / corporate responsibility etc – who else is going to do this? The CEO? A CXO by him/herself?;
  3. include no overarching framework policy that 1) spells out a commitment to security, 2) breaks down the responsibilities for everyone from the CEO to the interns, or 3) details the consequences for non-conformance – how well do buildings stand up without foundations?;
  4. are generic templates with zero attempt to fit them to the prevailing culture – sometimes the phrase “That’s not how we do things here!” is perfectly acceptable;
  5. are non-aspirational – it’s actually a good practice to set your policies above your current security capability, IF you have a comprehensive exception/variance process linked to a risk register / risk treatment plan as part of the framework;
  6. are not DIRECTLY linked to robust risk management processes to ensure full policy coverage and continuing suitability to the business – how do you know they’re right?, now and in the event of significant change?;
  7. are not part of an [annual] internal audit process to measure adherence – few companies even have an internal audit function, let alone one capable of assessing IT/IS policies;
  8. are not part of employee on-boarding and ongoing security awareness training programs – every role should have relevant policies assigned to it, and appropriate training should be continuous;
  9. are not maintained appropriately/consistently – you don’t need a librarian to do document management well, you just have to be organised; and
  10. are not distributed or made available to everyone whom they impact – “Policies, what policies?”

Bottom line is that I have never seen a policy set done well, and it’s not a coincidence that I’ve never seen security done well either. These two things go hand-in-hand and you absolutely cannot have one without the other.

Yes a decent policy set is ‘paperwork’, yes it’s bloody difficult and time consuming, and no, it’s not even remotely sexy, but don’t bother trying to get a security program in place without them. Seriously, don’t even bother, because it will fail.

Lego don’t send out a 4,000+ piece Death Star set without detailed build instructions, and that’s exactly what your policies, standards and procedures are; instructions on how to do security appropriately within your organisation.

So why don’t all security folks take this more seriously? Two main reasons; 1) they are so focused on technology that the processes fall to the wayside, and 2) they have tried over and over and finally gave up, electing to do what they can, knowing full well it will never be enough.

Sad, huh?

Security is about People, Process and Technology, in that order, because without a policy set you will have:

  • no understanding of the technology[ies] you will need – risk assessment;
  • no processes to run the technology properly – procedures;
  • no way to sustain the technologies moving forward – vulnerability management;
  • no understanding of what to do with technology output – incident response;
  • no-one who could perform the incident response even if you did – security awareness training.

A decent set of information security policies ties all of this together into a sustainable program, and if you still don’t think they are that important, you are simply not paying attention.

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

Policies & Procedures

Information Security Policy Set: It All Starts Here


Information Security Policies, or more accurately; Policies, Standards, Procedures, & Guidelines (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. Not appropriately anyway. 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 done 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 ask 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, but 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.
    o
  • 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.
    o
  • 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.
    o
  • 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.
    o
  • 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!]