| Previous | Table of Contents | Next |
In this final part of the book, you will first learn tips for handling intrusions. Hopefully, the previous chapters have convinced you to deploy an IDS. By doing so, you will have access to much more data when handling a security incident. After covering incident responses, we will close by reviewing the role of intrusion detection products in your environment. You will also have a chance to review shortcomings of IDSs and consider how they might be positioned in the future. By the time you finish reading this part, you will be familiar with:
By now, you probably realize that no perfect solution for security exists. Given all of the possible tradeoffs you must make, and all of the potential areas in which you or a vendor can make a mistake, someone always can sneak through a hole. The attack can come from the inside, or the attack can originate from the outside and be targeted at your public Internet presence. In this chapter, you’ll discover some of the options for when your buddy shouts across the room, “We’ve been hit!”
The three main topics to discuss about incident handling are as follows:
The worst thing you can do is make hasty decisions when you’ve been attacked. Know in advance what steps to follow. Quite simply, create a plan ahead of time. You can prepare your team for a security breach by adhering to the following guidelines.
Create an incident response team and assign specific responsibilities to team members. Provide backup personnel for each member as well. If you can afford external expertise, such as that provided by IBM’s Emergency Response Service or other consultants, involve them as well. Document each member’s role and post contact information at key locations in your site. If you are part of a multinational corporation, ensure that any country-specific requirements are handled by allowing for national language differences, time zones, and holidays. Your team should have 24-hour coverage.
Create and publicize a site security policy. Make sure that people support the policy by soliciting input, explaining the tradeoffs you make, and emphasizing the financial consequences of lapses in security. Obtain the backing of the appropriate corporate executives in your organization. If you detect that an intruder has gained access to the payroll system, no roadblocks should hinder your ability to handle the incident. Get authorizations and exceptions worked out in advance. The last thing you want to do is sit idly by while internal bureaucracy prevents you from saving the company from disaster.
Be ready with plenty of spare tapes or other backup media. When you’re hit, you’ll want to get a snapshot of the environment. Make sure that the response team has easy access to product media as well, in order to restore contaminated systems. If necessary, designate victim machines in advance. You do not want to be waiting for someone to find the keys to unlock the victim’s physical control device. These systems are like fire-fighting equipment—they should be ready for action at any moment.
Document your environment in advance. Know where all the firewalls, routers, modem pools, and other critical systems are in your network. Know the physical and logical connections for these systems. If your response team does not know the environment, they can’t protect it. As before, access to these resources is mandatory. If the routers are behind a locked door, you either need ready access to that room or a good fire ax to knock the door down. Should network administration at your site be shared with other authorities or departments not under your control, develop cooperation procedures in advance.
As in any endeavor, practice makes perfect. Train response team members on the latest intrusion techniques. Knowing what to look for in advance will help you detect intrusions sooner. Many people enjoy penetration testing when it’s endorsed by management. There is something exciting about sleuthing around and trying to avoid detection. Uh oh…those statements are not intended to encourage you to hack.
Rehearse your responses by creating sample intrusion data that the team can analyze. Think of response team training as a class in which everyone learns and in which the role of teacher can change from week to week. Decide in advance who in the team will be involved in the evaluation of the incident, and who will be busy watching for other problems. The team should not be a chaotic one in which everyone pours through source code or log files looking for evidence or data. Manage the team like any software development project and allocate specific assignments for team members. Measure and constantly evaluate your progress. You can set interim goals, such as “If we don’t discover how the break-in occurred and repair the problem in one hour, we’ll need to shut down the network.” Practice under the same conditions that you expect to encounter. If your team is aggressive enough, a simulated midnight raid will really test their determination and skill. Just don’t get too carried away. Training isn’t boot camp.
Document and conduct regular reviews of the response process. Update the process, the roles and responsibilities, and the team contact information so that it is always accurate. People come and go in the organization, so the process documentation for your responses should reflect changes in the organization and changes in policy. Make the document readily available. Publish it on a Web site, keep hard copy available in easily accessed locations. Another way to get buy-in from other employees is to designate and train incident response deputies. You probably have seen plenty of Westerns in which a shopkeeper or farmer displays elation at being deputized by the resident sheriff. Things haven’t changed that much. The security and network specialists in a company are not always viewed with admiration. Giving employees from other departments a chance to share in the responsibility for incident responses is good for a number of reasons you probably can think of on your own.
| Previous | Table of Contents | Next |