Planning responses for different violation scenarios well in advance—without the burden of an actual event—is good practice. Not only must companies define actions based on the type of violation, but it is also important to have solutions ready based on the anticipated kind of user violating the computer security policy.

Answers to the following questions should be a part of a company's site security plan:

• What outside agencies should be contacted, and who should contact them?
• Who may talk to the press?
• When do you contact law enforcement and investigative agencies?
• If a connection is made from a remote site, is the system manager authorized to contact that site?

What are our responsibilities to our neighbors and other Internet sites? Whenever a site suffers an incident that may compromise computer security, the strategies for reacting may be influenced by two opposing pressures.

If management fears that the site is sufficiently vulnerable, it may choose a protect and proceed strategy. The primary goals of this approach are to protect and preserve the site facilities and to provide normalcy for its users as quickly as possible. Attempts will be made to interfere with the intruder's processes, prevent further access, and begin immediate damage assessment and recovery. This process may involve shutting down the facilities, closing off access to the network, or other drastic measures. The drawback is that unless the intruders are identified, they may come back into the site via a different path or may attack another site.

The alternate approach, pursue and prosecute, adopts the opposite philosophy and goals. The primary goal is to allow intruders to continue their activities at the site until the site can identify the responsible persons. Law enforcement agencies and prosecutors endorse this approach. The drawback is that the agencies cannot exempt a site from possible user lawsuits if damage is done to their systems and data. Prosecution is not the only outcome possible if the intruder is identified. If the culprit is an employee or a student, the organization may choose to take disciplinary actions. Site management must carefully consider potential approaches to this issue before the problem occurs. The strategy adopted might depend upon each circumstance or there may be a global policy that mandates one approach in all circumstances. The following are checklists to help a site determine which of the two strategies to adopt.

Protect and Proceed

• if assets are not well protected
• if continued penetration could result in great financial risk
• if there is no possibility or willingness to prosecute
• if user base is unknown
• if users are unsophisticated and their work is vulnerable
• if the site is vulnerable to lawsuits from users, e.g., if their resources are undermined

Pursue and Prosecute

• if assets and systems are well protected
• if good backups are available
• if the risk to the assets is outweighed by the disruption caused by the present and potential future penetrations
• if this is a concentrated attack occurring with great frequency and intensity
• if the site has a natural attraction to intruders and consequently regularly attracts intruders
• if the site is willing to incur the financial (or other) risk to assets by allowing the perpetrator to continue
• if intruder access can be controlled
• if the monitoring tools are sufficiently well developed to make the pursuit worthwhile
• if the support staff is sufficiently clever and knowledgeable about the operating system, related utilities, and systems to make the pursuit worthwhile
• if management is willing to prosecute
• if the system administrators know what kind of evidence would lead to prosecution
• if there is established contact with knowledgeable law enforcement
• if there is a site representative versed in the relevant legal issues
• if the site is prepared for possible legal action from its own users if their data or systems become compromised during the pursuit

Capturing Lessons Learned

Once you believe that a system has been restored to a safe state, it is still possible that holes and even traps could be lurking. In the follow-up stage, the system should be monitored for items that may have been missed during the clean-up stage. It would be prudent to utilize some of the tools mentioned as a start. Remember that these tools do not replace continual system monitoring and good systems administration procedures. A security log can be most valuable during this phase of removing vulnerabilities. There are two considerations here. The first is to keep logs of the procedures that have been used to make the system secure again. This should include command procedures (e.g., shell scripts) that can be run on a periodic basis to recheck the security. Second, keep logs of important system events. These can be referenced when trying to determine the extent of the damage of a given incident.

After an incident, it is prudent to write a report describing the incident, method of discovery, correction procedure, monitoring procedure, and a summary of lessons learned. This will help develop a clear understanding of the problem. Remember that it is difficult to learn from an incident if you do not understand the source.