To create a good site policy for computer security, you need to do two things: determine your company's expectations of proper computer and network use, and define the procedures to prevent and respond to security incidents. To this end, you, working with your policy committee, need also to consider and to agree upon the following:
The organization's goals and direction. A university with building spread across a large campus will have different security concerns than a corporation in an office park. The site security policy has to conform to existing policies, rules, regulations, and laws the organization must adhere to. You'll, therefore, have to identify and consider these things while you develop the policy. If your network extends outside your facility, you'll have to consider security on perhaps a global scale. The policy should address local security issues caused by a remote site, as well remote system security issued caused by a local host or user.
Next, you'll need to look at whom, beside yourself, will devise the network site security policy. Policy creation should consist of a representative group of decision makers, technical personnel, and day-to-day users from different levels within the organization. Decision makers should have the power to enforce the policy. Technical personnel should advise on the ramifications of the policy. Likewise, day-to-day users should have a say in how easy or difficult the policy will be to carryout.
Developing a security policy requires that you identify the organizational assets, identify the threats, evaluate the risk, evaluate and implement the tools and technologies available to meet the risks, and develop a usage policy. In addition, you'll need to devise audit procedures for how to do timely reviews of the network and server usage, and how to respond to violations or breakdown. Finally, you'll need to communicate information the policy to everyone (both employees and contractors) whom uses the computer network. Plan to review the policy regularly.
Identifying your organization's assets
Your very first step in creating a site security policy consists of compiling a comprehensive list of all the things that need to be protected. Items to consider include:
Hardware: CPUs, boards, keyboards, terminals, workstations, personal computers, printers, disk drives, communication lines, terminal servers, routers. Software: source programs, object programs, utilities, diagnostic programs, operating systems, communication programs. Data: during execution, stored on-line, archived off-line, backups, audit logs, databases, in transit over communication media. People: users, people needed to run systems. Documentation: on programs, hardware, systems, local administrative procedures. Supplies: paper, forms, ribbons, magnetic media.
Evaluating the risks
A remote access email gateway will enable your employees to get to their email while they're away from the office. This gateway might also provide intruders with a side door to your network. Likewise, a FTP server will enable customers anywhere in the where instantly to get fixes for your software products. On the other hand, intruders might use your ftp server as an electronic tunnel to valuable corporate data.
With worldwide connections, someone can get into your system in the middle of the night when your building is locked up. The Internet allows the electronic equivalent of an intruder who looks for open windows and doors. Now, a person can check for hundreds of vulnerabilities in just a few hours.
Risk analysis involves determining what you'll need to protect, what you'll need to protect it from, and how to protect it. This process forces you to examine all of your risks, ranking each one by severity level. Possible risks to your network include:
Unauthorized access. Unavailable service, which can include some or all network services, corruption of data, or a slowdown due to a virus. Disclosure of sensitive information, especially that which gives someone else a particular advantage, or theft of information such as credit card information.
Once you've put the list together, then you'll need a scheme for weighing the risk against the importance of the resource. This exercise will enable the site policy makers to determine how much effort to spend protecting the resource.
Defining a policy for acceptable use
To define a policy for how users will interact with the network, you'll need to consider the following in a policy for acceptable use.
Who is allowed to use the resources? What is the proper use of the resources? Who is authorized to grant access and approve usage? Who may have system administration privileges? What are the users' rights and responsibilities? What are the rights and responsibilities of the system administrator vs. those of the user? What do you do with sensitive information?
For example, you'll want to cover the following topics when defining the users' rights and responsibilities:
What guidelines you have regarding resource consumption (whether users are restricted, and if so, what the restrictions are). What might constitute abuse in terms of system performance. Whether users are permitted to share accounts or let others use their accounts. How secret users should keep their passwords. How often users should change their passwords and any other password restrictions or requirements. Whether you provide backups or expect the users to create their own. Disclosure of information that may be proprietary. Statement on Electronic Mail Privacy (Electronic Communications Privacy Act). Specifically, does the company consider electronic mail private to each employee, or do they consider it the property of the organization? Your policy concerning mail or postings to mailing lists or discussion groups (obscenity, harassment, etc.), and on representing the organization to these areas. Policy on electronic communications: mail forging, etc.
You'll also need to define who'll interpret the policy -- an individual or a committee. No matter how well written it is, the policy will require interpretation from time to time, and this body will serve to review, to interpret, and to revise the policy as needed
Auditing and reviewing
To help determine if there is a violation of your security policy, you'll need to depend on the tools included with your computer and network. Most operating systems store numerous bits of information in log files. Examining these log files regularly will often provide the first line of defense for detecting unauthorized use of the system.
Compare lists of currently logged in users and past login histories. Most users typically log in and out at roughly the same time each day. An account logged in outside the normal time for the account may be in use by an intruder. Many systems maintain accounting records for billing purposes. These records can also be used to determine usage patterns for the system; unusual accounting records may indicate unauthorized use of the system. System logging facilities, such as the UNIX syslog utility, should be checked for unusual error messages from system software. For example, a large number of failed login attempts in a short period of time may indicate someone trying to guess passwords. Operating system commands which list currently executing processes can be used to detect users running programs they are not authorized to use, as well as to detect unauthorized programs which have been started by an intruder. By running various monitoring commands at different times throughout the day, you'll make it hard for an intruder to predict your actions. While it may be exceptionally fortuitous that an administrator would catch a violator in their first act, by reviewing log files you'll have a very good chance setting up procedures to identify them at a later date.
Security is a dynamic process. Since it's getting easy to break into network sites through easily available, point-and-click packages, you'll need to do regularly reviews of your network. To this end, you'll need to assemble the core team or a representative subset to review how well things are working, what are the latest threats and security tools, and what are the risks against new assets and business practices.
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.
Once you've determined that the violation is 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?
Whenever a site suffers an incident compromising computer security, two opposing pressures may influence the way the organization reacts.
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. On the other hand, 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
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.
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 lessons learned
Once you believe that a system has been restored to a safe state, you might 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 an IT consultant analyst from Boston.