|
What Do I Put in a =
Security=20
Policy?
William Farnsworth
August 10, =
2000
O.K. I just finished a great =
security=20
conference and I am headed home motivated to make some changes in =
my=20
organization. The boss (one of those "decision makers") is =
skeptical. He=20
barely signed my travel request and he is "pretty sure" that our =
network=20
is fine.
After all, we have a =
firewall and our=20
virus scanners are up to date. Even with a couple of mis-steps we =
were=20
only down for a little over a day with a fairly significant =
infection from=20
the I LOVE YOU virus. And we have no evidence of anybody hacking =
through=20
our perimeter. So… why do we need a security =
policy?
I explain in great detail the =
difference=20
between a virus and an aggressive attack from outside, but it =
seems to do=20
no good…
And then salvation… we get an =
email from one of=20
our salesmen in the field with a copy of a disaster plan=20
requirement from one of our biggest customers! The pretty =
brochure=20
indicates that since we are one of their primary suppliers, they =
want to=20
understand our security practices as part of a continuation of =
delivery=20
program they are pursuing. They want to make sure that all their =
key=20
suppliers have a disaster plan and security plan to keep =
delivering=20
product under adverse conditions. Boss says, "Well O.K. we need a =
security=20
plan, is it done yet?"
Salvation? I am not so sure =
anymore. Now I=20
actually get to write one. But… what does it look like? =
Sure I know=20
our systems, I know how we connect to the Internet, I understand =
the email=20
systems, I understand how our internal systems are connected and =
how=20
fragile they are… but what goes into a security =
plan?
I bring up my word processor and I =
write=20
"MyCompany Information Security Plan." Cool, now we are getting =
somewhere…=20
but... where… What’s next?
Back to the drawing board, and to =
the Internet=20
for some information.
There are lots of samples of =
security policies=20
on the web. Every college of any size has a published security =
manual, or=20
parts of it, on their web site (1-8). Well I don’t =
know… University=20
computer security policies? How well will they relate to my =
business?=20
Think about it a little.. An environment where you have users on =
your=20
network that may have little or no loyalty to your organization =
(how long=20
will they be part of the organization? Weeks? Months? A few =
years?)… Users=20
that may have little fear of retribution (after all what can you =
do to a=20
college freshman?)… Users that are striving to attaint the =
peak of peer=20
recognition… users that are (at least) self-styled =
techno-dweebs… sounds=20
like a pretty rough security environment. Perhaps we could =
learn a=20
little bit from them.
But… it seems like a =
formidable task to review=20
each of these and develop a plan for MyCompany. I wonder if there =
is a=20
template file or we could develop one from some site.
Sure enough, the National Institute =
of=20
Standards and Technology (NIST) has a couple of articles on how to =
build a=20
security policy. Cool. The boss will understand that.
"Guide for Developing Security =
Plans for=20
Information Technology Systems" (9) is almost exactly what we =
want.=20
Well almost, it was developed in 1988 so the majority of the =
security=20
emphasis is directed toward large systems and physical security, =
including=20
emphasis on floppy distribution of viruses. There are only two =
mentions of=20
firewalls in the document and then more in passing than anything =
else. It=20
is a very informative document, but in many ways it misses the =
mark for a=20
company whose greatest vulnerability is email viruses. And email =
is not=20
mentioned once in the document.
So… here we are almost back =
at square one. Ms=20
Swanson authored another document two years earlier with Barbara =
Guttman;=20
"Generally Acceptable Principles and Practices for Securing =
Information=20
Technology Systems." This document has perhaps a better =
overview of=20
the process but still lacks specific relevance in today’s =
world.=20
Off to the web again… and we =
find our favorite=20
source of technical documentation, the RFC’s. Sure enough, =
the original=20
RFC1244 "Site Security Handbook" (11) and it’s =
replacement RFC2196=20
"Site Security Handbook" provide more great information and =
we=20
start to see an outline forming.
The final outline is attached at =
the bottom of=20
this discussion, but our overall approach deserves some=20
attention.
It was clear that each of the =
organizational=20
units of our company and even our central Information Technology =
division=20
needed specific policy and procedure flexibility. The central =
organization=20
(CIS) provides telephone, network, web server and some financial =
services.=20
Each business unit, organized by vertical market segment may have =
slightly=20
different security requirements. The outline allows for a =
definition of=20
this flexibility in the General Information section, and each of =
the=20
operational units in the CIS organization has a section of the =
policy and=20
procedure manual outline below.
Business units and the =
international=20
organizations are free to write additional policies for IT areas =
for which=20
they have responsibility, but the corporate document will cover =
sections=20
that they do not touch.
There are a few common sections =
that are used=20
by each department, but each department is not an exact match to =
all the=20
other departments.
Authentication of the user is =
critical for most=20
of the departments. User password requirements are especially =
important=20
for the domain administration section, and for the legacy systems. =
We=20
continue to support legacy systems on VAX hardware and some of our =
new ERP=20
systems require separate login administration.
Intrusion protection is required in =
all=20
sections. Monitoring attempted (and real) access is of importance =
to make=20
sure that confidential information is not compromised, and the =
systems are=20
protected from malicious attacks.
Physical access to the data center, =
the Network=20
Operations Center, cable closets on the campus and the telephone =
switch=20
rooms is specified in this section. Who has access and who needs =
to be=20
escorted during visits are all specified here…
Almost all of our equipment has =
backup=20
requirements. The data center with its financial systems is our =
primary=20
concern, but we shouldn’t forget the network routers, =
switches, and even=20
the phone switches have magnetic media that needs backup policies. =
Firewalls, intrusion detection systems, content filters all =
require=20
consistent backup policy. Offsite storage is also a consideration. =
We live=20
in a tornado area and offsite backup is very definitely part of =
our daily=20
procedures.
Disaster planning is part of each =
of these=20
areas as well. Taking the time up front saves time and money when =
the=20
tornado wipes out the data center, or the NOC, or any of the =
buildings on=20
campus.
Auditing of all our systems is =
necessary to=20
provide evidence and clues to diagnose and document problems after =
an=20
incident. In addition clear usage policy is included to protect =
the=20
authorized network operations folks when it is necessary to scan =
various=20
machines and ports on the network. At the same time the sections =
on=20
intrusion protection and acceptable use policy include =
restrictions on who=20
can monitor and probe the network.
Some of the special topics that =
need to be=20
covered in any comprehensive security policy are policies for =
modems,=20
dial-in, dial-out, employee departure procedures and a section on =
incident=20
handling.
Incident handling is described in =
significant=20
detail with roles and responsibilities, and a step-by-step =
procedure from=20
identifying the incident to the final forensics.
I encourage you to look at other =
practices and=20
procedures for guidance for your own policy documentation and =
adapt them=20
to fit your implementation requirements.
Bibliography
(1) Various. "Texas A&M =
Computer=20
Security Policy." Texas A&M Computing and Information =
Services.=20
November 1999. http://www.tam=
u.edu/cis/qapcm/SecurityPolicy.html.=20
(August 10, 2000)
(2) Various. "ITS Lab Support =
Policies &=20
Guidelines." Information Technology Services, University of =
Colorado=20
at Boulder. January 1998. http://its=
web.colorado.edu/docs/policy.procedure.html.=20
(August 10, 2000).
(3) Fritchley, David. "Computer =
and Network=20
Use Policies." Policy and Procedure @ Ohio University. =
February 1997.=20
http://www.ohiou.edu/pol=
icy/91-003.html.=20
(August 10, 2000).
(4) Various. "Policies and =
Responsibilities=20
for Use of Campus Computer and Network Resources." Academic =
Computing=20
and Network Services, Florida State University. February 2000. http://www.acns.fsu.edu=
/docs/policy.html.=20
(August 10, 2000).
(5) Various. "Information =
Technology=20
Security Policy." Office of Information Technology Services, =
Murdoch=20
University, Perth, Western Australia, 1997, http://wwwits=
2.murdoch.edu.au/security/policy.html.=20
(August 10, 2000).
(6) Various. "Proposed Network =
Security=20
Policy." Computer Security Administration, University of =
Toronto. July=20
31, 2000. http://www.utoronto.ca/s=
ecurity/policy/.=20
(August 10, 2000).
(7) Various. "Information =
Technology=20
Computer and Network Security." University of California, =
Davis. May=20
14, 2000. http://security.ucda=
vis.edu/text/index.html.=20
(August 10, 2000).
(8)Masse, M. "Information =
Security Policy=20
for Administrative Information." Administrative Information =
Technology=20
Services, University of Illinois. April 1999. http=
://www.aits.uillinois.edu/security/securestandards.html.=20
(August 10, 2000).
(9) Swanson, Marianne. "Guide =
for Developing=20
Security Plans for Information Technology Systems." NIST =
Special=20
Publication 800-18. December 1988. http://csrc.nist.gov=
/nistpubs/Planguide.PDF.=20
(August 9, 2000).
(10) Swanson, Marianne and Guttman, =
Barbara.=20
"Generally Acceptable Principles and Practices for Securing =
Information=20
Technology Systems." NIST Special Publication 800-14, =
September 1996.=20
http://csrc.nist.gov/ni=
stpubs/800-14.pdf=20
(August 9, 2000).
(11) Holbrook, P. and Reynolds, J. =
editors.=20
"RFC1244 Site Security Handbook." July 1991. http://www.faqs.org/rfcs/r=
fc1244.html.=20
(August 9, 2000).
(12) Fraser, B. editor. "RFC2196 =
Site=20
Security Handbook." September 1997." http://www.faqs.org/rfcs/r=
fc2196.html.=20
(August 9, 2000).
Sample Security Policy=20
Outline
1. Introduction
1.1.1General =
Information
1.1.2=20
Objectives
1.2 Responsible Organizational =
Structure
1.2.1.1.1 Corporate =
Information=20
Services
1.2.1.1.2 Business Unit Information=20
Services
1.2.1.1.3 International =
Organizations
1.2.1.1.4=20
=
Tenants
1.2.2 Security=20
Standards
1.2.2.1.1=20
Confidentiality
1.2.2.1.2 Integrity
1.2.2.1.3=20
Authorization
1.2.2.1.4 Access
1.2.2.1.5 Appropriate =
Use
1.2.2.1.6 Employee=20
=
Privacy
2. Domain Services
2.1.1 =
Authentication
2.1.2 Password=20
Standards
2.1.3 Resident Personnel Departure
2.1.3.1.1 Friendly=20
Terms
2.1.3.1.2 Unfriendly=20
=
Terms
3. Email Systems
3.1.1 =
Authentication
3.1.2 Intrusion=20
Protection
3.1.3 Physical Access
3.1.4 Backups
3.1.5=20
Retention Policy
3.1.6=20
Auditing
4. WEB Servers
4.1.1 Internal
4.1.2=20
External
5. Data Center
5.1.1 =
Authentication
5.1.2 Intrusion=20
Protection
5.1.3 Physical Access
5.1.4 Backups
5.1.5=20
Retention Policy
5.1.6 Auditing
5.1.7 Disaster=20
Recovery
6. LAN/WAN
6.1.1 =
Authentication
6.1.2 Intrusion=20
Protection
6.1.3 Physical Access
6.1.3.1.1 =
Modems
6.1.3.1.2=20
Dial-in Access
6.1.3.1.3=20
Dial-out
6.1.4 Backups
6.1.5 =
Retention=20
Policy
6.1.6 Content Filtering
6.1.7 Auditing
6.1.8 =
Disaster=20
Recovery
6.1.8.1.1 Network =
Operations=20
Center
6.1.8.1.2 Physical Network=20
=
Layer
7. Desktop Systems
7.1.1 =
Authentication
7.1.2 Intrusion=20
Protection
7.1.3 Physical Access
7.1.4 Backups
7.1.5=20
Auditing
7.1.6 Disaster=20
Recovery
8. Telecommunication =
Systems
8.1.1 =
Authentication
8.1.2 Intrusion=20
Protection
8.1.3 Physical Access
8.1.4 Auditing
8.1.5 =
Backups
8.1.6 Retention Policy
8.1.7 Disaster=20
Recovery
9. Strategic Servers
9.1.1 =
Authentication
9.1.2 Intrusion=20
Protection
9.1.3 Physical Access
9.1.4 Backups
9.1.5=20
Retention Policy
9.1.6 Auditing
9.1.7 Disaster=20
Recovery
10. Legacy Systems
10.1.1=20
Authentication
10.1.1.1.1 Password =
Standards=20
10.1.2 Intrusion =
Protection
10.1.3=20
Physical Access
10.1.4 Backups
10.1.5 Retention =
Policy
10.1.6=20
Auditing
10.1.7 Disaster=20
Recovery
11. Security Services and =
Procedures
11.1 Auditing
11.2=20
Monitoring
12. Security Incident =
Handling
12.1 Preparing and Planning =
for Incident=20
Handling
12.2 Notification and Points of Contact
12.3 =
Identifying=20
an Incident
12.4 Handling an Incident
12.5 Aftermath of an =
Incident
12.6 Forensics and Legal Implications
12.7 Public =
Relations Contacts
12.8 Key Steps
12.8.1.1.1 =
Containment
12.8.1.1.2=20
Eradication
12.8.1.1.3 Recovery
12.8.1.1.4=20
Follow-Up
12.8.1.1.5 Aftermath / Lessons=20
=
Learned
12.9=20
Responsibilities
13. Ongoing Activities
13.1.1 Incident =
Warnings
13.1.1.1.1 Virus=20
warnings
13.1.1.1.2 Intrusion =
Vulnerabilities
13.1.1.1.3=20
Security=20
=
Patches
14. Contacts, Mailing Lists and =
Other=20
Resources
15. References
|
