Herding Cats 101: Development & =
Implementation of Security Policies at a University
As the owner of two cats, I can = vouch for the=20 fact that trying to get a cat to do anything on command is akin to = making=20 water flow uphill. Nearly impossible! Just like getting faculty, = staff and=20 students to readily agree to and abide by a university's security=20 policies. And that would be only half the battle. The other half = being the=20 creation and adoption of such security policies.
Universities have a well-deserved = reputation=20 for being primary launching sites for computer and network = attacks. The=20 "open" environment of a university lends itself well to the = development=20 and promotion of research and learning activities of faculty and = students.=20 But these same features make the university an ideal playground = for the=20 less well-intentioned. One of the launch points in the series of=20 denial-of-service attacks in February 2000 was a university in = California.=20 The system used to launch one of the attacks was compromised from = a source=20 outside the university.
These widely-publicized "hacker" = incidents=20 showcase the need for a basic security policy which governs and = oversees=20 the type of activities that are allowed on university computing = and=20 network resources. By providing basic guidelines for responsible = and=20 ethical use, a valuable resource can be shared by all university = community=20 members without infringing on the rights and privileges of others = but=20 still allowing enough flexibility and freedom for everyone to = accomplish=20 their goals and objectives. Without a policy in place, it is = impossible to=20 restrict undesirable activities.
Development of security = policies
In any organization, either private = or public=20 organizations, it would be difficult to have a single document be = the=20 authoritative SECURITY POLICY. Generally, multiple documents are = needed to=20 cover the broad range of issues and activities that fall into the = category=20 of "security". Separate policies should address different issues = such as=20 "Acceptable Behavior and Responsible Use", "Administrative = Information=20 Systems Security Policies", "Guidelines for Server Configuration = and=20 Attaching to a Network", "Software Security Policies", "Securing = of=20 Confidential Data", etc. Additionally, security policies in a = university=20 environment have to encompass and allow for a broad range of = activities.=20
But each policy should include = (where=20 appropriate) the following components:
Wherever possible, these security = policies=20 should reference existing policies to leverage processes already = in place=20 as, many times, technology just provides a different media and = additional=20 opportunities for behaviors already addressed elsewhere. For = example=20 cheating and plagiarism are already addressed in Student Code of = Conduct=20 policies. The medium by which the behavior is executed should not=20 supersede the behavior itself. Harassment is still harassment = whether done=20 face-to-face or electronically through email.
Additional supporting documents may = address=20 technical issues such as detailed instructions for securing = specific=20 systems and services, software installation and configuration, = password=20 administration and management, guidelines for attaching servers to = the=20 central network, backup policies and management, etc.
Prior to developing these policies, = it is=20 important to assess what resources need to be protected and to = determine=20 what CAN be protected. There's no point creating a policy or rule = that=20 cannot be enforced. It is also helpful to review policies of other = institutions and organizations as almost everyone has to deal with = these=20 same issues. It's often beneficial and insightful to look at = different=20 viewpoints and philosophies from organizations with various = purposes and=20 goals.
Who should develop these=20 policies?
If possible, recruit a task force = comprised of=20 representatives from different populations of the university = community to=20 develop these security policies. The committee should include=20 representatives from faculty, faculty administration, students, = staff,=20 system and network administrators, technology support staff, and=20 especially university administration. While the process may take = more=20 time, the end result will be a greater acceptance of these = policies by the=20 members of the university. And it is crucial to gain the approval = and=20 support of university administrators otherwise the ability to = implement=20 them will be severely curtailed.
Release initial drafts as Interim=20 policies.
Releasing an earlier version of the = policies=20 allows you to "work as you go". You retain the ability to = fine-tune the=20 policies before actually soliciting the formal approvals necessary = for=20 adoption. The process and effect of the interim policies can be = monitored=20 to see if the desired results are achieved. It may turn out that = some of=20 the recommendations may be too onerous or labor-intensive to put = into=20 practice. During this time, it would be prudent to solicit = comments and=20 opinions from larger populations such as student organizations, = executive=20 and administrative committees, technical support organizations, = and=20 faculty and staff unions.
Once the revision process has been = completed,=20 the final version should be compiled and re-released for final = comment.=20
Formal adoption of the policies = does not signal=20 the end of this process. In fact, nothing could be further from = the truth.=20 Having a policy in place, does not indicate that everyone will = know about=20 it and that it will be followed by everyone. There must be some = way of=20 notifying and educating the university community of the importance = of=20 abiding by these policies because without the underlying = understanding, it=20 will be like herding cats - nearly impossible at best. And this is = only=20 the beginning of an on-going, continuing process.
We have policies, now = what?
The university community needs to = be made aware=20 of the existence of your security policies and the impact of their = negligence to abide by those policies. Security is not just a set = of=20 documents and policies, but it's a mindset and philosophy that = needs to be=20 embodied by all. As we all know, the strength of our security is = as strong=20 as our weakest link. All members of the university need to = understand=20 their roles and the importance of their unified = participation.
Implementation of security policies = can be=20 tackled with a multi-pronged approach:
Formal adoption of the security = policies by the=20 university should be prominently and widely announced in both = official=20 notification channels as well as informal casual forums. = Face-to-face=20 group meetings may be held to explain the reasoning and impact of = these=20 policies and on-line forums may be used to carry-on discussions=20 electronically. The more opportunities provided for the community = to learn=20 about these things, the wider the adoption and support of these = security=20 policies.
The technology support organization = for the=20 university can assist in the implementation of policies by = developing=20 specific guidelines and recommendations that provides step-by-step = instructions that end-users can follow. This translates the more = general=20 policies into specific actions items that are easy to put in = practice.=20
Training of support staff provide = the=20 opportunity to indoctrinate the "security philosophy" into those = that are=20 directly involved and responsible for assisting the end users. = This=20 train-the-trainer philosophy leverages an existing information=20 distribution structure to facilitate getting the word out. By = teaching=20 security strategies and practices to support staff, they can = ensure their=20 end users are actually using them.
Monitoring, coordinating, and = tracking of=20 security incidents allows you to see if your security policies are = actually helping to decrease the number of incidents that are = occurring on=20 your campuses. Or you’ll be able to see if any changes need = to be made to=20 your policies. Without an incident tracking process, you cannot = determine=20 the impact the policies is having, for better or for worse, on = your=20 organization. It doesn’t make any sense to have policies in = place that=20 doesn’t improve the situation.
And finally, security policies and = procedures=20 must be reviewed constantly. Technologies change, threats change, = risks=20 and vulnerabilities change. To ensure that our policies still meet = our=20 needs, an on-going review process must be adopted. Otherwise, = we’ll be=20 right back to square one.
Hopper, D. Ian, Thomas, Pierre, = "Consulting=20 firm says its server was used to attack AOL", 11 February 2000, = URL: www.cnn.com/2000/TECH/computing/02/11/cyber.attacks.01/index.htm= l=20 , (21 November 2000).
University of Hawaii, "Use and = Management of=20 Information Technology Resources", October 1999, URL: www.hawaii= .edu/infotech/policies/itpolicy.html=20 (22 November 2000)
University of Virginia, Information = Technology=20 and Communications, "Security Policy", 1 September 1994, URL: http:/= /www.itc.virginia.edu/policy/Policies/security.html,=20 (21 November 2000).
U.S. Department of Education, = National Center=20 for Education Statistics, Safeguarding Your Technology, = NCES=20 98-297, Washington, D.C.: 1998
Virginia Polytechnic Institute and = State=20 University, "Acceptable Use of Computer and Communication = Systems", 4 June=20 1999, URL: www.vt.edu/admin= /policies/1000/2015.html,=20 (22 November 2000)
Virginia Polytechnic Institute and = State=20 University, "Acceptable Use Of Information Systems At Virginia = Tech", 16=20 June 1999, URL: www.vt.edu/= admin/policies/acceptuseguide.html,=20 (22 November 2000)
Wood, Charles Cresson, = Information Security=20 Policies Made Easy, California: Trade Services Publications,=20 1997