Enforcing Your Bullet-Proof Security Policy
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.
All users will need to know what's considered the proper use of their account or workstation. This communication can most easily be done at the time a user receives their account, by giving them a policy statement. Proper use policies typically should dictate things, such as the following: whether or not the account or workstation may be used for personal activities (such as checkbook balancing or letter writing), whether profit-making activities are allowed, or whether game playing is permitted, etc.
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:
- 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?
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.
- Protect-and-Proceed Strategy
- If assets are not well protected
- If continued penetration could result in great financial risk
- If the possibility or willingness to prosecute is not present
- 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 Strategy
- 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 possibly 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 penetrator 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 there is willingness on the part of management to prosecute
- If the system administrators know in general 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 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.