|
Herding Cats 101: Development & =
Implementation of Security Policies at a University
Jodi=20
Ito
November 22, 2000
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:
- reasoning behind the creation of =
the=20
policies=20
- expected and allowed behavior =
and=20
activities=20
- individual roles and =
responsibilities=20
- ownership, disclosure, and =
confidentiality=20
of systems, resources, and data=20
- due process and
- penalties and severity of =
penalties for any=20
violations or infringements.
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:
- education and awareness =
campaign=20
- development of implementation=20
recommendations and specifications=20
- on-going training opportunities =
for=20
technical support staff=20
- monitoring and tracking of =
incidents=20
- continual review and =
modification of=20
policies
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.
References:
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 |
