Video: Building blocks of IT security 1 - Establishing the requirement

In instalment one of his four-part viewpoint series, Tony Collings outlines the first of his essential building blocks for the successful implementation of an IT project: have you got the business requirement right?

Tony Collings OBE, executive chairman, ECA Group
Tony Collings OBE, executive chairman, ECA Group

The Law of Unintended Consequences seems to hit our increasingly complex and interconnected technological operations increasingly hard, but when you finally unpick yet another ‘breach and data loss' or ‘failure to deliver a service' situation, what often stands out is a failure to get the basics right.

By ‘basics' I am referring to those fundamental building blocks that are the foundation of our modern technological systems – systems which deliver business services and profits but are all-too-often not fit to safely underpin the business that relies on them! 

The four key concepts that both business and to a lesser extent government are fixating on are:

  • The ‘Cloud' – essentially ‘hosting' but not forgetting power and bandwidth
  • The Cyber Challenge – the interconnectivity of every piece of technology we have
  • Big Data – getting bigger with little structure of governance
  • Mobile computing – essentially ‘Apps' which are consuming more power and bandwidth to support mobile devices

These concepts themselves rely on certain ‘building blocks' that go unnoticed and are taken for granted and are neglected at our peril. So what can we do about it? In this first of four short “wakeup calls” I outline some of the most important aspects of the building blocks as a reminder to ensure our technology operations are underpinned by sound foundations.

Block 1: Have we got the business requirement right?

The first building block of any piece of technology has to start with a requirement that has been properly structured and thought through. Where that hasn't happened or has been rushed, there are inevitably tears, recriminations and spiralling costs.

Time spent on this basic functional block is often skimped and in my experience over the past 25 years, has been the principal cause of so many embarrassing failures in large projects and programmes, both in government and commercially.

Have we got the REQUIREMENT right?  It is not a silly question.  Having been CIO, consultant in due diligence and design and led security teams, I regularly see failure or disappointment that stems from poor requirement specification and failure to consult business functions.

How is the requirement described in functional terms? Information and data – whose? How much? Where will we hold it? How will it be delivered and who will have access to it?

Are there any privacy or confidentiality or security implications?

At one of the first formal programme boards of a large national programme I was involved in, the risk register had an item that read, “Security has increased the cost and complexity of the Programme”.

True, it had, as the programme based on a database of at least 50 million complex personal records had virtually NO security, confidentiality or privacy requirements at all. Core parts of the programme had to be redesigned on the fly, with added cost, complexity and timescales.

Do we need to look at a privacy impact assessment? It is extraordinary just how many service delivery based databases that were ‘breached' and data lost or compromised held significant amounts of personal data and did not follow even the basic advice published by the Information Commissioner on the protection of personal data.

Some government departments have an eminently sensible policy when setting out a new programme requirement called a Regulatory Impact Assessment (RIA). This asks what regulations – national and international – will be involved. What, if any, impact will data collection and storage/manipulation/sharing involve?

Are there to be data implications involving aggregation or association of very large databases? Will considerable collections of personal data, when aggregated, require added levels of confidentiality and security above normally assumed levels of information security? Programmes have fallen foul of the assumption that low levels of security will be required by ‘mere passenger data', forgetting that this is personal and financial data requiring added protection when aggregated.

Considering service delivery, what level of resilience will be required? Will the overall ‘system' be considered part of the critical national infrastructure? Is technology the best solution to the requirement and how will it affect business process and procedure and will any changes need to be made to support the new requirement?

When the requirement is ‘complete' is there an obvious ‘solution' and can that be costed in terms of technology, people and process, both in terms of likely lifetime cost and likely upgrade costs?

Has the requirement the wholehearted support at board level, namely the COO, CFO, head of risk, CISO and heads of functional departments and partner organisations or subsidiaries with associated funding?

Beware of sub-organisational level independent requirements being met by applications and databases developed through unofficial operational initiatives that later become ‘Business Critical'. Often these are successful yet are largely outside any corporate regulatory supervision, backup and DR support or may even be entirely invisible to the management chain.

Procurement – fixed price or specified tender?

Lastly, a complex requirement is often put out to procurement process and bidders asked for their solutions, at a fixed price. Will the solution be time sensitive? And if so, how is it to be kept up-to-date? And how will it meet urgent/new ideas and commercial opportunities?

Be very sure that the requirement and subsequent contracted solution are actually what is required or disaster beckons. Too often the ‘procurement process' becomes all absorbing and when the supplier finally meets the real business users, they realise that what is contracted for on their behalf is inadequate, or during the protracted ‘procurement process and fixed price contract' the requirement has actually changed.

Subsequent pressure on a supplier to ‘absorb extra requirements at no cost' ends in chaos, withdrawal of goodwill and dispute.

In summary, getting the requirement correct is not as easy as first appears but its importance cannot be overemphasised, particularly when it may be necessary to develop ‘operational commercial opportunities' by continuous rapid prototyping where the requirement-design-development and operational cycles are necessarily blurred.

Great for business but eventually somebody has the responsibility to manage and sort out the ongoing configuration and integration issues. Nothing is ever simple. 

Contributed by Tony Collings OBE, executive chairman, ECA Group.

  • In the next video and article, to be released next week (Monday 15 February), Tony Collings will talk about design and development of the requirement. 
close

Next Article in Opinion

Sign up to our newsletters