Introduction to Technology Security in Education Organizations

Robbery is illegal, but people still find it prudent to lock doors and close windows in their homes. Likewise, education organizations have always been concerned about protecting their valuable property, which certainly includes technology and information systems.

The security recommendations described in this resource are solid, fundamental business practices that are, for the most part, not unique to the education sector. They will help to protect an organization's investment in hardware, software, networking, and information resources.

What's at Risk?

Most people see the necessity of securing technology equipment. Machines cost money and therefore have value unto themselves. But if you take a moment to consider why organizations are so willing to spend large amounts of money on their computer systems—to store, access, and transmit information—the value of that information becomes more apparent as well. And because information has become so useful, it's not only the equipment that demands protection, but also the data. In the education community, information about students, staff, and other resources is far more valuable to the operation of school buildings, campuses, and district and state education agencies than even the most costly equipment.

Since the institution is ultimately responsible for the integrity and security of its data, management needs to take active steps to ensure that valuable equipment and the information it stores and processes are being adequately protected. If an education organization fails to protect its equipment and information in a manner that satisfies "standards of due care" and "reasonable safeguards," it opens itself to a host of potential problems-from allegations of negligence and incompetence, to law suits charging "computer malpractice," and forfeiture of insurance claims due to "preventable losses."

The Bottom Line on Security

Security involves more than keeping intruders out of confidential files. While an organization must certainly be aware of hackers (i.e., unauthorized users who attempt to access a system and its information), it must more regularly deal with threats like failed hard drives, spilled coffee, and refrigerator magnets. In fact, most security concerns an education organization must face are of a fairly regular nature. For example, the phrase "mean time between failures" is quite common in the computer sales industry. For non-statisticians, it refers to when (not if) every computer disk you own will fail. Planning to deal with this eventuality is not an exercise in the theoretical!

The goal of security is to protect your technology system without unnecessarily limiting its utility. The system shouldn't be so secure that authorized users can't get to the equipment and information they need to do their jobs.

At the same time, however, unauthorized access, especially to critical systems and sensitive information, must be prevented. Because of this contradiction, no system, be it electronic or paper, will ever be entirely secure, but the ideal of developing and maintaining a "trusted system" is realistic nonetheless, and should be the goal of every educational administrator.

To approach this goal, top-level decision-makers must be involved in any attempt to establish sound technology security policies and procedures. Although at times the prospect of such an endeavor may seem daunting, especially to a non-technical person, it must be undertaken all the same. According to Network Security Secrets, the following strategies must be adopted prior to successfully instituting security practices within an organization:

• Senior management should provide strong outward support.
• A single, empowered staff member should be made specifically responsible for security initiatives (and have the time needed for testing, monitoring, and other activities designed to provide feedback on the system).
• Employees should be educated through well-conceived training programs.
• All employees should participate in security procedures at all times.

The bottom line is that if, as an educational leader, you are prepared to commit to these requirements and make the effort to educate yourself on the fundamental issues affecting technology security, protecting your organization's resources more effectively becomes entirely possible. By developing and implementing a well-conceived set of safeguards that are customized to your organization's specific needs, you can increase the security of your system significantly.

Assessing Your Needs

How can a security catastrophe be prevented? In the case of a flood, tornado or earthquake, it probably can't. But like other potential troubles, even the devastating effects of these natural disasters can be minimized through a well-conceived and properly implemented security plan. The first phase in more effectively securing your technology begins with a process referred to as risk assessment. Put simply, risk assessment involves identifying:

• assets the organization possesses
• potential threats to those assets
• points in the organization where vulnerabilities to those threats exist
• probability of threats striking a vulnerability
• cost estimates of losses should a potential threat be realized

Risk assessment is a straightforward process and a most necessary step in decision-making. By evaluating risk, you are determining your needs so that you don't spend valuable resources on unnecessary safeguards while, at the same time, you don't leave yourself exposed to unprotected loss.

What will your risk assessment tell you? Well, since risk assessment is a process and not a product, it depends on your specific situation. As stated above, it tells you what you have, what it's worth, where you're weak, what to worry about, and why you should be concerned in the first place.

Say, for example, you realize the old building in which you store your network server (an asset) was not constructed with fire-resistant materials in the way you would require for a newly built structure (a vulnerability)—and you also realize that it's conceivable a fire (a threat) could strike the site (a probability that, while low, is real, and could therefore be estimated). The question becomes whether you should introduce countermeasures to protect your server from a fire.

Knowing what you do about the asset, vulnerability, threat, and probability, the answer then depends upon the cost of replacing that lost asset. If you are in a wealthy organization, perhaps $20,000 doesn't sound like an unreasonable expense; therefore you could afford to risk the loss of server. However, if you have other technology in the building as well, the replacement costs might be greater-so much so that despite the low probability of a fire damaging your assets, you wouldn't want to accept the risk should the threat (a fire) actually strike.

Another consideration when evaluating the merit of protection plans is the option of alternative solutions. Yes, building an up-to-date structure to house your server would be an effective way of protecting it in the example above, but so might be installing a sprinkler system or training staff to use fire extinguishers. Supplement this with an insurance policy to replace your equipment, and you have yet another effective, but less expensive, security alternative to rebuilding.

It is precisely these types of thoughts that the risk-assessment process should elicit. A properly executed risk assessment provides decision-makers with a methodical approach to determining security strategies—not based on a sales pitch or gut instinct, but on the concrete, context-specific findings of cost/benefit analysis.

Guidelines for Risk Assessment

According to Computer Security Guidelines, a properly conceived and implemented risk assessment should:

• provide the basis for deciding whether countermeasures are needed
• verify that countermeasures counter actual risk
• save time and money that might have been wasted on unnecessary countermeasures
• determine whether residual risk (that risk which remains after countermeasures have been introduced) is acceptable

Risk Assessment Outline:

• The Players: It's a Team Effort
• Timing: First Thing First
• Take Stock of What You Have and What It's Worth
• Step 1 - Identify Critical Systems and Sensitive Information
• Step 2 - Estimate the Value of System Components
• Identify Your Potential Threats and Vulnerabilities
• Step 3 - Identify Threats
• Step 4 - Identify Vulnerabilities
• Step 5 - Estimate the Likelihood of a Potential Penetration Becoming an Actual Penetration
• Think Through Your Defensive Options
• Step 6 - Identify Countermeasures Against Perceived Threats and Vulnerabilities
• Step 7 - Estimate Costs of Implementing Countermeasures
• Make Informed Decisions
• Step 8 - Select Suitable Countermeasures for Implementation

The Players: It's a Team Effort

The process of risk assessment should be initiated and directed by the top administrators in an organization. But although chief administrators captain the endeavor, feedback from all levels and job categories is required. In short, more people involved in the brainstorming process results in more ideas generated.

Timing: First Thing First

Risk Assessment is a prerequisite for any serious attempt to implement a security plan within an organization. Unless the organization's needs are first accurately assessed, there is no way of knowing whether financial and staff resources are being wisely invested in security initiatives.

Take Stock of What You Have and What It's Worth

Only careful and collaborative efforts will yield worthwhile results. Be inclusive, exhaustive, and realistic when documenting your assets. While an asset is often defined as real property, recall that one reason all those dollars were spent on technology in the first place was so that you could manipulate your organization's information more efficiently-information like student academic data, special support service files, staff health records, and organizational financial figures. Thus, education data is essential to the operation of the educational enterprise and is also an asset.

Step 1 - Identify Critical Systems and Sensitive Information

The goal in Step 1 is to make a distinction between general systems and information (i.e., those systems and that information that is helpful to your organization as it carries out its mission) and critical systems and sensitive information (i.e., those systems and that information that is private and/or vital to your organization as it carries out its mission).

For example, the computer that houses the "HELP" file for your organization's word processing software is a "general" support component. While it is useful to have access to HELP tools when facing a word processing problem, the files themselves are not vital to running an education organization. Conversely, the new software that manages a school system's substitute teacher scheduling is vital to the teaching mission. If it isn't available and working properly, principals could potentially find themselves with classrooms full of students who have no teacher. And that makes the system "critical" if ever there was one.

Don't allow yourself to feel restricted when brainstorming-among other pitfalls, avoid working within the paradigm of conventional technical definitions if you feel they might limit your ability to construct an exhaustive list of assets. For instance, when considering critical systems, don't restrict yourself to physical systems, which traditionally require actual hardware connections. Remember, the primary consequence of Step 1 is that all equipment and information identified as either sensitive or critical needs to be prioritized on the list of concerns that demand security. To leave out a component because you didn't think broadly enough leaves the organization vulnerable.

Step 2 - Estimate the Value of System Components

Estimating the value of your information system is not always simple, but the task is made more manageable by focusing on the word "estimate." After all, it may very well be impossible, or at least impractical, to try to derive a precise dollar value for some assets (especially information assets). Instead, try to calculate a reasonable approximation of the replacement value of each component of the system-both equipment and information. Be sure to consider the following factors when deriving your estimation:

• direct replacement costs of hardware, peripherals, networking technology, and software (Would there be installation costs? Consultant fees? Insurance deductibles? Necessary upgrades?)
• replacement costs of stored information (Would re-keying be necessary? Resurveying?)
• costs associated with the disruption of service or other activities (Would you have to pay staff overtime during the recovery period? What about extra school days at the end of the year to make up for missed time?)
• indirect but real costs associated with a loss of public confidence (Would it impede current or future data collection efforts? What would be the effect on legislative initiatives?)

While identifying sensitive information and critical systems is necessary for setting priorities, all resource have value and require attention in this step. One common mistake in this process that can lead to serious flaws in assessment results is when you focus on only the critical segments and sensitive information (as identified in Step 1) when estimating the value of an information system.

Identify Your Potential Threats and Vulnerabilities

How do you identify threats and vulnerabilities? In a word: Brainstorm! Maximize the resources at your disposal by including representatives from all organizational levels and duty types in the brainstorming effort. After all, you don't want that cleaning staff left out when they might be the only people on duty to protect equipment and information after hours. Nor do you want to exclude those library assistants who oversee the computers your students use to log on to the Internet. Always keep an open mind to what your users have to say.

Step 3 - Identify Threats

A recent NSA Training Brief estimated that as much as 67 percent of networked computers are infected with a virus in a given year. Even accounting for the growing prevalence of virus threats, more than half of all reported system damage is caused by unintentional employee action—in most cases, simple negligence. Any such action, actor, or event that contributes to risk is referred to as a threat. Be sure to consider the following types of threats:

• Natural Threats—Lightning, Tornado, Hurricane, Flood, Earthquake, Snow/Ice Storm, Forest Fire, Humidity, High Temperatures, Dirt Rain/Water Damage, Time (Aging Media)
• Human Threats (Intentional)—Theft, Vandalism, Arson, Hacking, File Sabotage, Wire Taps, Computer Viruses, Unauthorized Copying and Disclosure of Information
• Human Threats (Unintentional)—Equipment Failure, Power Fluctuations, Magnetic Fields, Spilled Beverages, User Error, Air Conditioning Ducts, Computer Viruses, Heating Units, Programmer Error, Lost Documentation, Lost Encryption Keys, Aging Facilities

Step 4 - Identify Vulnerabilities

Vulnerabilities refer to points within a system that are open to attack or damage, specifically they are the mechanisms by which threats access your system. Think of a thief (a threat), who is ready to strike your building (which houses your assets). An open back window through which that thief might enter the premises is a vulnerability.

Where is your system susceptible? Consider vulnerabilities to natural threats and both intentional and unintentional manmade threats as identified in Step 3. Review your list of threats to see if any new ideas are triggered. After this initial brainstorming, organize the list of vulnerabilities you've generated into categories such as the following and then once again see if additional thoughts come to mind:

• physical concerns (e.g., room access, building construction, and climate)
• hardware- and software-related issues (e.g., equipment, programs, and compatibility)
• media liabilities (e.g., disks, tapes, hard drives, and print copies)
• communications (e.g., access points and encryption)
• human concerns (e.g., personnel and office behavior)

Step 5 - Estimate the Likelihood of a Potential Penetration Becoming an Actual Penetration

What is the probability of a threat capitalizing on a vulnerability? Answering such a question might appear to be difficult, but you don't have to be able to predict the future in order to generate reasonable probabilities of future events. Use logic, as possible, to support your estimates. For example, for an institution located along the Mississippi River, earthquakes and floods are threats that are within the realm of possibility, but logic will tell you that the site is probably much more susceptible to floods. Using flood histories, the likelihood of the next 100-year flood can be estimated. Similarly, by researching geological data, you can estimate the likelihood of earthquakes.

Think Through Your Defensive Options

Step 6 - Identify Countermeasures Against Perceived Threats and Vulnerabilities

This step parallels Step 3 and Step 4 in that its purpose is to generate an exhaustive list of ideas-this time potential solutions to the concerns raised by your identified threats and vulnerabilities. When considering options, be sure to keep in mind that many threats and vulnerabilities can be addressed by more than one countermeasure. A potential thief, for example, could be thwarted by better locks, video cameras and other electronic surveillance, or even trained security patrol officers. Step 6 focuses on generating a list of such options for each perceived threat and vulnerability, not in selecting what appears to be the preferred option. That is attempted only after an exhaustive list is finalized and costs/benefits are considered. Issues to consider when brainstorming potential countermeasures include:

• physical security equipment and procedures-location and environmental strategies such as climate monitors, required building specifications, and regulations governing room access and food and beverage use
• information security practices-storage and use regulations such as labeling and write-protecting files
• software security techniques-purchasing and programming concerns such as copyright infringements and proper documentation
• user access controls-data and system access issues, including login and password protection
• networking security initiatives-connectivity issues like firewalls and encryption strategies

Countermeasures are often designed to serve one of the following functions (adapted from Information Security Modules):

• prevention - e.g., by installing locks on windows and doors, threats are prevented from easily accessing buildings and rooms that house your assets
• deterrence - e.g., by training users about the legal consequences of unacceptable use, potential threats that might otherwise consider destructive activities may be deterred
• containment - e.g., by segmenting each separate type of information in your system, even active threats can be limited to the record areas they can find and enter
• detection - e.g., by reviewing records of user activity, commonly referred to as audit trails, unwelcome activity can be uncovered
• recovery - e.g., by preparing and testing a contingency plan, "lost" systems and "damaged" information can be salvaged (or at least losses can be minimized)

For recommended countermeasure options, see sections on Physical Security, Information Security, Software Security, User Security, and Network (Internet) Security.

Step 7 - Estimate Costs of Implementing Countermeasures

This step entails determining the costs associated with countermeasures identified in Step 6. Remember that the vast majority of costs are twofold: initial and ongoing. Be certain to consider all of the following factors:

• both money and time for research, development, procurement, installation, and maintenance of security features
• staff training time-the costs are real and absolutely necessary
• altered productivity (e.g., having each employee spend one minute using a virus scanner three times each day may amount to only three minutes of work time per day, but when calculated for the entire organization and compounde d by a host of other possible security activities, such seemingly insignificant costs can add up)
• countermeasures already available to the organization that may require less investment to institute (e.g., if your accounting office currently uses certain security procedures, there may be fewer training costs because you already have a core of people who can share their expertise)

Make Informed Decisions

Step 8 - Select Suitable Countermeasures for Implementation

In Step 8, it's finally time to decide which countermeasures make the most sense to implement. Remember that there will probably be more than one countermeasure that can protect your system from any given threat or vulnerability, so you have choices. Your job is to determine which strategy makes the most sense from a cost/benefit perspective. This can be accomplished by comparing your estimated costs of potential losses for a given period of time with actual security costs that would be incurred when preventing such a loss for the same period of time.

One way to decrease your actual security costs is to keep in mind that a single countermeasure can actually serve as a solution to multiple threats and vulnerabilities. An example of this is when security officers who protect your most sensitive areas serve as a countermeasure to both external intruders and potentially misguided staff. Such a compromise solution is really no compromise at all-two potential threats are being countered for the price of one. In effect, you're getting twice the protection for the cost of a single countermeasure!

Dealing with Risk

Under what conditions could accepting risk make sense? Well, it is theoretically possible that an asteroid could smash into the earth and land, of all places, on your office. The risk is real, albeit small, and can be estimated as such. Should you, therefore, endeavor to build a concrete vault two miles beneath the surface of the earth to store backup files of your records, or should you accept the risk of an asteroid strike and figure that your system will be the last of your worries should the event actually occur? Your risk assessment (see Steps 1-8) and common sense will probably tell you that you can safely afford to accept the residual risk of asteroid strikes. While such an example is extreme, it illustrates that you don't have to counter every conceivable risk, but rather only those it makes sense to address.

Conversely, ignoring risk is not a stable strategy (even if it is a common practice). If you choose not to perform a risk assessment and, instead, simply choose to ignore your risks, they are still there all the same-you just won't be prepared for them. Thus, despite the fact that it is possible to handle risk in any of the three ways-counter it, accept it, or ignore it-only the first two are stable strategies, and both depend on the results of an accurate risk assessment.

Closing Thoughts on Risk Assessment

Once you determine your needs and priorities, you can then make security decisions based on concrete information. Sales pitches from vendors and gut instinct on the part of well-intentioned, but perhaps uninformed, staff need no longer serve as reasons for making security policy when competent administrators are armed with the information required to make rational, valid decisions. It should be emphasized that decision-makers must be involved in the entire process of risk assessment. Should, instead, they rely simply upon cost/benefit analysis without being aware of other important factors that might have been uncovered in the assessment process, they might not make a completely informed decision. A good example of this would be if it were determined in Step 1 that some of the student information on a computer was sensitive. As discussed throughout this document, those confidential records would need to be protected regardless of cost/benefit analysis because of the various laws in place that mandate protection of student and family education records. Not knowing this important fact could, in such an instance, lead to disastrous results for the organization and its students!

Security Policy: Development and Implementation

Who is responsible for securing an organization's technology resources? Perhaps the management information system (MIS) staff? Not exactly. Maybe it is the facilities staff? Wrong again. Ultimately, it is not only individual employees or departments that are responsible for the security of confidential information, but also the institution itself. It is, therefore, incumbent upon top administrators, who are charged with protecting the institution's best interests, to ensure that an appropriate and effective security policy is developed and put into practice throughout the organization.

While policies themselves don't solve problems, and can actually complicate things unless they are clearly written and observed, policy does define the ideal toward which all organizational efforts should point. By definition, security policy refers to clear, comprehensive, and well-defined plans, rules, and practices that regulate access to an organization's system and the information included in it. Good policy protects not only information and systems, but also individual employees and the organization as a whole. It also serves as a prominent statement to the outside world about the organization's commitment to security.

How to Develop Policy

Tenable security policy must be based on the results of a risk assessment. Findings from a risk assessment provide policy-makers with an accurate picture of the security needs specific to their organization. This information is imperative because proper policy development requires decision-makers to:

• identify sensitive critical systems and information
• incorporate local, state, and federal laws, as well as relevant ethical standards
• define institutional security goals and objectives
• set a course for accomplishing those goals and objectives
• ensure that necessary mechanisms for accomplishing the goals and objectives are in place

In this way, legal and regulatory concerns, organizational characteristics, contractual stipulations, environmental issues, and user input can all be incorporated into policy development. Effective security policy synthesizes these and other considerations into a clear set of goals and objectives that direct staff members as they perform their required duties.

Getting Perspective

Although finalizing organizational policy is usually a task reserved for top-level decision-makers, contributing to the development of policy should be an organization-wide activity. While every employee doesn't necessarily need to attend each security policy planning session, top-level administrators should include representatives from all job levels and types during the information-gathering phase (just as in the case of brainstorming during risk assessment). Meeting with staff members on a frequent basis to learn about significant issues that affect their work is a big step toward ensuring that there is buy-in at all levels of the organization.

Decision-makers also need to be informed of security arrangements that other organizations are making that potentially impact them and the policies they will be developing. If, for example, every district but one in a state commits to encryption software to protect messages sent over the Internet, the lone school that does not have the encryption key is going to have a very difficult time communicating with its partners. The point is that just as security planning demands coordination internally, it often requires it externally as well-a recommendation that should not be overlooked, especially by those organizations that practice site-based management.

What to Include

As stated, an organization's risk assessment informs policy-makers of the system's specific security needs. But regardless of those findings, the following general questions (adapted from Network Security Secrets) should be addressed clearly and concisely in any security policy:

• What is the reason for the policy?
• Who developed the policy?
• Who approved the policy?
• Whose authority sustains the policy?
• Which laws or regulations, if any, is the policy based on?
• Who will enforce the policy?
• How will the policy be enforced?
• Whom does the policy affect?
• What information assets must be protected?
• What are users actually required to do?
• How should security breaches and violations be reported?
• What is the effective date and expiration date of the policy?

Writing with Proper Tone

Policy should be written in a way that makes sense to its intended audience. After all, guidelines that aren't implemented foreshadow objectives that won't be met. Tips for reader-friendly policies (adapted from Network Security Secrets) include:

• be concise-focus on expectations and consequences, but explain the underlying rationale when appropriate
• don't temper the message-truth is, you're not asking but telling, so don't propose, suggest, or insinuate unless that is specifically what you mean to do
• use simple, straightforward language as is possible
• define any term that could potentially confuse a reader-no need to make things more difficult than necessary
• be creative-presentation should never interfere with content, but checklists and reference cards usually increase utility

Another hint for ensuring appropriate tone is to word policy in a way that makes sense to both developers and users before giving the draft to legal counsel. The purpose for this is to keep clear and meaningful points from being transformed into incomprehensible legal jargon. If the official policy does eventually get transformed into something particularly formal, consider rewriting a distributable version designed specifically for reader friendliness.

From the Board Room to the Break Room: Implementing Security Policy

This document presents a great deal of information for policy-makers to consider. The role of an effective administrator, however, is to absorb these recommendations as appropriate and distill the results into a meaningful and manageable set of employee regulations that fit the organization. These rules then serve as the mechanisms for implementing policy goals and objectives throughout the workplace. Although it might be tempting (and certainly possible) to create an exhaustive inventory of "do's and don'ts," formulating a short list of sensible rules that can realistically be implemented is undoubtedly a better strategy.

How can policy implementation be made realistic? Aside from keeping regulations clear, concise, and understandable, try to make them as easy as possible for staff to fulfill. By keeping things as simple as possible, employee participation becomes a realistic aspiration. Specific actions that increase the likelihood of your policies actually being realized in the work environment include:

• Specifically assign an empowered and committed administrator to be accountable for security: Someone must make security a day-to-day priority. This designated staff member must be authorized to both reward and reprimand employees, as necessary, at all levels of organizational hierarchy (see Security Management).
• Institute staff training that is specifically tailored to meet the requirements of security policy and the needs of your staff: Recognize that most computer users have never been trained to properly use technology-and what little training they do have was probably aimed at teaching them how to perform the basic functions of their job assignments. Thus, the majority of your staff members have little understanding of security issues, and there is no reason to expect that to change unless the organization does its part to correct the situation.
• Communicate organizational needs and expectations to staff members in both initial and ongoing ways: Make a serious attempt at getting the word out to staff, but don't be overly serious in its presentation. Just like in any marketing campaign, creativity and consistency will be rewarded by audience responsiveness. The following examples are recommended as effective strategies for communicating security expectations to staff:
• Hold security refresher workshops.
• Create an infrastructure to support staff (e.g., a Help Desk that is staffed with competent and readily available advisors).
• Acknowledge exceptional behavior frequently and publicly.
• Develop and distribute reference materials (e.g., checklists, brochures, and summaries-remembering that succinct and reader-friendly material is much more useful than an unabridged tome of security obscurities).
• Update the employee handbook to reflect security procedures.
• Keep security reminders visible throughout the workplace (e.g., posters, FYI memos, and e-mail broadcasts).

• Enforce security regulations equally at all levels of the organization: Each individual in the system must understand that he or she is personally accountable for security. Bosses have to say, "get with the system," mean it, and prove so by doing so themselves. If the rules don't apply to everyone, then they apply to no one. This is not simply an egalitarian concept-if the system is not secure from top to bottom, then, by definition, it is not secure!

If your institution has several types of work environments or levels of users, consider writing separate security regulations, all of which support broader policy, for each user group. Each policy can then be tailored to the specific needs of the particular environment or user type. To increase involvement and acceptance, have staff members contribute to the development of their own policy guidelines and procedures. For completeness and consistency across the institution, each user group may require the services of an expert security coordinator while developing its own subset of guidelines.

Personnel Issues

One aim of successful security policy is that it should limit the need for trust in the system. While this may seem like a cynical philosophy, it actually serves to protect both the organization's employees and the organization itself. But before the benefits of security can be realized, staff members must be properly informed of their roles, responsibilities, and organizational expectations. (Bullets concerning personnel issues have been adapted from the Underground Guide to Computer Security.)

• Employees must be told in writing:
  • what is and is not acceptable use of equipment
  • what the penalties for violating regulations will be
  • that their activities may be monitored
  • that security will be a part of performance reviews (i.e., users who do their share should be rewarded, but those who lag behind might be reprimanded or retrained)
• Employees should be reminded that:
  • organizational resources, including computers, belong to the organization
  • there should be no expectation of privacy for information stored on or transmitted with the organization's equipment
• Employees should be required to sign a Security Agreement (see Appendix D for a sample) to acknowledge that they are aware of their responsibilities and verify that they will comply with security policy. This requires that:
  • staff members should have ample opportunity to read and review all policies and regulations for which they will be held accountable
  • staff members should be provided an appropriate forum for clarifying questions or concerns they may have about the organization's expectations
  • staff members should not be given access to the system until a signed agreement is accounted for and maintained in a safe place

All new employees should be expected to meet the organization's security requirements and procedures as a part of their job description. Once hired, new employees should be informed of, and trained on, security policy as a part of their initial orientation in order to impress the importance of security upon them.

A Special Note on Outsiders

Outsiders (e.g., repair technicians, consultants, and temporary help) and outside organizations (e.g., other departments, other institutions, and contractors) with access to your system should also sign agreements that require them to respect and maintain the system security. But be careful not to share more about your security operation with outsiders than is necessary. Even apparently harmless warnings about what to expect of your defenses can give a skilled intruder an edge in tampering with your system. Instead, limit security briefings to those levels required to (1) keep them from breaching your defenses, (2) impress upon them that you are serious about protecting your system assets, and (3) ensure that they handle your assets in a secure manner.

Having said this, sharing general news with the public-parents, local organizations, business partners, and lawmakers to name few-about your organization's commitment to securing systems and the confidential information they contain can instill a feeling of confidence throughout your organization and community.

Closing Thoughts on Policy

The incredible pace of technological innovations requires that all security policies be reviewed on a frequent basis. How frequently depends on your organization's needs and technological savvy. Generally speaking, each new technological change has the potential to necessitate a corresponding policy change-so it is a good rule to review all security policies annually at a minimum.