Security Policies - To Be Or Not To Be Pointless…

Posted on March 17, 2015
Security Policies - To Be Or Not To Be Pointless…

 

…that was the question.

How many people actually find your security policies useful? Go on, guess. I’m willing to bet it’s only audit, risk, compliance management and the third-parties that assess you. Here’s the tweet from Phil Huggins (@oracuk) that kicked off a lively enough debate to make me want to write this. Phil’s core and continuing assertion was that good tech, awareness and risk management negated the need for any written security policies. https://twitter.com/oracuk/status/562541546034434048 …his fairly pragmatic last tweet on the matter…

…my reply

…and my final volley…

Yes, it was a little mean, but it’s one of the times I nailed what I should have said at the time, rather than swearing when it came to me later. In between those, there’s shedloads of really insightful back and forth from Phil, @InfoSecGeekLady (Rowenna Fielding), @SecWaza, @Rambling_Rant (Paul Moore), @ClausHoumann, @TheGrugq, @David_Sheryn, @lee_newcombe and @infosecmo (apologies if I missed anyone!). Rather than fill this with tonnes of embedded tweets, here’s where Rowenna brilliantly storified highlights and here is the original thread. Creds are owed to Mr. Huggins for prompting all this. It’s no mean feat to stir up that level of interest with this subject matter and he admits he was, at least a little, playing devil’s advocate. In fact, when you distill his objections, it comes down to how badly policies are put together (far from a unique viewpoint). Now it’s my chance to be selfish. I give you (with some helpful links) my exclusive point of view on where we’ve gone so wrong with the security benchmarks businesses should be creating, sharing, using and regularly updating.

What a policy should NOT be:

HUGE It should categorically NOT be a war and peace length reference book, including every security control the author has ever heard of.

  • The Policies – Often talked about as a one-pagers, but realistically a little more. Setting the company’s overarching requirement for security.
  • The Procedures & Standards – Key processes (e.g. risk management, incident management, supplier management) and standards (e.g. access control vulnerability management, mobile device, cloud, social media)
  • Operational guidance – The practical guides to getting the job done (e.g. build standards, or granular steps to deal with joiners/movers/leavers).

ISO27001 has exact guidance for documents needed to create an Information Security Management System (ISMS), including policies and procedures. That, depending on your business, may be a step too far, so this is more about common challenges, no matter how you decide to go about documenting security requirements. Note, that my last bullet above said guidance. With the exception of mandated legs and regs (and even most oversight bodies accept risk based exceptions), one size will NOT fit all. Controls required for Linux are not identical to those required for Windows. Suppliers shouldn’t be told to adhere to your exact security requirements – they’re not you – so a vendor version of documents is needed. If you operate in more than one country, there will be variations in data protection law and financial regulations, etc, etc. To get that right…and I cannot stress this enough…consult your SMEs. They know what’s reasonable and feasible for you and your environment. Security SMEs can overlay a risk and good practice perspective. In a nutshell…don’t impose rules you cannot implement or sustain. Bringing me neatly on to my next policy no no;

ABSOLUTE

Even if you nail that coverage and depth piece, you will need to make some exceptions. Periodically things won’t fit the documented mould for financial, strategic or technical reasons. A policy which gives no permission and efficient mechanism to make exceptions is not just pointless, it’s destructive. A constant round of everlasting audit issues, persistent regulatory non-compliance, or expensive gold-plating of controls. Folk lose faith in security, make up their own rules, or vote with their feet. To fix that counterproductive cycle, see the point below about risk ownership and ensure the highest level documents specify how exceptions work. The risk related level of sign off, role holder, process, requirement for regular review and mechanism to feed exceptions back into policy reviews and strategic plans for security. After all, if no-one can meet a specific aspirational standard, perhaps it’s surplus to requirements, or needs investment to achieve.

BOTTOMLESS

If your top level policy goes down to the point of specifying password length and encryption strength, you’ve got it wrong. The first bullet talks about how to segment advice, but this is more on why:

  1. Permission by omission – you’re never going to cover all fronts, no matter how hard you try and if it’s set out as your complete range of security requirements, folk will go to town on you if a breach is linked to something you missed.
  2. Future-proofing – security doesn’t stand still. Yes, you will (if you’re good) review it at least annually, but the more detail you have the quicker guidance will become irrelevant.
  3. Consistency – sooooo often you will find controls far more granular than their neighbour, at the same level in the same document.  It often looks like the author got really enthusiastic about their specific area of expertise, or about something that’s currently got the attention of the media and therefore the board. Don’t do it. It’s confusing and kills compliance management functions.

You should be rethinking this stuff regularly as technology and threats evolve, so don’t make a policy re-write rod for your own back.

RISK-NEUTRAL

Now this is where I’m at risk of getting shouty. Policies and supporting standards SHOULD be (but so very often are not), an expression of executive risk tolerance. Have you ever heard something like this?:

“We have zero tolerance for data loss incidents”

The typical response from security pros:

“Time to unplug the network, turn off the lights and go home then”

Understanding and setting a realistic tolerance level for risk is vital and that should be linked to the required level of security control. Achieving that depends enormously on how good you have been at spotting, assessing and scaling your risks. The way to test whether proposed controls are too little or too much is to think about typical fallout if controls are missing or broken. FAIR (Factor Analysis of Information Risk) is a great methodology for doing that, honing in on a realistic level of current risk vs a liveable level of risk for your specific business.

OWNERLESS

You must have roles and responsibilities in documents. It starts with a policy, procedure, standard or operational document owner and should go on, at a high level, to specify the corporate roles where data and risk ownership must land. Not forgetting to specify how and how far that accountability can be delegated (mainly to avoid ownership ending up back with security and IT managers). Is this familiar? A serious risk, non-compliance or incident is flagged to management. Everyone who should be accountable takes a figurative step back and the blamestorming begins. The need to take control and start fixing things, temporarily forgotten in the furore. Part of the antidote is putting together a rock solid risk RACI. Make it part of the policy formulation process. A good way to lead into that is to run targeted security incident scenarios (this 2014 document from SANS gives comprehensive incident management guidance including advice on key role holders and running exercises). It can quickly (and believe it or not, if done right, enjoyably) clarify who has skin in the game. Where the buck will stop if a regulator comes calling, or if share price bashing news of a breach ends up on Twitter.

PROPRIETARY

Even if you are not a financial services firm, healthcare provider, supplier to governments, or a payment card processor, it's not advisable to make up your 'own brand' policies. That's ok until you need to do business with a more regulated client. Think forward. You need to make policies relevant to YOUR business, but recognised standards as frameworks for control add credibility and enable easier negotiations. ISO27001 is often assumed to be a standard for security controls. It's not. It's a framework for security management (Dejan Kosutic just published a post on the shortest path to certification). Other ISO standards do look at good practice for security control e.g. ISO27002:2013 and ISO22301 (for business continuity). Then there's the mandatory legal and regulatory requirements and other focused guidance for specifics like cloud security and web app security. Rather than clutter this article, I've saved a starter for 10 list on my blog. You may want to get an expert in to clarify exactly what is applicable to your current business and future plan. It can become a tangled web. It can also seem like a very big stick for some organisations, but, building things in line with recognised security standards will impress clients, make keeping up with new legs/regs easier and an early start beats fudging or backfilling later.

OLD

If it’s passed it’s 1st birthday it’s too old. Just like you never cross the same river twice I don’t want to be assessing security against the same benchmarks in 5 years time. The bedrock of documents should remain the same (structure, core sections), but everything else should evolve to fit the flow of change in the organisation and surrounding risk landscape. Well that bit ended up longer than expected. I thought writing this article, given the subject, was going to be like pulling teeth, but turns out I had a lot to get off my chest. Suspect I could’ve eeked out a reasonable mnemonic too…feel free to suggest one.

So now to the aspirations;

Let's face it, even if you’ve already applied all of the above, most of what gets produced is still literary valium. Many folk give in and call in consultants. Here’s a tip; There’s no acknowledged gold-standard for this. Folk don’t share this stuff….well they do occasionally…just not voluntarily.  More than once I’ve caught the name of another company in what a consultant has cut, pasted and called output. You want…no, you NEED everyone to read, understand and implement what a policy tells them. So how the heck can that be achieved? Very briefly (as I’m sure you’re sick of reading by now) some very practical suggestions I made during the Twitter conversation:

It’s not rocket science and I don’t know why more firms don’t do this already. Build policies in a database, link top level policy, to risks, control objectives, controls, operational guides and relevant legs and regs. It’s a many to many mapping, so why try and do it in a flat format? Build it with a useful structure, so folk can drill down to practical guidance or up to risks. It’s for your PM who needs security requirements for an ecommerce project, your in-house team planning a change to user management processes, your compliance team to plan activity, or your supplier management team who needs to put an RFI together. After all, as Rowenna so eloquently says:

Sarah_Clarke.jpg

About the Author: Sarah Clarke is an Information Security Governance Risk and Compliance specialist with 14 years experience in the IT and Security trade. Currently working in financial services on vendor security governance projects. She also maintains her multi-award nominated Infospectives security blog, writes on various aspects of InfoSec for other security sites, is a founding advisory board member of the Give A Day charity initiative and was one of the first contributors to The Analogies Project. Her self proclaimed aim in life is to de-FUD and demystify information security for everyone. Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc  

Mastering Security Configuration Management

Master Security Configuration Management with Tripwire's guide on best practices. This resource explores SCM's role in modern cybersecurity, reducing the attack surface, and achieving compliance with regulations. Gain practical insights for using SCM effectively in various environments.

Get the Guide
Join over 20,000 IT security pros who get our top stories delivered to their inbox every week!