Communicating to Users
The site security policy should include a formal process, which communicates the site security policy to all users. In addition, an educational campaign will make users aware of how computer and network systems are to be used, and how to protect themselves from unauthorized users.
Users should be told how to detect unauthorized access to their account.
If the system prints the last login time when a user logs in, he or she should be told to check that time and note whether or not it agrees with the last time he or she actually logged in.
Ideally, the security policy should strike a balance between protection and productivity.
Responding to Violations
Upon realizing a site security violation, an organization will select a number of responses - both good and sub-optimal. To this end, you should plan responses for different scenarios without the burden of an actual event.
Not only do you need to define actions based on the type of violation, you'll also need to have a clearly defined series of actions for users who violate your computer security policy.
When a policy violation has been detected, you should immediately invoke the pre-defined define course of action. Next, you'll need to have an investigation performed to determine how and why the violation occurred, and what is the appropriate corrective action. The type and severity of action taken will vary depending on the type of violation that occurred.
Discovering Violations: Choose Your Strategy
Once you've determined that the violation it's being perpetrated by someone outside the organization, you'll have to decide what aspect of your security plan should be put in motion. So, you'll need to make sure you site security plan can answer the following questions:
If management fears that the site is sufficiently vulnerable, it may choose a protect-and-proceed strategy. This strategy's primary goal includes protecting and preserving the site facilities and keeping users from experiencing any interruptions, if possible. Active 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. Unless the intruder is identified directly, he or she may come back into the site via a different path or may attack another site.
On the other hand, the pursue-and-prosecute strategy adopts the opposite philosophy and goals. The primary goal allows intruders to continue their activities at the site until the site can identify the responsible persons. Law enforcement agencies and prosecutors endorse this approach. However, these agencies can't exempt a site from possible user lawsuits if damage occurs 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, your organization may choose to take disciplinary actions. To this end, the computer security policy will need to spell out the choices and how they will be selected if an intruder is caught.
Site management will need to carefully consider their approach to this issue before the problem occurs. The strategy adopted might depend upon each circumstance. Or there may be a global policy mandating one approach in all circumstances. You'll need to examine the pos and cons thoroughly. And you'll have to make the users of the facilities aware of the policy so they understand their vulnerabilities no matter which approach is taken.
The following checklists will help a site determine which strategy to adopt: Protect-and-Proceed Strategy or Pursue-and-Prosecute Strategy.
Capturing the Lessons You've Learned
Once you believe that a system has been restored to a safe state, you may not be completely off the hook - there may still be holes and even traps lurking in the system. You'll need to have the system monitored for items that may have been missed during the cleanup stage.
You'll find a security log to be a valuable asset while vulnerabilities are being removed. Keep logs of procedure that have been used to make the system secure again. This information should include command procedures (e.g., shell scripts) that can be run on a periodic basis to recheck the security. Keep logs of important system events. Reference these events to determine the extent of the damage of a given incident.
After an incident, you'll need to write a report describing the incident, method of discovery, correction procedure, monitoring procedure, and a summary of lesson learned. This exercise will provide you with a clear understanding of the problem.
Elizabeth M. Ferrarini is a free-lance writer based in Arlington, Massachusetts.
Editor's note: This article first appeared on Crossnodes.com, an internet.com site.