Main

T.O.C.

Part 1
Defining
Managing
Securing
Auditing
Training

Part 2
Overview
Gen. Sec.
LAN Sec.
Peri. Sec.

Part 3
Checklist
Sec. Pol.
Pwd Pol.
Budgets

Glossary

Biblio.

Managing Risk

You’ve learned that security is a process. You’ve learned there are some real threats to your library’s network. You’ve hopefully made a decision to minimize as much risk as possible. All of this can be called managing security, or managing risk. In this chapter I’ll present information to get you started on the road to securing your network: determining which measures to implement and how to carry that through; in other words, how to manage your library’s program of network security.

How to Secure Resources

Securing a computer network is the process of mitigating risk—bringing risk down to a manageable level. Another way of saying this is that network security is about balancing the consequential cost of dealing with an attack against the cost of implementing sufficient security measures to prevent, or reduce the likelihood of, an attack. Securing a network is important because there is a very real cost in recovering from an attack.

On the other hand, there is a definite cost in implementing security measures as well. Ideally, in securing network resources, we would like to spend just a little on security in order to keep from having to spend a lot on recovery. The work is a balancing act of cost versus risk.

Once one has a grasp on the necessity for network security—and what may occur if the network is left unsecured—it is a lot easier to begin the process of managing risk to network resources. In the last chapter we dealt with the first step: identifying threats. In this chapter we introduce the other major aspects of risk management:

• Assessing Risk—determining what to secure

• What are the threats present in your network environment

• What are the most significant risks in your network environment (review an appropriate checklist)

• How much latitude local users will have in using public workstations

• How much latitude staff and volunteers will have in accessing the network

• Developing a Security Policy

• Updating Staff Skills (providing/scheduling training: to recognize threats, enforce security policy)

• Monitoring Security

• Regularly Reviewing Security Resources for other measures to implement

• Repeating the Process

return to top

Assessing Risk—Deciding What to Secure

Your security management program begins the moment you assess the threats to your network to determine which are most likely to be realized in the form of an attack. Let’s call this step one: securing your network. In fact, let’s build a list of steps you will go through in securing your network:

1. Assess the threats to your network.

2. Assess the vulnerabilities open to attack. This requires investigating the possible vulnerabilities using a standard list of items that describe them.

3. Evaluate which vulnerabilities are most likely to be exploited by the threats you’ve identified. Vulnerabilities that can be exploited create the risk of an attack occurring. Vulnerabilities that are easily or conveniently exploited create great risk.

4. Estimate the cost of securing the vulnerabilities you’ve identified.

5. Determine how much money you have available for implementing security.

6. Prioritize the risks. Use the cost estimate you created in step 4 to decide which vulnerabilities you can reasonably secure. See "Determine Priorities" below for more details.

7. Hire someone (or have staff trained) to implement security measures that eliminate or minimize the vulnerabilities you’ve decided to secure.

8. If financially possible, have the security implementation audited to verify that your security decisions are implemented as specified.

Determine Priorities

It is step six above that is the most difficult, because there are multiple ways to categorize and prioritize risk. As mentioned, you must determine the cost of security first. If it costs more to secure a vulnerability than to recover from an attack on it, you will likely decide not to secure it. Likewise, if the risk is extremely low (the likelihood of its being exploited is low), then you may also decide not to secure it. On the other hand, even if the risk is very low, if the exploitation of the vulnerability will result in an extremely expensive recovery, then the vulnerability should be secured.

After this raw cost basis, you must prioritize the remaining areas. I’ve identified four common-sense principles used generally to prioritize actions. Let’s see how these work in the context of computer networks.

• Secure the simplest things first

This principle sounds good up front, but it has a weakness. Many involved in securing networks know the simplest things aren’t always the least expensive. Some security measures are simple only when you have sufficient knowledge to implement them. Unfortunately, obtaining someone with the requisite knowledge may not be inexpensive. So, given the limited budget circumstances most libraries find themselves in, simplicity may not be the best criterion to use. A second principle that might be more appropriate in determining priority is:

• Secure the least expensive things first

Expense—or lack of it—is also a good criterion, but it has limits as well. Someone will point out that the least expensive things don’t necessarily represent the most serious things. For these practitioners, it may be more appropriate to prioritize risk by a third principle:

• Secure the most serious things first

Believe it or not, there may be a fourth camp of security experts. These recognize that the most serious things are not always the things most likely to occur. They advocate this principle:

• Secure first the things most likely to result in an attack

This is a great deal of categorizing! In fact, there are 24 different ways to arrange just these four categories to determine priority. Thankfully, you get to choose which elements carry the most weight for the purposes of evaluating priority in your library. For right now, let’s just say this: if securing a vulnerability includes any three of the four of these principles (e.g., a very serious vulnerability, that is likely to be exploited and is inexpensive to implement), then it should have a very high priority for security.

Once you have determined priorities, it is very important to document the library’s decisions, especially when deciding not to secure some areas (some will say it is important to document all the security decisions, describing why security measures are implemented or why they are not). This documentation will be used in future reviews to determine which environmental conditions might have changed and whether the reasoning behind the decision is still valid.

Least Privilege

There is one more common security principle we need to introduce here because it impacts risk, even though it has nothing to do with prioritizing them. Rather, it has to do with the access a user has to network resources. It’s called the least privilege principle: when creating new network user accounts, grant the user the lowest level of privilege necessary to perform his job functions properly or use the available network resources appropriately.

For example, this means that you may be creating a security risk by granting a staff member the right to execute backup software on the server when the user has no responsibilities for backing up systems. The fact that the staff person has this right may lead to unintended access to other information—a password file, for instance.

This principle comes into play for the person actually performing the initial configuration of your library’s network and for the person charged with creating and maintaining user accounts for the library network.

return to top

A List of Suggested Priority Areas to Assess

While you could (and should) go through a long list of security measures, such as the Network Security Checklist included in Part III, it’s usually helpful to have a starting point. Here is a list of areas where attention to network security will provide the most benefit for a small investment in time and money. This can be considered a minimal security configuration suitable for those libraries where there is little risk of patron tampering.

• Theft and electrical protection, including a surge protector or UPS on all workstations, servers, and network equipment; placement of equipment (line-of-sight considerations, etc.) is also a factor

• Workstation security, including proper file system protection, through the use of third-party security software (such as WinSelect Policy+Kiosk, Fortres 101, or FoolProof Security), security hardware (such as Centurion Guard), or Windows itself if Windows NT Workstation/2000 Professional is used (through policies, profiles, and permissions)

• Proper file system protection on servers, with severe limitations placed on the patron account(s)

• Anti-virus software installed on all workstations

• Strong password selection on all staff and administrator accounts

• Secure configuration of the server Administrator account

• Proper router/firewall configuration. This item is best considered before equipment is purchased. Firewalls, which are generally used to keep the bad guys on the Internet from accessing any computers on your local network, come with different capabilities. It’s important that the firewall be configurable to prevent many common Internet-based attacks. It should also provide a network port called a DMZ to offer protection for publicly accessible servers, like a web server. There are several configuration issues to address here.

• Updated operating system software on all workstations and servers, and updated web server software if a web server is used.

• Do not install a web server in this configuration unless absolutely necessary. Providing access to web services over the Internet requires a more complicated configuration of the router/firewall and introduces several points of weakness into the network.

Of these items the first four will potentially be most expensive. If library computers are not covered by city/county or building insurance policies, such a policy might be investigated. Insurance policies should provide replacement costs and should cover theft of the equipment, accidental breakage, and damage due to lightning or other electrical anomaly. Workstation security software must be purchased, or a technician must be hired to configure tight security through Windows NT Workstation (2000 Professional).

However, the other items can be implemented with little or no additional cost to the library. The router/firewall configuration cost should be included with its purchase. Password selection can be taught to staff, as can proper procedures for updating, or "patching," server and workstation operating systems. The Administrator account configuration should have been included in the initial server and workstation configuration. If it was not, then, with a little staff training, the cost for reconfiguring it is minimal.

The Need for a Security Policy

In order to secure all the areas of your network adequately, it is necessary to determine how the resources will be used. To which resources will your staff, volunteers, and patrons need direct access? Which patron activities will be permitted and which will be restricted? What are the responsibilities of each of the constituent groups (staff, volunteers, patrons, contract technicians, city staff)? These questions point to the need for a written guide describing intended/appropriate access to and use of network resources.

A document created for this purpose is generally called a network security policy (referred to hereafter simply as a security policy). Security policies are still uncommon in local government agencies, but they are becoming quite common in the business sector. In libraries, the security policy will have some areas of overlap with the acceptable use policy. Whereas an acceptable use policy is generally aimed at patron use of the network, a security policy is much more comprehensive, including rules and guidelines for all access to and use of the network.

Just like an acceptable use policy, the security policy will only be useful if it is developed as an administrative guide rather than treated as just another task to be completed. There is a great need in small public libraries for such policies because they provide continuity, consistency, and a basis for enforcing staff and patron conduct on the network. Developing a security policy also makes an administration really think about the use of the network. The security policy encapsulates the decisions made by library administration regarding proper use of the network; therefore, future library directors don’t have to wonder why certain aspects of the network are implemented the way they are.

Libraries will benefit from doing a security policy "right," but this means taking more of the library director’s time. In some small public libraries there may be no desire to take time to do another paperwork project. If you simply can’t take the time, it will be better simply to review the library’s current acceptable use policy to be certain all of the proper "right and responsibilities" are included, as are all of the warnings regarding improper use. Be sure to note the reasons security decisions have been made and leave the notes for future administrative needs.

A sample security policy is provided in Part III for those libraries wanting to start with an existing document and refinish it to fit their own environment. This sample is a heavily edited version of one provided in the Federal Information Processing Standards (FIPS) documentation for federal agencies, including wording and provisions more commonly used in small public libraries. Permission to use the security policy in its current or edited form is granted to all entities.

return to top

The Process of Implementation

Once a risk assessment is completed and a security policy is developed, an implementation of these security decisions must be performed.

The following list provides a rough outline of the process of implementing a network security project. The first two items represent the risk assessment process presented earlier, but are repeated here for continuity.

1. Meet with a vendor or consultant educated in network security issues to discuss the costs of implementing various security measures (such as those in the Network Security Checklist) and the likely consequences of not implementing each measure.

2. Review costs and determine which security measures are required for your library and which risks the library is willing to accept (areas where security is not specifically implemented).

3. Develop a list of specific security measures to be implemented and a request for proposals (RFP) to be submitted to prospective vendors.

4. Review the RFP with the library board and with regional library system staff familiar with security in public libraries.

5. After the RFP is approved and formally produced, submit it to three or more suitable vendors and advertise it.

6. Award the project to the most appropriate responding vendor (for a discussion of appropriate vendor characteristics, see the discussion of vendor selection under audits on page 62).

7. If possible, have interested staff shadow the vendor during implementation to see what aspects of security in-house staff can learn.

8. Begin a similar process for a security audit to determine how well the vendor implementation matches the library’s stated goals for its security implementation.

Maintaining Security

Implementing network security is not the end of the project. Remember that security is a process. There is an ongoing aspect of security that requires regular maintenance.

Managing risk includes two associated topics as well: detecting intrusions and responding to attacks. These areas are formally called intrusion detection and incident response. Each of these is an important part of an organization’s network security program, and there are entire books available about them. They deserve discussion in separate chapters, but their complexity and cost will impair most small public libraries’ abilities to formally adopt them into the security project. Therefore, I present them briefly below, leaving a fuller discussion for another time.

In addition to these two areas, I also present below the other ongoing aspect of network security: keeping the library’s implementation current.

return to top

Intrusion Detection

As defined at the beginning of chapter one, an intrusion, or infiltration as it’s called in some sources, is a successful break-in, where a user exploits a vulnerability or breaks through the security implementation and gains unauthorized access to network resources. Intrusion detection is the art of using software tools and configuration techniques to monitor network activity so that any break-ins—or even break-in attempts—are reported to security staff. The report can take the form of a log entry (notation in a text file), an e-mail message, or an alert sent across the network to a manager’s console. In large businesses, the vast majority of a security manager’s time may be consumed with intrusion detection. After all, if someone breaks into your network, you want to know about it before they make off with all the treasure!

For our purposes, however, I need to reduce the topic to practices that are appropriate in a small public library. First, let’s refine our terminology. Public libraries probably won’t have a great number of intruders from the Internet. They may, however, have several local users over a period of time that "test the locks" on the doors of the library network. For example, you should expect over time to see someone to try to guess the Administrator password on a Windows NT/2000 workstation or server. You can also expect users to try to load their own software onto the local hard drive. While these may seem innocuous, especially if you’ve implemented security measures to prevent success in these attempts, they are still attempts at intrusion.

Let’s consider all the security mechanisms your library has put into place to be a bubble of security surrounding the network resources. Any attempt to test the network for vulnerabilities, implement known exploits, or just use the network in ways that are restricted by policy will be considered poking the bubble. Any successful attempts will be considered popping the bubble. Neither one is good. As a manager, you need to know when any of these events occurs.

Unless you stand over a user’s shoulder, the only way to know that such attempts are occurring is to monitor activity on the network. One can do this without having to know the content of a user’s searching on the Internet. Monitoring is accomplished primarily by configuring the Auditing feature within Windows NT/2000 user and group accounts. One can also monitor Internet activity by noting restricted router, firewall, and web server activity in a log file. A log is a standard text file (one that is editable in Notepad, for instance). Specified activities cause a new entry to be recorded in the log. All of the following devices are, or should be, capable of creating an activity/audit log:

• Windows NT/2000 Server (audit logs)

• Windows NT Workstation/2000 Professional (audit logs)

• Router

• Firewall/security appliance

• Web server

A network administrator can set the parameters controlling when a log entry is created. The log might record the type of activity that triggered the entry, the date and time, and the workstation and user id that were being used. Depending on the type of device, more information can be recorded in the log. The administrator can also configure many of these devices to send an alert when restricted actions are attempted.

In order to be effective, the logs must be reviewed on a regular basis (every day, two days, or once a week; any period longer than a week may be too long to be helpful, except to know someone is messing with your network). Staff or volunteers can be trained to examine the logs and assess the danger in intrusion attempts. [Note: It is possible to contract with a vendor to monitor logs for the library, but the service is usually financially impractical in small public libraries.] Reviewing logs is an important aspect of the library’s network security program, so someone must be assigned the responsibility. The library director must encourage regular review by seeking status checks occasionally.

Other options. For larger libraries, separate intrusion detection hardware/software can be purchased to perform more advanced duties. In businesses where a security breach can be catastrophic this equipment is common. However, the cost of equipment and maintenance is too great to be practical for small libraries.

Monitoring a server’s file system for changes is another option for some libraries. This security technique can provide information about an intrusion even if the audit log has been tampered with. This, too, may require maintenance from an outside vendor. If existing staff has the technical acumen to be trained in this procedure, the training is highly recommended.

The Cost of Intrusion

Is all this work worth it? Just remember what the consequences may be if, indeed, intrusions occur. In some cases the intrusion will be kids just playing. In others it may be serious hackers looking for a home. The following list of consequences is provided as a reminder, and a bit of a warning:

• Data loss or corruption

• Cracking an Administrator account and controlling the server or workstation

• Attacking the Web server and gaining Administrator privileges (defacing the web pages is one effect, controlling the server is another)

• Nest building in order to launch attacks on other targets

• System corruption/disablement

• Impounding of one or more computers as evidence due to illegal activities

return to top

Responding to an Incident

If you’ve had a chance to get coffee, you may have already thought of the next question. What happens when, despite the great lengths you’ve gone to secure your network, someone discovers a new vulnerability before you have an opportunity to close it and breaks into your network? What if the person you’ve put in charge of reviewing server logs discovers an intrusion? What if, like the library director in the opening scene to chapter one, you get an e-mail message indicating that one of your workstations participated in a coordinated attack of some other network across the Internet? What happens then?

Most libraries have no plan for such an event. The typical response tends to be haphazard. The problem with an ad hoc response is that the moments after the discovery can be important. It may not matter if you do anything, or what you do, for the next week or two. However, what you do the next few minutes may be very important. If the intrusion is ongoing, what you do may make the difference between "catching" an attacker and letting him get away. It may make the difference between being able to prosecute an attacker who’s caught and being unable to prosecute.

Do you have an incident response plan for your library? If not, here are some basic suggestions to get the planning process started:

• Find out if the city/county is interested in any attacks that may occur on the library network. If the library network is connected to the city/county network, there should be a great deal of interest. Otherwise, there may not be. Likewise, if the library receives its Internet connectivity through the school district, find out if the school district is interested in any attacks you discover on your network (there should be).

• Determine the proper chain of command. As a result of the step above, you may be required to contact a member of the city/county/school staff immediately. If you’ve contracted with a vendor to assist with network maintenance and security, you have a contact to call there as well. Determine who needs to be called first. Establish contingencies for your contacts as well. If one contact is on vacation, whom do you call in her place?

• Determine the proper course of action for legal inquiries. For example, if a law enforcement representative shows up with a court order to search records or impound equipment, do you call someone (either before or after some item gets whisked away as evidence)? If so, whom? If a local patron is discovered conducting illegal activities, what steps need to be followed?

• If insured equipment is damaged or stolen, what is the procedure for filing a claim? What is the contact person’s name and phone number?

• What procedures need to be set in motion as a result of your intrusion discovery? These may vary greatly based on the nature of the intrusion. This is especially important if the intrusion is active at the moment. In some cases, a staff member may be glued to the telephone and in front of a workstation for a while, acting as a remote security contractor’s eyes and fingers.

• There are also questions related to recovery. For example, if an attack results in an Internet-based attacker having control of a server, how will the server be restored to its "pre-hack" state? Who will be responsible for working on the server? How long will it be out of service? Will a loaner be available for the library’s use? Is there money in the budget to cover a vendor’s time in conducting the recovery?

As mentioned earlier, this is a topic that deserves much better coverage than we can devote to it here. I hope these suggestions are enough to get you started, at least in considering the ramifications of a break-in and how your library can recover.

Staying Current

With new vulnerabilities being announced weekly and new products and services being announced almost as often, how are you as a small library manager to keep up? One easy suggestion is for you to team up with other library directors in your area to split duties by assigning each a different security topic. Here are four areas to start with:

• Security updates to the Windows NT/2000 operating system

• Security updates to the Internet Explorer browser

• New workstation security techniques using Windows NT/2000

• Security updates to the Microsoft Office applications

There could be other areas as well, such as updates to network equipment.

While trained technical personnel should be hired to update network equipment, library staff must be aware that such updates exist. (In fact, if no technically proficient staff are available, even routine patch installation may require the services of an outside vendor.)

Besides security updates, what other activities are involved in keeping your network security implementation current?

• Review the backup program—check periodically with the person responsible for backups to be sure they are performed on schedule.

• Update anti-virus signatures—even though these are now downloadable automatically, it never hurts to check occasionally to be sure the signatures are indeed updated.

• Upgrade software—at some point, security patches are no longer sufficient. Keep track of optimal times for upgrading or replacing outdated software.

• Review and maintain the budget—the most important of all

return to top

Developing a Security Plan

No work on managing a service would be complete without a section on planning. In this case I present just a skeleton, which you can alter to fit your library’s needs.

• Assign Responsibilities

• For maintaining backups

• For assessing risk

• For implementing the security program

• For developing policies, plans, and procedures associated with security

• For monitoring log files

• Assess Risks

• Implement Specified Security Measures

• Develop Policies, Plans, and Procedures

• Network Security Policy

• Acceptable Use Policy

• Password Policy

• Backup Plan

• Disaster Recovery Plan

• Incident Response Plan

• Monitor Logs

• Report Anomalies and Incidents

• Perform Regular Maintenance

• Backing up data

• Reviewing network security sites for new vulnerabilities/software updates

• Patching operating systems

• Upgrading software

• Raising funds

Summary

In this chapter we covered a lot of ground. Here are the main points of managing security:

• First, assess risk; this includes evaluating the threats and vulnerabilities present in your network, as well as evaluating which are most likely to be exploited in your library environment.

• Next you would estimate the cost of securing the vulnerabilities and compare that to money available to secure them.

• Finally, prioritize risks by determining which of the vulnerabilities are most serious, are likely to be exploited, and are inexpensive to secure.

• Develop a formal process to hire a vendor to implement the desired security measures.

• Develop a security policy to describe the rights and responsibilities of users of the network and of management.

• Implement a procedure for monitoring access to the network to detect any illegal or unauthorized use of network resources.

• Determine proper procedure for use in responding to any security breaches.

• Develop an outlined plan for implementing security in your library.

• Determine how your library will keep its security implementation updated.

return to top

Continue to Securing Financial Resources