HOLY GRAIL : How secure is secure enough?
Jaikumar Vijayan
Computerworld
July 28, 2008
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=321921&source=NLT_SIC&nlid=92
If there is a Holy Grail in the information security industry, it surely is the answer to the question, "How secure is secure enough?"
It's a question that many security managers have either avoided answering altogether or tried to quickly sidestep by throwing a fistful of mainly pointless operational metrics at anyone who cared to ask.
But with a faltering economy beginning to put the squeeze on IT budgets, and security managers being asked to justify every dollar they spend, there is a growing need to come up with a better answer to the query. Increasingly, there is pressure on IT managers to demonstrate how exactly their security investments are helping them manage threats to their businesses. Companies want to know if the money they are spending on security is too much, too little or just enough.
Answering the question with any degree of accuracy involves art and luck as much as it does science, say security managers. But by adopting the right approaches, it is possible to arrive at a better answer than some might expect, they say.
Here are five steps to help you determine whether your company is secure enough.
1. Decide how secure you want to be.
To know whether your security controls are meeting business objectives, you first have to know how secure you want to be, says Krag Brotby, a consultant at the Information Systems Audit and Control Association (ISACA) and author of several books on security governance models.
There is no such thing as 100% avoidance of all risk, so the goal should be to decide how much you are comfortable with, he says.
"People often talk about acceptable risk," says Brotby, but what you really should focus on is acceptable business impact.
In other words, exactly how much disruption is your business willing to endure from a security compromise before it invests in mitigating potential threats? To make that determination, consider these questions:
v How much is the business willing to spend to mitigate a threat that poses a 1-in-10 chance of causing a business disruption worth about $2,000?
v How much would it be willing to spend on the same threat if it was likely to result in $10 million in damages?
v How long can a critical system be down?
v What sort of recovery-time objectives need to be met?
v What, if any, are the regulatory and industry compliance obligations?
"These are the type of questions that need to be asked at the executive level," Brotby says. "By the time you are through this negotiation process, you have a very strong indication of the acceptable level of impact" and can plan for the future accordingly.
2. Get a handle on asset value.
To manage risk, it's not enough just to know how serious a threat is, says John Meakin, group head of information security at Standard Chartered Bank. You also need to understand the probability of that threat actually being exploited in your environment, the value of the assets that are the targets of the threat and the likely effect on your business. Only then can you really know if the cost involved in mitigating a threat is justified, he says.
That approach has allowed Standard Chartered to do things like defer installing security patches — even critical ones — on some systems because it decided that the effort was not worthwhile, based on the actual risk.
Similarly, it has allowed the bank to permit unauthenticated access to some of its internal systems because there are enough compensating physical security controls.
"Once you use a risk-driven approach, it actually is incredibly liberating. It allows you to challenge some of the long-held rules" related to the use of security tools, Meakin says.
Core to this approach is the need to understand asset value, he says. Not all IT systems are created equal, and not all of them present the same risks or have the same level of exposure to threats. Therefore, it's important to assign a business value to the IT assets in your organization, says Meakin.
Asset value is based on factors such as the criticality of applications or the services supported by an IT asset and its interdependencies with other applications and infrastructure components, he says.
For instance, an Active Directory server that supports multiple business-critical applications would likely be considerably more important than a server running an e-mail application, from a business continuity standpoint.
3. Implement a control framework.
Once you have a good idea of the desired state of security, choose the most appropriate set of technology, management and process controls to help you get and stay there.
Perhaps the most efficient way of doing this is to implement an internal framework that maps business and risk management requirements to their appropriate IT controls, says Eric Litt, chief information security officer at General Motors Corp.
"In order to make good decisions, you need to have a framework for your security program," he says.
Standards such as the Cobit control framework, ISO 17799/27001 and COSO can help IT organizations identify the controls that will help them meet their particular business needs and comply with regulatory requirements, Litt says.
"You get every single tool underneath the sun," he says. "That's what these frameworks provide for you."
The ISO 27001 and 27002 frameworks can help a company develop policies, procedures and processes for meeting its risk management and compliance objectives, Litt says. They also provide a list of technology controls that need to be used to meet those objectives.
For example, the frameworks can be used to decide the appropriate tools to meet an internal data access control objective or to comply with a statute that requires data logging and auditing capabilities.
A formal framework gives companies a way to quickly assess how effectively their controls are working, because each security control is mapped to a specific business or compliance objective, says Marc Othersen, an analyst at Forrester Research Inc.
"It shows why a control is there in the first place. It links security controls to IT risks and shows what would happen if a particular control fails," says Othersen. "The IT risk management goal is to put context around a control failure."
4. Measure everything.
Use metrics to ensure compliance with control objectives. The audiences for such metrics and the purposes those metrics serve can vary, so it's important to ensure that all aspects of an IT security program are measured.
A metrics program that is focused purely on operational data — such as firewall log data or antivirus data — offers no navigational or management metrics, says ISACA's Brotby.
"If I don't have good policy compliance, is it because people don't know how to do it or because they are ignoring my policy?" he says.
To understand such issues, GM has established a four-tiered metrics framework to collect and analyze performance data on multiple aspects of the company's information security program.
GM's Metrics Framework
The audiences for information security metrics and the purposes those metrics serve can vary, so it's important to ensure that all aspects of an IT security program are measured. The layers on the GM pyramid do not represent a hierarchy; they are simply used to separate metrics by purpose and by audience. The minute-by-minute operational metrics, for example, help IT managers determine whether security tools are working as intended. The process layer helps the company decide whether course corrections are needed. The executive layer helps the information security team communicate with top management.
EXECUTIVE METRICS
(e.g., return on investments, and areas of overinvestment or underinvestment)
PROGRAM METRICS
(e.g., effectiveness of security training, governance and compliance programs)
PROCESS METRICS
(e.g., effectiveness of a security change-control process or an event remediation process)
OPERATIONAL AND TACTICAL METRICS
(e.g., incident logs, antivirus statistics, security tool uptime, software patch availability)
The right metrics can help businesses track, trend and report on security performance, says Ed Cooper, vice president of marketing at Skybox Security Inc., a vendor whose risk-modeling products are used by organizations such as Standard Chartered Bank. The trick is to know which metrics make sense for each stakeholder, how to gather the information and what language to present it in, he says.
"Everybody looks at risk from their own point of view. Metrics have to be put into some sort of relevancy" for each perspective, Cooper says.
5. Monitor all controls.
Implementing controls for dealing with security threats is one thing. Testing, monitoring and validating them is another. "If you have key controls on critical processes, you need continual monitoring to make sure they are working," Brotby says.
This sort of monitoring can be part of a broader IT governance program or compliance and auditing effort.
Often, many of the controls that companies are using to manage risk were originally implemented in response to some tactical issue. Many companies, for instance, have implemented network behavior analysis tools in response to concerns over so-called zero-day threats that take advantage of unpatched software vulnerabilities.
It's important to tie controls back to a specific business risk and then monitor them to ensure that they are indeed doing what they were intended to do.
"The problem with controls is that they are put in place reactively to a particular problem, and then they pile up, so you get layers of controls that people don't know are controls," Brotby says.
To a large extent, governance is what you are doing when you gather metrics to prove compliance with an internally or externally driven security requirement, Meakin says.
"Compliance means showing these are the risks and these are the controls, and, yes, I have mapped those controls to the regulatory requirement," he says. "The fact I am measuring is a demonstration of proper governance."
Taking such steps will be challenging for large companies where the security environment has grown in response to tactical considerations as opposed to strategic ones.