Stand up and be Counted

 Was it the mouse who sank the boat?  IT security and the concepts of blame, responsibility and ownership when things go wrong

 I was musing about a children’s book recently and decided that it should have a place on every IT manager’s bookshelf – not just in case the family pays an unexpected visit.  The book is called “Who sank the boat? [1] ” and, in rhyme and picture, explores the concepts of blame and responsibility. The plot is simple enough: Five animal friends decide to go for a row in the bay together, but disaster strikes when their little dinghy sinks through overloading – they had not even left the jetty yet: “Do you know who sank the boat?” 

 When it comes to information security - and a security breach in particular - there are always many fingers pointing at who might be to blame.  Questions are voiced:

 Who left that port open?  Was it the cow who almost fell in, when she tilted the boat and made such a din?

Who let that user get access to the data?  Was it the donkey who balanced her weight? Who yelled, ‘I’ll get in at the bow before it’s too late?’

Who failed to apply the patch?  Was it the pig as fat as butter, who stepped in at the side and caused a great flutter?

Who designed this network so poorly?  Was it the sheep who knew where to sit to level the boat so that she could knit?

 The search for the one who can be held responsible often looks like a grown-up version of the old Pass-the-Parcel game – only when the music stops you do not get a present.  (In fact, it probably feels more like a “Pass-the-Letter-Bomb” round.) In short: At its best, it is merely a waste of time. But far worse, undermining collective consciousness and colleagues’ loyalty, it simply creates bad feelings amongst those involved, and we are talking about the people you see and work with on a regular if not daily basis.  While it is important to identify and address all factors that led to a particular security breach in the first place, to find a convenient scapegoat alone does nothing to avoid something else going wrong one in the future. The solution?  Have someone in place whose job it is to be responsible!

 Sounds easy enough. But one of the biggest issues the information security world is dealing with is the failure of organisations to clarify ownership and responsibility before an event occurs. Many security breaches can be traced back to an absence of clear ownership and responsibility allocations.

 Think about it: Who, in your organisation, can or should be expected to stand up and take ownership or responsibility for security initiatives?  (Is it you? What happens when your business is paralyzed by the next version of the Slammer virus? Who will have sunk the “boat” in this case? 

• Was it the user, who downloaded the file and executed the virus, which spread to other machines? (“But it came from a friend who I trust!”)

• Was it the desktop administrator, who failed to apply the anti-virus software update? (“But nobody told me about the update!”)

• Was it the systems administrator who failed to apply those system patches that were announced last month (or even last year)?  (“But I did not want to disrupt the stable production environment!)

• Was it the IT manager, who failed to invest in security procedures to pick up the release of new virus updates and system patches? (“But why should that be necessary when all our IT staff should know themselves what to do?”)

• Was it the CIO, who wanted to cut costs? (“But because security operations are no longer mandatory, and I had no budget for real-time updates of anti-virus software!”)

• Was it the business managers, who failed to understand how much they relied on their network and systems and never defined a clear level of service? (“But the IT guys run our systems, so they should know how important it is to us!”)

• Was it the Risk Manager, who failed to identify an area of business risk introduced through technology? (“But I only manage operational risk, like accounting fraud!”)

• Was it Internal Audit, who failed to detect the lack of best practice controls? (“But I was not told to check the IT systems!”)

• Was it the Chief Executive, who failed to establish a “security culture” in the organisation and did not enforce good IT governance? (“But of course I support security initiatives!  Our IT operations team looks after this!”)

Passing the parcel may be an entertaining activity for five-year olds, but it is obviously counterproductive to pass on the blame in this manner within a business environment.  So we are all grown-ups now - but have we done our homework?

In the world of maturity and reason, two concepts exist that can be set against the immature and, let’s face it, childish concept of blame: Ownership and Responsibility when things go wrong. 

Take a look at Responsibility. The Oxford dictionary offers a range of definitions, but for this purpose the crucial one goes as follows: To be “responsible” means to be “legally or morally obliged to take care of something or to carry out a duty; liable to be blamed for loss or failure etc.”. 

In the context of IT security within an organisation, many people have a responsibility to ensure the continued security of the business. Responsibility rests on the shoulders of the Executives, who have to communicate the security message and fund security initiatives, as much as on the shoulders of the individual user, who has to adopt the corporate security culture.  If you have been given the responsibility for an activity, you are expected to complete it to your utmost ability, and expect your work to be reviewed and checked. 

And this is where Ownership comes in. In an organisation, someone else usually keeps track of whether you are or are not fulfilling your duties, i.e. your responsibilities. This is reflected in the hierarchical structure of an organisation.  It therefore makes sense that ownership roles are assigned as high up in this hierarchy as is deemed logical and practical. In my view, ownership is something to be associated with the CEO. While the concept of ownership has a slightly more subtle flavour than the “hard” concept of responsibility, ownership actually means that this is “where the buck stops”. Once defined and assigned to a particular person, ownership cannot be delegated. 

Ownership becomes a central issue to be addressed when an organisation plans to enhance its information security. For the establishment of an Information Security Management Framework, the New Zealand security standard AS/NZS ISO/IEC 17799 Information Security Management:2001 A Code of Practice  requires organisations to define security ownership early in the process. In fact, this should happen before a security policy is written – but in reality, this often is a case of whether the hen or the egg comes first. 

To assign ownership formally, and in form of a document, one must ask: Who should (or does, in practice, already) own the security and integrity of the organisation’s information resource?  This can be an individual or a group of “owners”.

Accepting security ownership will require the “owner” to ensure that certain activities are completed.  While these activities can - as responsibilities - be delegated to others to complete, it is the job of the “owner” to ensure that these activities are clearly defined and their results measured.  Each activity forms a component of the jigsaw puzzle that constitutes information security.  Unless each one is completed appropriately, there will be holes in the otherwise functional security structure, which can be exploited to the detriment of the business.  The individual or group who has been assigned ownership of IT security needs to assure that all required activities are completed as specified. 

Clearly defining security ownership and responsibilities in an organisation will establish a sound foundation for building security policies and an effective security management framework.  It will result in the threats and risks being understood and addressed.  

Remember the cow, the donkey, the pig, the sheep and the mouse, who sank their boat in a combined effort?  Our advice to them: Get together and sort out who has the skills and is in a position to own “boating security” from now on. Get this fellow to think about how to row safely next time, write down some rules and make sure that he or she checks that the rest of the crew abide by them.  Enjoy your trip!

Glen McCauley is a Director of eRisk consulting ltd. He is a certified information systems security professional based in Wellington with over 20 years IT experience.  He can be reached via email at glen@erisk.co.nz