Let s Not Go There...

Let's Not Go There...

Given the sensitive nature of their data, First Fidelity was lucky. Of course, relying on luck is not a good security approach. Here's what they should have done instead.

Focus on Prevention

Given the alternatives, you're probably wondering why First Fidelity used such a vulnerable configuration. After all, why expose your data to that much risk? The answer, of course, is, "Why not?" After all, there was no way that a hacker could break into their system. Surprisingly, a large number of companies still think this way.

Don't Think, "It Can't Happen to Me"

Many companies honestly don't see computer break-ins as any more likely than hitting the Lotto. Since these companies are so sure that they are somehow immune from hacker access, they don't take even basic precautions. Since it will never happen to them, they don't budget for security. They don't develop incident-response procedures. Therefore, they don't train their staff on how to respond to an incident.

Simple as it sounds, the most important thing you can do to prevent a break-in is to realize that it could happen to you! To prevent it from happening, use your most effective security tool training. Train everyone! From the highest-level manager to the lowest-level data-entry clerk, everyone should know how to protect data from theft, modification, or destruction by unauthorized users. After all, a malicious hacker with too much access could put everyone out of a job!

In a strict sense, unauthorized use is any use of the computer system not specifically authorized by the system administrator(s). Thus, an unauthorized user could be a malicious hacker, a cyber-joyrider, or even an employee who isn't allowed to use a particular system at a certain time or for a certain purpose. In the incident at First Fidelity, the unauthorized user detected could have been any of the above.

As the Computer Security Institute (CSI) discovered in a recent survey, and as illustrated in Figure 1-2, far too many managers are unaware of just how pervasive unauthorized access or misuse is.

Figure 1-2. WWW Site Incidents: What Type of Unauthorized Access or Misuse?

Know When You're Under Attack

The first problem in handling a break-in is to recognize when your system is being broken into! You need to be sure that what you're seeing is a real break-in and not just a hardware or software quirk or bizarre user behavior. Detection software may help to determine if your system is under attack in the first place. Installing detection software before an attack is absolutely critical, however. Consider the recent impact of Code Red. On July 19, 2001, Code Red infected 359,104 hosts, which were compromised in only 13 hours. At its peak it actually compromised some 2,000 new sites a minute, even sites that had detection software installed.

Most Intrusion-Detection Systems (IDSs) can detect the attack only if a signature exists. Sounds silly if you think about it. It's like waiting for a burglar to break into your house before you purchase a lock for the door. Furthermore, once you have a signature installed it is easy for adversaries to launch a new version of the attack and slip by the IDS.

Make sure your IDS can detect new zero-day attacks (sometimes called first-strike, or unknown attacks because they have not yet been reported, they are not publicly known, and signatures do not exist). If your IDS cannot detect zero-day attacks you need to update your architecture. Doing so helps you to protect against attacks that target protocols, like Code Red and Nimda and their variants.

I'm not suggesting that you install detection software on every system on your network. Strategically installing it in key locations (on networks and mission-critical systems), however, can give you the upper hand.

Prepare for the Worst

Although prevention is 80 percent of most cures, there is always the other 20 percent. The truth is that no matter how well you plan, there are always unforeseen problems. Being able to deal with those problems often boils down to having prepared for the unknown. To avoid the situation that First Fidelity found itself in, do the following:

Develop a Written Policy for Dealing with Break-ins

If your company lacks a written policy for dealing with network intrusions, you're not alone. Although we tend to focus on large U.S. companies, slack security extends beyond national borders. A 2001 survey of Canadian firms conducted by KPMG found that only half of the respondents had incident-response procedures for handling e-commerce security breaches.

Hire an Expert If You Need One

Forming an Incident-Response Team (IRT), developing policies and procedures, and keeping everything up-to-date can be a huge task. It takes time, knowledge, and coordination of staff and resources. If you don't have procedures in place and no one in your company has the expertise to develop them, hire an expert. And "expert" does not translate to "hacker." Be careful whom you hire. As illustrated in Figure 1-3, most companies do not hire reformed hackers as consultants.

Figure 1-3. Would Your Organization Consider Hiring Reformed Hackers as Consultants?

There are several companies that take this issue seriously and can provide valuable services. (For details, see Appendix A, "People and Products to Know.")

While developing incident-response procedures for a company several years ago, I talked with an executive from a security consulting company about the backup security expertise they provide. I asked how long it would take if we needed an expert onsite. "We have worldwide coverage," he said, "and can have a team onsite anywhere in the world in minutes to hours, depending on the location." Security companies that offer this type of service are ready and willing to assist, and will send their experts to you immediately if a problem surfaces. They have seen disasters, and they know how difficult it can be to clean up after a serious break-in. It's important to build this kind of relationship before you have a break-in, so that you know someone will be able to respond to your call if, or when, you find yourself in the midst of a disaster.

Get (or Provide) the Needed Training

Even when incident-response procedures exist, system administrators and users may not have been trained in their use. Policies and procedures that aren't clearly understood are not very useful. They may even give everyone a false sense of security. Not only do emergency procedures need to be well documented and distributed, but every computer user in the company from the Chief Executive Officer (CEO) to the data entry clerk needs to know how to implement them. Responsibility for computer security falls on every employee's shoulders.

It's a good idea to test your policies and procedures before an incident occurs. Consider a dry run. You may even want to hire a penetration team to test the security of your site. The Tiger Team can try to break into your site and at the same time test your team's response to a break-in. It's not a good idea to leave people guessing whether this is a real break-in or not, however. In other words, don't cry wolf. If you hire a security consultant to test your site security and response to a break-in, inform the support staff. Let them know that this is a dry run and not the real thing.

Designate a Point of Contact (POC)

During a break-in, the clock never stops ticking. If you have to think about who to call or what to do, precious time slips away. Procedures should designate who needs to be notified of the break-in. Your company should have a Point of Contact (POC) the equivalent of a 911 emergency line that users can call in the event of a break-in.

Understand and Prioritize Your Goals

Your company goals and priorities may be different than those of the guy next door. The bottom line here is that complex incidents don't allow time to think about the priorities. Therefore, your goals during a break-in must already be documented and understood before the break-in occurs.

Knowing your goals is essential to formulating an appropriate plan of attack. The goals appropriate for your network may include some or all of the following:

Protect customer information. You might maintain critical customer information on your network. If a hacker steals, modifies, destroys, or even posts the information to the Internet, you may find yourself in court.

Contain the attack. Prevent the use of your systems to launch attacks against other companies. Sometimes you may need to disconnect a system from the network to prevent further damage and limit the extent of the attack. For example, if you have a customer network (extranet) connected to your network and a hacker obtains access to the system that connects you to your customer's extranet, you must protect your customer's network. If you have to, be prepared (and know how) to pull the plug.

Notify senior management. Management is responsible for the adequacy, accuracy, and reliability of data. If the systems in your company are being broken into, the Chief Information Officer (CIO) should be informed and kept abreast of the situation.

Document the event. Recording all the details may provide management with the information necessary to assess the break-in and could assist in the prosecution of specific individuals.

Take a snapshot of the system. A snapshot is basically a photograph of what a computer's memory (primary storage, specific registers, etc.) contains at a specific point in time. (Sometimes, a snapshot is called a system dump.) Like a photograph, a snapshot can be used to catch intruders by recording information that the hacker may erase before the attack is completed or repelled. As such, a system snapshot provides crucial audit information.

Contact a Computer Security Incident Response Team (CSIRT). It's important to contact a CSIRT (e.g., CERT) during the early stage of the intrusion, because they may have information that can help you bring your intrusion to a close. For example, they may know how to fix the flaw in the vendor's software or hardware that allowed the intruder to access your network. They also compile statistics regarding the total number of break-ins and techniques used by hackers to gain entry. If you have your break-in under control and have fixed the problem that allowed the hacker to gain entry, you should still contact a CSIRT so they can keep accurate statistics. They will not share your company name or tell anyone that you were broken into. Many CSIRTs exist around the globe. For details, see Appendix A, "People and Products to Know."

Identify the intruder. This entry seems obvious, but it isn't always at the top of a list of priorities. Sure, it's nice to get even. But, it's even more important to get by. Don't get so caught up in trying to catch the intruder that you compromise the integrity of your data. If you cannot easily trace back an attack on your own network, you need to consider how important it is to be able to do so. Some vendors offer software that can easily track back attacks (as long as software is installed upstream). This should be strategized at the executive level of the organization.

Know who's responsible for what. Having clear-cut responsibilities removes any ambiguity that can arise. Knowing who's responsible for what facilitates speed and increases the likelihood of identifying the culprit.

Know whom you can trust. The actual break-in was only part of the real problem at First Fidelity. The other part was a lack of trust between key players. If we assume that Mike was guilty, the trust issue becomes a personnel problem. Were appropriate background checks conducted? As much as it seems an invasion of privacy, a thorough background check is essential for anyone who will be responsible for computer security.

If we assume that Mike was innocent, the trust issue resurfaces as a communications problem. Why didn't anyone call Mike early on? Was Dave uncomfortable speaking to Mike because Mike was from security? A phone call could have opened up communication channels and perhaps avoided the finger-pointing that ended up obscuring the investigation. Perhaps there was a history of unspoken mistrust between the system administrators and security team. Employee resentment or mistrust of the company's security team is a serious issue that needs direct attention. Ignoring such a problem puts the company at risk. A procedure for handling a conflict of interest would also have helped Dave. He would have been able to sidestep the security team by escalating the investigation to a higher level of authority.

React Quickly and Decisively

As the T-shirt so eloquently puts it, "stuff" happens. So, if a hacker breaks into your system in spite of your thorough safeguards, take at least the following measures.

Act Quicky!

The surest truth in security is that the longer you take to react, the more likely it is that the intruder will escape unharmed with your data unidentified and prepared to strike again later.

Follow the Game Plan

The whole point of having an incident-response procedure drawn up in advance is so that you (or your staff) can react immediately without having to think about it. Don't second-guess that plan just do it!

Record Everything!

Once a system is suspected to be under attack, it's extremely important to obtain information. Take a snapshot of the system. Any audit information you can gather is valuable and may ultimately help identify the source of the attack and prosecute the intruder.

Escalate the Problem When Necessary

Escalation is the referral of the problem to a higher level of authority. The incident-response procedure should indicate under what circumstances the problem should be escalated both internally and externally.

Internal escalation the referral of the problem to a higher level of authority within the company is required whenever the scale of a break-in goes beyond the knowledge base of the support team. External escalation calling in an outside expert is warranted when the incident is too complex for the internal team.

It's also important to have a plan in place for conflict-of-interest escalation. This type of escalation is needed when any members of the support team are suspects. (In the case of First Fidelity, the main suspect was part of the security team. Conflict-of-interest escalation could have alleviated a lot of stress and later personnel problems.)

Keep Good Records

It is wise to develop a reporting mechanism for all break-ins, even those that are resolved without apparent damage to the system. Break-in reports provide an overall picture of the status of network security. Break-in reports can also help pinpoint areas of your network that are vulnerable to security breaches.

Follow Up

After a break-in occurs, you need to assess what happened. Did your staff follow the goals and priorities? What lessons did you learn? What would you do differently next time? Have your systems been restored to a safe state no back doors?

After any security incident, do the following:

Re-examine Your Policies and Procedures

Thoroughly examine how well your procedures worked and decide whether you need to make changes for the future.

Report the Incident (and How You Handled It) to Management

If you are management, insist that all incidents be reported to you. A standard procedure for reporting any and every break-in provides an overall picture of the status of network security. If reports show that break-ins are chronic or increasing in frequency, it's obvious that security measures need to be updated or augmented. Report protocols can also be used to identify areas of the network that intruders might be targeting for data (e.g., source code for your new chip design).

Have Another Look at That Budget

On paper, everybody loves security. But when it comes to funding, security planning and response are often shorted. "The budget is tight this quarter, so management says incident-response costs will have to wait." The next thing you know, a year has gone by and the procedures still haven't been written.

The importance of security is easily overlooked. Every once in a while, a major break-in makes some poor soul's company the focal point of 60 Minutes or CNN. Everybody is suddenly very anxious to set up security measures and make sure that the same thing can't happen to them. Then the spotlight dims, the media go away, and the hacker goes to jail or disappears into cyberspace. Security becomes a nonissue, and management is once again reluctant to include it in the budget.

Marcus Ranum, often referred to as the father of firewalls, once said, "When it comes to security, it usually takes a bullet to the head of the guy standing next to you before management takes notice." If you are a manager responsible for security, don't take the "bullet" approach to security. The truth is, it costs much more to clean up after a serious break-in than it does to put defenses in place. To minimize those costs in the future, be sure to include requests for adequate funding for security requirements.

Checklist

Use this checklist to determine whether your company is prepared to respond to a break-in. Can you mark a "Yes" beside each item?

___ Do incident-response procedures exist?

___ Are procedures understandable and up-to-date?

___ Have all key personnel been trained in using the procedures?

___ Do the procedures include instructions for contacting a security expert 24-hours-a-day, 7-days-a-week?

___ If the security expert does not respond, does a procedure exist for escalating the problem to management?

___ Is there a procedure for determining when to contact outside help, and whom to contact?

___ Do procedures include notifying the CIO immediately when any break-in occurs, and again when the break-in is resolved?

___ Has adequate funding been allotted for developing and maintaining incident responses to break-ins?

___ Have key personnel actually attended all required training sessions?

___ Have appropriate background checks been conducted on key personnel?

___ Are communications between and among the system administration and security groups flowing smoothly?

___ Are disaster-recovery plans in place?

___ Do all systems have adequate security controls? ("Adequate" here means proven adequate by formal audit results.)

___ Are system audit logs enabled?

___ Are system logs periodically reviewed?

___ Are the tools needed to detect an intrusion installed and operational?

___ Can the detection software installed on your network detect unknown attacks?

___ Can you detect and prevent attacks on the network and the host (a layered approach to detection)?

___ Are attacks easy to trace back on your network?