The security industry has long been fond of making analogies between data protection applications and things like fire extinguishers, burglar alarms and seat belts – you may not need these devices all the time but when you do require their services you’re extremely happy that they are there, and that they work. No one would suggest that just because your car wasn’t in an accident this year that seat belts are a complete waste of time and money. The same goes for security solutions – no hack attacks in the last fiscal period obviously doesn’t mean the all-clear has finally sounded and you can jettison the firewalls and stop patching applications.
But logic such as this doesn’t fulfil an executive’s passionate desire for hard numbers to use when planning budgets and purchases. Any project that’s likely to be approved needs to show real business benefits and a solid return on investment in order to get, or retain funding. Such benefits are easy to calculate when it comes to things like advertising campaigns, marketing efforts and equipment expenditures. However, it is notoriously difficult to estimate exactly what revenue and productivity gains, cost-savings and value are produced by data security applications.
The problem is that there’s no way to know what might have happened – or not happened – without the security solution. While you can use system auditing trails to prove that some attacks were thwarted by your security systems, the majority of problems will probably have been warded off by the presence of the protection systems — data theft is often a crime of easy opportunity. That’s great, but is of no help in proving the benefits of a security system to the board who want to see hard numbers.
To get the green light on security projects, there needs to be an accurate and understandable model of an organisation’s risk factors together with an explanation of how the expenditure supports company objectives and needs. Here’s how to develop that model and make your case.
Security is risk management
An accurate method of determining RODSI – the Return On Your Data Security Investment — requires a different model from the standard cost-benefit analysis. Security is a risk management system and exactly like insurance, security’s value to any given corporation can be calculated. You have to determine what things might reasonably be expected to happen, how likely it is for these things to happen, and what it would cost to fix these problems should they occur. To answer these questions you need a risk analysis model.
Begin with the logical assumption that any business which collects, transmits and stores private customer data on a computer network is a target. Most executives accept the fact that the question now is not “if” your company’s network will be attacked, but when. But they still want to ensure they are not spending too much, or receiving diminishing returns on their investments. A good risk model answers all of these questions.
Developing a risk analysis model
Begin your risk modelling by determining the level of inherent threat exposure you have within the industry that you are part of, and the sort of data you collect. See the table to the right “Developing a risk analysis model” for an example.
Any industry that’s known to have and hold large amounts of valuable data – retail, universities and government agencies among others – is more at risk that those industries that aren’t likely to harbour much in the way of re-sellable information.
Once a company’s overall basic risk factor is established, other factors must be considered to arrive at a true picture of its data threat potential.
Companies have their own corporate cultures, their own policies, procedures and business practices, all of which either enhance or undermine technological security measures. Individual employees, most probably with varying degrees of security awareness, also impact the vulnerability of sensitive data. If scant attention is paid to employee training, developing solid security policies, ensuring that applications are patched promptly, and paying anything more than basic lip service to the idea of security, then a company’s risk profile is affected. The damage a successful breach can cause will be much higher in such an organisation than a company in the same industry that has a corporate culture centred on security. (See the table to the right “Policy and procedure risks”).
A company’s individual risk factor can be difficult to discuss with executives, especially if poor choices and priorities have created unacceptably high risk levels. If so, use the inherent and individual risk factor to establish probability (the likelihood of a data breach) without pointing fingers or making accusations – e.g. “as a retailer who processes and stores vast amounts of payment card data and employs many, often temporary workers who aren’t fully trained in the importance of data security…etc” and focus more on the costs associated with a breach.
Counting the cost
After an organisation’s particular risk profile has been established, that profile is then used to determine the likelihood of a breach. A model can be created of the various costs that are likely to be involved in managing a data breach. And here’s where things get challenging.
Based on all the cost factors discussed in depth below, the cost of a breach can be reasonably estimated. But there is no single set of figures that fit all businesses; so you’ll need to work out the costs likely to accrue if your own systems are successfully attacked. The principal variable that will drive many of the costs is the size of the breach – specifically, how many client records have been compromised. Larger breaches obviously require a greater expenditure to prepare proper responses and handle the communication after-effects of disclosure. And clearly the risk of liabilities associated with fraudulent use of the data will escalate as the number of records grows.
In general, the majority of security consultancy companies estimate that a data breach will cost a company roughly euro 25 per compromised customer record. This is a general guideline, not a hard and fast rule, and includes the costs of managing the damage caused by publicly reporting a breach. While the UK does not legally require companies to publicly report breaches, the calls for such a law are getting louder, and may be not too distant. Best to plan for it now, since it really is the right way to do business.
The costs of managing a significant data breach include:
– Detection of the breach and determination of response
– System downtime
– Customer remediation (if publicly reportable)
– Corporate remediation (if publicly reportable)
– Cost of fraudulent use of data, associated fines and litigation
1. Begin your cost analysis by determining the loss associated with systems going offline and the work/time involved in analysing a breach.
As soon as a breach is suspected to have occurred, costs begin to mount. Typically systems may need to be shut down to prevent further damage and allow for a thorough analysis; it’s possible that at least part of the business will need to go ‘offline’. The initial investigation will require a careful look back through system logs and auditing records in an attempt to determine the extent of the breach and its likely impact on the business.
Obviously, the more skilled the attacker, the harder it will be to backtrack and discover exactly what he’s done and how he’s done it. Outside experts may be needed to help determine what actually happened. The time period immediately following a suspected breach is always a disruptive and costly process that typically has a severe impact on the company’s overall productivity. Developing a response plan before an attack occurs can help mitigate these costs to some extent.
2. Factor in the costs of responding to the breach
Affected systems frequently need to be isolated during the initial investigation and potentially may need to be taken offline completely until the factors enabling the breach can be fully determined and affected systems can be completely analysed, cleaned out/patched or otherwise repaired.
The initial triage will likely be followed by a more in-depth internal systems review. Depending on the size of the breach this stage will require significant internal investment and cooperation with outside vendors such as assessors, consultants and card issuing agencies. A breach should also trigger a heightened obligation for periodic audit and assessment.
If publicly reportable, factor in costs of notifying customers and investors, as well as setting up communications systems to respond quickly to their concerns. The media will also need access to company spokespeople.
In a breach that exposes payment card data there is a very high likelihood of fines and penalties being imposed. For example, companies who process, store, or transmit payment card data are required to adhere to the Payment Card Industry (PCI) Data Security Standard (DSS). The standard was developed by major credit card companies to help enhance consumer data security. Non-compliant businesses run the risk of losing the ability to process credit card payments and face fines of about euro 250,000 per incident, as well as increased auditing controls and possible loss of card processing services.
Crunching the numbers
The potential of an attack occurring, and the estimated cost of such an attack compared to the cost of the proposed security system, comprise your RODSI analysis.
But you should also include information about how your proposed security initiative will support the business’ mission and vision. Compliance issues are a strong factor to include in your cost benefit analysis, comprehensive security systems are no longer an option for many businesses – they are a requirement.
Modern security systems often simplify the process of consistently complying with data security regulations, and will also complement many businesses’ missions to create and maintain sustainable sources of revenue. As an example, a web application firewall (WAF) supports a mission to expand online sales and services. Without a WAF, such an initiative is likely to devolve into a costly mess, plagued by nasty hack attacks and stolen data. You can back up these statements with research showing the prevalence of specific sorts of attacks such as cross-site scripting and SQL injection.
The days when FUD (fear, uncertainty and doubt) were all that it took to sell a security project to executives are almost gone. Calculating risk factors and developing a cost analysis isn’t likely to be anyone but an insurance actuary’s idea of fun, but it’s guaranteed to be significantly less stressful than managing an attack on your system.
