Tài liệu GIAC Basic Security Policy doc

1




GIAC Basic Security Policy

Version 1.4 February 27, 2001


I keep six honest serving men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
Rudyard Kipling





CONTRIBUTING AUTHORS:

Doug Austin Dyncorp Information Systems, LLC
Alexander Bryce Alexander, Ltd.
Rob Dinehart IBJ Whitelhall Financial Group
Stephen Joyce bitLab, LLC
Carol Kramer SANS Institute
Randy Marchany Virginia Tech Computing Center
Stephen Northcutt Global Incident Analysis Center
John Ritter Intecs International, Inc.
Matt Scarborough IC

Arrigo Triulzi Albourne Parners, Ltd.

EDITED BY: Carol Kramer, Stephen Northcutt, Fred Kerby

If you have corrections or additions or would like to be involved in
enhancing this project, please send email to:

2

A
note from the director of GIAC Training and Certification:
I have never ceased to be amazed by the fact that you can’t take a class in information security without
being told to do this or the other thing in accordance with “your security policy”. But nobody ever
explains what policy is, or how to write or evaluate it. This is why we have begun this research and
educational project into security policy. We hope you find this booklet useful, and even more, that you
will get involved and help. Consensus is a powerful tool and we need the ideas and criticisms of the
information security community to make this the roadmap for usable, effective policy. Thank you!

Stephen Northcutt

CONTENTS

1. PREFACE

2. USING SECURITY POLICY TO MANAGE RISK

3. DEFINING SECURITY POLICY

4. IDENTIFYING SECURITY POLICY

5. SECURITY POLICY WORKSHEET

6. EVALUATING SECURITY POLICY

7. ISSUE-SPECIFIC SECURITY POLICY

7.1 Anti-Virus

7.2 Password Assessment

7.3 Backups

7.4 Incident Handling

7.5 Proprietary Information

8. WRITING A PERSONAL SECURITY POLICY

9. EXERCISES

APPENDIX A - Policy Templates

APPENDIX B - Sample Non-Disclosure Agreement
3
1. PREFACE


S
ecurity policy protects both people and information.

Safeguarding information is challenging when records are created and stored on
computers. We live in a world where computers are globally linked and accessible,
making digitized information especially vulnerable to theft, manipulation, and
destruction. Security breaches are inevitable. Crucial decisions and defensive action
must be prompt and precise.

A security policy establishes what must be done to protect information stored on
computers. A well-written policy contains sufficient definition of “what” to do so that
the “how” can be identified and measured or evaluated.

An effective security policy also protects people. Anyone who makes decisions or takes
action in a situation where information is at risk incurs personal risk as well. A security
policy allows people to take necessary actions without fear of reprisal. Security policy
compels the safeguarding of information, while it eliminates, or at least reduces,
personal liability for employees.

Please take a minute and turn to the back of this book and examine the non-disclosure
agreement in Appendix A.

This is one of two examples in the book that is not written in plain English. This legal
document is based on the actual non-disclosure agreement that GIAC uses when
disclosing proprietary information. Despite the lawyer language of the document, it
doesn’t take long to see that the purpose of this is to protect information. It carefully
spells out the procedures, the who, what, where, when and how for the case where an
organization has sensitive information that it is going to disclose to an individual. As we
learn more about policies, we will find that many aspects of a policy can be found in a
document like this. In fact, an organization’s policy might reference a document like
this. For instance, an organization may have a policy that says, "sensitive information
shall only be released to individuals who have signed a non-disclosure agreement that is
on file with the corporate legal office". Now that we have an example of a policy that

protects information, I would like to show an example of a policy that protected an
individual - in this case, me.


Sinking a Warship

I was scanning our entire Navy lab, one subnet at a time (the recommended approach),
fixing problems as I found them. I was running the scanner on low power when I hit a network
and received a phone call from a friend. "Stephen, the net is down, we think you killed it".
4
"It" was a mock up of a real Navy warship. All of the communications on the model were
the same as the one on the real ship. When its networking hardware received a packet (from me)
on a certain port, it died. Its FDDI ring came to a complete stop.
The people in this little lab were furious with me. They formed an investigative panel and
called me in. I could see by the grim looks all around the table that this was not going to be
pleasant. The sparks flew; one fellow in particular wanted to do me harm. He continues to be
angry with me to this day! Finally someone asked whether could happen in real life. The answer
was “yes”. The next question was, “then shouldn’t we get it fixed”?
The point is, my network scan made these people angry enough that my job would have
been in jeopardy if I’d not had my ducks in a row. I’d received permission to run the scan prior
to doing so. So should you!
Stephen Northcutt


5
2. USING SECURITY POLICY TO MANAGE RISK


PROBLEM: The only secure computer is one that is not connected to a network and is
powered off. Use of computers to process information has associated risks. You need a

methodology to validate that the organization is responsible and accountable for
managing that risk.

ACTION: Learn how to manage risks related to your job.

Step 1: Identify risks.
Determine how your organization uses computers and networks in the conduct of
business, both routinely and under emergency circumstances. This will provide insight
into the risks that you face. Examples of some things that can pose risks include: using
the Internet, not using anti-virus software on desktop computers, permitting
customers/suppliers/partners to bypass the protection afforded by your firewall,
permitting personal use of corporate computers and networks.

Step 2: Communicate your findings.
Identifying risks is necessary, but not sufficient. Decision-makers need to know what
the risks are, as well as options for managing those risks. Be sure you have adequately
communicated the situation in writing to folks who can make a difference.

Step 3: Update the security policy as needed.
If there is no written policy in place, write it and get it signed by upper level
management. A well-written policy, signed by top executives, will identify the
corporation’s values and demonstrate that senior management supports the
information security activities required by the policy
.


Step 4: Develop and refine methods to measure compliance with the policy.
If you cannot measure compliance (conformance), the policy is unenforceable.

Where is it written…?

The decisions we make must stand the test of reasonableness: given the situation, could a
reasonable person be expected to make the same decision? It’s amazing to hear people who have
been practicing computer security for more than a decade, ask, “What instruction requires that
we do it that way? (or at all)". Having a written and dated policy signed by upper management
can help move these folks to where they need to be.
6
3. DEFINING SECURITY POLICY


PROBLEM: All security and technical classes talk about the necessity of basing
procedures on a good security policy. We need to understand what is meant by policy;
there are many conflicting definitions.

ACTION: Identify how your organization defines policy.

Step 1: Get a copy of your organization’s Policy Development Guide.
Ideally, the guide will describe what topics to include in the policy document. Typical
sections can include:
Purpose - the reason for the policy.
Related documents – lists any documents (or other policy) that affect the contents
of this policy.
Cancellation - identifies any existing policy that is cancelled when this policy
becomes effective.
Background - provides amplifying information on the need for the policy.
Scope - states the range of coverage for the policy (to whom or what does the
policy apply?).
Policy statement - identifies the actual guiding principles or what is to be done.
The statements are designed to influence and determine decisions and actions within
the scope of coverage. The statements should be prudent, expedient, and/or

advantageous to the organization.
Action - specifies what actions are necessary and when they are to be
accomplished.
Responsibility - states who is responsible for what. Subsections might identify
who will develop additional detailed guidance and when the policy will be reviewed
and updated.

Step 2: Determine who can sign the policy.
If you are part of a Department of Defense organization, the authority may be reserved
for the senior military officer. In other cases, it may be a senior vice president or a CIO
or other manager. In any case, the policy must be signed by someone with sufficient
authority and credibility that it is accepted by members of the organization to which it
applies.

Step 3: Identify the process used to get policy drafted, signed, and
implemented in your organization.
Once you’ve identified what should be in the policy and who will sign it, you need to
identify the folks who will help develop and review the policy before you submit it for
signature. Typical participants (in addition to the security staff) can include members of
the legal and human resources staff, as well as a representative from one or more
collective bargaining units.

7
Coaching Football
Think of a football game. Picture the coach at practice sessions, in the locker room
before the game. What is the coach doing? He is presenting, refining and reworking a
plan for winning the game, a plan that’s practiced over and over until it’s perfect! We
can see team captains and players referring to the plan before each play. What does a
game plan have to do with a computer security policy? The game plan is actually a
policy on how to win the game. The team that identifies its capabilities and limitations,

along with the capabilities and limitations of its opponents, will devise the best plan and
the best chance of winning if they follow it.

8
4. IDENTIFYING SECURITY POLICY


PROBLEM: My organization doesn’t seem to have a security policy.

ACTION: Identify what your organization does have, and try to make it better.
Your actions may include lobbying to create or expand current policy.

Step 1: Recognize that policy exists on different levels.
Unless you are at the top of the organizational hierarchy, there is likely to be a part of
the organization above your level that issues policy that you are expected to implement.
A common hierarchy for policy in an organization might look like this:

Enterprise-wide or Corporate Policy: the highest level (perhaps national); consists of
high-level documents that provide a direction or thrust to be implemented at lower
levels in the enterprise.

Division-wide Policy: typically consists of an amplification of enterprise-wide
policy as well as implementation guidance. This level might apply to a particular
region of a national corporation.

Local Policy: contains information specific to the local organization or corporate
element.

Issue-Specific Policy: policy related to specific issues, e.g. firewall or anti-virus
policy.

Security Procedures and Checklists: local Standard Operating Procedures (SOPs);
derived from security policy.

Security policy may exist on some levels and not on others. Documents interact and
support one another, and generally contain many of the same elements. In a typical
organization, policy written to implement higher-level directives may not relieve
(waive) any of the requirements or conditions stipulated at a higher level. Security
policy must always be in accordance with local, state, and federal computer crime laws.

Step 2: Collect and organize the applicable written, dated, and signed policy
documents.
Now that you understand the policy hierarchy, you can collect policy documents
available at several levels in the organization. A security policy usually exists (and is
enforced to some extent) even if it is not written down. When you find instances of
unwritten policy, note them as areas for improvement. Putting the policy in writing
prevents misunderstandings and promotes right actions. Encourage your management
to articulate security policy in writing.

Step 3: Assemble existing procedures for inclusion in the policy review.
In the process of collecting policy documents, you may find procedures (perhaps issue
9
specific) that do not appear to be the result of any specific policy. If so, note them for
inclusion in the policy review (discussed next).

10
5. POLICY WORKSHEET

Procedures are derived from policies. A procedure can be used to identify and define
the parent policy, even if the policy is not written and signed.

ACTION: List procedures for which you need to document the policy. Make notes
on the who, what, when, and where.

Sample worksheet:
Step 1: Who does the procedure? Why?
The network administrator rolls out anti-
virus updates to local desktops.
To protect against virus infections.
Certain administrative rights are needed to
configure the push to users’ local drives.

Step 2: What is the procedure? Why?
Definitions are unpacked, and placed in a
shared directory. Login scripts download
the files, apply the update, and reboot the
machines. Machine names are flagged in
the database as having been updated

Automate the process; create an exception
list.
Step 3: When is the procedure done? Why?
The procedure is done weekly. To keep up to date with the latest virus
attacks. Our vendor rolls out new
definitions every Thursday.

Step 4: Where is the procedure done? Why?
The procedure is done from any
administrative workstation. The procedure
is applied to all desktops running Windows

9x at location XXXX.
No special location is required to apply the
procedure. All desktops need to have the
most current updates.

Step 5: Looking at the notes from both columns, the policy becomes clear. The
description identifies the threat (virus infection) and provides for safeguards.

Sample policy derived from procedures outlined in the example above:
To ensure all desktops running Windows 9x are protected from viruses with the most recent
updates, the network administrator at each location will apply the latest virus definition updates
biweekly. Although the process can be automated, checks must be put in place to ensure the
updates have been applied successfully.

11
6. EVALUATING SECURITY POLICY


PROBLEM: Your organization has a written security policy, but it is confusing,
difficult to follow, or doesn’t address one or more significant risk areas.

ACTION: Identify policy attributes that need improvement and prepare draft
revisions.

Step 1: Verify that the security policies contain the most common elements.
Look for the following elements, and note what is missing.

Purpose

Security policy usually contains a statement, often at the beginning, describing the

reason the policy is being established, and any associated goals.

Related documents
This is often entitled “References” and usually cites higher-level policy or
implementation guidance.

Cancellation

New or updated policy may supersede existing (perhaps outdated) policy. This section
identifies those policies and clarifies what is actually in effect.

Background

This optional section is sometimes included to provide information amplifying the need
for the policy. It may also provide historical information relevant to the subject.

Scope

This section identifies the depth and breadth of coverage (to whom or what the policy
applies). Is it for one element of the organization or will it also apply to contractor
agencies who work for your organization?

Policy statement

Identifies the actual guiding principles or what is to be done. The statement(s) are
designed to influence and determine decisions and actions within the scope of coverage.
The statements should define actions that are prudent, expedient, or advantageous to
the organization.

Responsibility

The security policy document states who is responsible for what. Typical positions that
might be addressed include the head of the corporation, the CIO, people in the legal
department or in human resources, system administrators, and information security
officers. Subsections might identify how additional detailed guidance will be
developed and provided, as well as the frequency of policy review. Methods or
12
techniques for measuring compliance may also be included in this section (as well as
identifying parties responsible for the audit).

Action

This section specifies what actions are necessary and when they are to be accomplished.
It may identify the time frame in which additional guidance (mentioned above) will be
forthcoming. Hopefully the policy meets the criteria stated above, but there may be a
need for a waiver process. This is one logical place to identify that process as well as
the time frame for policy review (and by whom).

Note that not all sections are required. If your search for a Policy Development Guide
was successful, consult it to determine required sections. If there is no written guide,
use the above template and check with other folks who have been successful in getting
other policy signed and implemented.

Step 2: Examine the security policy to see if it is clear
.
One simple way to test for clarity is to have one of the individuals identified as being
responsible determine whether he or she understands the responsibility.

Step 3: Examine the security policy to see if it is concise
.

A specific policy topic (e.g., anti-virus signature updates) shouldn’t exceed two pages.
Many organizations limit them to one page.

Step 4: Examine the policy to see if it is realistic
.
Security policy shouldn’t require people to try to implement things that can’t be
implemented.

Government Policy

People in the United States government create some of the worst security policy in the world.
They spend taxpayer money contracting for huge notebooks of overly long, poorly written, non-
specific prose. The policy documents are so large that they cannot be updated without generating
a massive review cycle. They often require people to implement things that are not possible to
implement. Here is a brief example:
“The head of a Federal agency may employ standards for the cost effective security
and privacy of sensitive information in a Federal computer system within or under
the supervision of that agency that are more stringent than the standards
promulgated by the Secretary of Commerce, if such standards contain, at a
minimum, the provisions of those applicable standards made compulsory and
binding by the Secretary of Commerce.”

How many times did you have to read this example of
government policy before you understood what it said?
Or are you still trying?

13

Step 5: Examine the policy to see if it provides sufficient guidance
that a

specific procedure can be developed from it.
Policies address what is to be done and why. Procedures specify how things are done
and are how policy ultimately gets implemented. For example, if you have an Internet
connection policy, you should be able to create procedures that allow you to configure
your firewall from it. Procedures are also the basis for written checklists. Writing
guidelines or checklists is work, and people often do not wish to be bothered
documenting procedures. Many organizations have one or two employees proficient in
configuring systems, firewalls and routers. They often claim to be "too busy" to develop
written procedures. But what happens when they aren’t there?

The Bomb:

Deak Parsons was a Captain in the Navy and an Ordnance specialist. He was assigned
to the Manhattan Project during World War II. He put the first production atomic bomb
together but not in a lab or armory. He put it together in the bomb bay of the B-29 airplane
that dropped the first atomic bomb. He assembled it at 29,000 feet over the Pacific Ocean on the
way to Japan.
Parsons had one assistant who read to him a seven-step checklist. The checklist was a
kind of policy on how to do the job. The procedure was very stressful and risky, but it was
something he could almost do blindfolded, because of the checklist.
Good policy will reduce both stress and risk, just like the checklist did. If you
don’t have a policy (or checklist), you’ve got a time bomb on you hands waiting to go BOOM!

Step 6: Examine the policy to see if it is consistent
with higher-level policy and
guidance.
If you discover any discrepancies between the policy you are reviewing and higher-
level policy, note them, as you will need to resolve them for the policy to be
meaningful. Security policy must also be in accordance with local, state, and federal
computer crime laws. Again, note any contradictions you discover so you can get the

policy corrected.

Step 7: Examine the policy to see if it is forward looking
.
Security policy should be open to change based on new risks and vulnerabilities,
especially following an incident. It should not be hardware- or software-specific.

Step 8: Examine the policy for provisions to keep it current
.
Security policy should be reviewed regularly. Revisions in implementation should
reflect lessons learned from recent incidents and new threats to the organization’s
security. See “Action” above.

Step 9: Check to see if the security policy is readily available.
The Policy Development Guide may provide information regarding responsibility for
publishing and making available specific policy documents. Security policy should be
14
incorporated in employee handbooks and posted for reference. It must be required
reading as part of the new employee orientation process.

15
7. ISSUE-SPECIFIC SECURITY POLICY

Issue-specific policies may often be brief and to the point. The following examples of
issue-specific security policy steps contain information and ideas you may find valuable
for your organization.

Issue-Specific Policy #7.1: ANTI-VIRUS

PROBLEM: Normal day-to-day work encompasses email, Internet connections,

installing new software, and taking work home at the end of the day and bringing it
back in the morning. All these practices allow the introduction of viruses.

ACTION: Develop an anti-virus policy.

Step 1: Select the scope of the policy.
An anti-virus policy serves as an umbrella for a set of procedures. The policy should
address how to select software products, what to do when a virus is detected, how to
limit the possible entry paths, how to contain the damage to infected systems, and how
to deploy the software to ensure desktop coverage.

Step 2: Layer your defenses.
In addition to desktop software, consider including procedures in the policy to scan for
viruses and other malicious code on the file servers, mail servers, firewalls and other
machines that see traffic from the Internet to internal machines.

Step 3: Identify responsibilities.
Make sure that persons responsible for keeping the signatures updated understand
that. If workers transport files from the office to home and back again, the anti-virus
strategy should take this into account and advise them that they are responsible for
scanning files introduced in any way that bypasses protection provided by the
corporation.

Step 4: Measure the effectiveness.
Every anti-virus policy should require reporting of viruses; that is the only way to
gauge the extent of problems. However, people seldom report viruses. Reporting takes
time, and may indicate failure to follow policy. Consider using anti-virus products that
report automatically.

Issue-Specific Policy #7.2: PASSWORD ASSESSMENT


PROBLEM: Password assessment is necessary to maintain the protection of
information, but the procedure may appear to be illegitimate. People have been
prosecuted for assessing (cracking) passwords, when they claimed they were just doing
their job.
16

ACTION: Develop a password assessment policy.

Step 1: Identify the risk.
The early history of hacking was mostly an exercise in password guessing. This is still a
popular technique. Consider how many Windows NT systems have been compromised
via the one-two punch of null sessioning and password guessing. Even better than
guessing is password cracking. Once intruders have the password file, they can attack
off line. There are a variety of techniques to acquire the password file for both Unix and
NT systems. To make both acquisition and cracking of password files more difficult for
attackers, define minimum standards for passwords. The security policy should specify
procedures for formulating passwords, such as requiring eight characters, and avoiding
the use of dictionary words by inserting a non A-Z character in the string. It should
also define procedures for maintaining the security of password files as described in
Step 2.

Step 2: Enumerate the countermeasures.
The policy should employ procedures for configuring systems to make it more difficult
for the attacker to access the password file in the first place. These include shadow
passwords for Unix, and disabling null sessions for NT.

Step 3: Enable administrators to legally assess password strength.

The policy should enforce password protection by providing for the use of systems
tools that filter passwords and tools that crack them the same cracking tools that
attackers use. Identify conditions under which password assessment is permitted and
encouraged. If you plan to use password cracking yourself, be sure you have written
authorization – either unequivocal policy, or a separate authorization from top management.

Step 4: Escrow passwords for use during incidents.
Incident handlers and system administrators may need to access privileged passwords.
The policy should provide for a procedure to store critical systems passwords in a
sealed envelope in a secure container.

Case in Point!

Randall Schwartz
Randall L. Schwartz is a well-known security consultant, respected for his contributions
to the Perl programming language through two books and long-time participation in the Perl
newsgroups.
While he was working as a consultant at an Intel Corporation facility in Beaverton,
Oregon, he ran a program called “crack” to test the strength of passwords at another division of
Intel where he had previously worked. His actions were not covered by a specific written policy.
Mr. Schwartz was charged with (1) altering a computer and a computer network without
authorization; (2) using a computer and computer network for the purpose of committing a theft;
17
(3) committing theft of individual passwords.
In late July 1995, a jury convicted Randall Schwartz of three felony counts under
Oregon’s Computer Crime Law. His sentence included five years of probation, 480 hours of
community service, 90 days of deferred jail time, and $68,000 of restitution to Intel. By the end
of 1995, his legal bill exceeded $170,000. Eventually, due to exemplary compliance with the
terms of probation, the judge converted the deferred jail time to suspended jail time.
This story is told in more detail, and insights on some important computer policy issues

are offered at The excerpt above is taken from that site.


Issue-Specific Policy #7.3: BACKUPS


If you had a complete system failure tomorrow
morning, how quickly could you restore operations?

PROBLEM: It is critically important to make copies of ongoing work and stored
information, but making backups is a sporadic practice. A lot of work doesn’t get
backed up.

ACTION: Develop a backup policy.

Step 1: Identify backups as critical to the organization’s survival.
It costs a lot of money to create data and manage information, but users and
organizations often don’t take backups seriously. The policy should stress the need for
being able to stay in business. A well-written document will provide for backups of all
data. If the information was sufficiently important to gather in the first place, it must be
backed up until such time as a conscious decision is made that the organization no
longer needs the information.

Step 2: Empower system administrators to succeed.
Identify where the data is to be stored for scheduled backups. Some organizations
specify that ALL data is to be stored on the servers. It sure makes doing a backup much
simpler than having the data located on multiple desktops. The policy should specify
how backups are created, stored, and tested.

Some organizations are very casual with

their media and don’t protect it. It is not uncommon to see backup tapes sitting on the
computer. Full backups include password files and other sensitive data, and should be
stored off site. Off site data storage can be as simple as keeping it in another building,
or as elaborate as storing backed-up data in another country.

Step 3: Provide for exceptions to the norm.
If the organization uses corporate servers and generally requires all employees to store
data there, there may be cases where it is difficult to get personnel to keep their data on
the server. The policy must make provisions for such exceptions. One organization
addresses this making backup part of performance assessment and by including a
18
statement of responsibility in the employee’s annual performance plan. If the employee
does not keep the data on the server, the employee is personally responsible for backing
up the data. Loss of data and no backup means no performance award for the year.

Step 4: Make sure the policy is implemented.
Security policy should provide for compliance, such as spot-checking. The policy could
reference a procedure in which administrators go into a system and look for recently
modified data, then ask to be shown where it is backed up.


Issue-Specific Policy #7.4: INCIDENT HANDLING


PROBLEM: Many well-written, specific, and realistically implemented security
policies have an important weakness: they preclude necessary, independent actions in
the case of an emergency.

ACTION: Develop an incident handling policy.

Late night bid:

It’s 2:00 a.m. on a Saturday morning. Your team is trying to finish a time-critical
project - an important bid - by sending a file. There are problems getting through the firewall.
The obvious solution is to modify the firewall, but this is prohibited by the security policy. The
team faces a dilemma. If they don’t act, they will not meet the deadline. If they do act, they risk
the consequences of violating a written security policy. What do they do?

Failure to act:

In a computer incident, what you don’t do can be as important as what you do. In one
case, several systems were damaged by malicious code. This site didn’t have a written incident
procedure, and the one person who knew how to protect evidence so the attacker could be
prosecuted was not available. By the time the responsible person called in, the organization had
reinstalled the operating system on the attacked computers. Through pure dumb luck they still
managed to get the arrest and conviction, but a written procedure for evidence collection and
protection would have made the prosecution run a lot smoother.

Step 1: Recognize that incidents require changing the way we operate.
Emergency situations require trusting people and processes. If a security policy is too
restrictive, people may not be able to act legally, and could end up not acting at all. A
security policy should provide procedures that allow people to react quickly and
appropriately in an emergency. In the examples above, it is good policy to require
approval for all changes to the firewall under normal circumstances; but the policies
don’t address the fact that needs are different during an emergency. An incident
handling policy should allow procedures for temporary modifications that can be
approved by a specified supervisor, and then reviewed the next working day.

19
Step 2: Identify the various roles and responsibilities.

Sometimes people disagree over jurisdiction during an incident. Emergency incident
handling is where people need advanced or "loaned" approval the most. When things
are going badly and an incident must be contained, a machine or even a whole network
may have to be taken off line, which usually requires a high level of authority.

Step 3: Identify the process for notification and escalation.
During an emergency it is sometimes necessary to contact authorities. The policy
should specify which authorities are contacted and who does the contacting. The policy
should provide for frequent updating to keep names and phone numbers current.

Step 4: Ensure that you learn something from every incident.
Incidents are one of the greatest opportunities to improve processes, policy, and
procedures. They provide a small window of opportunity to make changes while
organizational inertia is temporarily suspended during and immediately after an
incident. Use this opportunity to review and improve the security policy.


Issue-Specific Policy #7.5: PROPRIETARY INFORMATION


PROBLEM: There is a large potential for having proprietary information stored
on/in our organization’s computers and resources. Information that would
be considered proprietary would be vendor source code, benchmark
programs, benchmark results, scientific codes, and data sets. Since members
of the support staff will have full access to the systems and resources, they
will potentially have access to proprietary information. Members of the
support staff are responsible for ensuring that all proprietary information is
protected from disclosure or modification.

ACTION: Develop a policy for handling proprietary information.

Crown Jewels:

The difference between any two competing organizations is usually pretty small. If you
think about it, they primarily use the same tools, technologies, suppliers, and processes. Other
than marketing, what often makes the difference between them are the trade secrets and secret
process differences. If these are lost to the competition, an organization’s competitive advantage
may be lost. In courts, trade secrets have been protected only when they are subject to extra
processes, above those applied to all other information, that ensure the secret data are more
protected than other data.


Step 1: Ensure appropriate measures are in place for protecting
proprietary information.
There is no point in having a policy or protecting information without physical
and logical access control.
20

Step 2: Identify boundaries, stating what is acceptable and not
acceptable about access to information.
The system administrator of an email system can probably read every message in
the system since she has system privileges. This does not mean that such
behavior is acceptable.

Step 3: Establish auditing procedures and rules about making copies of
proprietary information.
If the sensitive information is kept in a protected system, it should not be copied
or sent to a non-protected system or sent in the clear across a public network.

Step 4: Identify limits for information disclosure.

Information that is proprietary or sensitive should not be disclosed to any third
party. If information must be disclosed, the individual that is disclosing the
information should ensure that the individual receiving the information is
authorized and has signed a non-disclosure agreement, such as the sample in
Appendix B of this book.

21
8. WRITING A PERSONAL SECURITY POLICY


PROBLEM: The work that you do is not specifically covered in your organization’s
written security policy.

ACTION: Write a personal security policy for yourself.

Step 1: Describe each job function with a tailored policy.
Your personal policy should cover a single job function, so if you are a system
administrator and also a member of your organization’s incident handling team, you
would need two policies. If you find a need to create policy for a half-dozen or more
functional roles, you may want to review your staffing plan with your manager and
agree how the responsibilities should be shared.

Step 2: Make it meaningful.
Include the common elements of a general security policy in your personal policy. Use
your job description as a resource. If someone wanted to evaluate your performance,
how could they do it?

Step 3: Follow the guidelines for writing good policy.
Keep it short and simple. The scope of your normal responsibilities shouldn’t take
more than a paragraph, even though it may be tempting to write much more. Reference

specific procedures, and make sure the expectations are realistic.

Step 4: Use the policy to define appropriate limits.
A personal policy can be used as a basis for saying "no". People get asked to do things
that range from frivolous to illegal. Put a statement in your policy that says,
“Computer staff do not support employees’ home computers for uses other than access
to corporate resources and virus protection”.

Step 5: Have it countersigned (endorsed) by the proper authority.
Get your personal security policy signed by your boss, or better yet, your boss’ boss.

If your boss has signed the policy, then the implication is
that he or she agrees with the stand you’re taking.

Step 6: Make sure it is current.
Reflect on what kinds of incidents you have handled in the past year. Tasks that are
outside normal duties should be covered in your personal policy. If your
responsibilities affect system down time for mission-critical systems, include that in
your policy statement. If you are required to make decisions that affect the profitability
of your business, say so in your personal policy. Update your personal security policy
at least twice a year. When you update your policy, keep the old versions and you will
be able to track how your job has changed over time.
22

Step 7: Keep your management informed.
An advantage to having a signed personal security policy is that the manager two levels
above you can have a clear understanding of what you do and the challenges you face.
Give copies of your personal policy to management.

Step 8: Keep your work portfolio current.

Keep a copy of your personal policy and any procedures you develop in your
professional portfolio.

23
9. EXERCISES


To gain full benefit from this publication, we recommend that you complete the
following exercises.

The following exercises are OPTIONAL for students pursuing GIAC certification.

If you are taking this course through a college or university, or as part of a corporate-
sponsored training program, you may be REQUIRED to complete these exercises and
submit them to your professor/instructor or corporate point of contact. If you are
unsure whether you should complete them, check with your professor/instructor or your
corporate point of contact.

EXERCISE 1
Complete this exercise using your organization as an example.

Scenario:

Your boss has become aware that many of the passwords being used on the server you
administer are very weak. In some cases, they are the same as the userid. Being a
technical type, you suggest running “crack” to test passwords. Before you begin the
assessment, consider the following:

1.) Is there an organizational policy to cover password assessment?

2.) What is the name of the policy document that covers this?

3.) Have you read it?

4.) Are you covered by it?

5.) What are two improvements you can suggest to the policy?


EXERCISE 2
Complete this exercise using a mythical organization.

Create a short firewall policy, no longer than one page. Begin with the name and
purpose of the policy, and the name and title of the approving administrator. Write one
paragraph on each of the following:

1.) Define the scope.

2.) Define the incoming connection policy.

3.) Define the outgoing connection policy.
24

4.) Define the process for maintaining the policy (including who is responsible).

5.) Define the process for approving changes to the policy. Who is responsible? How
do you ensure compliance? If there is an emergency clause, define it.


EXERCISE 3

Complete this exercise using your organization and your job. If this is assignment is
REQUIRED for you, submit your work on letterhead signed by your management. The ideal
approving official is two levels higher in the organization that your position. However, one level
higher is acceptable.

During security incidents, you may be called upon to make decisions that are normally
made by people one or two levels higher in authority. Think about some of these cases
and write a paragraph authorizing the appropriate actions.

Example: "During non-core work hours, or when senior management is not available, [Name] is
empowered to do the following: modify the firewall configuration, focus the intrusion detection
sensor and modify desktop system lockdown configurations to meet the needs of the organization.
Any such activity shall be documented by e-mail and sent to management for review."


EXERCISE 4
Complete this exercise using your organization and its existing policies.

For any normal
responsibilities listed in your personal policy that are not covered in
your corporate or local policy:

1.) Identify the corporate or local policy that is the most appropriate to cover this
responsibility.

2.) Write a one-paragraph entry in language and style similar to this policy and describe
where it should be inserted into the policy.

3.) Repeat the process above for emergency
responsibilities. When you have completed

the task, show it to your manager. It wouldn’t hurt to suggest that your work be used to
update corporate or local policy!


EXERCISE 5
Complete this exercise using your organization and your job.

Describe two incidents. They do not have to be computer- or network-attack related.
25

For each incident:
1.) Give a brief summary of the problem and what initiated the incident.
2.) How did you get involved?
3.) What actions did you take?
4.) Were the actions you took derived from existing corporate/local policy and
procedures or did you have to "make it up"?
5.) Did you run into any problems, or make any errors?
6.) Were policy or procedures changed as a result of the incident?

This is an effective way to help a supervisor list specifics in a
performance appraisal. It gives employees the opportunity to share
how they’ve contributed to the organization.