This article can also be found in the Premium Editorial Download "Information Security magazine: Filling the data protection gap."
Download it now to read this article plus other related content.
According to a published report, seven out of 10 companies overspend on IT security expenses without improving security or becoming compliant. What causes this phenomenon? Isn't overspending on security a good thing?
The cause is the introduction and promotion of "pet" risks by decision makers. A pet risk is a threat, vulnerability, or product that solves an apparent problem in the minds of IT or security managers. It's their favorite issue, consuming all their attention and therefore, requiring an overabundance of resources to mitigate.
In what is a common occurrence for many large organizations, decision makers get in their minds that they need a specific product to prevent what they perceive is an information security risk. IT and security leaders in the organization spend many dollars and hours to get solutions in place to mitigate their pet risks. However, the return on security investment (ROSI) isn't readily apparent and often, the expense isn't worth the apparent risk. It's like a person who's so fearful of having their car stolen that they spend hundreds on an anti-theft system even though they're driving a 1996 Ford Contour. The cost of mitigation is out of balance with either the asset value or the real risk.
The decision maker has the position or influence to get the funding and personnel to address their pet risks. They are a danger for many organizations because they cause an imbalance in the risk equation and often cause undue spending
An example of a risk fawned on by many IT and security managers these days is data leakage; the fear is that employees could place company information on a USB drive or CD and it could be stolen or lost. Management may be convinced that they need to stop this threat at all costs so they look for a data loss prevention (DLP) solution to prevent employees from using USB drives or CD burners. However, while data leakage may be an issue, it may not be the organization's biggest problem. A common example is businesses using DLP to prevent data leakage when they've never taken the time to identify their critical data and where it resides on their network or systems. Implementing a DLP technology may be a decision maker's pet risk and therefore one that's addressed ahead of other more important risks.
How do you solve the problems caused by the pet risk phenomenon? What you need is an honest assessment of risk. Addressing and quantifying risks allows for their ranking and prioritization based on the needs of the business. Collaboration between security, IT, and business leaders using common risk analysis processes such as Factor Analysis of Information Risk (FAIR), OCTAVE, or the National Institute of Standards and Technology (NIST ) Special Publication 800-30 also reduces the possibility of favored risks eating critical resources without increasing security or providing compliance.
There are three ways to prevent pet risks from causing you to bark up the wrong "security tree:"
- Conduct a risk assessment;
- Collaborate on the results with all stakeholders;
- Be open and honest on the best ways to protect the business.
In the DLP case above, decision makers should look at all of their risks and determine where data leakage actually occurs. They should address the potential impact and probability of data leakage. Is it just an irritant or could it be a major issue? How likely is it that critical data can and will leak out of the organization? They need to collaborate with others on their risk assessment to see how it affects the business.
Pet risks are created by closed minds. Open your mind to address all possible risks to your organization. Talk to others to get their honest opinion. Get outside help when needed. Don't be the owner of a pet risk.
Ron Woerner is a security analyst at a large architecture and engineering firm in the Midwest. Send comments on this column to email@example.com.
This was first published in February 2010