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.

Auditing Security

Once your library embarks upon a program of network security, how do you know your resources are secured as well as they should be, or can be? Once your staff, or a contractor you’ve hired, has configured your network components for secure operation, how can you confirm that the job is done well? To what standard do you compare your security implementation?

If any of these questions have occurred to you, then you get bonus points for thinking ahead. These are pertinent questions that every manager should ask at some point in the process of installing, configuring, or securing her network. Taking the word of staff or a contractor when you can’t verify the work yourself is risky. The best course is to hire an independent contractor, one who is knowledgeable in the basics of securing network resources, especially in networks providing public access.

A security audit is the process of assessing the various components and the operating environment of a computer network for vulnerabilities. The audit may be either casual or formal, superficial or detailed, onsite or conducted entirely over the Internet. An in-house self-audit can be conducted when the library employs technically trained personnel, but this is unusual. These audits work well in a security project where the library is assessing what security measures may need to be implemented. As a final audit, however, a self-audit loses the benefit of an independent, objective view.

In this chapter I present some of the issues surrounding security audits and contracting with an auditor to test the security implementation of your organization’s network. I also propose three levels of auditing for small public libraries, by which the security of your network can be assessed. If you are able to contract for an audit, then these are many of the items your auditor will be reviewing. If not, then these points should provide you or your network administrator with a guide to use in conducting a self-audit.

Purpose of an Audit

In order to assure library staff and interested funding authorities that the library network’s implementation meets some definition of "best practice," it is necessary to perform an audit of the configuration. Best practice does not mean perfect. As mentioned in previous chapters, it is impossible to create a perfectly secure network. That ideal would provide access to no users at all. Any walls that are built technologically can, in theory, be "vaulted" technologically. In public libraries and other small community organizations where funding for technology is extremely limited, best practice is amended to provide a configuration that is reasonably secure given the organization’s determination of its acceptable level of risk.

In small public libraries, acceptable risk may be much greater than it would be, say, in a small non-profit community organization, where the loss of proprietary information or of personal information associated with community businesses or organization members is critical. So the determination of what is an appropriate level of security may differ from one organization to another. The audit provides feedback to the library director indicating whether the library configured security meets its determination of appropriate security.

Benefits of an Audit

Having created security goals for the library in response to developing its security policy, library staff and board members will have engaged in a reasonable discussion of the risks associated with offering public network services. The library will also have determined a base level of security it wishes to implement.

After hiring someone to configure the network to meet this level of security, the security audit will determine how well the security implementation meets the library’s goals. The following list shows the potential results of a network security audit:

• It will point out problems or weaknesses in a network’s configuration so that the library may address them.

• It will verify the work of a vendor or staff implementing measures to secure the network;

• It provides assurance to funding agencies that resources are protected as well as reasonably possible;

• It provides an independent evaluation of a library’s compliance with a set of network security standards, lending both credibility to future requests for funding and justification for current spending.

return to top

Is an Audit Essential?

In short, no. At this time, there is no granting agency I am aware of that requires a network security audit as part of its technology grant. A few local funding authorities are just now beginning to implement security policies, and many have no security policy, so they are not yet concerned with audits.

However, without an audit it is impossible for the library to know how open to attack its network is. Therefore, the library cannot know how likely it is to lose the service of a workstation, a server, or other network device. Where no audit is performed, a range of scenarios may be present, but be unknown. Here is a list of extreme scenarios and their consequences:

• The network may be relatively secure and experience no attacks

• The network may be very insecure and experience no attacks

• The network may be very insecure, experience attacks, and lose all services

When the library has no knowledge of its network’s degree of insecurity, it is much more likely that one of the following consequences will be realized:

• minor attacks, where library staff occasionally have to reconfigure equipment and/or software

• frequent or significant attacks, resulting in the library having to pay a vendor to reconfigure equipment and/or software

• more significant attacks, where the library loses access to a workstation or server until it is reconfigured; this may also include illegal activities where a workstation or server is impounded as evidence, in which the loss may be limited or permanent

• a major attack, where the library will lose all access to the Internet or to its catalog

Hopefully, these illustrate that without an audit the library will not have a proper idea of its network security risk. Therefore, the library director will have no means to budget adequately for annual network support and maintenance. If the library significantly under-budgets its need for network maintenance, it may be unable to have network equipment repaired or reconfigured. In most libraries, this is an unacceptable risk.

On the other hand, some libraries simply do not have the financial resources for an independent audit (grant resources are becoming available for audits, however). In this case, a self-audit is highly recommended.

A self-audit requires someone on staff or a volunteer to be familiar with securing the network in the basic ways mentioned in the Network Security Checklist included in Part III of this guide. The implementation chapters in Part II will help you learn what each measure means, but staff will need additional training to implement/audit these measures. One portion of the online component of this training series will provide this basic instruction. There are other network security training resources as well.

The Audit Project

Content

Security practitioners may each recommend different security measures to be implemented, depending on their background experience and knowledge of the library environment. Here are seven major areas I use to classify specific security measures:

• General Security

• Physical Security

• Password Security

• Hardware Security

• Server Security (operating system and server software)

• Workstation Security (operating system and security utilities)

• Perimeter Security

All of these may be evaluated in a network security audit. Not all of them, and not all of the measures described within each area, are appropriate in every environment. In addition, as mentioned previously, the library must decide what its acceptable level of risk is. By doing so, the library can determine the scope of its own audit.

One aspect of deciding which measures will be audited is whether the cost of securing a specific measure is greater than the cost of recovering from an attack resulting from leaving it unsecured. Where a specific security measure is not implemented, the library should provide written justification of its exclusion to the auditor. This informs the auditor of the parameters of the audit. While the auditor may suggest reasons for implementing such a measure, the library is the ultimate arbiter of what risks it is willing to accept.

return to top

Standard Security Measures

To our knowledge, there is no standard list of network security measures that can or should be implemented or assessed to ensure maximum security of a library’s computer network. The only documents close to this ideal that I have discovered are the consensus documents from the SANS Institute (listed in the bibliography). To fill the gap and assist libraries with security implementations and audits, I have developed the Network Security Checklist. The measures listed in the Checklist are divided into three separate levels of network security in public libraries. These are presented in Elements of a Security Audit at the end of this chapter.

As more practicing library network administrators and analysts review the Checklist, it should become more of a standard, reflecting the best practice in public libraries. A copy will be maintained online with the electronic version of this manual. (See the reverse of the title page for the Web address.)

What an Auditor Might Examine and Test

There are a number of established methods for conducting security audits. Some assess the security of all aspects of the network. Some assess the security of particular components, such as just the security of the perimeter equipment (router/firewall, web server) connecting the network to the Internet. In the business world, managing staff accounts and Internet-based attacks draw the most attention, but these are usually not the primary concern of most libraries.

There are three common types of audits. Each uses very different techniques.

• The automated audit. This type of audit involves the use of commonly available network scanning and assessment tools, usually onsite, to check a network for known vulnerabilities in operating systems (such as Windows NT Server, Linux, etc.) and in the network configuration itself. If no other techniques are used, this type of audit has limited usefulness for libraries. The audit report may consist mainly of printouts from the scanning utilities.

• The black box audit; also called a penetration study. It gets its name from the bad guys who may be trying to break into your network. In this scenario an auditor will be located outside the library and do his testing of the library’s firewall and/or router configuration over the Internet. The auditor may or may not have any information regarding the library’s internal network, but any information he has will be basic, such as a range of IP numbers representing the workstations or servers on the network. Because everything is hidden from the auditor, he must discover details about the network independently, just as a cracker would. Only minimal information is provided in the auditor’s report through this type of audit.

• The white box audit; sometimes referred to as a manual audit. This audit requires an onsite visit and includes an examination of many more aspects of network security, resulting in a more thorough determination of the library’s actual security implementation. It may make use of automated scans, but will also feature manual analysis of the physical and logical network configuration, the building, the configuration parameters of equipment, servers, and workstations, and the documentation that serves as a foundation for the site’s security, comparing the implementation against "best practice." Therefore, the auditor must be given access to most, if not all, of the library’s network configuration information, including staff account and administrator passwords.

Specific items that could be included in a manual audit are listed in Elements of a Security Audit in Public Libraries later in this chapter.

return to top

Information an Auditor Needs

The scope of the audit, as described above, will require the auditor to have access to differing levels of information. The information may be public or very sensitive information. I recommend asking the auditor what he or she requires soon after a contract is signed. The library may need some time locating and packaging the materials requested. The auditor may need some time to review the materials after receiving them prior to an onsite visit.

Here is a list of the items most likely to be requested by the auditor for reference prior to or during the security audit:

• Network diagram (installer should have supplied one)

• Network addressing documentation (installer should have supplied one)

• List of hardware and software passwords

• Documentation for the servers/workstations/network equipment used in the library’s network

• Various policies and plans, if available (and just having a document formally drafted may be one item of the security audit):

• Security Policy

• Acceptable Use Policy

• Password policy

• Backup plan

• Budget plan, or technology plan with budgetary information

• Training documentation:

• Network equipment and software configuration procedures (staff use)

• Strong password selection (staff and possibly patrons)

• Basic use of workstations (patrons and staff)

• Basic security of sensitive information, such as passwords (staff)

return to top

Responsibilities

When the library hires a security consultant to perform an audit, especially an onsite, manual audit, there is some risk inherent in providing access to confidential and sensitive network information. The auditor will have access to an administrator account and passwords, as well as access to sensitive documents, such as personnel records or patron information. Therefore, it is a good idea to have a non-disclosure agreement (actually, a disclosure agreement, limiting what will and what will not be disclosed) indicating the responsibilities of the auditor and organization in detail.

First, the library must agree to disclose all of the information required by the auditor to access system and network resources during the audit. This information will provide the auditor with a basis from which to perform a thorough inspection and audit of the network. Lacking information such as an administrator’s password may prevent the auditor from accessing portions of the network which need to be evaluated.

On the other hand, the auditor must agree not to disclose to any other party any of the information she is provided for purposes of the audit, or any information she accesses/discovers during the course of the audit. Any such disclosure can be considered a breach of security. The auditor, however, may need to disclose some information in specific instances to another person in her organization, so her firm—and not just the specific auditor—should be bound under this area of non-disclosure.

Sound security practice (some may call it paranoia) suggests that an agency undergoing an audit should change all significant passwords (for administrator accounts) immediately after the auditor concludes the final onsite visit. When changed, the new passwords should be created with strong password guidelines currently practiced or suggested for practice by the auditor.

In addition to the disclosure agreement signed by the auditing firm, it is also a good idea for the library to have a similar written agreement with the firm it uses for installation and/or maintenance of the library’s network equipment. [Note: The vendor responsible for installation and configuration must agree to provide to the library the specific passwords used to configure or administer each piece of equipment (hub, switch, router, firewall, etc.). In several cases in the past, vendors have withheld these passwords from library staff, causing the library difficulty in trying to change vendors for maintenance and expense in trying to solve configuration problems.] The signed agreement should also include a statement that the vendor will not disclose such information to any third party.

Likewise, the library has responsibilities in this regard as well. The library must agree not to disclose the nature of passwords and other configuration information used by a vendor, because the vendor may use similar devices in the creation of passwords for other agencies. This is not recommended from a security standpoint, but may indeed occur. By disclosing the library’s password to some other agency or library (third party), the library may inadvertently give someone a "head start" in breaking into another agency’s network.

A final responsibility of the auditor will be to schedule the time at which an onsite visit will be made. In some cases, the audit may interrupt ordinary operation of the network, and the audited agency needs time in advance to prepare for the possibility of an outage. For example, especially in public libraries, public access workstations may need to be reserved for the auditor’s inspection, leading to "downtime" for the library’s public access service.

Project Deliverables

The primary product of a network security audit will be the auditor’s report. In businesses there may be a formal presentation of findings as well, providing business representatives an opportunity to ask the auditor questions. Such presentations require time to develop, time to travel back to the business, and time to make the presentation. All this increases the final cost of the audit. Most libraries would be better served to receive copies of the report and have an opportunity through e-mail or a phone call to resolve questions arising from the report.

Be aware that some audit reports are mainly printouts from automated network scanning utilities. While these may be extensive, their content may be unhelpful. At the other extreme are complete custom documents detailing the state of security on each system, including areas of weakness in each system, with a list of recommendations for further implementation. Such documentation is very helpful, but is expensive to produce.

return to top

Selecting an Auditor

Qualifications

Network security auditing in small organizations is still in its infancy. There are very few practitioners who are certified security professionals. Therefore, determining a vendor’s qualification to conduct the audit is based on several evaluative factors:

• Does the consultant or vendor possess a knowledge of general security principles ("best practice") commonly used in the library’s network operating system?

• Does the vendor possess a certification for the operating system used in the library’s network (e.g., MSCE for Windows NT/2000, RHCE for Red Hat Linux) or for the network devices installed (e.g., CCNA for Cisco switches and routers)? For operating systems, it is important to realize certification measures basic of knowledge of an operating system at one point in time—it does not guarantee (and, in fact, indicates very little about) knowledge of common security practices used with the operating system. Microsoft now requires students to pass a security unit for its Windows 2000 MSCE certification.

• How trustworthy is the consultant or vendor? Whoever performs the audit will have complete access to your systems, so trust in the vendor is crucial!

• Does the consultant or vendor have experience with network security in a public access environment, especially in small public libraries?

There may be other vendor qualifications or characteristics that are important to your library. For example, the hourly/daily fee a vendor charges is a primary consideration for most small public libraries. If you develop a Request for Proposals (RFP) or Request for Quotes (RFQ) for the project, be sure to ask responding vendors for references of other clients, particularly any public library clients. Ask the RFP/RFQ respondent to describe her experience with security in a public access environment. Also ask her for a generic copy (with all client references and any sensitive information removed) of a report or two from a similar audit she performed previously. Evaluate each vendor responding to the library RFP or RFQ based on these characteristics and documents.

Formal Process

The security audit is really the last step in implementing a network security project. So a number of preliminary steps is assumed:

• Research the various aspects of security in a public library setting.

• Meet with a system administrator or a network vendor representative to discuss the possible costs of implementing various security measures and the risks incumbent in not implementing each.

• Review the costs and risks to determine which items of network security are required in your library and which risks the library is willing to accept.

• Contract for the security implementation.

Given the security implementation, there is a separate process required to conduct a network security audit. Here are the major steps:

• Create a list of the security measures implemented, which then becomes a list of items to be audited; include written documentation of the library’s decisions not to implement specific measures.

• Develop a Request for Proposals (RFP) or a Request for Quotes (RFQ) for the security audit, including the measures to be audited.

• Review the draft RFP or RFQ with the library board and with regional library system staff familiar with network security in public libraries.

• After the final RFP or RFQ draft is approved and formally produced, submit it to three or more likely/suitable vendors and advertise it.

• Evaluate responses to the request, with an eye toward the characteristics presented in the previous section.

• Follow up by contacting the references provided by the respondents.

• Award the audit project to the appropriate vendor and arrange an onsite visit.

• Gather all relevant network documentation (especially passwords, plans, and policies) requested by the auditor and deliver as agreed.

• Conduct any onsite and Internet-based assessments.

• Once the auditor has completed his or her assessment, change all administrator-level passwords (see the Sample Password Policy in Part III for help in creating strong—not easily hacked—passwords. This may seem paranoid, but this is very sensitive information about your network. Believe it or not, some hackers even have day jobs as network consultants! (Okay, maybe I got a little enthusiastic again, but do change those passwords!)

• Review the audit report to see if any specified areas of network security require more implementation work; review any additional comments or recommendations the auditor may include in the report and determine their appropriateness to your library’s needs.

return to top

Elements of a Security Audit

In the following tables I present three levels of security a small public library may choose to implement and have audited. The lists are creatively labeled Basic, Intermediate, and Advanced. They are cumulative. To secure a network at Level Two, everything in Level One must be implemented as well. The items listed in each level are taken from the Network Security Checklist and categorized according to the top ten threats identified in Chapter One. They are listed in order of expected cost, from the least to secure to the most expensive.

The lists may not completely represent your library’s needs, but are intended to be a starting point. Feel free to delete or add specific security measures from other levels as library administration deems appropriate.

Summary

In this chapter we looked at various aspects of network security audits. These include:

• Purpose

• Benefits

• Knowledge of unsecured vulnerabilities

• Verification of a vendor’s security implementation

• Assurance that a library is doing all it can to secure its network infrastructure

• Is an Audit Essential

• What Security Measures Should be Included in an Audit

• What an Auditor Might Examine in the Network

• Just the publicly available computers (router, web server, and possibly public workstations)

• Tests for known vulnerabilities

• Comprehensive review of security practice including access control on workstation and servers

• Review of administrative process, including policies, plans, and procedures

• Information an Auditor Needs

• Network documentation and passwords

• Equipment documentation

• Copies of policies, plans, and procedures

• Copies of training documentation

• Responsibilities of the Library and Vendors

• How to Select an Auditor

• Qualifications

• Formal Process

• Elements of a Security Audit

• Three levels: basic, intermediate, and advanced

return to top

Continue to Training Users