Defusing the Security Bomb – Part 1
Mike Thompson
Part 1 – The business perspective
With any IT project, we know that optimal solutions are only possible when they align to the needs of the business. So why is it that this alignment is so difficult for information security?
I often see business managers who are very nervous about their information security exposures, yet rely completely on their IT or security departments to ‘fix the problem’. This could easily be construed as passing the buck, but there are good reasons why this happens.
Focusing on the business side of the equation, the causes of this dilemma can be broken down into four basic areas:
1.The business behaves reactively to media events and perceived risks, adopting less than ideal solutions.
2.The business simply lacks the expertise to understand information security and would rather defer decision-making to more technical or specialist groups, often vendors.
3.Projects do not include information security in the critical business analysis stages, leaving it to the end of the development lifecycle.
4.There is no language or communication tool that the business can use to communicate its needs simply and effectively.
These are fundamental issues for organisations struggling with ever-increasing security demands and tighter budgets. It would be easy to say that the business needs to take a more considered approach, but without the necessary guidance, effective collaboration and alignment between the business and IT is unlikely.
Security by media
I recently helped a friend of mine with an IT problem. His video surveillance system was suddenly dropping browser connections after about 30 seconds. It wasn’t until I analysed the issue that I found he had recently purchased a new subscription to an anti-virus product and a bug was responsible for his problems.
Spurred by recent malware scares, my friend felt he was doing the right thing to protect his business. However, when I explained to him that free anti-malware was already bundled with his operating system, he quickly realised he had just paid a considerable sum of money for something he didn’t need and that was actually causing problems in his business.
Rather than making IT control decisions, the business should be focused on understanding the sensitivity of its data. Matching the security controls should be a separate process undertaken in consultation with independent control experts.
It’s a technology issue
I have lost count of the organisations I have seen that have positioned information security as an IT responsibility. In fact, a significant number of organisations even place the security role under the CIO. I could talk about how wrong that is on many levels, but the big question is – Why did management adopt this approach in the first place?
In most cases, the security role was handed to IT simply because the business didn’t understand it and IT thought it did. Unfortunately IT only understood the technology and not the requirements of the business.
Of course information security is equally a business and IT problem, but unless both parties recognise that, IT will more often than not inherit the problem.
Security as an afterthought
I find it very odd that when gathering requirements for a new application, a business analyst typically asks a user about screen preferences, navigation, etc., but fails to ask – “What would the impact be if that data was exposed?” It’s a very important question upon which critical security control decisions depend, but the question is not always asked.
It makes sense to gather these requirements as early as possible in the software development lifecycle, but very little, if any, detailed guidance exists, even in the well-established methodologies. Inevitably there is a mad rush at the end of the project, based on educated guesswork and politics, to implement something that resembles a secure solution.
Speaking the right language
I was once asked to review the information security controls to be implemented as part of large government project. This project had been completed for approximately six months, but had hit a roadblock. Based on its established policies and baseline standards, the information security team was concerned that security was not up to scratch and had refused to let the controls be implemented.
After six months the project team was becoming quite desperate as costs ballooned and its reputation diminished. The team simply could not convince the security team that its controls were appropriate for the application.
The problem was resolved in two weeks by dividing the problem into two parts:
1.The project team (the ‘business’) provided the data sensitivity ratings 2.The information security team (‘IT’) analysed the controls that would be used and their effectiveness ratings.
The results were then put through an independent matching process, which determined whether there were any residual exposures, how much was exposed, and what was required to close the gap. Because the language used was designed specifically for each part, both sides could express their needs in their own words without stepping over the boundaries. They trusted the results and there was unanimous agreement with the recommendations, even though very little actually changed in the application.
In summary
From a business perspective, information security may seem daunting, but recognising that there are two parts to the problem, being proactive rather than reactive and adopting a process and language that supports both sides can deliver optimal solutions. In Part 2, we look at the IT perspective.
This article was brought to you by Enex TestLab, content directors for CSO Australia