Barriers to Success

Even after the team is formed, training has begun, and the team is managing incidents, there are still obstacles to overcome en route. The success or failure of the team and the incident response process depends on dealing with these obstacles. Some might be impossible to overcome, but the team (and its stakeholders) must, as a minimum, address the problems and develop strategies for coping with them.

The most effective way to overcome the following obstacles is through a competent, efficient, and timely incident response process. Dealing with incidents promptly and effectively will go further in selling the team to stakeholders and defusing potential conflicts than will anything else. Conversely, a poorly managed incident will cause harm to the team and its reputation, harm that no amount of good will or good intentions can fix.

Budget

Lack of funding is typically the major obstacle. A team might be formed as a response to an incident. The company might have good intentions, might acquire excellent people, and might give them the time, training, and equipment they need. Unfortunately, security all too often is one of the first items reduced in the budget process, and the team might be an attractive target.

The team’s own success often works against it. An incident response team might mitigate the impact of several small incidents. When the budget is reviewed, management might simply feel that there have been no incidents to speak of, so there is money to be saved in this area.

Security is inherently hard to quantify. One of the major problems in information technology as a whole is to define cost savings or improved productivity. Whereas the impact of a new machine on the shop floor might be obvious, adding email connectivity to all managers might be much less so. The cost savings for information technology tend to be soft, and productivity typically tends to be seen in terms of jobs changing function as opposed to workers producing more direct output.

In the same way, security does not directly produce revenue. Although it might save large amounts in the long run, these savings are extremely hard to define. Cost savings typically come in the form of avoiding large payments as opposed to actual reductions in operating costs. For example, good security might help shield the company from lawsuits or might reduce the amount of recovery costs incurred after an incident. It might even include such unquantifiable items such as opportunity costs. When distributed denial-of-service attacks hit an e-commerce site, to what extent does good security allow the site to remain operational for customers to continue to come (or did poor security allow customers to visit other sites instead)?

Good record keeping during incidents is valuable not only to quantify the cost of the incident for potential litigation, but also to help develop data on cost savings. The incident response team should address costs and potential savings early in its formulation and should develop a process to track these items (within the corporate accounting system) for use in later budget cycles.

Management Reluctance

Unfortunately, incident response is viewed as simply another overhead function. Managers might be unlikely to support another source of overhead when revenue centers might be competing for the same resources. As in the budget process, managers might believe that incidents do not happen or only happen to others.

Users might be reluctant to call on the incident response team if they are unfamiliar with its capabilities or charter. They might fear the perceived consequences of admitting that there is a problem more than the actual consequences involved in the issue.

This is primarily an awareness issue. Team leaders must meet with line unit managers and discuss the team’s capabilities and what it has to offer the business as a whole. Real incidents that have happened recently to the business or to peers can be used to illustrate the severity of the problem. The team, however, must be viewed as firefighters rather than auditors. Managers and users should see them as the people to call when things go wrong, not as people who will come in looking to place blame.

Organizational Resistance

Resistance to a new computer incident response capability might come as other organizations feel threatened. There are almost certainly rival organizations within the company that could feel that incident response should fall within their purview. If the team gets additional resources, other groups might see it as a threat.

Not only will the team find itself competing for critical resources with these other groups, it might also find itself not getting the coordinated assistance required to properly manage an incident.

In Chapter 10,“Responding to Insider Attacks,” the importance of coordinating with physical security is discussed. The physical security organization typically controls all physical access to the facility and might have the data needed to place a person at the keyboard. They might also have trained investigators that can be invaluable in providing support such as interviewing witnesses, interfacing with law enforcement, or securing physical evidence.

IT operations might also feel threatened. They might see the incident response function as a specific criticism of their ability to secure their systems. The team will require extensive support from operations during the course of an incident but must be careful not to alienate them during the investigation.

One-on-one coordination between peers can be extremely helpful in allaying these fears. Managers should meet, discuss their capabilities, and develop methods of providing mutual support during both incidents and normal operations. Peers at the engineering level should ideally do the same. For example, a UNIX security engineer can meet with other systems administrators and discuss common UNIX security problems. He or she might find that the other administrators are unaware of many of these. He or she might also find that some security measures cannot be implemented in the current environment. It is far better to be aware of potential risks ahead of time and to understand the logic that went into accepting those risks than to be surprised during an actual incident. Administrators might also find that some of the security measures might make their jobs easier as well.

Incident response can also assist the physical security people by providing forensics support. If, for example, a person is accused of physical theft of equipment, a forensics examination of the equipment might provide additional evidence. If a person is accused of theft of trade secrets (even if that theft doesn’t involve digital data), an examination of the person’s computer might yield either more evidence or at least more information regarding where and what to investigate.

Politics

It would be wonderful if businesses and organizations had no internal politics. The team, regardless of its skills or capabilities, can become a pawn in a political game. For example, if the team is funded by the information security organization and traditional ill will exists between security and IT operations, it is unlikely that the team will ever be accepted. If the team is formed out of internal audit, line managers might feel threatened.

There are no easy answers to this problem and certainly no “one size fits all.” The only secret to dealing with political issues is to consider them carefully during the formation of the team and address them early. Management and user buy-in are critical to the success.

User Awareness

User training is often viewed as a panacea for security. It is true that many incidents are, in fact, noticed early in their life, but users are often unaware of what they are seeing. Users must be knowledgeable not only about basic security practices such as password choice, but also about what constitutes an anomaly or what might be an incident in the making. For example, many UNIX systems display the last time the user logged on. When the user logs on, if the time displayed is not the same as he or she remembers it (if, for example, the last logon was during the weekend or when the user was out of the office), this information does no good unless the user reports the inconsistent data to someone.

There are many ways to spread the information about the incident response team. The first step is to educate the help desk. These people will field most end user questions first and must be able to recognize the difference between a simple password reset request (“I’ve forgotten my password”) and one that could be caused by an intrusion (“My password doesn’t work anymore”).

The next step is to get the word out to end users. Logon banners can help, but users tend to ignore them over time. Mouse pads or stickers on the monitor are also ways to spread contact information. The team should have an internal web site with an easily remembered URL (such as security.company.com). It should have a central telephone number, again something easy to remember. The number, web site, and team email (perhaps [email protected]) should all be at the front of the corporate phone directory. A team that is not called is every bit as useless as one with no skills.