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. Show
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? Q. Isn't policy written at the district and state level? Q. Shouldn't expert technology consultants be hired to do the job? 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:
The Logic of Well-Planned Policy If: Organizational needs define policyand: Policy guides personnel and technology decisionsthen: 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:
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:
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. 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:
Increase security awareness by making security references readily available.
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.
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. What are the three types of security policies where would each be used?A: Three types of security policies in common use are program policies, issue-specific policies, and system-specific policies. Program policies are the highest-level and generally set the tone of the entire information security program. Issue-specific policies deal with a specific issues like email privacy.
Who is responsible for enforcing policy that affects the use of technology?System administrators and users are responsible for enforcing policy. Based on NIST Special Publication 800-14, there are three types of information security policies.
What is security policy in information security?A security policy is a document that states in writing how a company plans to protect its physical and information technology (IT) assets. Security policies are living documents that are continuously updated and changing as technologies, vulnerabilities and security requirements change.
What are the differences between a policy a standard and a practice what type of policy would be needed to guide use of the web e mail office equipment for personal use?Policy - Written instructions that describe proper behavior. Standard - Detailed statement of what must be done to comply with policy. Practice - Examples of actions that would comply with policy.
|