Chapter 3-Security Policy: Development and Implementation, from Safeguarding Your Technology, NCES Publication 98-297 (National Center for Education Statistics)

Chapter 1	Chapter 2	Chapter 3	Chapter 4	Chapter 5	Chapter 6	Chapter 7	Chapter 8	Chapter 9	Chapter 10
Table of Contents					Glossary of Terms

CHAPTER 3
Security Policy:
Development and Implementation

Illustration of the Cover of Safeguarding Your Technology

CHAPTER 3 IN A NUTSHELL:

Why Do You Need a Security Policy?
Commonly Asked Questions
How to Develop Policy
Closing Thoughts on Policy
Policy Development and Implementation Checklist

While the organization is responsible for securing confidential information, should there be a breach, it is the chief adminis-trator who sits in the "hot" seat.

Why Do You Need a Security Policy?

Who is responsible for securing an organization's information? Perhaps the Research and Evaluation department? Not exactly. The Management Information System (MIS) 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 in fact 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.

It Really Happens!

Like many people, Fred Jones thought he had a difficult job. As the Information Systems Manager in a small school district, he was responsible for operating a district-wide computer network--everything from installation and maintenance to user support and training. While it was clearly not a one-man job, he was his own one-man staff. Fred had tried to explain to his superintendent that the district's network was vulnerable to a range of threats because his small budget and non-existent staff prevented him from handling system security effectively, but his warnings had always been ignored.

One morning at a staff meeting, and much to Fred's surprise, the superintendent announced that he had read a newspaper article about a student breaking into a neighboring school district's computer system and changing report card records. The boss proceeded to declare that Fred was now being charged with developing and instituting a computer security policy for the school district.

As soon as the meeting was over, Fred approached the superintendent to request an appointment for them to discuss a shared vision for development of the security policy. "Effective security policy requires input and commitment from the whole organization, so I think we should sit down and map out a plan for developing our security policy," Fred asserted.

But the superintendent declined the invitation to participate in the policy-development process. "Fred, I'm just too busy to get involved in this project. I trust you to do a job that will make us all proud." When Fred asked about expanding his staff and budget to meet the increased workload, the superintendent again dismissed the issue. "Fred, times are tough and the budget is lean. Maybe next year we'll be able to work something out. In the meantime, you get cracking on securing our system as if your job depends on it... in fact, I guess your job does depend on it."

Fred watched his unrealistic, if well-intentioned, boss walk away, realizing that his job was no longer difficult, but truly impossible. He was now expected to develop, institute, manage, and monitor an organization-wide security policy without assistance, consent, or buy-in from a single employee, much less empowered high-level administrators. He knew that the organizational support he failed to receive meant that there was little chance of his being able to effectively secure the system--and that it was just a matter of time before a significant breach in system security would take place. Fred found himself in the terrible position of being responsible for stopping the inevitable, yet powerless to do so.

Commonly Asked Questions

Q. What does this document have to offer that experienced education policy-makers don't already know?
A. Experienced policy-makers certainly bring a great deal of skill to security policy development. But in many ways, security policy is different from other forms of more traditional policy--it requires policy-makers to think like data entry clerks, MIS staff, research and evaluation specialists, legal counsel, building administrators, teachers, and so on. Many of the procedural guidelines included here will already be appreciated by seasoned policy-makers, but this document tailors the information so that it can be more readily applied to the specific concerns of information and system security--an area of expertise not always held by educational administrators and policy-makers.

Q. Isn't policy written at the district and state level?
A. Yes, but not exclusively. Whoever is in charge of a site (be it a building, campus, district, or state education agency) must be concerned about protecting sensitive information and critical systems that can be accessed from within that site. This concern is articulated through security policies that are designed to regulate access and protect information and systems as circumstances within the organization specifically warrant.

Q. Shouldn't expert technology consultants be hired to do the job?
A. There certainly are roles for expert consultants when instituting security policy: they could be hired as general technical support or they might be useful in offering advice about countermeasures (e.g., a password system). But generally speaking, the chief educational administrator and his or her employees need to shoulder the responsibility of protecting their system because, after all, it is their system. They are the people who know it best and they will be the ones who have to implement adopted security policy. Outside contractors, while certainly capable of lending expertise to the process, cannot take the place of committed and informed staff.

How to Develop Policy

Tenable security policy must be based on the results of a risk assessment as described in Chapter 2. 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 information and critical systems

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

Effective security policy focuses planning guides activity, and, ideally, permeates an organization's entire culture

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 as they perform their required duties.

The Logic of Well-Planned Policy
If: Organizational needs define policy
and: Policy guides personnel and technology decisions
then: Personnel and technology serve organizational needs.

If staff have minimal input in policy development, they may show minimal interest in policy implementation.

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 administra-tors should include representatives from all job levels and types in the information gathering phase (just as in the case of brainstorming during risk assessment). Non-administrative staff have an especially unique perspective to share with policy-makers that simply cannot be acquired by any other means. Meeting with staff 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.

Reviewing security arrangements in other organizations might uncover information that can contribute to more effective policy development.

While it makes sense to get as much input from potential users as is possible, it is also essential that voices from outside the organization be heard during the information gathering stages of policy development. Why? Because decision-makers 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 school but one in a district 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.

Creating consortia, cooperatives, and other types of associations enables organizations to pool resources and share expenses as they endeavor to devise and implement security strategies.

What to Include

An organization's risk assessment, and not this document or any other source, informs policy-makers of their system's specific security needs. But regardless of those findings, the following general questions 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, are 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 policy 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 need be

Be creative--presentation should never interfere with content, but checklists and reference cards increase utility

Rewrite formal policy into a reader-friendly version that is distributed to staff.

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.

Read Chapters 5-9 for specific security guidelines to support your policies.

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 his or her organization. These rules then serve as the mechanisms for operationalizing 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.

Policies that are neither implementable nor enforceable are useless--ten security regulations that are implemented are more effective than 110 that are ignored.

If everyone is responsible in general, then no one is accountable in particular.

How can policy implementation be made realistic? Aside from keeping regulations clear, concise, and understandable, endeavor to make them as easy as possible for staff to fulfill. Remember, the goal is not to tell staff "how it is" as much as to get everyone to join in the effort. 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 Chapter 4, Security Management).

Unless the organization educates its users, there is little reason to expect security procedures to be implemented properly.

Increase security awareness by making security references readily available.

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 overcoming their fears and teaching them how to turn on their machines. At most, they may have learned how to use a particular piece of software for a specific application. Thus, the majority of your staff 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. Reluctance on the part of the organization to adequately prepare staff for making security policy a part of the work environment makes the rest of the effort an exercise in the theoretical--and theory won't protect a system from threats that are all too real (see Chapter 10, Training).

Because most people are unwilling to act unless they believe they are personally responsible, each user must be held individ-ually accountable for specific security functions.

Communicate organizational needs and expectations to staff 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 it by doing so themselves. If the rules don't apply to everyone, then they apply to no one. This is not simply an egalitarian moral--if the system is not secure from top to bottom, then, by definition, it is not secure!

Expecting every employee to become a security expert is wholly unrealistic. Instead, break down recommended security practices into manageable pieces that are tailored to meet individual job duties. A single, short and well-focused message each week will be better received than a monthly volume of information that is overly ambitious.

Without proof that an employee agreed to abide by security regulations, the sometimes necessary tasks of reprimand-ing, dismissing, or even prosecuting security violators can be difficult to pursue.

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 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 terribly 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 must be properly informed of their roles, responsibilities, and organizational expectations.

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 (users who do their share should be rewarded, whereas those who lag behind might be reprimanded or retrained).

Access without accountability is a recipe for chaos.

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 should have ample opportunity to read and review all policies and regulations for which they will be held accountable.
- Staff should be provided an appropriate forum for clarifying questions or concerns they may have about the organization's expectations.
- Staff 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.

Outside organizations should be expected to guarantee (via binding agreements) that they and their employees will use and secure shared information appropriately.

A Special Note on Outsiders

Outsiders (e.g., repair technicians, consultants, and temporary help) and outside organizations (e.g., other departments, other educational institutions, and contractors) with access to your system should also sign agreements that require them to respect and maintain the confidentiality of your information. 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 confidential information 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? That depends on your organization's needs and technological savvy. Generally speaking, however, each new technological change has the potential to necessitate a corresponding policy change--so it is a good rule to review all organizational policies (security or otherwise) annually at a minimum.

Policy Development and Implementation Checklist

While it may be tempting to refer to the following checklist as your security plan, to do so would limit the effectiveness of the recommendations. They are most useful when initiated as part of a larger plan to develop and implement security policy throughout an organization. Other chapters in this document also address ways to customize policy to your organization's specific needs--a concept that should not be ignored if you want to maximize the effectiveness of any given guideline.

Security Checklist for Chapter 3
The brevity of a checklist can be helpful, but it in no way makes up for the detail of the text.

Check Points for Policy Development and Implementation
Are the findings of the organization's risk assessment (see Chapter 2) available?
Have staff who represent a range of job levels and types been included in the security policy development process?
Have security-related practices, agreements, and arrangements in other organizations been reviewed to ensure that organizational policy is in line with those in comparable institutions and potential or actual trading partners?
Has appropriate and meaningful support/reference information been provided within the policy itself (see checklist under "What to Include")?
Has policy been written in a way that can be understood and appreciated by staff?
Have policy goals and objectives been translated into organizational security regulations that are designed to modify staff behavior?
Has an empowered and committed administrator been specifically assigned to be accountable for security (see also Chapter 4)?
Have staff received security training that was specifically tailored to their needs (see also Chapter 10)?
Have organizational needs and expectations been communicated to staff in both initial and ongoing ways (see checklist of recommended strategies)?
Are security regulations enforced equally at all levels of the organization?
Have staff been informed of their security roles and responsibilities in writing?
Have security issues been included as a part of employee performance reviews?
Is adequate time provided for reading and reviewing Security Agreements before employees and outsiders are required to sign and submit them?
Is an appropriate forum provided for clarifying concerns and answering questions about Security Agreements before employees and outsiders are required to sign and submit them?
Are all new employees trained on their security roles, responsibilities, and expectations?
Are outsiders (e.g., repair technicians) and outside organizations required to sign Security Agreements to acknowledge that they are aware of their responsibilities and will abide by the organization's security rules?
Has news of the organization's commitment to security been shared with the general public as appropriate?
Are security policies reviewed annually at a minimum?

Quote- No doctrine, howerve high, however true, can make men happy until it is translated into life! (Henry van Dyke)