Many readers have contacted us recently, interested in information about developing an intrusion detection response plan. People are interested for a good reason - according to available research most of you do not have a written plan.
It is impossible to create a response plan that reflects your organization's values without an accurate risk assessment. You need to know the value of your data and the impact upon business operations if specific systems become unavailable or compromised. Knowing and appreciating the value of your systems is the foundation to know how closely to monitor systems, how quickly to respond to attacks and even how many resources to deploy.
In surveying some of the available documentation for intrusion detection response plans, some of the key components common to many are:
General guidelines and standards of intrusion detection requirements. Each intrusion that occurs is unique and does not necessarily fit the textbook examples of what you are expecting. General guidelines that spell out how long a system under attack can remain plugged into a network, how soon to shut down a compromised host and how quickly to go to backups, can help crystallize response steps for IT workers when they believe systems are under attack but have not identified the source of the problems.
Documentation of tools and training requirements. It is important to document and inventory the tools needed for intrusion response, including ID software, backups and file system recovery tools. There also need to be written requirements for training IT staff how to deal with intrusions. This can be SANS courses, CERT's Software Engineering Institute, training offered for your intrusion detection tools, or even custom training developed in-house. Training should also include some form of regular fire drill. If your organization does not have a formalized Computer Security Incident Response Team I recommend that it be assembled and organized along the lines of "Handbook for Computer Security Incident Response Teams," also from the Software Engineering Institute.
Build an offline kit of standard system utilities. Depending upon how quick you are in detecting an intruder, you may or may not be able to trust normal utilities, for example, on Unix: ls, ps, top, mount, cp, mv or grep, to help you detect tampering. Skilled attackers may substitute their own versions of ls and top, which conveniently filter out rogue daemons they have installed. You should have clean copies of these utilities ready to use.
Incident reporting and contact forms. Documenting incidents is very important, not only as an aid for solving the intrusion problem, but also for an audit trail that may even be used in criminal proceedings. It is critical to capture as much information as possible and create forms enabling users who are not ID specialists to provide as much information as possible. Some of the important elements of incident reporting forms are:
- Contact information for person(s) discovering problem and/or responsible parties.
- Target systems and/or networks. Know all about the systems under attack, including operating system versions, IP addresses and so on.
- Purpose of systems under attack. What are the systems used for (payroll, R&D and so on), as well as some kind of a ranking of the importance of the system.
- Evidence of intrusion. Discover anything that is known about the intrusion, method of attacks used, source IP address of attacker and network contact information for this address.
- List of parties to notify. This can include the technical contacts, internal legal contacts and possibly the legal authorities.
Response steps. After gaining the report of the intrusion, it is time to take countermeasure steps:
Define the type of attack. Is it a denial of service attack? Root compromise? Has the attack destroyed data? Compromised systems? Is the attack ongoing?
Inform users. Systems may need to be quickly shut down, so users should be prepared to close files and look for alternative work options.
Contain the intrusion. Particularly if the attack is ongoing, it is critical to prevent the intrusion from spreading. If the attack is a denial of service, but the security and data of a host system is intact, filtering countermeasures should be employed to prevent the attacker's source address from getting through. If the attack is more serious involving the compromise of local security, the system should probably be shut down, unplugged from the network and restarted in single user mode with tools to analyze the file system, log files and processes.
Identify the source. You can't always expect to be accurate, but you can at least identify the IP addresses that it appears to be coming from. You can then look up the contact information for these IP addresses at ARIN and contact the network administrator. You likely aren't contacting the source, but are probably contacting an innocent third party. However, this person may be able to track down the connection further, or may actually find the attacker on their systems.
Notify all interested parties. Management needs to ultimately make the call if it is safe to bring the system back online and if the attack warrants getting the legal authorities involved.
More detailed repair of the systems, if needed. If the security of a system is compromised, some degree of file repair, extending to restoring from backup, may be required.
Detailed postmortem of the intrusion. Write a detailed report of the intrusion and use the information to find ways to improve the long-term security of the network. Learn from your mistakes and find ways to patch the holes.
Network World Security Alert will keep you up to date on the latest security holes and patches, with daily updates from key vendors, security organizations and Network World reporters. See the latest dispatches from the security here.