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.’;
    o
  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.).;
    o
  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
    o
  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.
    o
  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.
    o
  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.
    o
  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.
    o
  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!]

If You Get Hacked, Blame Your CEO

According to statistics that I’ve just made up, less than [cough]% of all breaches are the result of a determined / planned attack, the remaining [mumble]% are the result of inadequate security of one sort or another.

The second sort is the overwhelming majority, but yes, I do need to start doing proper research.

My proposition is simple:

  1. CEO doesn’t care = no-one else cares.
  2. CEO ignores security = everyone else ignores security.
  3. CEO is passive-aggressive and devoid of  charisma =  he / she will surround themselves with talentless sycophants…

…you get the point.

I am always amazed that the kind of people who have the ability to either raise themselves to the top position, or start their own company, are often completely incapable of using their enormous influence to an end that has value and meaning.  Well, beyond the self-serving kind anyway.

My absolute favourite Demotivator (www.despair.com) is this one;

leadersdemotivator

 

Like most humour, it’s only funny if it’s at least partially true. Sadly, this is the case for many organisation in terms of leadership in the realm of security.

As I have stated WAY too many times now;

Let’s be very clear; The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities.  If the organisation fails to achieve [enter any goal here], its the CEOs fault, and no-one else’s.

I can think of one very good example in my own experience where the CEO actually takes time out of their busy schedule to RUN the PCI assessment every year.  Of course she delegates the detail to her team, but she remains the focal point for communication and issues, and gets her hands dirty every day ensuring that her entire company takes security as seriously as she does.  The result is that they achieve compliance every year with a minimum of ADDITIONAL effort beyond their business as usual processes.

Unfortunately in this case her chosen consulting company also sold her a bunch of their crappy products that cause never-ending grief, but that’s life.

Despite all of the articles I’ve written on a variety of subjects, I really only have one goal for this blog; to change the perception of what security is, and what it can do for a business.

Security started out on the wrong foot by being lumped in with IT, who were already seen almost as a necessary evil. I guess it’s kinda like Scotty in Star Trek, he has saved their skins a thousand times by “giving ‘er all she’s got” but it’s always Kirk who gets the glory.  And yes, I’m very aware I just completely stereotyped myself.

In reality, no other department in an organisation has a better idea of exactly HOW they do business.  Every server, laptop, mobile phone (pre-BYOD), database and application is maintained by IT, and all of THAT is under the purview of security whose job it is to make sure it stays available and accurate.  But that’s just the beginning, it’s what the security folks can do WITH that knowledge that brings the real benefits (see How Information Security Enables Transformational Change for one such example).

The challenge I face however, is that the benefits will only ever be achieved if the CEO supports it.  Nothing happens without them, and seeing as I’m just in security, you can imagine how many CEOs I get in front of.

Still, a goal is a goal.