Re: Systems staff policy guidelines

Eliot <lear@turbo.bio.net> Thu, 12 April 1990 21:20 UTC

Received: from turbo.bio.net by cert.sei.cmu.edu (5.61/2.2) id AA02494; Thu, 12 Apr 90 17:20:31 -0400
Received: by turbo.bio.net (5.61/IG-2.0) id AA22743; Thu, 12 Apr 90 14:20:27 -0700
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.turbo.bio.net.sun4.40 via MS.5.6.turbo.bio.net.sun4_40; Thu, 12 Apr 90 14:20:26 -0700 (PDT)
Message-Id: <oa9D4OW6f0951KdEc_@turbo.bio.net>
Date: Thu, 12 Apr 90 14:20:26 -0700 (PDT)
From: Eliot <lear@turbo.bio.net>
To: ssphwg@cert.sei.cmu.edu, TYSON@warbucks.ai.sri.com (Mabry Tyson)
Subject: Re: Systems staff policy guidelines
In-Reply-To: <19900410174132.7.TYSON@ELCAPITAN.AI.SRI.COM>
References: <19900410174132.7.TYSON@ELCAPITAN.AI.SRI.COM>

[I'm just back from vacation and perusing some vast amount of mail for
this subject, so my apologies in the all too likely event that this
topic has been hased to death.]

The biggest problem with all too many UNIX implementations is that they
don't leave behind audit trails, nor do they have any concept of
multilevel security access mechanisms (not MLS!!).  Many sites supply
software for people to get different levels of access to UNIX systems. 
For example, if an operator only needs to control the printers, there
are ``privileged'' control programs that he/she should be allowed to
access.  These programs should ONLY control the printers.  If someone
needs to control the news system, they need only access to the news
system.  In many instances there is no reason to practice barn door
security.  All too often, however, physical access is the true key.  In
these instances, hard copy terminals and online console logs can help. 
All these issues should be fleshed out.

The irony with all of these ideas is that they are not new, and have
been implemented on a number of systems like VMS.  Most flavors of UNIX,
however, seem to have lagged behind.  Perhaps one result this committee
may have is a software library to assist administrators in this area.

Eliot Lear
[lear@turbo.bio.net]




Received: from [128.237.253.35] by NRI.NRI.Reston.VA.US id aa14171;
          16 Apr 90 10:00 EDT
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA25186; Mon, 16 Apr 90 10:02:02 -0400
Resent-Message-Id: <9004161402.AA25186@taos.cert.sei.cmu.edu>;
Return-Path: ph@cert.sei.cmu.edu
Received: from CERT.SEI.CMU.EDU by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA23259; Fri, 13 Apr 90 15:27:55 -0400
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA05347; Fri, 13 Apr 90 15:24:33 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA23193; Fri, 13 Apr 90 15:24:07 -0400
Message-Id: <9004131924.AA23193@taos.cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Subject: sysadmin policy article
Date: Fri, 13 Apr 90 15:24:05 EDT
From: "J. Paul Holbrook" <ph@cert.sei.cmu.edu>;
Resent-To: gvaudre@NRI.Reston.VA.US
Resent-Date: Mon, 16 Apr 90 10:01:59 EDT
Resent-From: "J. Paul Holbrook" <ph@cert.sei.cmu.edu>;

There's a very good article by Bud Hovell on system administration
policies in the March 1990 issue of Unix Review (p.28).  For those
of you who don't have access to this magazine, the column was
developed out of a message to the system administration list moderated
by Bjorn Sateva.  The digest the message was in is available via
anonymous FTP from
terminator.cc.umich.edu:/unix/sysadmin/sysadm-list/v1n03.Z.  

I recommend trying to find the Unix Review version; it's been cleaned
up and re-written from the post on sysadmin.

One of the main points of the article is that too often policy is
defined only when "management finds itself confronted with a
situation that demands an immediate response."  The result, contends
Hovell, is a bad policy that often over-reacts to the problem.  The
right solution is to problem, Hovell says, is to "Define policies that
lay out the rules in @i<writing, in advance>, and explain to users the
reasoning behind them."

This strikes at one of the motivations for creating this working
group: site security policies and procedures need to be laid down
before a incident happens, rather than after.

J. Paul Holbrook  CERT/SEI/CMU
ph@cert.sei.cmu.edu




Received: from [128.237.253.35] by NRI.NRI.Reston.VA.US id aa14181;
          16 Apr 90 10:00 EDT
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA25196; Mon, 16 Apr 90 10:02:19 -0400
Resent-Message-Id: <9004161402.AA25196@taos.cert.sei.cmu.edu>;
Return-Path: vhslan!kleonard@gvlv2.GVL.Unisys.COM
Received: from CERT.SEI.CMU.EDU by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA25132; Mon, 16 Apr 90 08:39:04 -0400
Received: from gvlv2.GVL.Unisys.COM by cert.sei.cmu.edu (5.61/2.2)
        id AA05813; Mon, 16 Apr 90 08:27:24 -0400
Received: by gvlv2.GVL.Unisys.COM (5.61/mls/3.1) 
	id AA17848; Mon, 16 Apr 90 08:27:17 -0400
Received: by vhslan (UUPC/pcmail 1.095b) with UUCP; Fri, 13 Apr 90 09:19:59 EST
Date: Fri, 13 Apr 90 09:19:59 EST
From: Ken Leonard <kleonard%vhslan@gvlv2.gvl.unisys.com>;
Message-Id: <2625e00f.vhslan@vhslan>
X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)
To: ssphwg@cert.sei.cmu.edu
Subject: Privilege Access Compartmentation (was Systems staff policy)
Resent-To: gvaudre@NRI.Reston.VA.US
Resent-Date: Mon, 16 Apr 90 10:02:18 EDT
Resent-From: "J. Paul Holbrook" <ph@cert.sei.cmu.edu>;

Eliot Lear (lear@turbo.bio.net) wrote:
>
> The biggest problem with all too many UNIX implementations is that they
> don't leave behind audit trails,
-....................^^^^^^^^^^^^
This should probably be a major topic/concern all by itself.
-
> nor do they have any concept of
> multilevel security access mechanisms (not MLS!!).
-.^^^^^^^^^^^^^^^^^^^
PLEASE, let's get off this term, and stay off, unless we are meaning
_just_ and _all_ what it means in the DoD arena, where many of us _do_
play and where we really have _many_ additional and different issues.
-
Maybe we could describe what (I think) we are talking about here as:
-.vvvvvvvvvvvvvvvv
> multimode access mechanisms (not MLS!!).  Many sites supply
> software for people to get different [_modes_ not _levels_ ?] of access to
> UNIX systems.
>
> For example, if an operator only needs to control the printers, there
> are ``privileged'' control programs that he/she should be allowed to
> access.  These programs should ONLY control the printers.  If someone
> . . .
> however, seem to have lagged behind.  Perhaps one result this committee
> may have is a software library to assist administrators in this area.
-...............^^^^^^^^^^^^^^^^
or reference to sources, or operational techniques, or whatever someone
may be doing to "compartmentize" system-admin -mgmt -control  -operation
functions.
-------------------
regardz,
Ken

-- 
Ken Leonard
I'm too old to know better.



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa13183;
          18 Apr 90 14:09 EDT
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA02756; Wed, 18 Apr 90 13:30:12 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA26867; Wed, 18 Apr 90 13:29:17 -0400
Message-Id: <9004181729.AA26867@taos.cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Subject: ssphwg attendence in Pittsburgh and future
Reply-To: ph@cert.sei.cmu.edu
Date: Wed, 18 Apr 90 13:29:16 EDT
From: "J. Paul Holbrook" <ph@cert.sei.cmu.edu>;

We'd like have some idea of how many people we'll be meeting with in
Pittsburgh.  If you're planning to attend the Site Security Policy
Handbook WG meeting in Pittsburgh, please message me so we can get a
count.  That meeting will be from 9:15-12:00 on Wednesday, May 2.

In addition to the Pittsburgh meeting we've also considered having a
longer meeting (say some part of a day) in Southern California
sometime in the week of June 11-15.  (Usenix is then, and Joyce and I
will both be there.)  If you might be interested in attending such a
meeting, please let me know in a message.

Thanks -

Paul Holbrook
ssphwg co-chair
ph@cert.sei.cmu.edu OR ph@sei.cmu.edu


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa09942;
          25 Apr 90 12:36 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA19909; Wed, 25 Apr 90 11:52:28 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA03582>; Wed, 25 Apr 90 08:52:35 -0700
Date: Wed, 25 Apr 90 08:53:19 PDT
From: jkrey@venera.isi.edu
Posted-Date: Wed, 25 Apr 90 08:53:19 PDT
Message-Id: <9004251553.AA05637@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA05637>; Wed, 25 Apr 90 08:53:19 PDT
To: ssphwg@cert.sei.cmu.edu
Subject: Agenda for Pittsburgh IETF, May 2nd
Cc: jkrey@venera.isi.edu, ph@sei.cmu.edu

Folks,

Enclosed is the SSPHWG agenda for the Pittsburgh IETF.  Hope
to see you there!

Paul and Joyce

=======================================================================


		SSPHWG Agenda - Pittsburgh 
			    May 1990
		Wednesday, May 2nd, 9:15-12Noon


Welcome SSPHWG members!

SSPHWG Charter 


	1)  Discussion on current security policy and relationship to
            the Security Policy Working Group (SPWG).

	2)  Goals and directions of the SSPHWG (strawman proposal
            by J. Paul Holbrook).

	3)  Structure and organization of handbook.

	4)  Timeframe for writing and submission for 
            publication of the handbook.

	5)  Review of plans/action items for next round of meetings.

		a)  Next meeting in Los Angeles, Tuesday, June 12th
                    at USC/Information Sciences Institute.

		b)  Next IETF meeting in August at University of
                    British Columbia.



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa12498;
          25 Apr 90 15:32 EDT
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA20528; Wed, 25 Apr 90 14:52:07 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA03253; Wed, 25 Apr 90 14:52:06 -0400
Message-Id: <9004251852.AA03253@taos.cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Subject: June 12 ssphwg meeting at ISI
Date: Wed, 25 Apr 90 14:52:05 EDT
From: "J. Paul Holbrook" <ph@cert.sei.cmu.edu>;

The Site Security Policy Working Group will be holding an all-day
meeting at ISI in Marina Del Rey on Tuesday, June 12.  Usenix is in
Anaheim the following three days, so we hope that some people who
might be in Southern California for that event can come to the working
group meeting.

We considered holding a BOF at Usenix, but decided that the best
choice was to have an all-day format where we could get a reasonable
amount of work done.

We'll send out a formal RSVP message after the IETF meeting.  


Paul Holbrook      CERT/SEI/CMU
Joyce K. Reynolds  ISI/USC

ssphwg co-chairs



Received: from [128.237.253.5] by NRI.NRI.Reston.VA.US id aa14369;
          26 Apr 90 15:20 EDT
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA02059; Thu, 26 Apr 90 14:38:44 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA04103; Thu, 26 Apr 90 14:38:25 -0400
Message-Id: <9004261838.AA04103@taos.cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Subject: Why do we need a Site Security Policy Handbook?
Date: Thu, 26 Apr 90 14:38:24 EDT
From: "J. Paul Holbrook" <ph@cert.sei.cmu.edu>;

Now that we have the list in place and a forum to talk, I'd like to
start trying to get some consensus on who are the customers of this
handbook and what is they need.

I hope this note will help us build some common understanding when
the working group first meets in Pittsburgh.

Here's my opinion on where I see the group going.  This isn't cast
in stone: please expand and critique this.  Please respond: is this
heading in a useful direction?  We'll discuss this further in
Pittsburgh.


THE NEED

Why is there a need for a handbook like this?  Looking at some of the
needs may help us understand what kind of product we want to produce.

As a member of the CERT, I've come in contact with many sites trying
to deal with computer security problems.  It's often a rude shock when
they discover someone has compromised their systems.  Even for sites
that have a good technical understanding of how to keep their systems
secure, there are often policy questions that they haven't addressed.
These policy issues make dealing with the incident much more
difficult.  Once the incident is over, the push to 'make sure this
doesn't happen again' can result in policy made in hast; these
policies can be more restrictive and cumbersome than they need to be.

A computer security compromise has much in common with any other
computer 'disaster' such as an equipment breakdown or a fire.  You
need to have plans in place to prevent the problem, to deal with the
problem while it's happening, and to deal with the consequences after
the fact.  Although it may seem over-dramatic to compare a security
compromise to a fire, the effect a malicious intruder could have on a
site's operations could be devastating.

Another way to look at the question of 'need' is to turn it around:
why should any site (especially an academic site) care about creating
a computer security policy and procedures?


  - There is a real threat out there.  Intruders are using common
holes to break into systems.  Sites need to understand what the
threats and risks are.

  - Policies and procedures help you maintain the environment you
want.  Many organizations value open communication and sharing.  One
security incident, and "the powers that be" could force a site into a
more closed environment.  Policies show that you are aware of the
problem and are taking steps to deal with it.

  - Policies help guide cost-effective decisions.  An academic site
may decide that the cost of dealing with an incident doesn't warrant
spending lots of time or money on defenses.  A business may make a
different decision.

  - Policies And Procedures clarify responsibility and authority.  Do
you have the authority to look at a student's files?  If so, do
students know that?


THE CUSTOMERS OF THIS WORK

Customers of what we're trying to do:

   - Systems administrators 
   - Site decision makers 
       - this includes administrators (in the traditional sense),
managers, policy makers.  The people who have the 'official' word on
what goes on at a site

Some people who are explicitly not customers: 
   - Programmers
   - End users

We don't need to produce a recommended set of security policies and
procedures.  The IETF Security Policy Working Group (SPWG) is working
on that goal.  Instead, what we we will produce is a set of guidelines
and issues that policy makers will need to consider when they make
their own policies and guidelines.  This should be a tool to help
people understand the need for security procedures and policies and
how to go about creating them.  We can include suggestions where
appropriate, but much of the specifics of what a site decides to do
will depend on the local circumstances.  A university might make
different choices about security from a government research lab.


THE OUTPUT OF THE GROUP

We hope to produce a guide to the kinds of problems sites might face,
the issues they should consider, and guidelines to the kinds of steps
they can take to preventing and dealing with security problems.  This
handbook could be published as an RFC or an FYI.

Over time, this handbook might expand to become a more general
reference on site computer security.  Some of the things that might be
included:

   - suggested policies and procedures (perhaps whatever the Security
Policy WG produces)

   - bibliographies of other information to read

   - pointers to tools to help with site security



J. Paul Holbrook    CERT/SEI/CMU   ph@cert.sei.cmu.edu
Joyce K. Reynolds   ISI/USC	   jkrey@isi.edu

SSPHWG group co-chairs



Received: from [128.237.253.5] by NRI.NRI.Reston.VA.US id aa02971;
          1 May 90 23:13 EDT
Received: from intrepid.itstd.sri.com by cert.sei.cmu.edu (5.61/2.2)
        id AA04097; Tue, 1 May 90 22:25:30 -0400
Received: from localhost by intrepid.itstd.sri.com (5.61/1.3davy)
	id AA06472; Tue, 1 May 90 19:25:27 -0700
Message-Id: <9005020225.AA06472@intrepid.itstd.sri.com>;
To: ssphwg@cert.sei.cmu.edu
Subject: White paper available: "Improving the Security of Your UNIX System"
Date: Tue, 01 May 90 19:25:26 PDT
From: davy@itstd.sri.com


A new white paper from SRI International's Information and Telecommunication
Sciences and Technology Division is now available.

The paper, "Improving the Security of Your UNIX System," describes measures
that you as a system administrator can take to make your UNIX system(s) more
secure.  Oriented primarily at SunOS 4.x, most of the information covered
applies equally well to any Berkeley UNIX system with or without NFS and/or
Yellow Pages (NIS).  Some of the information can also be applied to System
V, although this is not a primary focus of the paper.

An abbreviated Table of Contents:

	1. INTRODUCTION
		The Internet Worm, the Wily Hacker, other break-ins
	2. IMPROVING SECURITY
	   2.1 Account Security
	   	Passwords, expiration dates, guest accounts, group accounts,
		Yellow Pages
	   2.2 Network Security
		Trusted hosts, secure terminals, NFS, FTP, TFTP, mail,
		finger, modems and terminal servers, firewalls
	   2.3 File System Security
		Setuid shell scripts, sticky bit on directories, setgid
		bit on directories, umask values, encrypting files,
		devices
	3. MONITORING SECURITY
	   3.1 Account Security
	   	lastlog, utmp, wtmp, acct
	   3.2 Network Security
	   	syslog, showmount
	   3.3 File System Security
	   	find, checklists, backups
	   3.4 Know Your System
	   	ps, who, w, ls
	4. SOFTWARE FOR IMPROVING SECURITY
	   4.1 Obtaining Fixes and New Versions
	  	Sun fixes on UUNET, Berkeley fixes, SIMTEL-20 and UUNET,
		vendors
	   4.2 The npasswd Command
	   4.3 The COPS Package
	   4.4 Sun C2 Security Features
	   4.5 Kerberos
	5. KEEPING ABREAST OF THE BUGS
	   5.1 CERT
	   5.2 DDN Management Bulletins
	   5.3 Security-related mailing lists
	6. SUGGESTED READING
	7. CONCLUSIONS
	REFERENCES
	APPENDIX A - SECURITY CHECKLIST

In order to format the paper, the "troff" text formatter and the "-ms" macro
package (available with any Sun or Berkeley UNIX system) are required.  You
*do not* need a PostScript printer, unless you want to print the cover page
with the SRI logo on it.

The paper is available via anonymous FTP from the host SPAM.ITSTD.SRI.COM
(128.18.4.3) as the file "pub/security-doc.tar.Z".  Be sure to remember to
set "image" mode on the transfer.  Sorry, UUCP access is not available - if
you don't have Internet access, find a friend who does.

Enjoy.

Dave Curry

SRI International
Information and Telecommunications
Sciences and Technology Division
333 Ravenswood Avenue
Menlo Park, CA 94025
(415) 859-2508

davy@itstd.sri.com


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa11127;
          9 May 90 16:44 EDT
Received: from sdsu.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA18065; Wed, 9 May 90 13:35:11 -0400
Received: from ucselx.sdsu.edu by sdsu.edu; id AA26371
	sendmail 5.61/SDSU-GW-1.5 via SMTP
	Wed, 9 May 90 10:34:35 -0700 for ssphwg@cert.sei.cmu.edu
Received: by ucselx.SDSU.EDU (5.61/SDSU-CLIENT)
	id AA06514 for delivery to ssphwg@cert.sei.cmu.edu; Wed, 9 May 90 10:34:01 -0700
Date: Wed, 9 May 90 10:34:01 -0700
From: Richard Caasi <caasi%ucselx@sdsu.edu>;
Message-Id: <9005091734.AA06514@ucselx.SDSU.EDU>;
To: ssphwg@cert.sei.cmu.edu
Subject: Unix Security










      IIMMPPRROOVVIINNGG TTHHEE SSEECCUURRIITTYY OOFF YYOOUURR      UUNNIIXX SSYYSSTTEEMM


             David A. Curry, Systems Programmer
Information and Telecommunications Sciences and Technology Division
                     ITSTD-721-FR-90-21
                   Paul K. Hyder, Manager
                     Computer Facility

               Boyd C. Fair, General Manager
                Division Operations Section

             Michael S. Frankel, Vice President
Information and Telecommunications Sciences and Technology Division






















                  This page intentionally left blank.
                               Just throw it out.






_C_O_N_T_E_N_T_S



1      INTRODUCTION...........................................  1
1.1    UNIX Security..........................................  1
1.2    The Internet Worm......................................  2













_C_O_N_T_E_N_T_S (_c_o_n_t_i_n_u_e_d)



1.3    Spies and Espionage..................................2
1.4    Other Break-Ins......................................3
1.5    Security is Important................................3

2      IMPROVING SECURITY...................................5
2.1    Account Security.....................................5
2.1.1  Passwords............................................5
2.1.1.1                                  Selecting Passwords6
2.1.1.2                                    Password Policies7
2.1.1.3                           Checking Password Security7
2.1.2  Expiration Dates.....................................8
2.1.3  Guest Accounts.......................................8
2.1.4  Accounts Without Passwords...........................9
2.1.5  Group Accounts and Groups............................9
2.1.6  Yellow Pages.........................................10
2.2    Network Security.....................................11
2.2.1  Trusted Hosts........................................11
2.2.1.1                                 The hosts.equiv File11
2.2.1.2                                     The .rhosts File12
2.2.2  Secure Terminals.....................................12
2.2.3  The Network File System..............................13
2.2.3.1                                     The exports File13
2.2.3.2                                    The netgroup File14
2.2.3.3                        Restricting Super-User Access16
2.2.4  FTP..................................................16
2.2.4.1                                          Trivial FTP17
2.2.5  Mail.................................................18
2.2.6  Finger...............................................19
2.2.7  Modems and Terminal Servers..........................19
2.2.8  Firewalls............................................20
2.3    File System Security.................................20
2.3.1  Setuid Shell Scripts.................................21
2.3.2  The Sticky Bit on Directories........................22
2.3.3  The Setgid Bit on Directories........................22
2.3.4  The umask Value......................................22
2.3.5  Encrypting Files.....................................23
2.3.6  Devices..............................................23
2.4    Security Is Your Responsibility......................24

3      MONITORING SECURITY..................................25
3.1    Account Security.....................................25
3.1.1  The lastlog File.....................................25
3.1.2  The utmp and wtmp Files..............................25
3.1.3  The acct File........................................26
3.2    Network Security.....................................27
3.2.1  The syslog Facility..................................27
3.2.2  The showmount Command................................28
3.3    File System Security.................................29
3.3.1  The find Command.....................................29













_C_O_N_T_E_N_T_S (_c_o_n_t_i_n_u_e_d)



3.3.1.1                      Finding Setuid and Setgid Files29
3.3.1.2                         Finding World-Writable Files31
3.3.1.3                                Finding Unowned Files31
3.3.1.4                                Finding .rhosts Files31
3.3.2  Checklists...........................................32
3.3.3  Backups..............................................33
3.4    Know Your System.....................................33
3.4.1  The ps Command.......................................33
3.4.2  The who and w Commands...............................34
3.4.3  The ls Command.......................................34
3.5    Keep Your Eyes Open..................................34

4      SOFTWARE FOR IMPROVING SECURITY......................35
4.1    Obtaining Fixes and New Versions.....................35
4.1.1  Sun Fixes on UUNET...................................35
4.1.2  Berkeley Fixes.......................................36
4.1.3  Simtel-20 and UUNET..................................37
4.1.4  Vendors..............................................37
4.2    The npasswd Command..................................37
4.3    The COPS Package.....................................38
4.4    Sun C2 Security Features.............................38
4.5    Kerberos.............................................39

5      KEEPING ABREAST OF THE BUGS..........................41
5.1    The Computer Emergency Response Team.................41
5.2    DDN Management Bulletins.............................41
5.3    Security-Related Mailing Lists.......................42
5.3.1  Security.............................................42
5.3.2  RISKS................................................42
5.3.3  TCP-IP...............................................42
5.3.4  SUN-SPOTS, SUN-NETS, SUN-MANAGERS....................42
5.3.5  VIRUS-L..............................................43

6      SUGGESTED READING....................................45

7      CONCLUSIONS..........................................47

REFERENCES..................................................49

APPENDIX A - SECURITY CHECKLIST.............................51












                        May 4, 1990








_1.  _I_N_T_R_O_D_U_C_T_I_O_N

_1._1.  _U_N_I_X _S_E_C_U_R_I_T_Y

     The operating system, although now in widespread use in
environments   concerned  about  security,  was  not  really
designed with security in mind [Ritc75].  This does not mean
that  does  not  provide  any  security  mechanisms; indeed,
several very good ones are available.  However,  most  ``out
of  the box'' installation procedures from companies such as
Sun Microsystems still install the operating system in  much
the  same  way as it was installed 15 years ago: with little
or no security enabled.

     The reasons for this state of affairs are largely  his-
torical.   was originally designed by programmers for use by
other programmers.  The environment in which it was used was
one  of  open  cooperation, not one of privacy.  Programmers
typically collaborated with  each  other  on  projects,  and
hence  preferred  to  be able to share their files with each
other  without  having  to  climb  over  security   hurdles.
Because  the  first  sites  outside  of Bell Laboratories to
install were university research laboratories, where a simi-
lar  environment  existed, no real need for greater security
was seen until some time later.

     In the early 1980s, many  universities  began  to  move
their  systems out of the research laboratories and into the
computer centers, allowing (or forcing) the user  population
as  a  whole  to  use  this  new and wonderful system.  Many
businesses and government sites began to install systems  as
well,  particularly  as  desktop  workstations  became  more
powerful and affordable.  Thus, the operating system  is  no
longer being used only in environments where open collabora-
tion is the goal.  Universities require  their  students  to
use  the  system for class assignments, yet they do not want
the students to be able to copy from each other.  Businesses
use their systems for confidential tasks such as bookkeeping
and payroll.  And the government uses  systems  for  various
unclassified yet sensitive purposes.

     To complicate matters, new features have been added  to
over  the years, making security even more difficult to con-
trol.  Perhaps  the  most  problematic  features  are  those
relating  to networking: remote login, remote command execu-
tion, network file systems, diskless workstations, and elec-
tronic mail.  All of these features have increased the util-
ity and usability of by untold amounts.  However, these same
features, along with the widespread connection of systems to
_________________________
is a registered trademark of is a trademark of  Digital
Equipment Corporation.  Sun-3 and are trademarks of Sun
Microsystems.  Annex is a trademark of Xylogics, Inc.













the Internet and other networks, have  opened  up  many  new
areas of vulnerability to unauthorized abuse of the system.

_1._2.  _T_H_E _I_N_T_E_R_N_E_T _W_O_R_M

     On the evening of November 2, 1988, a  self-replicating
program,  called  a  _w_o_r_m,  was  released  on  the  Internet
[Seel88,  Spaf88,  Eich89].   Overnight,  this  program  had
copied  itself from machine to machine, causing the machines
it infected to labor under huge loads, and  denying  service
to  the  users of those machines.  Although the program only
infected two types of computers,* it spread quickly, as  did
the  concern,  confusion,  and  sometimes  panic  of  system
administrators whose machines  were  affected.   While  many
system  administrators  were  aware that something like this
could theoretically happen - the security holes exploited by
the worm were well known - the scope of the worm's break-ins
came as a great surprise to most people.

     The worm itself did not destroy any  files,  steal  any
information   (other   than  account  passwords),  intercept
private mail, or plant other destructive software  [Seel88].
However,  it did manage to severely disrupt the operation of
the  network.   Several  sites,  including  parts  of   Ames
Research  Center  and  Goddard  Space Flight Center, the Jet
Propulsion Laboratory, and the U. S. Army Ballistic Research
Laboratory,  disconnected  themselves  from  the Internet to
avoid recontamination.  In addition, the Defense  Communica-
tions  Agency  ordered  the connections between the and shut
down, and kept  them  down  for  nearly  24  hours  [Eich89,
Elme88].   Ironically,  this  was perhaps the worst thing to
do, since the first fixes to combat the  worm  were  distri-
buted via the network [Eich89].

     This incident was perhaps  the  most  widely  described
computer  security  problem  ever.   The worm was covered in
many newspapers and magazines around the  country  including
the  _N_e_w  _Y_o_r_k  _T_i_m_e_s,  _W_a_l_l  _S_t_r_e_e_t  _J_o_u_r_n_a_l, _T_i_m_e and most
computer-oriented technical publications, as well as on  all
three major television networks, the Cable News Network, and
National Public Radio.  In January  1990,  a  United  States
District  Court  jury found Robert Tappan Morris, the author
of the worm, guilty of charges brought against him  under  a
1986  federal computer fraud and abuse law.  Morris faces up
to five years in prison and a $250,000 fine [Schu90].   Sen-
tencing is scheduled for May 4, 1990.


9_________________________
9  * Sun-3 systems from  Sun  Microsystems  and  systems
from  Digital Equipment Corp., both running variants of
4._x from the University of California at Berkeley.













_1._3.  _S_P_I_E_S _A_N_D _E_S_P_I_O_N_A_G_E

     In August 1986, the Lawrence  Berkeley  Laboratory,  an
unclassified  research laboratory at the University of Cali-
fornia at Berkeley, was attacked by an unauthorized computer
intruder  [Stol88,  Stol89].  Instead of immediately closing
the holes the intruder was using, the system  administrator,
Clifford  Stoll,  elected to watch the intruder and document
the weaknesses he exploited.  Over the next 10 months, Stoll
watched  the  intruder  attack over 400 computers around the
world, and successfully enter about 30.  The computers  bro-
ken  into  were located at universities, military bases, and
defense contractors [Stol88].

     Unlike many intruders seen on the Internet,  who  typi-
cally  enter systems and browse around to see what they can,
this intruder was looking for something specific.  Files and
data  dealing  with  the  Strategic  Defense Initiative, the
space shuttle, and other military topics all seemed to be of
special interest.  Although it is unlikely that the intruder
would have  found  any  truly  classified  information  (the
Internet is an unclassified network), it was highly probable
that he could find a wealth of sensitive material [Stol88].

     After a  year  of  tracking  the  intruder  (eventually
involving  the  National Security Agency, Air Force Intelli-
gence, and authorities in West Germany), five men  in  Hann-
over,  West  Germany were arrested.  In March 1989, the five
were charged with  espionage:  they  had  been  selling  the
material  they found during their exploits to the One of the
men, Karl Koch (``Hagbard''),  was  later  found  burned  to
death  in  an  isolated forest outside Hannover.  No suicide
note was found [Stol89].  In February  1990,  three  of  the
intruders (Markus Hess, Dirk Bresinsky, and Peter Carl) were
convicted of espionage in a German court  and  sentenced  to
prison  terms, fines, and the loss of their rights to parti-
cipate in elections [Risk90].  The last  of  the  intruders,
Hans Hu"bner (``Pengo''), still faces trial in Berlin.

_1._4.  _O_T_H_E_R _B_R_E_A_K-_I_N_S

     Numerous other computer security problems have occurred
in  recent years, with varying levels of publicity.  Some of
the more widely known incidents include break-ins on network
[McLe87], the ``Christmas Virus'' [Risk87], a virus at Mitre
Corp. that caused the to be temporarily isolated from  other
networks   [Risk88],   a   worm   that  penetrated  networks
[Risk89a], break-ins on U. S.  banking  networks  [Risk89b],
and a multitude of viruses, worms, and trojan horses affect-
ing personal computer users.

_1._5.  _S_E_C_U_R_I_T_Y _I_S _I_M_P_O_R_T_A_N_T

     As the previous stories demonstrate, computer  security












is an important topic.  This document describes the security
features provided by the  operating  system,  and  how  they
should  be  used.  The discussion centers around version 4._x
of the version of sold by Sun  Microsystems.   Most  of  the
information presented applies equally well to other systems.
Although there is no  way  to  make  a  computer  completely
secure  against unauthorized use (other than to lock it in a
room and turn it off), by following the instructions in this
document  you  can  make  your  system  impregnable  to  the
``casual'' system cracker,* and make it more  difficult  for
the sophisticated cracker to penetrate.

_2.  _I_M_P_R_O_V_I_N_G _S_E_C_U_R_I_T_Y

     system security can be divided into three main areas of
concern.   Two  of these areas, account security and network
security, are primarily concerned with keeping  unauthorized
users  from  gaining  access to the system.  The third area,
file system security, is concerned with preventing unauthor-
ized  access, either by legitimate users or crackers, to the
data stored in the system.  This section describes the secu-
rity tools provided to make each of these areas as secure as
possible.

_2._1.  _A_C_C_O_U_N_T _S_E_C_U_R_I_T_Y

     One of the easiest ways for a cracker  to  get  into  a
system  is by breaking into someone's account.  This is usu-
ally easy to do, since many systems have old accounts  whose
users  have  left  the  organization, accounts with easy-to-
guess passwords, and so on.  This section describes  methods
that can be used to avoid these problems.

_2._1._1.  _P_a_s_s_w_o_r_d_s

     The password is the most vital part  of  account  secu-
rity.   If  a cracker can discover a user's password, he can
then log in to the system and operate with all the capabili-
ties  of that user.  If the password obtained is that of the
super-user, the problem is more serious:  the  cracker  will
have read and write access to every file on the system.  For
this  reason,  choosing  secure   passwords   is   extremely
_________________________
9  * The term ``hacker,'' as applied to computer  users,
originally had an honorable connotation: ``a person who
enjoys learning the details of programming systems  and
how  to stretch their capabilities - as opposed to most
users of  computers,  who  prefer  to  learn  only  the
minimum  amount  necessary''  [Stee88].  Unfortunately,
the media has distorted this definition and given it  a
dishonorable  meaning.   In deference to the true hack-
ers, we will use the term ``cracker''  throughout  this
document.
9











important.

     The _p_a_s_s_w_d program [Sun88a, 379] places very  few  res-
trictions  on what may be used as a password.  Generally, it
requires that  passwords  contain  five  or  more  lowercase
letters,  or four characters if a nonalphabetic or uppercase
letter is included.  However, if the user ``insists'' that a
shorter  password  be used (by entering it three times), the
program will allow it.  No  checks  for  obviously  insecure
passwords  (see below) are performed.  Thus, it is incumbent
upon the system administrator to ensure that  the  passwords
in use on the system are secure.

     In [Morr78], the authors describe experiments conducted
to  determine  typical  users' habits in the choice of pass-
words.  In a collection of 3,289 passwords, 16% of them con-
tained three characters or less, and an astonishing 86% were
what could generally be described as  insecure.   Additional
experiments  in  [Gram84]  show  that by trying three simple
guesses on each account - the login name, the login name  in
reverse,  and  the two concatenated together - a cracker can
expect to obtain access to between 8 and 30 percent  of  the
accounts  on  a  typical system.  A second experiment showed
that by trying the 20 most common female first  names,  fol-
lowed by a single digit (a total of 200 passwords), at least
one password was valid on each  of  several  dozen  machines
surveyed.   Further  experimentation by the author has found
that by trying variations on the login  name,  user's  first
and  last  names,  and  a  list  of nearly 1800 common first
names, up to 50  percent of the passwords on any given  sys-
tem can be cracked in a matter of two or three days.

_2._1._1._1.  _S_e_l_e_c_t_i_n_g _P_a_s_s_w_o_r_d_s

     The object when choosing a password is to  make  it  as
difficult as possible for a cracker to make educated guesses
about what you've chosen.  This leaves  him  no  alternative
but  a brute-force search, trying every possible combination
of letters, numbers, and  punctuation.   A  search  of  this
sort, even conducted on a machine that could try one million
passwords per second (most machines can try  less  than  one
hundred per second), would require, on the average, over one
hundred years to complete.  With this as our  goal,  and  by
using the information in the preceding text, a set of guide-
lines for password selection can be constructed:

     o+    _D_o_n'_t use your login  name  in  any  form  (as-is,
          reversed, capitalized, doubled, etc.).

     o+    _D_o_n'_t use your first or last name in any form.

     o+    _D_o_n'_t use your spouse's or child's name.

     o+    _D_o_n'_t use other information easily obtained  about












          you.   This  includes license plate numbers, tele-
          phone numbers, social security numbers, the  brand
          of  your  automobile,  the  name of the street you
          live on, etc.

     o+    _D_o_n'_t use a password of all  digits,  or  all  the
          same  letter.   This  significantly  decreases the
          search time for a cracker.

     o+    _D_o_n'_t use a word contained in (English or  foreign
          language)  dictionaries,  spelling lists, or other
          lists of words.

     o+    _D_o_n'_t use a password shorter than six characters.

     o+    _D_o use a password with mixed-case alphabetics.

     o+    _D_o use a password with  nonalphabetic  characters,
          e.g., digits or punctuation.

     o+    _D_o use a password that is easy to remember, so you
          don't have to write it down.

     o+    _D_o use a  password  that  you  can  type  quickly,
          without  having  to  look  at  the keyboard.  This
          makes it harder for someone to steal your password
          by watching over your shoulder.

     Although this list may seem to restrict passwords to an
extreme,  there  are  several  methods  for choosing secure,
easy-to-remember passwords that obey the above rules.   Some
of these include the following:

     o+    Choose a line or two from a song or poem, and  use
          the  first letter of each word.  For example, ``In
          Xanadu did Kubla  Kahn  a  stately  pleasure  dome
          decree'' becomes ``IXdKKaspdd.''

     o+    Alternate between one consonant  and  one  or  two
          vowels,  up  to  eight  characters.  This provides
          nonsense words that are usually pronounceable, and
          thus  easily remembered.  Examples include ``rout-
          boo,'' ``quadpop,'' and so on.

     o+    Choose  two  short  words  and  concatenate   them
          together with a punctation character between them.
          For    example:    ``dog;rain,''     ``book+mug,''
          ``kid?goat.''

     The importance  of  obeying  these  password  selection
rules  cannot be overemphasized.  The Internet worm, as part
of its strategy for breaking into new machines, attempted to
crack  user passwords.  First, the worm tried simple choices
such as the login name, user's first and last names, and  so












on.   Next,  the worm tried each word present in an internal
dictionary of 432 words (presumably Morris considered  these
words to be ``good'' words to try).  If all else failed, the
worm   tried   going   through   the   system    dictionary,
/_u_s_r/_d_i_c_t/_w_o_r_d_s,  trying  each  word [Spaf88].  The password
selection rules above successfully guard against  all  three
of these strategies.

_2._1._1._2.  _P_a_s_s_w_o_r_d _P_o_l_i_c_i_e_s

     Although asking users to select secure  passwords  will
help  improve  security,  by itself it is not enough.  It is
also important to form a set of password policies  that  all
users must obey, in order to keep the passwords secure.

     First and foremost, it is important to impress on users
the need to keep their passwords in their minds only.  Pass-
words should never be written down on desk blotters,  calen-
dars,  and the like.  Further, storing passwords in files on
the computer must be prohibited.  In either case, by writing
the  password  down  on  a piece of paper or storing it in a
file, the security of the user's account is  totally  depen-
dent  on the security of the paper or file, which is usually
less than the security offered by  the  password  encryption
software.

     A second important policy is that users must never give
out  their  passwords  to  others.  Many times, a user feels
that it is easier to give someone else his password in order
to copy a file, rather than to set up the permissions on the
file so that it can be copied.  Unfortunately, by giving out
the  password  to  another  person,  the user is placing his
trust in this other person not to  distribute  the  password
further, write it down, and so on.

     Finally, it is important to  establish  a  policy  that
users  must  change  their  passwords from time to time, say
twice a year.  This is difficult to enforce on since in most
implementations,  a password-expiration scheme is not avail-
able.  However, there are ways  to  implement  this  policy,
either by using third-party software or by sending a memo to
the users requesting that they change their passwords.

     This set of policies should be printed and  distributed
to all current users of the system.  It should also be given
to all new users when they receive their accounts.  The pol-
icy  usually carries more weight if you can get it signed by
the most ``impressive'' person in your  organization  (e.g.,
the president of the company).

_2._1._1._3.  _C_h_e_c_k_i_n_g _P_a_s_s_w_o_r_d _S_e_c_u_r_i_t_y

     The procedures and policies described in  the  previous
sections, when properly implemented, will greatly reduce the












chances of a cracker breaking into your system via a  stolen
account.  However, as with all security measures, you as the
system administrator must periodically check to be sure that
the  policies  and  procedures are being adhered to.  One of
the unfortunate truisms of password security is that, ``left
to  their  own  ways, some people will still use cute doggie
names as passwords'' [Gram84].

     The best way to check the security of the passwords  on
your  system is to use a password-cracking program much like
a real cracker would use.  If you succeed  in  cracking  any
passwords,  those  passwords  should be changed immediately.
There are a few freely available password cracking  programs
distributed  via  various  source  archive  sites; these are
described in more detail in Section 4.  A  fairly  extensive
cracking  program is also available from the author.  Alter-
natively, you can  write  your  own  cracking  program,  and
tailor  it  to your own site.  For a list of things to check
for, see the list of guidelines above.

_2._1._2.  _E_x_p_i_r_a_t_i_o_n _D_a_t_e_s

     Many sites, particularly those with a large  number  of
users,  typically  have  several  old  accounts lying around
whose  owners  have  since  left  the  organization.   These
accounts  are  a  major  security hole: not only can they be
broken into if the password is insecure, but because  nobody
is using the account anymore, it is unlikely that a break-in
will be noticed.

     The simplest way to prevent unused accounts from  accu-
mulating  is  to  place an expiration date on every account.
These expiration dates should be near enough in  the  future
that  old  accounts  will be deleted in a timely manner, yet
far enough apart that the users will not become annoyed.   A
good  figure  is  usually one year from the date the account
was installed.  This tends to  spread  the  expirations  out
over the year, rather than clustering them all at the begin-
ning or end.  The expiration date can easily  be  stored  in
the  password file (in the full name field).  A simple shell
script can be used to periodically check that  all  accounts
have  expiration  dates,  and  that  none  of  the dates has
passed.

     On the first day of each month, any user whose  account
has  expired  should  be  contacted  to  be sure he is still
employed by the organization, and that he is actively  using
the  account.   Any user who cannot be contacted, or who has
not used his account recently, should be  deleted  from  the
system.   If a user is unavailable for some reason (e.g., on
vacation) and cannot be contacted,  his  account  should  be
disabled by replacing the encrypted password in the password
file entry with an asterisk (*).  This makes  it  impossible
to  log  in to the account, yet leaves the account available












to be re-enabled on the user's return.

_2._1._3.  _G_u_e_s_t _A_c_c_o_u_n_t_s

     Guest accounts present still another security hole.  By
their nature, these accounts are rarely used, and are always
used by people who should only have access  to  the  machine
for  the  short  period  of  time they are guests.  The most
secure way to handle guest accounts is to install them on an
as-needed basis, and delete them as soon as the people using
them leave.  Guest accounts should  never  be  given  simple
passwords such as ``guest'' or ``visitor,'' and should never
be allowed to remain in the password file when they are  not
being used.

_2._1._4.  _A_c_c_o_u_n_t_s _W_i_t_h_o_u_t _P_a_s_s_w_o_r_d_s

     Some sites have installed accounts with names  such  as
``who,''  ``date,''  ``lpq,''  and so on that execute simple
commands.  These accounts are intended  to  allow  users  to
execute  these  commands  without  having  to  log in to the
machine.  Typically these accounts have no password  associ-
ated with them, and can thus be used by anyone.  Many of the
accounts are given a user id of zero, so that  they  execute
with super-user permissions.

     The problem with  these  accounts  is  that  they  open
potential  security holes.  By not having passwords on them,
and by having super-user permissions, these accounts practi-
cally invite crackers to try to penetrate them.  Usually, if
the cracker can gain access to the system, penetrating these
accounts  is  simple,  because  each account executes a dif-
ferent command.  If the cracker can replace any one of these
commands  with  one  of  his own, he can then use the unpro-
tected account to execute his program with  super-user  per-
missions.

     Simply put, accounts without passwords  should  not  be
allowed on any system.

_2._1._5.  _G_r_o_u_p _A_c_c_o_u_n_t_s _a_n_d _G_r_o_u_p_s

     Group accounts have become popular at many  sites,  but
are  actually a break-in waiting to happen.  A group account
is a single account shared by several people, e.g.,  by  all
the collaborators on a project.  As mentioned in the section
on password security, users should not share passwords - the
group  account  concept  directly violates this policy.  The
proper way to allow users to share information, rather  than
giving  them a group account to use, is to place these users
into a group.  This is  done  by  editing  the  group  file,
/_e_t_c/_g_r_o_u_p  [Sun88a,  1390;  Sun88b, 66], and creating a new
group with the users  who  wish  to  collaborate  listed  as
members.












     A line in the group file looks like

        groupname:password:groupid:user1,user2,user3,...

The _g_r_o_u_p_n_a_m_e is the name assigned to the group, much like a
login  name.  It may be the same as someone's login name, or
different.  The maximum length of  a  group  name  is  eight
characters.  The password field is unused in versions of and
should contain an asterisk (*).  The  _g_r_o_u_p_i_d  is  a  number
from  0 to 65535 inclusive.  Generally, numbers below 10 are
reserved for special purposes, but you may choose any unused
number.   The  last  field  is a comma-separated (no spaces)
list of the login names of the users in the  group.   If  no
login  names  are listed, then the group has no members.  To
create a group called ``hackers'' with Huey, Duey, and Louie
as  members,  you would add a line such as this to the group
file:

        hackers:*:100:huey,duey,louie


     After the group has been created, the files and  direc-
tories the members wish to share can then be changed so that
they are owned by this group, and the group permission  bits
on  the  files  and directories can be set to allow sharing.
Each user retains his own account, with  his  own  password,
thus protecting the security of the system.

     For example, to change Huey's ``programs'' directory to
be  owned  by  the new group and properly set up the permis-
sions so that all members of the group may  access  it,  the
_c_h_g_r_p  and  _c_h_m_o_d commands would be used as follows [Sun88a,
63-66]:

        # chgrp hackers ~huey/programs
        # chmod -R g+rw ~huey/programs


_2._1._6.  _Y_e_l_l_o_w _P_a_g_e_s

     The Sun Yellow Pages system  [Sun88b,  349-374]  allows
many  hosts  to share password files, group files, and other
files via the network, while the files are stored on only  a
single  host.   Unfortunately,  Yellow Pages also contains a
few potential security holes.

     The principal way Yellow Pages works is to have a  spe-
cial  line  in the password or group file that begins with a
``+''.  In the password file, this line looks like

        +::0:0:::

and in the group file, it looks like














        +:

These lines should only be present in the  files  stored  on
Yellow Pages client machines.  They should not be present in
the files on the Yellow Pages  master  machine(s).   When  a
program  reads the password or group file and encounters one
of these lines, it goes through the network and requests the
information it wants from the Yellow Pages server instead of
trying to find it in the local file.  In this way, the  data
does  not  have  to  be maintained on every host.  Since the
master machine already has all the information, there is  no
need for this special line to be present there.

     Generally speaking, the Yellow Pages service itself  is
reasonably  secure.  There are a few openings that a sophis-
ticated (and dedicated) cracker could exploit,  but  Sun  is
rapidly  closing  these.   The  biggest  problem with Yellow
Pages is the ``+'' line in the password file.  If the  ``+''
is  deleted from the front of the line, then this line loses
its special Yellow Pages meaning.  It instead becomes a reg-
ular  password  file  line  for an account with a null login
name, no password, and user id zero (super-user).  Thus,  if
a  careless  system  administrator  accidentally deletes the
``+''.  the whole system is wide open to any attack.*

     Yellow Pages is too useful a service to suggest turning
it  off, although turning it off would make your system more
secure.  Instead, it is recommended that you read  carefully
the  information  in  the  Sun  manuals in order to be fully
aware of Yellow Pages' abilities and its limitations.

_2._2.  _N_E_T_W_O_R_K _S_E_C_U_R_I_T_Y

     As trends toward internetworking continue,  most  sites
will,  if they haven't already, connect themselves to one of
the numerous regional networks springing up around the coun-
try.   Most  of  these  regional networks are also intercon-
nected, forming the Internet [Hind83, Quar86].   This  means
that  the  users  of your machine can access other hosts and
communicate with  other  users  around  the  world.   Unfor-
tunately,  it  also  means  that  other hosts and users from
around the world can access your  machine,  and  attempt  to
break into it.

     Before internetworking became commonplace, protecting a
system  from  unauthorized  access  simply meant locking the
machine in a room by itself.  Now  that  machines  are  con-
nected  by networks, however, security is much more complex.
_________________________
9  * Actually, a line  like  this  without  a  ``+''  is
dangerous  in  any password file, regardless of whether
Yellow Pages is in use.
9











This section describes the tools and  methods  available  to
make your networks as secure as possible.

_2._2._1.  _T_r_u_s_t_e_d _H_o_s_t_s

     One of the most convenient  features  of  the  Berkeley
(and  Sun) networking software is the concept of ``trusted''
hosts.  The software allows the specification of other hosts
(and  possibly  users)  who  are  to be considered trusted -
remote logins and remote command executions from these hosts
will  be  permitted  without  requiring  the user to enter a
password.  This is very convenient,  because  users  do  not
have to type their password every time they use the network.
Unfortunately, for the same reason, the concept of a trusted
host is also extremely insecure.

     The Internet worm made extensive  use  of  the  trusted
host   concept  to  spread  itself  throughout  the  network
[Seel88].  Many sites that had  already  disallowed  trusted
hosts  did  fairly well against the worm compared with those
sites that did allow trusted hosts.  Even  though  it  is  a
security  hole,  there  are  some valid uses for the trusted
host concept.  This section describes how to properly imple-
ment  the  trusted  hosts  facility while preserving as much
security as possible.

_2._2._1._1.  _T_h_e _h_o_s_t_s._e_q_u_i_v _F_i_l_e

     The file /_e_t_c/_h_o_s_t_s._e_q_u_i_v [Sun88a, 1397] can be used by
the  system  administrator  to indicate trusted hosts.  Each
trusted host is listed in the file, one host per line.  If a
user  attempts to log in (using _r_l_o_g_i_n) or execute a command
(using _r_s_h) remotely from  one  of  the  systems  listed  in
_h_o_s_t_s._e_q_u_i_v,  and that user has an account on the local sys-
tem with the same login name, access  is  permitted  without
requiring a password.

     Provided adequate care is taken  to  allow  only  local
hosts  in  the  _h_o_s_t_s._e_q_u_i_v  file,  a  reasonable compromise
between security and convenience can be achieved.   Nonlocal
hosts (including hosts at remote sites of the same organiza-
tion) should never be  trusted.   Also,  if  there  are  any
machines  at  your organization that are installed in ``pub-
lic'' areas (e.g., terminal rooms)  as  opposed  to  private
offices, you should not trust these hosts.

     On Sun systems, _h_o_s_t_s._e_q_u_i_v is controlled with the Yel-
low Pages software.  As distributed, the default _h_o_s_t_s._e_q_u_i_v
file distributed by Sun contains a single line:

        +

This indicates that _e_v_e_r_y _k_n_o_w_n  _h_o_s_t  (i.e.,  the  complete
contents  of  the  host file) should be considered a trusted












host.  This is totally incorrect and a major security  hole,
since  hosts  outside the local organization should never be
trusted.  A correctly configured  _h_o_s_t_s._e_q_u_i_v  should  never
list  any  ``wildcard''  hosts  (such  as  the  ``+''); only
specific host names should be used.  When installing  a  new
system  from  Sun  distribution tapes, you should be sure to
either replace the Sun default _h_o_s_t_s._e_q_u_i_v with a  correctly
configured one, or delete the file altogether.

_2._2._1._2.  _T_h_e ._r_h_o_s_t_s _F_i_l_e

     The ._r_h_o_s_t_s file [Sun88a, 1397] is similar  in  concept
and  format  to  the  _h_o_s_t_s._e_q_u_i_v  file,  but allows trusted
access only to specific host-user combinations, rather  than
to hosts in general.* Each user may create a ._r_h_o_s_t_s file in
his  home directory, and allow access to her account without
a password.  Most people use this mechanism to allow trusted
access  between  accounts they have on systems owned by dif-
ferent organizations who do not trust each other's hosts  in
_h_o_s_t_s._e_q_u_i_v.   Unfortunately,  this  file  presents  a major
security problem: While  _h_o_s_t_s._e_q_u_i_v  is  under  the  system
administrator's  control and can be managed effectively, any
user may create a ._r_h_o_s_t_s file granting access  to  whomever
he chooses, without the system administrator's knowledge.

     The only secure way to manage ._r_h_o_s_t_s files is to  com-
pletely disallow them on the system.  The system administra-
tor should check the system often  for  violations  of  this
policy  (see  Section  3.3.1.4).   One possible exception to
this rule is the ``root'' account; a  ._r_h_o_s_t_s  file  may  be
necessary  to  allow network backups and the like to be com-
pleted.

_2._2._2.  _S_e_c_u_r_e _T_e_r_m_i_n_a_l_s

     Under newer versions of the  concept  of  a  ``secure''
terminal  has  been  introduced.  Simply put, the super-user
(``root'') may not log in on a nonsecure terminal, even with
a  password.  (Authorized users may still use the _s_u command
to  become  super-user,  however.)  The   file   /_e_t_c/_t_t_y_t_a_b
[Sun88a,  1478]  is used to control which terminals are con-
sidered secure.|- A short excerpt from  this  file  is  shown
below.




_________________________
9  * Actually, _h_o_s_t_s._e_q_u_i_v may be used to specify  host-
user combinations as well, but this is rarely done.
9  |- Under non-Sun versions of  Berkeley  this  file  is
called /_e_t_c/_t_t_y_s.














        console  "/usr/etc/getty std.9600"  sun      off secure
        ttya     "/usr/etc/getty std.9600"  unknown  off secure
        ttyb     "/usr/etc/getty std.9600"  unknown  off secure
        ttyp0    none                       network  off secure
        ttyp1    none                       network  off secure
        ttyp2    none                       network  off secure

The keyword ``secure'' at the end  of  each  line  indicates
that  the  terminal  is  considered  secure.  To remove this
designation, simply edit the file and delete the  ``secure''
keyword.   After  saving  the  file,  type  the  command (as
super-user):

        # kill -HUP 1

This tells the _i_n_i_t process to reread the _t_t_y_t_a_b file.

     The Sun default configuration for _t_t_y_t_a_b is to consider
all terminals secure, including ``pseudo'' terminals used by
the remote login software.  This means that ``root'' may log
in  remotely  from  any  host on the network.  A more secure
configuration would consider as secure  only  directly  con-
nected  terminals, or perhaps only the console device.  This
is how file servers and other machines with disks should  be
set up.

     The  most  secure  configuration  is  to   remove   the
``secure''  designation  from  all  terminals, including the
console device.  This requires that those users with  super-
user  authority  first log in as themselves, and then become
the super-user via the _s_u command.   It  also  requires  the
``root''  password  to  be entered when rebooting in single-
user mode, in order to prevent users  from  rebooting  their
desktop  workstations and obtaining super-user access.  This
is how all diskless client machines should be set up.

_2._2._3.  _T_h_e _N_e_t_w_o_r_k _F_i_l_e _S_y_s_t_e_m

     The Network File System [Sun88d] is designed  to  allow
several  hosts  to share files over the network.  One of the
most common uses of is to allow diskless workstations to  be
installed  in  offices,  while keeping all disk storage in a
central location.  As distributed by Sun,  has  no  security
features  enabled.  This means that any host on the Internet
may access your files via regardless of  whether  you  trust
them or not.

     Fortunately, there are several easy ways to  make  more
secure.   The  more  commonly  used methods are described in
this section, and these can be used to make your files quite
secure  from  unauthorized  access  via Secure introduced in
Release 4.0, takes security one step further, using  public-
key  encryption  techniques  to  ensure  authorized  access.












Discussion of secure is deferred until Section 4.

_2._2._3._1.  _T_h_e _e_x_p_o_r_t_s _F_i_l_e

     The file /_e_t_c/_e_x_p_o_r_t_s [Sun88a, 1377] is perhaps one  of
the  most important parts of configuration.  This file lists
which file systems are exported (made available  for  mount-
ing)  to other systems.  A typical _e_x_p_o_r_t_s file as installed
by the Sun installation procedure looks something like this:

        /usr
        /home
        /var/spool/mail
        #
        /export/root/client1    -access=client1,root=client1
        /export/swap/client1    -access=client1,root=client1
        #
        /export/root/client2    -access=client2,root=client2
        /export/swap/client2    -access=client2,root=client2

The _r_o_o_t= keyword specifies  the  list  of  hosts  that  are
allowed  to have super-user access to the files in the named
file system.  This keyword is discussed in detail in Section
2.2.3.3.   The  _a_c_c_e_s_s=  keyword specifies the list of hosts
(separated by colons) that are allowed to  mount  the  named
file  system.  If no _a_c_c_e_s_s= keyword is specified for a file
system, any host anywhere on the network may mount that file
system via

     Obviously, this  presents  a  major  security  problem,
since  anyone  who  can mount your file systems via can then
peruse them at her leisure.  Thus, it is important that  all
file systems listed in _e_x_p_o_r_t_s have an _a_c_c_e_s_s= keyword asso-
ciated with them.  If you have only a few hosts  which  must
mount  a  file system, you can list them individually in the
file:

        /usr    -access=host1:host2:host3:host4:host5

However, because the maximum number of  hosts  that  can  be
listed  this way is ten, the _a_c_c_e_s_s= keyword will also allow
netgroups to be specified.  Netgroups are described  in  the
next section.

     After making any  changes  to  the  _e_x_p_o_r_t_s  file,  you
should run the command

        # exportfs -a

in order to make the changes take effect.

_2._2._3._2.  _T_h_e _n_e_t_g_r_o_u_p _F_i_l_e

     The file /_e_t_c/_n_e_t_g_r_o_u_p [Sun88a, 1407] is used to define












netgroups.   This  file  is  controlled by Yellow Pages, and
must be rebuilt in the Yellow  Pages  maps  whenever  it  is
modified.  Consider the following sample _n_e_t_g_r_o_u_p file:

        A_Group      (servera,,) (clienta1,,) (clienta2,,)

        B_Group      (serverb,,) (clientb1,,) (clientb2,,)

        AdminStaff   (clienta1,mary,) (clientb3,joan,)

        AllSuns      A_Group B_Group

This file defines four netgroups, called  _A__G_r_o_u_p,  _B__G_r_o_u_p,
_A_d_m_i_n_S_t_a_f_f, and _A_l_l_S_u_n_s.  The _A_l_l_S_u_n_s netgroup is actually a
``super group'' containing all the members  of  the  _A__G_r_o_u_p
and _B__G_r_o_u_p netgroups.

     Each member of a  netgroup  is  defined  as  a  triple:
(host,  user, domain).  Typically, the _d_o_m_a_i_n field is never
used, and is simply left blank.  If either the _h_o_s_t or  _u_s_e_r
field  is left blank, then any host or user is considered to
match.  Thus the triple (host,,) matches  any  user  on  the
named host, while the triple (,user,) matches the named user
on any host.

     Netgroups are useful when restricting  access  to  file
systems  via  the  _e_x_p_o_r_t_s file.  For example, consider this
modified version of the file from the previous section:

        /usr                    -access=A_Group
        /home                   -access=A_Group:B_Group
        /var/spool/mail         -access=AllSuns
        #
        /export/root/client1    -access=client1,root=client1
        /export/swap/client1    -access=client1,root=client1
        #
        /export/root/client2    -access=client2,root=client2
        /export/swap/client2    -access=client2,root=client2

The /_u_s_r file system may now only be mounted by the hosts in
the  _A__G_r_o_u_p  netgroup,  that  is,  _s_e_r_v_e_r_a,  _c_l_i_e_n_t_a_1,  and
_c_l_i_e_n_t_a_2.  Any other host that tries to mount this file sys-
tem will receive an ``access denied'' error.  The /_h_o_m_e file
system may be mounted by any of  the  hosts  in  either  the
_A__G_r_o_u_p or _B__G_r_o_u_p netgroups.  The /_v_a_r/_s_p_o_o_l/_m_a_i_l file sys-
tem is also restricted to these hosts, but in  this  example
we used the ``super group'' called _A_l_l_S_u_n_s.

     Generally, the best way to configure the _n_e_t_g_r_o_u_p  file
is  to  make  a single netgroup for each file server and its
clients, and then  to  make  other  super  groups,  such  as
_A_l_l_S_u_n_s.   This  allows  you  the flexibility to specify the
smallest possible group of hosts for  each  file  system  in
/_e_t_c/_e_x_p_o_r_t_s.












     Netgroups can also be used  in  the  password  file  to
allow access to a given host to be restricted to the members
of that group, and they can be used in the _h_o_s_t_s._e_q_u_i_v  file
to centralize maintenance of the list of trusted hosts.  The
procedures for doing this are defined in more detail in  the
Sun manual.

_2._2._3._3.  _R_e_s_t_r_i_c_t_i_n_g _S_u_p_e_r-_U_s_e_r _A_c_c_e_s_s

     Normally, translates the super-user id to a special  id
called  ``nobody''  in order to prevent a user with ``root''
on a remote workstation from accessing other people's files.
This is good for security, but sometimes a nuisance for sys-
tem administration, since you cannot make changes  to  files
as ``root'' through

     The _e_x_p_o_r_t_s file also allows you  to  grant  super-user
access  to  certain  file systems for certain hosts by using
the _r_o_o_t= keyword.  Following this keyword a colon-separated
list  of  up to ten hosts may be specified; these hosts will
be allowed to access the file  system  as  ``root''  without
having  the  user  id converted to ``nobody.'' Netgroups may
not be specified to the _r_o_o_t= keyword.

     Granting ``root'' access to a host should not  be  done
lightly.   If  a  host has ``root'' access to a file system,
then the super-user on that host will have  complete  access
to  the  file  system,  just  as  if  you  had given him the
``root'' password on the  server.   Untrusted  hosts  should
never be given ``root'' access to file systems.

_2._2._4.  _F_T_P

     The File Transfer Protocol, implemented by the _f_t_p  and
_f_t_p_d  programs [Sun88a, 195-201, 1632-1634], allows users to
connect to remote systems and transfer files back and forth.
Unfortunately,  older  versions  of  these programs also had
several bugs in them that allowed crackers to break  into  a
system.   These  bugs  have  been fixed by Berkeley, and new
versions are available.  If your _f_t_p_d* was  obtained  before
December  1988,  you should get a newer version (see Section
4).

     One of the more useful features of is the ``anonymous''
login.   This  special login allows users who do not have an
account on your machine to have restricted access  in  order
to transfer files from a specific directory.  This is useful
if you wish to distribute software to the  public  at  large
without giving each person who wants the software an account
_________________________
9  * On  Sun  systems,  _f_t_p_d  is  stored  in  the   file
/_u_s_r/_e_t_c/_i_n._f_t_p_d.   On most other systems, it is called
/_e_t_c/_f_t_p_d.
9











on your machine.  In order to securely set up anonymous  you
should follow the specific instructions below:

     1.   Create an  account  called  ``ftp.''  Disable  the
          account by placing an asterisk (*) in the password
          field.  Give the account a special home directory,
          such as /_u_s_r/_f_t_p or /_u_s_r/_s_p_o_o_l/_f_t_p.

     2.   Make the  home  directory  owned  by  ``ftp''  and
          unwritable by anyone:

                  # chown ftp ~ftp
                  # chmod 555 ~ftp


     3.   Make the directory ~_f_t_p/_b_i_n, owned by  the  super-
          user  and  unwritable  by anyone.  Place a copy of
          the _l_s program in this directory:

                  # mkdir ~ftp/bin
                  # chown root ~ftp/bin
                  # chmod 555 ~ftp/bin
                  # cp -p /bin/ls ~ftp/bin
                  # chmod 111 ~ftp/bin/ls


     4.   Make the directory ~_f_t_p/_e_t_c, owned by  the  super-
          user  and  unwritable  by anyone.  Place copies of
          the password and group files  in  this  directory,
          with  all the password fields changed to asterisks
          (*).  You may wish to delete all but a few of  the
          accounts  and  groups  from  these files; the only
          account that must be present is ``ftp.''

                  # mkdir ~ftp/etc
                  # chown root ~ftp/etc
                  # chmod 555 ~ftp/etc
                  # cp -p /etc/passwd /etc/group ~ftp/etc
                  # chmod 444 ~ftp/etc/passwd ~ftp/etc/group


     5.   Make the directory ~_f_t_p/_p_u_b, owned by ``ftp''  and
          world-writable.   Users  may then place files that
          are to be accessible via anonymous in this  direc-
          tory:

                  # mkdir ~ftp/pub
                  # chown ftp ~ftp/pub
                  # chmod 777 ~ftp/pub


     Because the anonymous feature allows anyone  to  access
your system (albeit in a very limited way), it should not be
made available on every host on the network.   Instead,  you












should choose one machine (preferably a server or standalone
host) on which to allow this service.  This makes monitoring
for security violations much easier.  If you allow people to
transfer files to your machine (using the world-writable _p_u_b
directory, described above), you should check often the con-
tents of the directories into  which  they  are  allowed  to
write.  Any suspicious files you find should be deleted.

_2._2._4._1.  _T_r_i_v_i_a_l _F_T_P

     The Trivial File Transfer  Protocol,  is  used  on  Sun
workstations  (and  others)  to allow diskless hosts to boot
from the network.  Basically, is a stripped-down version  of
there is no user authentication, and the connection is based
on the User Datagram Protocol instead  of  the  Transmission
Control  Protocol.   Because they are so stripped-down, many
implementations of have security holes.   You  should  check
your hosts by executing the command sequence shown below.

        % tftp
        tftp> connect _y_o_u_r_h_o_s_t
        tftp> get /etc/motd tmp
        _E_r_r_o_r _c_o_d_e _1: _F_i_l_e _n_o_t _f_o_u_n_d
        _t_f_t_p> _q_u_i_t
        %

If your version does not respond with  ``_F_i_l_e  _n_o_t  _f_o_u_n_d,''
and instead transfers the file, you should replace your ver-
sion of _t_f_t_p_d* with a newer one.  In particular, versions of
prior to release 4.0 are known to have this problem.

_2._2._5.  _M_a_i_l

     Electronic mail is one of the main reasons for connect-
ing  to  outside  networks.   On  most versions of Berkeley-
derived systems, including those from Sun, the _s_e_n_d_m_a_i_l pro-
gram  [Sun88a, 1758-1760; Sun88b, 441-488] is used to enable
the receipt and delivery of mail.   As  with  the  software,
older  versions  of  _s_e_n_d_m_a_i_l  have  several bugs that allow
security violations.  One of these bugs was used with  great
success  by the Internet worm [Seel88, Spaf88].  The current
version of _s_e_n_d_m_a_i_l from Berkeley is version 5.61, of  Janu-
ary  1989.   Sun is, as of this writing, still shipping ver-
sion 5.59, which has a known security problem.   They  have,
however,  made a fixed version available.  Section 4 details
how to obtain these newer versions.

     Generally, with the exception  of  the  security  holes
mentioned   above,   _s_e_n_d_m_a_i_l   is  reasonably  secure  when
_________________________
9  * On  Sun  systems,  _t_f_t_p_d  is  stored  in  the  file
/_u_s_r/_e_t_c/_i_n._t_f_t_p_d.  On most other systems, it is called
/_e_t_c/_t_f_t_p_d.
9











installed by most vendors' installation  procedures.   There
are,  however,  a  few  precautions  that should be taken to
ensure secure operation:

     1.   Remove the ``decode'' alias from the aliases  file
          (/_e_t_c/_a_l_i_a_s_e_s or /_u_s_r/_l_i_b/_a_l_i_a_s_e_s).

     2.   If you create aliases that allow  messages  to  be
          sent to programs, be absolutely sure that there is
          no way to obtain a shell or  send  commands  to  a
          shell from these programs.

     3.   Make sure the ``wizard'' password is  disabled  in
          the  configuration file, _s_e_n_d_m_a_i_l._c_f.  (Unless you
          modify the distributed configuration  files,  this
          shouldn't be a problem.)

     4.   Make sure  your  _s_e_n_d_m_a_i_l  does  not  support  the
          ``debug'' command.  This can be done with the fol-
          lowing commands:

          % telnet localhost 25
          220 yourhost Sendmail 5.61 ready at 9 Mar 90 10:57:36 PST
          debug
          500 Command unrecognized
          quit
          %


          If your _s_e_n_d_m_a_i_l responds to the ``debug'' command
          with ``_2_0_0 _D_e_b_u_g _s_e_t,'' then you are vulnerable to
          attack and should replace  your  _s_e_n_d_m_a_i_l  with  a
          newer version.

By following the procedures above, you can be sure that your
mail system is secure.

_2._2._6.  _F_i_n_g_e_r

     The ``finger'' service, provided by the _f_i_n_g_e_r  program
[Sun88a,  186-187], allows you to obtain information about a
user such as her full name, home directory, last login time,
and  in  some  cases when she last received mail and/or read
her mail.  The _f_i_n_g_e_r_d program [Sun88a, 1625]  allows  users
on remote hosts to obtain this information.

     A bug in _f_i_n_g_e_r_d was also exercised with success by the
Internet worm [Seel88, Spaf88].  If your version of _f_i_n_g_e_r_d*
is older than November 5, 1988, it should be replaced with a
_________________________
9  * On   Sun   systems,   _f_i_n_g_e_r_d    is    stored    in
/_u_s_r/_e_t_c/_i_n._f_i_n_g_e_r_d.   On  most  other  systems,  it is
called /_e_t_c/_f_i_n_g_e_r_d.
9











newer version.  New versions are available from  several  of
the sources described in Section 4.

_2._2._7.  _M_o_d_e_m_s _a_n_d _T_e_r_m_i_n_a_l _S_e_r_v_e_r_s

     Modems and terminal servers (terminal  switches,  Annex
boxes,  etc.) present still another potential security prob-
lem.  The main problem with these devices is one  of  confi-
guration   -   misconfigured  hardware  can  allow  security
breaches.  Explaining how to configure every brand of  modem
and  terminal  server  would  require volumes.  However, the
following items should be checked for on any modems or  ter-
minal servers installed at your site:

     1.   If a user dialed up to a modem hangs up the phone,
          the  system  should  log  him out.  If it doesn't,
          check the hardware connections and the kernel con-
          figuration of the serial ports.

     2.   If a user logs off, the system  should  force  the
          modem  to hang up.  Again, check the hardware con-
          nections if this doesn't work.

     3.   If the connection from a terminal  server  to  the
          system  is  broken, the system should log the user
          off.

     4.   If the terminal server is connected to modems, and
          the  user  hangs  up,  the  terminal server should
          inform the system that the user has hung up.

     Most modem and terminal server manuals cover in  detail
how  to  properly  connect these devices to your system.  In
particular you should pay close attention to  the  ``Carrier
Detect,'' ``Clear to Send,'' and ``Request to Send'' connec-
tions.

_2._2._8.  _F_i_r_e_w_a_l_l_s

     One of the newer ideas in network security is that of a
_f_i_r_e_w_a_l_l.  Basically, a firewall is a special host that sits
between your outside-world network  connection(s)  and  your
internal  network(s).   This  host does not send out routing
information about your internal network, and thus the inter-
nal  network is ``invisible'' from the outside.  In order to
configure a firewall machine, the  following  considerations
need to be taken:

     1.   The firewall  does  not  advertise  routes.   This
          means  that users on the internal network must log
          in to the firewall in order  to  access  hosts  on
          remote  networks.  Likewise, in order to log in to
          a host on the internal network from the outside, a
          user  must  first  log in to the firewall machine.












          This is inconvenient, but more secure.

     2.   All electronic mail sent by  your  users  must  be
          forwarded  to  the firewall machine if it is to be
          delivered  outside  your  internal  network.   The
          firewall  must  receive  all  incoming  electronic
          mail, and then redistribute it.  This can be  done
          either with aliases for each user or by using name
          server records.

     3.   The firewall machine should  not  mount  any  file
          systems via or make any of its file systems avail-
          able to be mounted.

     4.   Password security on the firewall must be  rigidly
          enforced.

     5.   The firewall host should not trust any other hosts
          regardless  of  where  they are.  Furthermore, the
          firewall should not be trusted by any other host.

     6.   Anonymous and other similar services  should  only
          be provided by the firewall host, if they are pro-
          vided at all.

     The purpose of the firewall is to prevent crackers from
accessing  other hosts on your network.  This means, in gen-
eral, that you must maintain  strict  and  rigidly  enforced
security  on  the  firewall,  but  the  other hosts are less
vulnerable, and hence security may be somewhat lax.  But  it
is important to remember that the firewall is not a complete
cure against crackers - if a  cracker  can  break  into  the
firewall  machine,  he  can then try to break into any other
host on your network.

_2._3.  _F_I_L_E _S_Y_S_T_E_M _S_E_C_U_R_I_T_Y

     The last defense against system crackers are  the  per-
missions offered by the file system.  Each file or directory
has three sets of permission bits associated  with  it:  one
set for the user who owns the file, one set for the users in
the group with which the file is associated, and one set for
all  other users (the ``world'' permissions).  Each set con-
tains three identical permission  bits,  which  control  the
following:

     _r_e_a_d     If set, the file or directory may be read.  In
              the  case of a directory, read access allows a
              user to see the contents of a  directory  (the
              names of the files contained therein), but not
              to access them.

     _w_r_i_t_e    If set, the file or directory may  be  written
              (modified).  In the case of a directory, write












              permission  implies  the  ability  to  create,
              delete, and rename files.  Note that the abil-
              ity to remove a file is _n_o_t controlled by  the
              permissions  on  the file, but rather the per-
              missions on the directory containing the file.

     _e_x_e_c_u_t_e  If set, the file or directory may be  executed
              (searched).   In the case of a directory, exe-
              cute permission implies the ability to  access
              files contained in that directory.

     In addition, a fourth permission bit  is  available  in
each  set  of permissions.  This bit has a different meaning
in each set of permission bits:

     _s_e_t_u_i_d  If set in the owner permissions, this bit  con-
             trols  the ``set user id'' (setuid) status of a
             file.  Setuid status means that when a  program
             is  executed,  it executes with the permissions
             of the user owning the program, in addition  to
             the  permissions of the user executing the pro-
             gram.   For   example,   _s_e_n_d_m_a_i_l   is   setuid
             ``root,''  allowing  it  to  write files in the
             mail queue area, which  normal  users  are  not
             allowed  to  do.   This  bit  is meaningless on
             nonexecutable files.

     _s_e_t_g_i_d  If set in the group permissions, this bit  con-
             trols the ``set group id'' (setgid) status of a
             file.  This behaves in exactly the same way  as
             the  setuid  bit,  except  that the group id is
             affected instead.  This bit is  meaningless  on
             non-executable files (but see below).

     _s_t_i_c_k_y  If set in the world permissions, the ``sticky''
             bit  tells  the  operating system to do special
             things with the text  image  of  an  executable
             file.   It is mostly a holdover from older ver-
             sions of and has little if any use today.  This
             bit  is also meaningless on nonexecutable files
             (but see below).

_2._3._1.  _S_e_t_u_i_d _S_h_e_l_l _S_c_r_i_p_t_s

     Shell scripts that have the setuid or setgid  bits  set
on  them  are  _n_o_t secure, regardless of how many safeguards
are taken when writing them.  There  are  numerous  software
packages  available that claim to make shell scripts secure,
but every one released so far has not managed to  solve  all
the problems.

     Setuid and setgid shell scripts should never be allowed
on any system.













_2._3._2.  _T_h_e _S_t_i_c_k_y _B_i_t _o_n _D_i_r_e_c_t_o_r_i_e_s

     Newer versions of have attached a new  meaning  to  the
sticky  bit.   When this bit is set on a directory, it means
that users may not delete or rename other  users'  files  in
this  directory.   This  is  typically  useful  for the /_t_m_p
directory.  Normally, /_t_m_p is world-writable,  enabling  any
user  to delete another user's files.  By setting the sticky
bit on /_t_m_p, users may only delete their own files from this
directory.

     To set the sticky bit on a directory, use the command

        # chmod o+t _d_i_r_e_c_t_o_r_y


_2._3._3.  _T_h_e _S_e_t_g_i_d _B_i_t _o_n _D_i_r_e_c_t_o_r_i_e_s

     In 4.0, the setgid bit was also given  a  new  meaning.
Two  rules  can  be  used for assigning group ownership to a
file in

     1.   The System V mechanism, which says that  a  user's
          primary  group  id (the one listed in the password
          file) is assigned to any file he creates.

     2.   The Berkeley mechanism, which says that the  group
          id  of a file is set to the group id of the direc-
          tory in which it is created.

     If the setgid bit is set on a directory,  the  Berkeley
mechanism  is enabled.  Otherwise, the System V mechanism is
enabled.  Normally, the Berkeley  mechanism  is  used;  this
mechanism  must  be  used if creating directories for use by
more than one member of a group (see Section 2.1.5).

     To set the setgid bit on a directory, use the command

        # chmod g+s _d_i_r_e_c_t_o_r_y


_2._3._4.  _T_h_e _u_m_a_s_k _V_a_l_u_e

     When a file is created by a program, say a text  editor
or  a compiler, it is typically created with all permissions
enabled.  Since this is rarely  desirable  (you  don't  want
other users to be able to write your files), the _u_m_a_s_k value
is used to modify the set of permissions a file  is  created
with.   Simply  put, while the _c_h_m_o_d command [Sun88a, 65-66]
specifies what bits should be turned  _o_n,  the  umask  value
specifies what bits should be turned _o_f_f.

     For example, the default umask on most systems is  022.
This  means  that  write  permission for the group and world












should be turned off whenever a file is created.  If instead
you  wanted to turn off all group and world permission bits,
such that any file you created would not be readable,  writ-
able, or executable by anyone except yourself, you would set
your umask to 077.

     The umask value is specified in the ._c_s_h_r_c or  ._p_r_o_f_i_l_e
files  read  by  the  shell using the _u_m_a_s_k command [Sun88a,
108, 459].  The ``root'' account should have the line

        umask 022

in its /._c_s_h_r_c file, in  order  to  prevent  the  accidental
creation of world-writable files owned by the super-user.

_2._3._5.  _E_n_c_r_y_p_t_i_n_g _F_i_l_e_s

     The standard _c_r_y_p_t command [Sun88a, 95] is not  at  all
secure.  Although it is reasonable to expect that _c_r_y_p_t will
keep the casual ``browser'' from reading  a  file,  it  will
present  nothing more than a minor inconvenience to a deter-
mined cracker.  _C_r_y_p_t implements a one-rotor  machine  along
the  lines  of  the  German Enigma (broken in World War II).
The methods of attack on such a machine are well known,  and
a  sufficiently large file can usually be decrypted in a few
hours even without  knowledge  of  what  the  file  contains
[Reed84].   In fact, publicly available packages of programs
designed to ``break'' files encrypted with _c_r_y_p_t  have  been
around for several years.

     There are software  implementations  of  another  algo-
rithm,  the  Data Encryption Standard available on some sys-
tems.  Although this algorithm  is  much  more  secure  than
_c_r_y_p_t,  it  has never been proven that it is totally secure,
and many doubts about  its  security  have  been  raised  in
recent years.

     Perhaps the best thing to say about encrypting files on
a  computer  system  is  this:  if you think you have a file
whose contents are important enough to  encrypt,  then  that
file  should  not  be  stored  on  the computer in the first
place.  This is especially  true  of  systems  with  limited
security, such as systems and personal computers.

     It  is  important  to  note  that  passwords  are   _n_o_t
encrypted   with  the  _c_r_y_p_t  program.   Instead,  they  are
encrypted with a modified  version  of  the  that  generates
one-way   encryptions  (that  is,  the  password  cannot  be
decrypted).  When you log in, the system  does  not  decrypt
your  password.   Instead,  it encrypts your attempted pass-
word, and if this comes out to the same result as encrypting
your real password, you are allowed to log in.














_2._3._6.  _D_e_v_i_c_e_s

     The security of devices is an important issue in Device
files  (usually  residing  in /_d_e_v) are used by various pro-
grams to access the data on the disk drives  or  in  memory.
If  these device files are not properly protected, your sys-
tem is wide open to a cracker.  The entire list  of  devices
is  too  long  to  go into here, since it varies widely from
system to system.  However, the following  guidelines  apply
to all systems:

     1.   The  files  /_d_e_v/_k_m_e_m,  /_d_e_v/_m_e_m,  and   /_d_e_v/_d_r_u_m
          should  never  be  readable by the world.  If your
          system supports the notion of the  ``kmem''  group
          (most  newer  systems do) and utilities such as _p_s
          are setgid ``kmem,'' then these  files  should  be
          owned  by  user  ``root''  and group ``kmem,'' and
          should be mode 640.  If your system does not  sup-
          port  the notion of the ``kmem'' group, and utili-
          ties such as _p_s are setuid  ``root,''  then  these
          files  should  be  owned by user ``root'' and mode
          600.

     2.   The disk devices, such as  /_d_e_v/_s_d_0_a,  /_d_e_v/_r_x_y_1_b,
          etc.,  should  be owned by user ``root'' and group
          ``operator,'' and should be mode 640.   Note  that
          each  disk  has  eight  partitions  and two device
          files for each partition.  Thus, the disk  ``sd0''
          would  have  the following device files associated
          with it in /_d_e_v:

                  sd0a     sd0e     rsd0a     rsd0e
                  sd0b     sd0f     rsd0b     rsd0f
                  sd0c     sd0g     rsd0c     rsd0g
                  sd0d     sd0h     rsd0d     rsd0h


     3.   With very few exceptions, all other devices should
          be owned by user ``root.'' One exception is termi-
          nals, which are changed to be owned  by  the  user
          currently  logged  in on them.  When the user logs
          out, the ownership of the  terminal  is  automati-
          cally changed back to ``root.''

_2._4.  _S_E_C_U_R_I_T_Y _I_S _Y_O_U_R _R_E_S_P_O_N_S_I_B_I_L_I_T_Y

     This section has detailed numerous tools for  improving
security  provided by the operating system.  The most impor-
tant thing to note about these tools is that  although  they
are  available,  they  are  typically not put to use in most
installations.  Therefore, it is incumbent on you, the  sys-
tem  administrator,  to take the time and make the effort to
enable these tools, and thus to  protect  your  system  from
unauthorized access.












_3.  _M_O_N_I_T_O_R_I_N_G _S_E_C_U_R_I_T_Y

     One of the most important tasks in keeping any computer
system  secure  is  monitoring  the  security of the system.
This involves examining system log  files  for  unauthorized
accesses  of  the  system,  as well as monitoring the system
itself for security holes.  This section describes the  pro-
cedures  for  doing  this.  An additional part of monitoring
security involves keeping abreast of security problems found
by others; this is described in Section 5.

_3._1.  _A_C_C_O_U_N_T _S_E_C_U_R_I_T_Y

     Account security should be  monitored  periodically  in
order  to  check  for  two things: users logged in when they
``shouldn't'' be (e.g., late at night, when they're on vaca-
tion, etc.), and users executing commands they wouldn't nor-
mally be expected to use.  The commands  described  in  this
section can be used to obtain this information from the sys-
tem.

_3._1._1.  _T_h_e _l_a_s_t_l_o_g _F_i_l_e

     The file /_u_s_r/_a_d_m/_l_a_s_t_l_o_g [Sun88a,  1485]  records  the
most  recent  login  time  for each user of the system.  The
message printed each time you log in, e.g.,

        Last login: Sat Mar 10 10:50:48 from spam.itstd.sri.c

uses the time stored in the _l_a_s_t_l_o_g file.  Additionally, the
last  login  time  reported  by the _f_i_n_g_e_r command uses this
time.  Users should be told to carefully examine  this  time
whenever  they  log in, and to report unusual login times to
the system administrator.  This is an  easy  way  to  detect
account  break-ins, since each user should remember the last
time she logged into the system.

_3._1._2.  _T_h_e _u_t_m_p _a_n_d _w_t_m_p _F_i_l_e_s

     The file /_e_t_c/_u_t_m_p [Sun88a, 1485] is used to record who
is  currently  logged  into  the  system.   This file can be
displayed using the _w_h_o command [Sun88a, 597]:

        % who
        hendra   tty0c   Mar 13 12:31
        heidari  tty14   Mar 13 13:54
        welgem   tty36   Mar 13 12:15
        reagin   ttyp0   Mar 13 08:54   (aaifs.itstd.sri.)
        ghg      ttyp1   Mar  9 07:03   (hydra.riacs.edu)
        compion  ttyp2   Mar  1 03:01   (ei.ecn.purdue.ed)

For each user, the login name, terminal  being  used,  login
time, and remote host (if the user is logged in via the net-
work) are displayed.



                        May 4, 1990








     The file  /_u_s_r/_a_d_m/_w_t_m_p  [Sun88a,  1485]  records  each
login and logout time for every user.  This file can also be
displayed using the _w_h_o command:

        % who /usr/adm/wtmp
        davy     ttyp4    Jan  7 12:42 (annex01.riacs.ed)
                 ttyp4    Jan  7 15:33
        davy     ttyp4    Jan  7 15:33 (annex01.riacs.ed)
                 ttyp4    Jan  7 15:35
        hyder    ttyp3    Jan  8 09:07 (triceratops.itst)
                 ttyp3    Jan  8 11:43

A line that contains a login name  indicates  the  time  the
user logged in; a line with no login name indicates the time
that the terminal was logged off.  Unfortunately, the output
from  this  command  is  rarely  as simple as in the example
above; if several users log in at once, the login and logout
times  are all mixed together and must be matched up by hand
using the terminal name.

     The _w_t_m_p file may also be examined using the _l_a_s_t  com-
mand  [Sun88a,  248].  This command sorts out the entries in
the file, matching up login and logout times.  With no argu-
ments, _l_a_s_t displays all information in the file.  By giving
the name of a user or terminal, the output can be restricted
to  the  information about the user or terminal in question.
Sample output from the _l_a_s_t command is shown below.

        % last
        davy      ttyp3  intrepid.itstd.s Tue Mar 13 10:55 - 10:56 (00:00)
        hyder     ttyp3  clyde.itstd.sri. Mon Mar 12 15:31 - 15:36 (00:04)
        reboot    ~                       Mon Mar 12 15:16
        shutdown  ~                       Mon Mar 12 15:16
        arms      ttyp3  clyde0.itstd.sri Mon Mar 12 15:08 - 15:12 (00:04)
        hyder     ttyp3  spam.itstd.sri.c Sun Mar 11 21:08 - 21:13 (00:04)
        reboot    ~                       Sat Mar 10 20:05
        davy      ftp    hydra.riacs.edu  Sat Mar 10 13:23 - 13:30 (00:07)

For each login session, the user name, terminal used, remote
host  (if  the  user  logged  in via the network), login and
logout times, and session duration are shown.  Additionally,
the  times of all system shutdowns and reboots (generated by
the _s_h_u_t_d_o_w_n and _r_e_b_o_o_t commands [Sun88a, 1727,  1765])  are
recorded.   Unfortunately,  system crashes are not recorded.
In newer versions of the  operating  system,  pseudo  logins
such  as  those  via  the  _f_t_p command are also recorded; an
example of this is shown in the last line of the sample out-
put, above.

_3._1._3.  _T_h_e _a_c_c_t _F_i_l_e

     The file /_u_s_r/_a_d_m/_a_c_c_t [Sun88a, 1344-1345] records each
execution of a command on the system, who executed it, when,
and how long it took.  This information is logged each  time



a  i .if !0 .if !0 .tl May 4, 1990 i .if 0 .if o .tl i .if 0








.if e .tl command completes, but only  if  your  kernel  was
compiled  with  the option enabled (the option is enabled in
some kernels, but is usually disabled by default).

     The _a_c_c_t file can be displayed using the _l_a_s_t_c_o_m_m  com-
mand  [Sun88a, 249].  With no arguments, all the information
in the file is displayed.   However,  by  giving  a  command
name, user name, or terminal name as an argument, the output
can be restricted to information about  the  given  command,
user,  or  terminal.   Sample  output from _l_a_s_t_c_o_m_m is shown
below.

        % lastcomm
        sh         S     root     __         0.67 secs Tue Mar 13 12:45
        atrun            root     __         0.23 secs Tue Mar 13 12:45
        lpd         F    root     __         1.06 secs Tue Mar 13 12:44
        lpr        S     burwell  tty09      1.23 secs Tue Mar 13 12:44
        troff            burwell  tty09     12.83 secs Tue Mar 13 12:44
        eqn              burwell  tty09      1.44 secs Tue Mar 13 12:44
        df               kindred  ttyq7      0.78 secs Tue Mar 13 12:44
        ls               kindred  ttyq7      0.28 secs Tue Mar 13 12:44
        cat              kindred  ttyq7      0.05 secs Tue Mar 13 12:44
        stty             kindred  ttyq7      0.05 secs Tue Mar 13 12:44
        tbl              burwell  tty09      1.08 secs Tue Mar 13 12:44
        rlogin     S     jones    ttyp3      5.66 secs Tue Mar 13 12:38
        rlogin      F    jones    ttyp3      2.53 secs Tue Mar 13 12:41
        stty             kindred  ttyq7      0.05 secs Tue Mar 13 12:44

The first column indicates the name  of  the  command.   The
next  column displays certain flags on the command: an ``F''
means the process spawned a child process, ``S''  means  the
process  ran  with  the set-user-id bit set, ``D'' means the
process exited with a core dump, and ``X'' means the process
was  killed abnormally.  The remaining columns show the name
of the user who ran the program, the terminal he ran it from
(if  applicable), the amount of time used by the command (in
seconds), and the date and time the process started.

_3._2.  _N_E_T_W_O_R_K _S_E_C_U_R_I_T_Y

     Monitoring network security is more difficult,  because
there are so many ways for a cracker to attempt to break in.
However, there are some programs available  to  aid  you  in
this task.  These are described in this section.

_3._2._1.  _T_h_e _s_y_s_l_o_g _F_a_c_i_l_i_t_y

     The _s_y_s_l_o_g facility [Sun88a, 1773] is a mechanism  that
enables  any command to log error messages and informational
messages to the system console, as well as to  a  log  file.
Typically,   error   messages   are   logged   in  the  file
/_u_s_r/_a_d_m/_m_e_s_s_a_g_e_s along with the date,  time,  name  of  the
program sending the message, and (usually) the process id of
the program.  A sample segment of the _m_e_s_s_a_g_e_s file is shown



below.   ii .if !0 .if !0 .tl May 4, 1990 ii .if 0 .if o .tl








ii .if 0 .if e .tl

        Mar 12 14:53:37 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr
        Mar 12 15:18:08 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr
        Mar 12 16:50:25 sparkyfs login: ROOT LOGIN ttyp4 FROM pongfs.itstd.sri
        Mar 12 16:52:20 sparkyfs vmunix: sd2c:  read failed, no retries
        Mar 13 06:01:18 sparkyfs vmunix: /: file system full
        Mar 13 08:02:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst
        Mar 13 08:28:52 sparkyfs su: davy on /dev/ttyp3
        Mar 13 08:38:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst
        Mar 13 10:56:54 sparkyfs automount[154]: host aaifs not responding
        Mar 13 11:30:42 sparkyfs login: REPEATED LOGIN FAILURES ON ttyp3 FROM
                        intrepid.itstd.s, daemon

Of particular interest in this sample are the messages  from
the  _l_o_g_i_n  and  _s_u  programs.   Whenever someone logs in as
``root,'' _l_o_g_i_n logs this information.   Generally,  logging
in  as  ``root'' directly, rather than using the _s_u command,
should be discouraged, as it is hard to track  which  person
is  actually  using the account.  Once this ability has been
disabled, as described in Section 2.2.2, detecting  a  secu-
rity violation becomes a simple matter of searching the _m_e_s_-
_s_a_g_e_s file for lines of this type.

     _L_o_g_i_n also logs any case of someone  repeatedly  trying
to  log in to an account and failing.  After three attempts,
_l_o_g_i_n will refuse to let the person try anymore.   Searching
for  these  messages in the _m_e_s_s_a_g_e_s file can alert you to a
cracker attempting to guess someone's password.

     Finally, when someone uses the _s_u  command,  either  to
become  ``root''  or  someone   else, _s_u logs the success or
failure of this operation.  These messages can  be  used  to
check  for  users  sharing their passwords, as well as for a
cracker who has penetrated one  account  and  is  trying  to
penetrate others.

_3._2._2.  _T_h_e _s_h_o_w_m_o_u_n_t _C_o_m_m_a_n_d

     The _s_h_o_w_m_o_u_n_t command [Sun88a, 1764] can be used on  an
file server to display the names of all hosts that currently
have something mounted from the server.   With  no  options,
the  program  simply displays a list of all the hosts.  With
the -_a and -_d options, the output is somewhat  more  useful.
The  first option, -_a, causes _s_h_o_w_m_o_u_n_t to list all the host
and directory combinations.  For example,











iii .if !0 .if !0 .tl May 4, 1990
iii .if 0 .if o .tl
iii .if 0 .if e .tl







        bronto.itstd.sri.com:/usr/share
        bronto.itstd.sri.com:/usr/local.new
        bronto.itstd.sri.com:/usr/share/lib
        bronto.itstd.sri.com:/var/spool/mail
        cascades.itstd.sri.com:/sparky/a
        clyde.itstd.sri.com:/laser_dumps
        cm1.itstd.sri.com:/sparky/a
        coco0.itstd.sri.com:/sparky/a

There will be one line of output for each directory  mounted
by a host.  With the -_d option, _s_h_o_w_m_o_u_n_t displays a list of
all directories that are presently mounted by some host.

     The output from _s_h_o_w_m_o_u_n_t should  be  checked  for  two
things.   First,  only  machines  local to your organization
should appear there.  If you have set up proper netgroups as
described  in  Section  2.2.3, this should not be a problem.
Second, only ``normal'' directories should be  mounted.   If
you  find unusual directories being mounted, you should find
out who is mounting them and why - although it  is  probably
innocent,  it may indicate someone trying to get around your
security mechanisms.

_3._3.  _F_I_L_E _S_Y_S_T_E_M _S_E_C_U_R_I_T_Y

     Checking for security  holes  in  the  file  system  is
another  important  part of making your system secure.  Pri-
marily, you need to check for files that can be modified  by
unauthorized users, files that can inadvertently grant users
too many permissions, and files that can inadvertently grant
access  to  crackers.   It  is  also important to be able to
detect unauthorized modifications to the file system, and to
recover from these modifications when they are made.

_3._3._1.  _T_h_e _f_i_n_d _C_o_m_m_a_n_d

     The _f_i_n_d command [Sun88a, 183-185] is a general-purpose
command  for searching the file system.  Using various argu-
ments, complex matching patterns based  on  a  file's  name,
type, mode, owner, modification time, and other characteris-
tics, can be constructed.  The names of files that are found
using  these  patterns  can then be printed out, or given as
arguments to other commands.  The general format of  a  _f_i_n_d
command is

        % find _d_i_r_e_c_t_o_r_i_e_s _o_p_t_i_o_n_s

where _d_i_r_e_c_t_o_r_i_e_s is a list of  directory  names  to  search
(e.g.,  /_u_s_r),  and  _o_p_t_i_o_n_s contains the options to control
what is being searched for.  In general, for the examples in
this  section,  you will always want to search from the root
of the file system (/), in order to find all files  matching
the patterns presented.



iv .if !0 .if !0 .tl May 4, 1990 iv .if 0 .if o .tl iv .if 0








.if e .tl

     This section describes how to use _f_i_n_d  to  search  for
four  possible security problems that were described in Sec-
tion 2.

_3._3._1._1.  _F_i_n_d_i_n_g _S_e_t_u_i_d _a_n_d _S_e_t_g_i_d _F_i_l_e_s

     It is important to check the system often for unauthor-
ized  setuid  and  setgid  programs.  Because these programs
grant special privileges to the user who is executing  them,
it  is  necessary  to  ensure that insecure programs are not
installed.   Setuid  ``root''  programs  should  be  closely
guarded - a favorite trick of many crackers is to break into
``root'' once, and leave a setuid program  hidden  somewhere
that  will  enable  them to regain super-user powers even if
the original hole is plugged.

     The command to search for setuid and setgid files is

        # find / -type f -a \( -perm -4000 -o -perm -2000 \) -print

The options to this command have the following meanings:

     /    The name of the directory to be searched.  In this
          case, we want to search the entire file system, so
          we specify /.   You  might  instead  restrict  the
          search to /_u_s_r or /_h_o_m_e.

     -type f
          Only examine files whose type  is  ``f,''  regular
          file.   Other options include ``d'' for directory,
          ``l'' for  symbolic  link,  ``c''  for  character-
          special  devices, and ``b'' for block-special dev-
          ices.

     -a   This specifies ``and.''  Thus,  we  want  to  know
          about  files  whose  type is ``regular file,'' _a_n_d
          whose permissions bits match  the  other  part  of
          this expression.

     \( -perm -4000 -o -perm -2000 \)
          The parentheses in this part of  the  command  are
          used  for grouping.  Thus, everything in this part
          of the command matches a single  pattern,  and  is
          treated  as  the  other half of the ``and'' clause
          described above.

          -perm -4000
               This specifies a match if  the  ``4000''  bit
               (specified  as an octal number) is set in the
               file's permission modes.  This  is  the  set-
               user-id bit.




          v .if !0 .if !0 .tl May 4, 1990 v .if 0 .if o  .tl








          v .if 0 .if e .tl
          -o   This specifies ``or.'' Thus, we want to match
               if  the  file  has the set-user-id bit _o_r the
               set-group-id bit set.

          -perm -2000
               This specifies a match if  the  ``2000''  bit
               (specified  as an octal number) is set in the
               file's permission modes.  This  is  the  set-
               group-id bit.

     -printThis indicates that for any file that matches the
          specified  expression  (is  a regular file _a_n_d has
          the setuid _o_r setgid bits set in its permissions),
          print its name on the screen.

     After executing this command  (depending  on  how  much
disk space you have, it can take anywhere from 15 minutes to
a couple of hours to complete), you  will  have  a  list  of
files  that  have  setuid  or  setgid bits set on them.  You
should then examine each of these  programs,  and  determine
whether  they  should  actually have these permissions.  You
should be especially suspicious of programs that are _n_o_t  in
one of the directories (or a subdirectory) shown below.

        /bin
        /etc
        /usr/bin
        /usr/ucb
        /usr/etc


     One file distributed with /_u_s_r/_e_t_c/_r_e_s_t_o_r_e, is  distri-
buted  with  the  setuid  bit  set on it, and should not be,
because of a security hole.  You should be  sure  to  remove
the setuid bit from this program by executing the command

        # chmod u-s /usr/etc/restore


_3._3._1._2.  _F_i_n_d_i_n_g _W_o_r_l_d-_W_r_i_t_a_b_l_e _F_i_l_e_s

     World-writable files, particularly system files, can be
a security hole if a cracker gains access to your system and
modifies them.  Additionally, world-writable directories are
dangerous, since they allow a cracker to add or delete files
as he wishes.  The _f_i_n_d command to find  all  world-writable
files is

        # find / -perm -2 -print

In this case, we do not use the -_t_y_p_e option to restrict the
search,  since  we are interested in directories and devices
as well as files.  The -_2 specifies the world write bit  (in



octal).  vi .if !0 .if !0 .tl May 4, 1990 vi .if 0 .if o .tl








vi .if 0 .if e .tl

     This list of  files  will  be  fairly  long,  and  will
include  some  files  that  _s_h_o_u_l_d  be  world writable.  You
should not be concerned if  terminal  devices  in  /_d_e_v  are
world writable.  You should also not be concerned about line
printer error log files being world writable.  Finally, sym-
bolic  links  may  be  world writable - the permissions on a
symbolic link, although they exist, have no meaning.

_3._3._1._3.  _F_i_n_d_i_n_g _U_n_o_w_n_e_d _F_i_l_e_s

     Finding files that are owned by nonexistent  users  can
often  be  a  clue  that a cracker has gained access to your
system.  Even if this is not the case, searching  for  these
files gives you an opportunity to clean up files that should
have been deleted at the same  time  the  user  herself  was
deleted.  The command to find unowned files is

        # find / -nouser -print

The -_n_o_u_s_e_r option matches files that are owned by a user id
not  contained  in  the  /_e_t_c/_p_a_s_s_w_d  database.   A  similar
option, -_n_o_g_r_o_u_p, matches files owned by nonexistent groups.
To  find all files owned by nonexistent users _o_r groups, you
would use the -_o option as follows:

        # find / -nouser -o -nogroup -print


_3._3._1._4.  _F_i_n_d_i_n_g ._r_h_o_s_t_s _F_i_l_e_s

     As mentioned in Section 2.2.1.2, users should be prohi-
bited  from  having  ._r_h_o_s_t_s  files  in  their accounts.  To
search for this, it is only necessary to search the parts of
the file system that contain home directories (i.e., you can
skip / and /_u_s_r):

        # find /home -name .rhosts -print

The -_n_a_m_e option indicates that the  complete  name  of  any
file  whose  name  matches  ._r_h_o_s_t_s should be printed on the
screen.

_3._3._2.  _C_h_e_c_k_l_i_s_t_s

     Checklists can be a useful tool for  discovering  unau-
thorized  changes  made  to system directories.  They aren't
practical on file systems that contain  users'  home  direc-
tories  since  these  change all the time.  A checklist is a
listing of all the files contained  in  a  group  of  direc-
tories:  their sizes, owners, modification dates, and so on.
Periodically, this information  is  collected  and  compared
with the information in the master checklist.  Files that do



not vii .if !0 .if !0 .tl May 4, 1990 vii .if 0  .if  o  .tl








vii .if 0 .if e .tl match in all attributes can be suspected
of having been changed.

     There are several utilities that  implement  checklists
available  from public software sites (see Section 4).  How-
ever, a simple utility can be  constructed  using  only  the
standard _l_s and _d_i_f_f commands.

     First, use the _l_s command [Sun88a, 285] to  generate  a
master list.  This is best done immediately after installing
the operating system, but can be done at any  time  provided
you're  confident  about the correctness of the files on the
disk.  A sample command is shown below.

        # ls -aslgR /bin /etc /usr > MasterChecklist

The file _M_a_s_t_e_r_C_h_e_c_k_l_i_s_t now contains a complete list of all
the  files  in these directories.  You will probably want to
edit it and delete the lines for  files  you  know  will  be
changing   often   (e.g.,  /_e_t_c/_u_t_m_p,  /_u_s_r/_a_d_m/_a_c_c_t).   The
_M_a_s_t_e_r_C_h_e_c_k_l_i_s_t file should be stored somewhere safe where a
cracker  is  unlikely  to  find it (since he could otherwise
just change the data in it): either on a different  computer
system, or on magnetic tape.

     To search for changes in the file system, run the above
_l_s  command again, saving the output in some other file, say
_C_u_r_r_e_n_t_L_i_s_t.  Now use the _d_i_f_f command [Sun88a, 150] to com-
pare the two files:

        # diff MasterChecklist CurrentList

Lines that are only in the master checklist will be  printed
preceded  by a ``<,'' and lines that are only in the current
list will be preceded by a ``>.'' If there is one line for a
file, preceded by a ``<,'' this means that the file has been
deleted since the master checklist was created.  If there is
one  line  for  a file, preceded by a ``>,'' this means that
the file has been created since  the  master  checklist  was
created.  If there are two lines for a single file, one pre-
ceded by ``<'' and the other by ``>,'' this  indicates  that
some  attribute  of  the  file  has changed since the master
checklist was created.

     By carefully constructing the master checklist, and  by
remembering  to  update  it periodically (you can replace it
with a copy of _C_u_r_r_e_n_t_L_i_s_t, once you're sure the differences
between the lists are harmless), you can easily monitor your
system for  unauthorized  changes.   The  software  packages
available from the public software distribution sites imple-
ment basically the same scheme as the one  here,  but  offer
many  more  options  for  controlling  what  is examined and
reported.




viii .if !0 .if !0 .tl May 4, 1990 viii .if 0 .if o .tl viii








.if 0 .if e .tl
_3._3._3.  _B_a_c_k_u_p_s

     It is impossible to overemphasize the need for  a  good
backup  strategy.   File system backups not only protect you
in the even of hardware failure or accidental deletions, but
they  also  protect  you  against  unauthorized  file system
changes made by a cracker.

     A good backup strategy will dump the entire  system  at
level zero (a ``full'' dump) at least once a month.  Partial
(or ``incremental'') dumps should be done at least  twice  a
week,  and ideally they should be done daily.  The _d_u_m_p com-
mand [Sun88a, 1612-1614] is recommended over other  programs
such  as _t_a_r and _c_p_i_o.  This is because only _d_u_m_p is capable
of creating a backup that can be used to restore a  disk  to
the  exact  state  it  was in when it was dumped.  The other
programs do not take into account files deleted  or  renamed
between  dumps,  and do not handle some specialized database
files properly.

_3._4.  _K_N_O_W _Y_O_U_R _S_Y_S_T_E_M

     Aside from running large monitoring  programs  such  as
those  described  in  the previous sections, simple everyday
commands can also be useful  for  spotting  security  viola-
tions.  By running these commands often, whenever you have a
free minute (for  example,  while  waiting  for  someone  to
answer the phone), you will become used to seeing a specific
pattern of output.  By being  familiar  with  the  processes
normally  running  on your system, the times different users
typically log in, and so on,  you  can  easily  detect  when
something is out of the ordinary.

_3._4._1.  _T_h_e _p_s _C_o_m_m_a_n_d

     The _p_s command [Sun88a, 399-402] displays a list of the
processes  running on your system.  _P_s has numerous options,
too many to list here.  Generally, however, for the  purpose
of monitoring, the option string -_a_l_x_w_w is the most useful.*
On  a  Sun  system  running 4.0, you should expect to see at
least the following:

     _s_w_a_p_p_e_r, _p_a_g_e_d_a_e_m_o_n
          System programs that help the virtual memory  sys-
          tem.

     /_s_b_i_n/_i_n_i_t
          The  _i_n_i_t  process,  which  is   responsible   for
_________________________
9  * This is true for Berkeley-based systems.  On System
V  systems,  the  option string -_e_l_f should be used in-
stead.
9


          numerous ix .if !0 .if !0 .tl May 4, 1990 ix .if 0








          .if  o  .tl  ix  .if  0 .if e .tl tasks, including
          bringing up login processes on terminals.

     _p_o_r_t_m_a_p, _y_p_b_i_n_d, _y_p_s_e_r_v
          Parts of the Yellow Pages system.

     _b_i_o_d, _n_f_s_d, _r_p_c._m_o_u_n_t_d, _r_p_c._q_u_o_t_a_d, _r_p_c._l_o_c_k_d
          Parts of the Network File System If the system you
          are  looking  at  is  not  a file server, the _n_f_s_d
          processes probably won't exist.

     _r_a_r_p_d, _r_p_c._b_o_o_t_p_a_r_a_m_d
          Part of the system that allows diskless clients to
          boot.

     Other commands you should  expect  to  see  are  _u_p_d_a_t_e
(file  system  updater); _g_e_t_t_y (one per terminal and one for
the console); _l_p_d (line  printer  daemon);  _i_n_e_t_d  (Internet
daemon, for starting other network servers); _s_h and _c_s_h (the
Bourne shell and C shell, one or more per logged  in  user).
In  addition,  if there are users logged in, you'll probably
see invocations of various compilers, text editors, and word
processing programs.

_3._4._2.  _T_h_e _w_h_o _a_n_d _w _C_o_m_m_a_n_d_s

     The _w_h_o command, as mentioned previously, displays  the
list of users currently logged in on the system.  By running
this periodically, you can learn at what  times  during  the
day various users log in.  Then, when you see someone logged
in at a different time, you can investigate  and  make  sure
that it's legitimate.

     The _w command [Sun88a, 588]  is  somewhat  of  a  cross
between  _w_h_o and _p_s.  Not only does it show a list of who is
presently logged in, but it also displays how long they have
been  idle  (gone without typing anything), and what command
they are currently running.

_3._4._3.  _T_h_e _l_s _C_o_m_m_a_n_d

     Simple as its function is, _l_s is actually  very  useful
for  detecting  file  system  problems.   Periodically,  you
should use _l_s on the various  system  directories,  checking
for  files that shouldn't be there.  Most of the time, these
files will have just ``landed'' somewhere by accident.  How-
ever,  by  keeping a close watch on things, you will be able
to detect a cracker long before you might have otherwise.

     When using _l_s to check for oddities, be sure to use the
-_a option, which lists files whose names begin with a period
(.).  Be particularly alert for files or  directories  named
``...'',  or ``..(space)'', which many crackers like to use.
(Of course, remember that ``.'' and ``..'' are  supposed  to












be there.)

_3._5.  _K_E_E_P _Y_O_U_R _E_Y_E_S _O_P_E_N

     Monitoring for security breaches is every bit as impor-
tant  as  preventing  them in the first place.  Because it's
virtually impossible to make a system totally secure,  there
is  always  the  chance, no matter how small, that a cracker
will be able to gain access.  Only by monitoring can this be
detected and remedied.

_4.  _S_O_F_T_W_A_R_E _F_O_R _I_M_P_R_O_V_I_N_G _S_E_C_U_R_I_T_Y

     Because security is of great concern to many  sites,  a
wealth  of  software  has  been  developed for improving the
security  of  systems.   Much  of  this  software  has  been
developed at universities and other public institutions, and
is available free for the asking.   This  section  describes
how  this software can be obtained, and mentions some of the
more important programs available.

_4._1.  _O_B_T_A_I_N_I_N_G _F_I_X_E_S _A_N_D _N_E_W _V_E_R_S_I_O_N_S

     Several sites on the Internet  maintain  large  reposi-
tories  of  public-domain and freely distributable software,
and make this material available for anonymous This  section
describes some of the larger repositories.

_4._1._1.  _S_u_n _F_i_x_e_s _o_n _U_U_N_E_T

     Sun Microsystems  has  contracted  with  Communications
Services, Inc. to make fixes for bugs in Sun software avail-
able via anonymous You can access these fixes by  using  the
_f_t_p  command  [Sun88a,  195-201]  to  connect  to  the  host
_f_t_p._u_u._n_e_t.  Then change into the directory  _s_u_n-_f_i_x_e_s,  and
obtain  a  directory listing, as shown in the example on the
following page.






























% ftp ftp.uu.net
Connected to uunet.UU.NET.
220 uunet FTP server (Version 5.93 Tue Mar 20 11:01:52 EST 1990) ready.
Name (ftp.uu.net:davy): anonymous
331 Guest login ok, send ident as password.
Password:               _e_n_t_e_r _y_o_u_r _m_a_i_l _a_d_d_r_e_s_s _y_o_u_r_n_a_m_e@_y_o_u_r_h_o_s_t _h_e_r_e
230 Guest login ok, access restrictions apply.
ftp> cd sun-fixes
_2_5_0 _C_W_D _c_o_m_m_a_n_d _s_u_c_c_e_s_s_f_u_l.
_f_t_p> _d_i_r
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 2258
-rw-r--r--  1 38       22           4558 Aug 31  1989 README
-rw-r--r--  1 38       22         484687 Dec 14  1988 ddn.tar.Z
-rw-r--r--  1 38       22         140124 Jan 13  1989 gated.sun3.Z
-rwxr-xr-x  1 38       22          22646 Dec 14  1988 in.ftpd.sun3.Z
.....
.....
-rw-r--r--  1 38       22          72119 Aug 31  1989 sendmail.sun3.Z
-rwxr-xr-x  1 38       22          99147 Aug 31  1989 sendmail.sun4.Z
-rw-r--r--  1 38       22           3673 Jul 11  1989 wall.sun3.Z
-rw-r--r--  1 38       22           4099 Jul 11  1989 wall.sun4.Z
-rwxr-xr-x  1 38       22           7955 Jan 18  1989 ypbind.sun3.Z
-rwxr-xr-x  1 38       22           9237 Jan 18  1989 ypbind.sun4.Z
226 Transfer complete.
1694 bytes received in 0.39 seconds (4.2 Kbytes/s)
ftp> quit
_2_2_1 _G_o_o_d_b_y_e.
%

The file _R_E_A_D_M_E contains a brief description  of  what  each
file  in  this  directory  contains, and what is required to
install the fix.

_4._1._2.  _B_e_r_k_e_l_e_y _F_i_x_e_s

     The University of California  at  Berkeley  also  makes
fixes  available via anonymous these fixes pertain primarily
to the current release of (currently release 4.3).  However,
even  if you are not running their software, these fixes are
still important, since many vendors (Sun,  Sequent  ,  etc.)
base their software on the Berkeley releases.

     The Berkeley fixes are available for anonymous from the
host  _u_c_b_a_r_p_a._b_e_r_k_e_l_e_y._e_d_u  in  the directory _4._3/_u_c_b-_f_i_x_e_s.
The file _I_N_D_E_X in this directory describes  what  each  file
contains.

     Berkeley also distributes new versions of _s_e_n_d_m_a_i_l  and
_n_a_m_e_d [Sun88a, 1758-1760, 1691-1692] from this machine.  New
versions of these commands are stored in the _4._3  directory,
usually   in   the   files  _s_e_n_d_m_a_i_l._t_a_r._Z  and  _b_i_n_d._t_a_r._Z,












respectively.

_4._1._3.  _S_i_m_t_e_l-_2_0 _a_n_d _U_U_N_E_T

     The two largest general-purpose  software  repositories
on  the  Internet  are  the hosts _w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l and
_f_t_p._u_u._n_e_t.

     _w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l is a machine operated by the  U.
S.  Army  at  White  Sands  Missile  Range, New Mexico.  The
directory _p_d_2:<_u_n_i_x-_c> contains a large amount of  software,
primarily  taken from the _c_o_m_p._s_o_u_r_c_e_s newsgroups.  The file
_0_0_0-_m_a_s_t_e_r-_i_n_d_e_x._t_x_t contains a master list and  description
of  each piece of software available in the repository.  The
file _0_0_0-_i_n_t_r_o-_u_n_i_x-_s_w._t_x_t contains information on the mail-
ing  list  used  to announce new software, and describes the
procedures used for transferring files from the archive with

     _f_t_p._u_u._n_e_t is operated by Communications Services, Inc.
in  Falls Church, Virginia.  This company sells Internet and
access to sites all over the country (and  internationally).
The  software  posted  to the following source newsgroups is
stored here, in directories of the same name:

        comp.sources.games
        comp.sources.misc
        comp.sources.sun
        comp.sources.unix
        comp.sources.x

Numerous other distributions, such as all the freely distri-
butable  Berkeley source code, Internet Request for Comments
and so on are also stored on this machine.

_4._1._4.  _V_e_n_d_o_r_s

     Many vendors make fixes  for  bugs  in  their  software
available  electronically,  either  via mailing lists or via
anonymous You should contact your vendor to find out if they
offer  this service, and if so, how to access it.  Some ven-
dors that offer these services include Sun Microsystems (see
above),  Digital Equipment Corp., the University of Califor-
nia at Berkeley (see above), and Apple Computer.

_4._2.  _T_H_E _N_P_A_S_S_W_D _C_O_M_M_A_N_D

     The _n_p_a_s_s_w_d command, developed by Clyde Hoover  at  the
University  of Texas at Austin, is intended to be a replace-
ment for the standard _p_a_s_s_w_d command [Sun88a, 379], as  well
as  the  Sun  _y_p_p_a_s_s_w_d command [Sun88a, 611].  _n_p_a_s_s_w_d makes
passwords more secure by refusing to allow users  to  select
insecure passwords.  The following capabilities are provided
by _n_p_a_s_s_w_d:













     o+    Configurable minimum password length

     o+    Configurable to force users to use mixed  case  or
          digits and punctuation

     o+    Checking  for  ``simple''  passwords  such  as   a
          repeated letter

     o+    Checking against the host  name  and  other  host-
          specific information

     o+    Checking against the login name,  first  and  last
          names, and so on

     o+    Checking  for  words  in   various   dictionaries,
          including the system dictionary.

     The _n_p_a_s_s_w_d distribution  is  available  for  anonymous
from _e_m_x._u_t_e_x_a_s._e_d_u in the directory _p_u_b/_n_p_a_s_s_w_d.

_4._3.  _T_H_E _C_O_P_S _P_A_C_K_A_G_E

     COPS is a security tool for system administrators  that
checks  for  numerous  common  security problems on systems,
including many of the things described in this document.  is
a collection of shell scripts and C programs that can easily
be run on almost any variant.  Among other things, it checks
the  following  items  and  sends  the results to the system
administrator:

     o+    Checks  /_d_e_v/_k_m_e_m  and  other  devices  for  world
          read/writability.

     o+    Checks special/important files and directories for
          ``bad'' modes (world writable, etc.).

     o+    Checks for easily guessed passwords.

     o+    Checks for duplicate user ids, invalid  fields  in
          the password file, etc.

     o+    Checks for duplicate group ids, invalid fields  in
          the group file, etc.

     o+    Checks  all  users'  home  directories  and  their
          ._c_s_h_r_c,  ._l_o_g_i_n,  ._p_r_o_f_i_l_e,  and ._r_h_o_s_t_s files for
          security problems.

     o+    Checks all commands in the /_e_t_c/_r_c files  [Sun88a,
          1724-1725]  and _c_r_o_n files [Sun88a, 1606-1607] for
          world writability.

     o+    Checks  for  bad  ``root''  paths,   file   system
          exported to the world, etc.












     o+    Includes an expert system that checks to see if  a
          given  user (usually ``root'') can be compromised,
          given that certain rules are true.

     o+    Checks for _c_h_a_n_g_e_s in the setuid  status  of  pro-
          grams on the system.

     The package is  available  from  the  _c_o_m_p._s_o_u_r_c_e_s._u_n_i_x
archive  on  _f_t_p._u_u._n_e_t,  and  also  from  the repository on
_w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l.

_4._4.  _S_U_N _C_2 _S_E_C_U_R_I_T_Y _F_E_A_T_U_R_E_S

     With the release of  4.0,  Sun  has  included  security
features  that allow the system to operate at a higher level
of security, patterned after the C2* classification.   These
features can be installed as one of the options when instal-
ling the system from the distribution tapes.   The  security
features added by this option include

     o+    Audit trails that  record  all  login  and  logout
          times,  the  execution of administrative commands,
          and the execution of  privileged  (setuid)  opera-
          tions.

     o+    A more secure password  file  mechanism  (``shadow
          password   file'')  that  prevents  crackers  from
          obtaining a list of the encrypted passwords.

     o+    encryption capability.

     o+    A (more) secure implementation that  uses  public-
          key  encryption  to  authenticate the users of the
          system and the hosts on the network,  to  be  sure
          they really are who they claim to be.

These security features are described in detail in [Sun88c].

_4._5.  _K_E_R_B_E_R_O_S

     Kerberos [Stei88] is an authentication system developed
by  the  Athena  Project  at  the Massachusetts Institute of
Technology.  Kerberos is a third-party  authentication  ser-
vice,  which  is  trusted by other network services.  When a
user logs in, Kerberos  authenticates  that  user  (using  a
password),  and  provides  the  user with a way to prove her
identity to other servers and  hosts  scattered  around  the
network.
9_________________________
9  * C2 is one of several security  classifications  de-
fined  by the National Computer Security Center, and is
described in [NCSC85], the ``orange book.''













     This authentication is then used by  programs  such  as
_r_l_o_g_i_n  [Sun88a,  418-419]  to  allow  the user to log in to
other hosts without a password  (in  place  of  the  ._r_h_o_s_t_s
file).   The  authentication is also used by the mail system
in order to guarantee that mail is delivered to the  correct
person,  as  well  as to guarantee that the sender is who he
claims to be.  has also been modified by M.I.T. to work with
Kerberos, thereby making the system much more secure.

     The overall  effect  of  installing  Kerberos  and  the
numerous  other  programs  that  go  with it is to virtually
eliminate the ability of users to ``spoof'' the system  into
believing  they are someone else.  Unfortunately, installing
Kerberos is very intrusive, requiring  the  modification  or
replacement of numerous standard programs.  For this reason,
a source license is usually necessary.  There are  plans  to
make  Kerberos  a  part  of  4.4BSD,  to  be released by the
University of California at Berkeley sometime in 1990.

_5.  _K_E_E_P_I_N_G _A_B_R_E_A_S_T _O_F _T_H_E _B_U_G_S

     One of the hardest things about keeping a system secure
is  finding  out  about  the security holes before a cracker
does.  To combat this, there are several sources of informa-
tion you can and should make use of on a regular basis.

_5._1.  _T_H_E _C_O_M_P_U_T_E_R _E_M_E_R_G_E_N_C_Y _R_E_S_P_O_N_S_E _T_E_A_M

     The Computer Emergency Response Team (CERT)  was  esta-
blished  in  December  1988 by the Defense Advanced Research
Projects Agency to address  computer  security  concerns  of
research  users  of  the  Internet.   It  is operated by the
Software Engineering Institute  at  Carnegie-Mellon  Univer-
sity.   The  serves  as  a  focal point for the reporting of
security  violations,  and  the  dissemination  of  security
advisories to the Internet community.  In addition, the team
works with vendors of various systems in order to coordinate
the fixes for security problems.

     The sends out security advisories to the  _c_e_r_t-_a_d_v_i_s_o_r_y
mailing  list whenever appropriate.  They also operate a 24-
hour hotline that can be called to report security  problems
(e.g.,  someone  breaking  into  your system), as well as to
obtain current  (and  accurate)  information  about  rumored
security problems.

     To join the _c_e_r_t-_a_d_v_i_s_o_r_y mailing list, send a  message
to  _c_e_r_t@_c_e_r_t._s_e_i._c_m_u._e_d_u and ask to be added to the mailing
list.  Past advisories are available for anonymous from  the
host  _c_e_r_t._s_e_i._c_m_u._e_d_u.  The 24-hour hotline number is (412)
268-7090.















_5._2.  _D_D_N _M_A_N_A_G_E_M_E_N_T _B_U_L_L_E_T_I_N_S

     The _D_D_N _M_a_n_a_g_e_m_e_n_t _B_u_l_l_e_t_i_n is  distributed  electroni-
cally by the Defense Data Network Network Information Center
under contract to the Defense Communications Agency.  It  is
a  means  of  communicating official policy, procedures, and
other information of  concern  to  management  personnel  at
facilities.

     The _D_D_N _S_e_c_u_r_i_t_y _B_u_l_l_e_t_i_n is distributed electronically
by  the  (Security Coordination Center), also under contract
to as a means of communicating information  on  network  and
host security exposures, fixes, and concerns to security and
management personnel at facilities.

     Anyone may join the mailing lists for  these  two  bul-
letins by sending a message to _n_i_c@_n_i_c._d_d_n._m_i_l and asking to
be placed on the mailing lists.

_5._3.  _S_E_C_U_R_I_T_Y-_R_E_L_A_T_E_D _M_A_I_L_I_N_G _L_I_S_T_S

     There are several other mailing lists operated  on  the
Internet  that  pertain  directly  or  indirectly to various
security issues.  Some of the more useful ones are described
below.

_5._3._1.  _S_e_c_u_r_i_t_y

     The Security  mailing  list  exists  to  notify  system
administrators  of security problems _b_e_f_o_r_e they become com-
mon knowledge, and to provide security enhancement  informa-
tion.   It  is a restricted-access list, open only to people
who can be verified as being principal systems people  at  a
site.   Requests to join the list must be sent by either the
site contact listed  in  the  Network  Information  Center's
database,  or  from the ``root'' account on one of the major
site machines.  You must include the destination address you
want on the list, an indication of whether you want to be on
the mail reflector list or receive weekly digests, the elec-
tronic  mail  address and voice telephone number of the site
contact if it isn't you, and the name,  address,  and  tele-
phone  number of your organization.  This information should
be sent to _s_e_c_u_r_i_t_y-_r_e_q_u_e_s_t@_c_p_d._c_o_m.

_5._3._2.  _R_I_S_K_S

     The digest is a component of the Committee on Computers
and  Public  Policy, moderated by Peter G. Neumann.  It is a
discussion forum on risks to the  public  in  computers  and
related systems, and along with discussing computer security
and privacy issues, has discussed such subjects as the Stark
incident,  the  shooting down of the Iranian airliner in the
Persian Gulf (as it relates to the computerized weapons sys-
tems), problems in air and railroad traffic control systems,












software engineering, and so on.  To join the mailing  list,
send  a  message to _r_i_s_k_s-_r_e_q_u_e_s_t@_c_s_l._s_r_i._c_o_m.  This list is
also available in the newsgroup _c_o_m_p._r_i_s_k_s.

_5._3._3.  _T_C_P-_I_P

     The list is intended to act as a discussion  forum  for
developers  and maintainers of implementations of the proto-
col suite.  It also discusses network-related security prob-
lems  when they involve programs providing network services,
such as _s_e_n_d_m_a_i_l.  To join the list, send a message to  _t_c_p-
_i_p-_r_e_q_u_e_s_t@_n_i_c._d_d_n._m_i_l.   This list is also available in the
newsgroup _c_o_m_p._p_r_o_t_o_c_o_l_s._t_c_p-_i_p.

_5._3._4.  _S_U_N-_S_P_O_T_S, _S_U_N-_N_E_T_S, _S_U_N-_M_A_N_A_G_E_R_S

     The and lists are all discussion groups for  users  and
administrators  of systems supplied by Sun Microsystems.  is
a fairly general list, discussing everything  from  hardware
configurations  to  simple  questions.  To subscribe, send a
message to _s_u_n-_s_p_o_t_s-_r_e_q_u_e_s_t@_r_i_c_e._e_d_u.  This  list  is  also
available in the newsgroup _c_o_m_p._s_y_s._s_u_n.

     is a discussion list for items pertaining to networking
on Sun systems.  Much of the discussion is related to Yellow
Pages, and name servers.  To subscribe, send  a  message  to
_s_u_n-_n_e_t_s-_r_e_q_u_e_s_t@_u_m_i_a_c_s._u_m_d._e_d_u.

     is a discussion list for Sun system administrators  and
covers  all  aspects  of Sun system administration.  To sub-
scribe, send a message to _s_u_n-_m_a_n_a_g_e_r_s-_r_e_q_u_e_s_t@_e_e_c_s._n_w_u._e_d_u.

_5._3._5.  _V_I_R_U_S-_L

     The list is a forum  for  the  discussion  of  computer
virus  experiences, protection software, and related topics.
The list is open to the public, and is implemented as a mail
reflector, not a digest.  Most of the information is related
to personal computers, although some of it may be applicable
to larger systems.  To subscribe, send the line

        SUB VIRUS-L _y_o_u_r _f_u_l_l _n_a_m_e

to the address _l_i_s_t_s_e_r_v%_l_e_h_i_i_b_m_1._b_i_t_n_e_t@_m_i_t_v_m_a._m_i_t._e_d_u.

_6.  _S_U_G_G_E_S_T_E_D _R_E_A_D_I_N_G

     This section suggests some alternate sources of  infor-
mation  pertaining to the security and administration of the
operating system.

_U_N_I_X _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n _H_a_n_d_b_o_o_k
Evi Nemeth, Garth Snyder, Scott Seebass
Prentice Hall, 1989, $26.95












     This is perhaps the best general-purpose book on system
     administration  currently  on  the  market.   It covers
     Berkeley and System V.  The 26 chapters and  17  appen-
     dices  cover  numerous  topics,  including  booting and
     shutting down the system, the file system,  configuring
     the  kernel,  adding  a disk, the line printer spooling
     system, Berkeley networking, _s_e_n_d_m_a_i_l,  and  _u_u_c_p.   Of
     particular  interest are the chapters on running as the
     super-user, backups, and security.

_U_N_I_X _O_p_e_r_a_t_i_n_g _S_y_s_t_e_m _S_e_c_u_r_i_t_y
F. T. Grammp and R. H. Morris
AT&T Bell Laboratories Technical Journal
October 1984

     This is an excellent discussion of  some  of  the  more
     common  security  problems  in  and  how to avoid them,
     written by two of Bell Labs'  most  prominent  security
     experts.

_P_a_s_s_w_o_r_d _S_e_c_u_r_i_t_y: _A _C_a_s_e _H_i_s_t_o_r_y
Robert Morris and Ken Thompson
Communications of the ACM
November 1979

     An excellent discussion  on  the  problem  of  password
     security,  and some interesting information on how easy
     it is to crack passwords and  why.   This  document  is
     usually reprinted in most vendors' documentation.

_O_n _t_h_e _S_e_c_u_r_i_t_y _o_f _U_N_I_X
Dennis M. Ritchie
May 1975

     A discussion on security from one of the original crea-
     tors of the system.  This document is usually reprinted
     in most vendors' documentation.

_T_h_e _C_u_c_k_o_o'_s _E_g_g
Clifford Stoll
Doubleday, 1989, $19.95

     An excellent story of Stoll's experiences tracking down
     the  German crackers who were breaking into his systems
     and selling the data they found to  the  Written  at  a
     level that nontechnical users can easily understand.

_S_y_s_t_e_m _a_n_d _N_e_t_w_o_r_k _A_d_m_i_n_i_s_t_r_a_t_i_o_n
Sun Microsystems
May, 1988

     Part of the  documentation,  this  manual  covers  most
     aspects  of  Sun system administration, including secu-
     rity issues.  A must for anyone operating a Sun system,












     and a pretty good reference for other systems as well.

_S_e_c_u_r_i_t_y _P_r_o_b_l_e_m_s _i_n _t_h_e _T_C_P/_I_P _P_r_o_t_o_c_o_l _S_u_i_t_e
S. M. Bellovin
ACM Computer Communications Review
April, 1989

     An interesting discussion of some of the security prob-
     lems  with  the  protocols  in  use on the Internet and
     elsewhere.  Most of these problems are far  beyond  the
     capabilities  of  the  average cracker, but it is still
     important to be aware of them.  This article is techni-
     cal  in nature, and assumes familiarity with the proto-
     cols.

_A _W_e_a_k_n_e_s_s _i_n _t_h_e _4._2_B_S_D _U_N_I_X _T_C_P/_I_P _S_o_f_t_w_a_r_e
Robert T. Morris
AT&T Bell Labs Computer Science Technical Report 117
February, 1985

     An interesting article from the author of the  Internet
     worm, which describes a method that allows remote hosts
     to ``spoof'' a host into believing  they  are  trusted.
     Again, this article is technical in nature, and assumes
     familiarity with the protocols.

_C_o_m_p_u_t_e_r _V_i_r_u_s_e_s _a_n_d _R_e_l_a_t_e_d _T_h_r_e_a_t_s: _A _M_a_n_a_g_e_m_e_n_t _G_u_i_d_e
John P. Wack and Lisa J. Carnahan
National Institute of Standards and Technology
Special Publication 500-166

     This document provides a good introduction to  viruses,
     worms,  trojan horses, and so on, and explains how they
     work and how they are used to attack computer  systems.
     Written  for  the  nontechnical  user,  this  is a good
     starting point for learning about these security  prob-
     lems.   This document can be ordered for $2.50 from the
     U. S. Government Printing Office, document number  003-
     003-02955-6.

_7.  _C_O_N_C_L_U_S_I_O_N_S

     Computer security is playing an increasingly  important
role  in our lives as more and more operations become compu-
terized, and as computer networks  become  more  widespread.
In order to protect your systems from snooping and vandalism
by unauthorized crackers, it  is  necessary  to  enable  the
numerous security features provided by the system.

     In this document, we have covered the major areas  that
can be made more secure:

     o+    Account security













     o+    Network security

     o+    File system security.

Additionally, we have discussed how to monitor for  security
violations,  where  to  obtain security-related software and
bug fixes, and numerous mailing lists for finding out  about
security problems that have been discovered.

     Many crackers  are  not  interested  in  breaking  into
specific systems, but rather will break into any system that
is vulnerable to the attacks they know.   Eliminating  these
well-known  holes  and monitoring the system for other secu-
rity problems will usually serve as adequate defense against
all  but  the  most  determined crackers.  By using the pro-
cedures and sources described in this document, you _c_a_n make
your system more secure.



















































































































_R_E_F_E_R_E_N_C_E_S

[Eich89]  Eichin, Mark W., and Jon A. Rochlis.  _W_i_t_h  _M_i_c_r_o_-
          _s_c_o_p_e  _a_n_d  _T_w_e_e_z_e_r_s:  _A_n _A_n_a_l_y_s_i_s _o_f _t_h_e _I_n_t_e_r_n_e_t
          _V_i_r_u_s _o_f _N_o_v_e_m_b_e_r _1_9_8_8.   Massachusetts  Institute
          of Technology.  February 1989.

[Elme88]  Elmer-DeWitt, Philip.  `` `The Kid Put Us  Out  of
          Action.' '' _T_i_m_e, 132 (20): 76, November 14, 1988.

[Gram84]  Grammp, F. T., and R. H. Morris.  ``UNIX Operating
          System  Security.'' _A_T&_T _B_e_l_l _L_a_b_o_r_a_t_o_r_i_e_s _T_e_c_h_n_i_-
          _c_a_l _J_o_u_r_n_a_l, 63 (8): 1649-1672, October 1984.

[Hind83]  Hinden, R., J. Haverty, and  A.  Sheltzer.   ``The
          Internet:  Interconnecting  Heterogeneous Computer
          Networks with Gateways.'' _I_E_E_E _C_o_m_p_u_t_e_r  _M_a_g_a_z_i_n_e,
          16 (9): 33-48, September 1983.

[McLe87]  McLellan,  Vin.   Hackers:  There's  More  to  the
          Story.'' _D_i_g_i_t_a_l _R_e_v_i_e_w, November 23, 1987, p. 80.

[Morr78]  Morris,  Robert,  and  Ken  Thompson.   ``Password
          Security:  A Case History.'' _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e
          _A_C_M, 22 (11): 594-597, November  1979.   Reprinted
          in  _U_N_I_X  _S_y_s_t_e_m  _M_a_n_a_g_e_r'_s  _M_a_n_u_a_l,  4.3 Berkeley
          Software Distribution.  University of  California,
          Berkeley.  April 1986.

[NCSC85]  National Computer Security Center.  _D_e_p_a_r_t_m_e_n_t  _o_f
          _D_e_f_e_n_s_e  _T_r_u_s_t_e_d  _C_o_m_p_u_t_e_r  _S_y_s_t_e_m _E_v_a_l_u_a_t_i_o_n _C_r_i_-
          _t_e_r_i_a,  Department   of   Defense   Standard   DOD
          5200.28-STD, December, 1985.

[Quar86]  Quarterman, J. S., and J. C.  Hoskins.   ``Notable
          Computer Networks.'' _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, 29
          (10): 932-971, October 1986.

[Reed84]  Reeds, J. A., and P. J. Weinberger.  ``File  Secu-
          rity  and  the  UNIX  System Crypt Command.'' _A_T&_T
          _B_e_l_l  _L_a_b_o_r_a_t_o_r_i_e_s  _T_e_c_h_n_i_c_a_l  _J_o_u_r_n_a_l,  63   (8):
          1673-1683, October 1984.

[Risk87]  _F_o_r_u_m _o_n _R_i_s_k_s _t_o  _t_h_e  _P_u_b_l_i_c  _i_n  _C_o_m_p_u_t_e_r_s  _a_n_d
          _R_e_l_a_t_e_d  _S_y_s_t_e_m_s.  Committee on Computers and Pub-
          lic Policy, Peter G. Neumann, Moderator.  Internet
          mailing list.  Issue 5.73, December 13, 1987.

[Risk88]  _F_o_r_u_m _o_n _R_i_s_k_s _t_o  _t_h_e  _P_u_b_l_i_c  _i_n  _C_o_m_p_u_t_e_r_s  _a_n_d
          _R_e_l_a_t_e_d  _S_y_s_t_e_m_s.  Committee on Computers and Pub-
          lic Policy, Peter G. Neumann, Moderator.  Internet
          mailing list.  Issue 7.85, December 1, 1988.

[Risk89a] _F_o_r_u_m _o_n _R_i_s_k_s _t_o  _t_h_e  _P_u_b_l_i_c  _i_n  _C_o_m_p_u_t_e_r_s  _a_n_d












          _R_e_l_a_t_e_d  _S_y_s_t_e_m_s.  Committee on Computers and Pub-
          lic Policy, Peter G. Neumann, Moderator.  Internet
          mailing list.  Issue 8.2, January 4, 1989.

[Risk89b] _F_o_r_u_m _o_n _R_i_s_k_s _t_o  _t_h_e  _P_u_b_l_i_c  _i_n  _C_o_m_p_u_t_e_r_s  _a_n_d
          _R_e_l_a_t_e_d  _S_y_s_t_e_m_s.  Committee on Computers and Pub-
          lic Policy, Peter G. Neumann, Moderator.  Internet
          mailing list.  Issue 8.9, January 17, 1989.

[Risk90]  _F_o_r_u_m _o_n _R_i_s_k_s _t_o  _t_h_e  _P_u_b_l_i_c  _i_n  _C_o_m_p_u_t_e_r_s  _a_n_d
          _R_e_l_a_t_e_d  _S_y_s_t_e_m_s.  Committee on Computers and Pub-
          lic Policy, Peter G. Neumann, Moderator.  Internet
          mailing list.  Issue 9.69, February 20, 1990.

[Ritc75]  Ritchie, Dennis M.  ``On the Security  of  UNIX.''
          May  1975.   Reprinted  in  _U_N_I_X  _S_y_s_t_e_m _M_a_n_a_g_e_r'_s
          _M_a_n_u_a_l,  4.3   Berkeley   Software   Distribution.
          University of California, Berkeley.  April 1986.

[Schu90]  Schuman,  Evan.   ``Bid  to  Unhook  Worm.''  _U_N_I_X
          _T_o_d_a_y!, February 5, 1990, p. 1.

[Seel88]  Seeley, Donn.  _A _T_o_u_r _o_f _t_h_e _W_o_r_m.  Department  of
          Computer  Science,  University  of Utah.  December
          1988.

[Spaf88]  Spafford, Eugene H.  _T_h_e _I_n_t_e_r_n_e_t _W_o_r_m _P_r_o_g_r_a_m: _A_n
          _A_n_a_l_y_s_i_s.  Technical Report Department of Computer
          Science, Purdue University.  November 1988.

[Stee88]  Steele, Guy L. Jr., Donald R.  Woods,  Raphael  A.
          Finkel,  Mark R. Crispin, Richard M. Stallman, and
          Geoffrey S. Goodfellow.  _T_h_e _H_a_c_k_e_r'_s  _D_i_c_t_i_o_n_a_r_y.
          New York: Harper and Row, 1988.

[Stei88]  Stein, Jennifer G., Clifford Neuman,  and  Jeffrey
          L.  Schiller.   ``Kerberos: An Authentication Ser-
          vice for Open Network Systems.'' _U_S_E_N_I_X _C_o_n_f_e_r_e_n_c_e
          _P_r_o_c_e_e_d_i_n_g_s,  Dallas, Texas, Winter 1988, pp. 203-
          211.

[Stol88]  Stoll, Clifford.  ``Stalking  the  Wily  Hacker.''
          _C_o_m_m_u_n_i_c_a_t_i_o_n_s  _o_f  _t_h_e  _A_C_M, 31 (5): 484-497, May
          1988.

[Stol89]  Stoll, Clifford.  _T_h_e  _C_u_c_k_o_o'_s  _E_g_g.   New  York:
          Doubleday, 1989.

[Sun88a]  Sun Microsystems.  _S_u_n_O_S  _R_e_f_e_r_e_n_c_e  _M_a_n_u_a_l,  Part
          Number 800-1751-10, May 1988.

[Sun88b]  Sun Microsystems.  _S_y_s_t_e_m _a_n_d _N_e_t_w_o_r_k  _A_d_m_i_n_i_s_t_r_a_-
          _t_i_o_n, Part Number 800-1733-10, May 1988.













[Sun88c]  Sun Microsystems.  _S_e_c_u_r_i_t_y _F_e_a_t_u_r_e_s  _G_u_i_d_e,  Part
          Number 800-1735-10, May 1988.

[Sun88d]  Sun Microsystems.  ``Network File System:  Version
          2  Protocol  Specification.'' _N_e_t_w_o_r_k _P_r_o_g_r_a_m_m_i_n_g,
          Part Number 800-1779-10, May 1988, pp. 165-185.






























































































































_A_P_P_E_N_D_I_X _A - _S_E_C_U_R_I_T_Y _C_H_E_C_K_L_I_S_T

     This checklist summarizes the information presented  in
this  paper,  and can be used to verify that you have imple-
mented everything described.



_A_c_c_o_u_n_t _S_e_c_u_r_i_t_y
     []        Password policy developed and distributed to all users
     []        All passwords checked against obvious choices
     []        Expiration dates on all accounts
     []        No ``idle'' guest accounts
     []        All accounts have passwords or ``*'' in the password field
     []        No group accounts
     []        ``+'' lines in _p_a_s_s_w_d and _g_r_o_u_p checked if running Yellow Pages

_N_e_t_w_o_r_k _S_e_c_u_r_i_t_y
     []        _h_o_s_t_s._e_q_u_i_v contains only local hosts, and no ``+''
     []        No ._r_h_o_s_t_s files in users' home directories
     []        Only local hosts in ``root'' ._r_h_o_s_t_s file, if any
     []        Only ``console'' labeled as ``secure'' in _t_t_y_t_a_b (servers only)
     []        No terminals labeled as ``secure'' in _t_t_y_t_a_b (clients only)
     []        No NFS file systems exported to the world
     []        _f_t_p_d version later than December, 1988
     []        No ``decode'' alias in the aliases file
     []        No ``wizard'' password in _s_e_n_d_m_a_i_l._c_f
     []        No ``debug'' command in _s_e_n_d_m_a_i_l
     []        _f_i_n_g_e_r_d version later than November 5, 1988
     []        Modems and terminal servers handle hangups correctly

_F_i_l_e _S_y_s_t_e_m _S_e_c_u_r_i_t_y
     []        No setuid or setgid shell scripts
     []        Check all ``nonstandard'' setuid and setgid programs for security
     []        Setuid bit removed from /_u_s_r/_e_t_c/_r_e_s_t_o_r_e
     []        Sticky bits set on world-writable directories
     []        Proper umask value on ``root'' account
     []        Proper modes on devices in /_d_e_v

_B_a_c_k_u_p_s
     []        Level 0 dumps at least monthly
     []        Incremental dumps at least bi-weekly






















































































Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa11707;
          9 May 90 17:40 EDT
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA18964; Wed, 9 May 90 17:14:40 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA16701; Wed, 9 May 90 17:14:43 -0400
Resent-Message-Id: <9005092114.AA16701@taos.cert.sei.cmu.edu>;
Message-Id: <9005092114.AA16701@taos.cert.sei.cmu.edu>;
Date: 9 May 90 12:38:00 EDT
From: "zmudzinski, thomas" <zmudzinskit@imo-uvax.dca.mil>;
Subject: Reference Material
To: ssphwg <ssphwg@cert.sei.cmu.edu>;
Resent-To: ssphwg@cert.sei.cmu.edu
Resent-Date: Wed, 09 May 90 17:14:41 EDT
Resent-From: "J. Paul Holbrook" <ph@cert.sei.cmu.edu>;

   D C A           I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      9-May-1990 12:36 DST
                                        From:      Thomas E. Zmudzinski 
                                                   ZMUDZINSKIT 
                                        Dept:      DISDB (B615) McLean
                                        Tel No:    (703) 285-5459

TO:  SSPHWG@CERT.SEI.CMU.EDU              ( REMOTE )


Subject: Reference Material

Our eagle-eyed librarian located something that at first scan looks to be 
a GREAT source book for the SSPHWG.  Library of Congress Cataloging Data:

    Caelli, William.
      Information security for managers/by William Caelli,
      Dennis Longley, and Micheal Shain.
      p.cm.
      Includes index.
      ISBN 0-935859-73-X:$100.00
      1.Electronic data processing departments--Security
      measures.
    2.Computers--Access control.I.Longley,Dennis.II.
    Shain, Michael.III.Title.
    HF5548.37.C34 1989
    658.4'78--dc20

It's available from Macmillan Publishers Ltd via Globe Book Services Ltd 
[ISBN 0-333-46203-3] and Stockton Press, 15 East 26th Street, NYC 10010.

Chapter Titles:
    Data Security
    Computer Security Risk Analysis and Management
    Countermeasures
    Communications Security
    Financial and Banking Networks
    Office Automation Security
    Security and the Law

Appendices:
    Security Models
    Cryptography
    Access Control
    Communications Security
    Data Protection Laws at a Glance
    List of Questions 
      [Xref'd to the page numbers of the ANSWERS!]

/z/

"Security is just a state of mind...so is insanity"           
                                                              
-------------   Disclaimer under construction   ------------- 

The above does not constitute an endorsement for any product, 
organization, or anything else that can be traced back to me. 
                              In fact, I never said this :{D 

------   End construction - Resume normal blathering   ------ 


Received: from venera.isi.edu by NRI.NRI.Reston.VA.US id aa10601;
          16 May 90 12:49 EDT
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA23402>; Wed, 16 May 90 09:45:17 -0700
Date: Wed, 16 May 90 09:46:12 PDT
From: jkrey@venera.isi.edu
Posted-Date: Wed, 16 May 90 09:46:12 PDT
Message-Id: <9005161646.AA01274@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA01274>; Wed, 16 May 90 09:46:12 PDT
To: gvaudre@NRI.Reston.VA.US
Subject: SSPHWG Minutes, CMU/SEI - Pittsburgh
Cc: craig@bbn.com, crocker@tis.com, jkrey@venera.isi.edu, ph@sei.cmu.edu, 
    ssphwg@cert.sei.cmu.edu


SSPHWG
Current Meeting Report
Reported by: Joyce K. Reynolds and J. Paul Holbrook

SSPHWG Agenda - CMU/SEI - Pittsburgh - May 1990


	Welcome SSPHWG members!

	SSPHWG Charter 


	1)  Discussion on current security policy and relationship to
            the Security Policy Working Group (SPWG).

	2)  Goals and directions of the SSPHWG (strawman proposal
            by J. Paul Holbrook)**.

	    **NOTE:  The strawman proposal is included at the end of
              this report.

	3)  Needs and requirements.

	4)  Timeframe for writing and submission for 
            publication of the handbook.

	5)  Review of plans/action items for next round of meetings.

		a)  Next meeting in Los Angeles, Tuesday, June 12th
                    at USC/Information Sciences Institute.

		b)  Next IETF meeting in August at University of
                    British Columbia.


Attendees:

Ames, Stan		SRA@MITRE.ORG
Bajzek, Tom		twb@andrew.cmu.edu
Barron, Pat		pat@transarc.com
Cady, Glee		ghc@merit.edu
Carpenter, Jeff		jjc@unix.cis.pitt.edu
Cavanaugh, John		John.Cavanaugh@StPaul.NCR.COM
Cherenson, Andrew	arc@sgi.com
Colella, Richard	colella@osi3.ncsl.nist.gov
Cox, Burtis		zk0001@wnyosi4.navy.mil
Crumb, Steve		scrumb@mot.com
Engineer, Hunaid	hunaid@opus.cray.com
Galvin, James		galvin@tis.com
Goldick, Jonathan	goldick@b.psc.edu
Hallgren, Martyne	martyne@tcgould.tn.cornell.edu
Hollingsworth, Greg	gregh@mailer.jhuapl.edu
LaQuey, Tracy		tracy@sirius.cc.utexas.edu
Martin, Marilyn		martin@CDNnet.CA
Morris, Don		morris@ucar.edu
Newman, Gerard		gkn@sds.sdsc.edu
Pepin, Marc-Andre	Pepin@crim.ca
Perrott, Marsha		mlp@andrew.cmu.edu
Pethia, Rich		RDP@CERT.SEI.CMU.EDU
Pike, Tod		tgp@sei.cmu.edu
Reilly, Michael		reilly@nsl.dec.com
Reschly, Jr., Robert	reschly@brl.mil
Seaver, Tim		tas@mcnc.org
Smith, Pat		psmith@merit.edu
Stahl, Mary		STAHL@NISC.SRI.COM
Sturtevant, Allen	STURTEVANT@ES.NET
Wood, C. Philip		cpw@lanl.gov
Yuan, Aileen		aileen@gateway.mitre.org


	SSPHWG Minutes - CMU/SEI - Pittsburgh
		April 30-May 4 1990


Needs:

	If there is a "real threat", who are the:

	- legitimate contact points

		technical 
		administrative

	Phone Calls to Site(s)  Three scenarios presented.

	You are at your site and a someone calls, stating that:
		
	1. They have a worm program, and would like		
           permission to unleash it onto your site's network.
		
	2. They are the F.B.I., and are calling with the notification
           of intrusion into your site - F.B.I. suggests to keep the
           net open to watch the intruder.

	3. He is a hacker.  The	hacker states that he has capability
	   to crack your site's	passwords, etc.

What procedures and policies should be in place so that you and your
site can deal with the above situations?

		WHO YA GONNA CALL???

		WHAT ARE THE LEGAL IMPLICATIONS??

===============================================================================

Who are the customers of our Handbook:

		-system administrators
		-site decision makers
		-site auditing the teams (?)

This Handbook will NOT be a guide on how to do:

		-risk assessment
		-contingency planning
		

This Handbook will promote and encourage people to hook into already
existing mechanisms, even if the site doesn't have security procedures
in place.  They may have emergency procedures and policies that could
be relevant.

Focus on things related to the network:

		-prevention
		-response
		-cleanup/followup

Assumptions:

		network-connected
		hosts
		network devices
			-terminal servers
			-modems

Point out "natural" conflicts that will occur.

Physical security statement in this handbook (??)

		could point out some of the risks.



- What kinds of items should be in the handbook??

- What issues should be addressed??

	List and discussion of issues:


	1) Physical Security

	2) Site Security Boundary

		- Model
			definition of terms

		- Clues on what to do when you must cross organizational 
		  boundaries:

			- defining contact points

			1) technical
			2) administrative
			3) response teams
			4) investigative

		-Invisible/Visible

			5) legal
			6) vendors (products or providers)
			7) press (policy and procedures)
			8) service providers

	3) Updates

		- Procedures
		- Tools

	4) Education of Users

	5) Historical (collection of information)
	   [collection and protection of evidence]
	   [facts versus assumption or -----]

	6) Policy issues (Privacy)

	7) System Administrator's  and Network Administrator's rights,
	   responsibilities, AND liabilities

	8) Rights and responsibilities of Users

	9) Formal and Informal legal procedures

		- local security/police
		- FBI, Secret Service, etc.
		- Verification of contact

	10) Concept of "Inter-net", "Outer-net"

		- circles of trust
		- "firewall" type concepts

	11) Procedures with working with response teams

	12) Participation in "drills" (?)

	13) "Security" of the communications lines (phones, etc.)

	14) "Insider" threats to the site

	15) Welcome banners (?)

		- is the access really authorized?
		- how do you know if you're authorized?

	16) Guidelines for acceptable use?

	17) Configuration management

		- passwords
		- bug fixes

	18) Tools

		- preventive
		- response
		- inventory of tools?

	19) Education

		- legal
		- administrators
		- users

	    (How do they deal with different kinds of 
             threats and risks?)

	20) Decision making authority

		- WHO is authorized to make what decisions?
		- WHAT authority do administrators have?
		- Layout for different cases
		    for example: call in legal investigator,
			 or remove a user
		- "License to hack"
		    MUST be authorized in advance??
		- Tiger Teams

	21) Emergency response

	22) Resources
		- other security devices
		- other books/lists/informational sources
		- form a subgroup?
			 

SSPHWG volunteers will take on the task of developing a draft outline
to be presented at the next SSPHWG meeting at USC/Information Sciences
Institute in Marina del Rey on Tuesday, June 12th.  The SSPHWG will be
also be meeting at the next IETF plenary at University of British
Columbia.

========================================================================

The following document was sent out to the SSPHWG mailing list several
days before the meeting.  Discussion of this document lead into the
other items noted in the minutes above.  There was no specific action
on this document, as it was intended mainly to make sure everyone
agreed with the general direction of the group.


GOALS AND DIRECTIONS OF THE SSPHWG -- A STRAWMAN
  by J. Paul Holbrook

THE NEED

Why is there a need for a handbook like this?  Looking at some of the
needs may help us understand what kind of product we want to produce.

As a member of the CERT, I've come in contact with many sites trying
to deal with computer security problems.  It's often a rude shock when
they discover someone has compromised their systems.  Even for sites
that have a good technical understanding of how to keep their systems
secure, there are often policy questions that they haven't addressed.
These policy issues make dealing with the incident much more
difficult.  Once the incident is over, the push to 'make sure this
doesn't happen again' can result in policy made in hast; these
policies can be more restrictive and cumbersome than they need to be.

A computer security compromise has much in common with any other
computer 'disaster' such as an equipment breakdown or a fire.  You
need to have plans in place to prevent the problem, to deal with the
problem while it's happening, and to deal with the consequences after
the fact.  Although it may seem over-dramatic to compare a security
compromise to a fire, the effect a malicious intruder could have on a
site's operations could be devastating.

Another way to look at the question of 'need' is to turn it around:
why should any site (especially an academic site) care about creating
a computer security policy and procedures?

  - There is a real threat out there.  Intruders are using common
holes to break into systems.  Sites need to understand what the
threats and risks are.

  - Policies and procedures help you maintain the environment you
want.  Many organizations value open communication and sharing.  One
security incident, and "the powers that be" could force a site into a
more closed environment.  Policies show that you are aware of the
problem and are taking steps to deal with it.

  - Policies help guide cost-effective decisions.  An academic site
may decide that the cost of dealing with an incident doesn't warrant
spending lots of time or money on defenses.  A business may make a
different decision.

  - Policies And Procedures clarify responsibility and authority.  Do
you have the authority to look at a student's files?  If so, do
students know that?


THE CUSTOMERS OF THIS WORK

Customers of what we're trying to do:

   - Systems administrators
   - Site decision makers
       - this includes administrators (in the traditional sense),
         managers, policy makers.  The people who have the 'official' word on
         what goes on at a site

Some people who are explicitly not customers:
   - Programmers
   - End users

We don't need to produce a recommended set of security policies and
procedures.  The IETF Security Policy Working Group (SPWG) is working
on that goal.  Instead, what we we will produce is a set of guidelines
and issues that policy makers will need to consider when they make
their own policies and guidelines.  This should be a tool to help
people understand the need for security procedures and policies and
how to go about creating them.  We can include suggestions where
appropriate, but much of the specifics of what a site decides to do
will depend on the local circumstances.  A university might make
different choices about security from a government research lab.


THE OUTPUT OF THE GROUP

We hope to produce a guide to the kinds of problems sites might face,
the issues they should consider, and guidelines to the kinds of steps
they can take to preventing and dealing with security problems.  This
handbook could be published as an RFC or an FYI.

Over time, this handbook might expand to become a more general
reference on site computer security.  Some of the things that might be
included:

   - suggested policies and procedures (perhaps whatever the Security
     policy WG produces)

   - bibliographies of other information to read

   - pointers to tools to help with site security





Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa10865;
          16 May 90 13:34 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA20086; Wed, 16 May 90 12:45:17 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA23402>; Wed, 16 May 90 09:45:17 -0700
Date: Wed, 16 May 90 09:46:12 PDT
From: jkrey@venera.isi.edu
Posted-Date: Wed, 16 May 90 09:46:12 PDT
Message-Id: <9005161646.AA01274@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA01274>; Wed, 16 May 90 09:46:12 PDT
To: gvaudre@NRI.Reston.VA.US
Subject: SSPHWG Minutes, CMU/SEI - Pittsburgh
Cc: craig@bbn.com, crocker@tis.com, jkrey@venera.isi.edu, ph@sei.cmu.edu, 
    ssphwg@cert.sei.cmu.edu


SSPHWG
Current Meeting Report
Reported by: Joyce K. Reynolds and J. Paul Holbrook

SSPHWG Agenda - CMU/SEI - Pittsburgh - May 1990


	Welcome SSPHWG members!

	SSPHWG Charter 


	1)  Discussion on current security policy and relationship to
            the Security Policy Working Group (SPWG).

	2)  Goals and directions of the SSPHWG (strawman proposal
            by J. Paul Holbrook)**.

	    **NOTE:  The strawman proposal is included at the end of
              this report.

	3)  Needs and requirements.

	4)  Timeframe for writing and submission for 
            publication of the handbook.

	5)  Review of plans/action items for next round of meetings.

		a)  Next meeting in Los Angeles, Tuesday, June 12th
                    at USC/Information Sciences Institute.

		b)  Next IETF meeting in August at University of
                    British Columbia.


Attendees:

Ames, Stan		SRA@MITRE.ORG
Bajzek, Tom		twb@andrew.cmu.edu
Barron, Pat		pat@transarc.com
Cady, Glee		ghc@merit.edu
Carpenter, Jeff		jjc@unix.cis.pitt.edu
Cavanaugh, John		John.Cavanaugh@StPaul.NCR.COM
Cherenson, Andrew	arc@sgi.com
Colella, Richard	colella@osi3.ncsl.nist.gov
Cox, Burtis		zk0001@wnyosi4.navy.mil
Crumb, Steve		scrumb@mot.com
Engineer, Hunaid	hunaid@opus.cray.com
Galvin, James		galvin@tis.com
Goldick, Jonathan	goldick@b.psc.edu
Hallgren, Martyne	martyne@tcgould.tn.cornell.edu
Hollingsworth, Greg	gregh@mailer.jhuapl.edu
LaQuey, Tracy		tracy@sirius.cc.utexas.edu
Martin, Marilyn		martin@CDNnet.CA
Morris, Don		morris@ucar.edu
Newman, Gerard		gkn@sds.sdsc.edu
Pepin, Marc-Andre	Pepin@crim.ca
Perrott, Marsha		mlp@andrew.cmu.edu
Pethia, Rich		RDP@CERT.SEI.CMU.EDU
Pike, Tod		tgp@sei.cmu.edu
Reilly, Michael		reilly@nsl.dec.com
Reschly, Jr., Robert	reschly@brl.mil
Seaver, Tim		tas@mcnc.org
Smith, Pat		psmith@merit.edu
Stahl, Mary		STAHL@NISC.SRI.COM
Sturtevant, Allen	STURTEVANT@ES.NET
Wood, C. Philip		cpw@lanl.gov
Yuan, Aileen		aileen@gateway.mitre.org


	SSPHWG Minutes - CMU/SEI - Pittsburgh
		April 30-May 4 1990


Needs:

	If there is a "real threat", who are the:

	- legitimate contact points

		technical 
		administrative

	Phone Calls to Site(s)  Three scenarios presented.

	You are at your site and a someone calls, stating that:
		
	1. They have a worm program, and would like		
           permission to unleash it onto your site's network.
		
	2. They are the F.B.I., and are calling with the notification
           of intrusion into your site - F.B.I. suggests to keep the
           net open to watch the intruder.

	3. He is a hacker.  The	hacker states that he has capability
	   to crack your site's	passwords, etc.

What procedures and policies should be in place so that you and your
site can deal with the above situations?

		WHO YA GONNA CALL???

		WHAT ARE THE LEGAL IMPLICATIONS??

===============================================================================

Who are the customers of our Handbook:

		-system administrators
		-site decision makers
		-site auditing the teams (?)

This Handbook will NOT be a guide on how to do:

		-risk assessment
		-contingency planning
		

This Handbook will promote and encourage people to hook into already
existing mechanisms, even if the site doesn't have security procedures
in place.  They may have emergency procedures and policies that could
be relevant.

Focus on things related to the network:

		-prevention
		-response
		-cleanup/followup

Assumptions:

		network-connected
		hosts
		network devices
			-terminal servers
			-modems

Point out "natural" conflicts that will occur.

Physical security statement in this handbook (??)

		could point out some of the risks.



- What kinds of items should be in the handbook??

- What issues should be addressed??

	List and discussion of issues:


	1) Physical Security

	2) Site Security Boundary

		- Model
			definition of terms

		- Clues on what to do when you must cross organizational 
		  boundaries:

			- defining contact points

			1) technical
			2) administrative
			3) response teams
			4) investigative

		-Invisible/Visible

			5) legal
			6) vendors (products or providers)
			7) press (policy and procedures)
			8) service providers

	3) Updates

		- Procedures
		- Tools

	4) Education of Users

	5) Historical (collection of information)
	   [collection and protection of evidence]
	   [facts versus assumption or -----]

	6) Policy issues (Privacy)

	7) System Administrator's  and Network Administrator's rights,
	   responsibilities, AND liabilities

	8) Rights and responsibilities of Users

	9) Formal and Informal legal procedures

		- local security/police
		- FBI, Secret Service, etc.
		- Verification of contact

	10) Concept of "Inter-net", "Outer-net"

		- circles of trust
		- "firewall" type concepts

	11) Procedures with working with response teams

	12) Participation in "drills" (?)

	13) "Security" of the communications lines (phones, etc.)

	14) "Insider" threats to the site

	15) Welcome banners (?)

		- is the access really authorized?
		- how do you know if you're authorized?

	16) Guidelines for acceptable use?

	17) Configuration management

		- passwords
		- bug fixes

	18) Tools

		- preventive
		- response
		- inventory of tools?

	19) Education

		- legal
		- administrators
		- users

	    (How do they deal with different kinds of 
             threats and risks?)

	20) Decision making authority

		- WHO is authorized to make what decisions?
		- WHAT authority do administrators have?
		- Layout for different cases
		    for example: call in legal investigator,
			 or remove a user
		- "License to hack"
		    MUST be authorized in advance??
		- Tiger Teams

	21) Emergency response

	22) Resources
		- other security devices
		- other books/lists/informational sources
		- form a subgroup?
			 

SSPHWG volunteers will take on the task of developing a draft outline
to be presented at the next SSPHWG meeting at USC/Information Sciences
Institute in Marina del Rey on Tuesday, June 12th.  The SSPHWG will be
also be meeting at the next IETF plenary at University of British
Columbia.

========================================================================

The following document was sent out to the SSPHWG mailing list several
days before the meeting.  Discussion of this document lead into the
other items noted in the minutes above.  There was no specific action
on this document, as it was intended mainly to make sure everyone
agreed with the general direction of the group.


GOALS AND DIRECTIONS OF THE SSPHWG -- A STRAWMAN
  by J. Paul Holbrook

THE NEED

Why is there a need for a handbook like this?  Looking at some of the
needs may help us understand what kind of product we want to produce.

As a member of the CERT, I've come in contact with many sites trying
to deal with computer security problems.  It's often a rude shock when
they discover someone has compromised their systems.  Even for sites
that have a good technical understanding of how to keep their systems
secure, there are often policy questions that they haven't addressed.
These policy issues make dealing with the incident much more
difficult.  Once the incident is over, the push to 'make sure this
doesn't happen again' can result in policy made in hast; these
policies can be more restrictive and cumbersome than they need to be.

A computer security compromise has much in common with any other
computer 'disaster' such as an equipment breakdown or a fire.  You
need to have plans in place to prevent the problem, to deal with the
problem while it's happening, and to deal with the consequences after
the fact.  Although it may seem over-dramatic to compare a security
compromise to a fire, the effect a malicious intruder could have on a
site's operations could be devastating.

Another way to look at the question of 'need' is to turn it around:
why should any site (especially an academic site) care about creating
a computer security policy and procedures?

  - There is a real threat out there.  Intruders are using common
holes to break into systems.  Sites need to understand what the
threats and risks are.

  - Policies and procedures help you maintain the environment you
want.  Many organizations value open communication and sharing.  One
security incident, and "the powers that be" could force a site into a
more closed environment.  Policies show that you are aware of the
problem and are taking steps to deal with it.

  - Policies help guide cost-effective decisions.  An academic site
may decide that the cost of dealing with an incident doesn't warrant
spending lots of time or money on defenses.  A business may make a
different decision.

  - Policies And Procedures clarify responsibility and authority.  Do
you have the authority to look at a student's files?  If so, do
students know that?


THE CUSTOMERS OF THIS WORK

Customers of what we're trying to do:

   - Systems administrators
   - Site decision makers
       - this includes administrators (in the traditional sense),
         managers, policy makers.  The people who have the 'official' word on
         what goes on at a site

Some people who are explicitly not customers:
   - Programmers
   - End users

We don't need to produce a recommended set of security policies and
procedures.  The IETF Security Policy Working Group (SPWG) is working
on that goal.  Instead, what we we will produce is a set of guidelines
and issues that policy makers will need to consider when they make
their own policies and guidelines.  This should be a tool to help
people understand the need for security procedures and policies and
how to go about creating them.  We can include suggestions where
appropriate, but much of the specifics of what a site decides to do
will depend on the local circumstances.  A university might make
different choices about security from a government research lab.


THE OUTPUT OF THE GROUP

We hope to produce a guide to the kinds of problems sites might face,
the issues they should consider, and guidelines to the kinds of steps
they can take to preventing and dealing with security problems.  This
handbook could be published as an RFC or an FYI.

Over time, this handbook might expand to become a more general
reference on site computer security.  Some of the things that might be
included:

   - suggested policies and procedures (perhaps whatever the Security
     policy WG produces)

   - bibliographies of other information to read

   - pointers to tools to help with site security





Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa29389;
          21 May 90 14:34 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA00817; Mon, 21 May 90 13:36:37 -0400
Posted-Date: Mon, 21 May 90 10:36:22 PDT
Message-Id: <9005211736.AA03568@venera.isi.edu>;
Received: from LOCALHOST by venera.isi.edu (5.61/5.61+local)
	id <AA03568>; Mon, 21 May 90 10:36:26 -0700
To: ssphwg@cert.sei.cmu.edu
Subject: RSVP - next SSPHWG mtg., June 12th
Cc: jkrey@venera.isi.edu, ph@sei.cmu.edu
Reply-To: jkrey@venera.isi.edu
Date: Mon, 21 May 90 10:36:22 PDT
From: "Joyce K. Reynolds" <jkrey@isi.edu>;


SSPHWGers,

Paul and I need a head count for the next SSPHWG meeting, to be held
Tuesday, June 12th, 9:00am-5:00pm, here at USC/Information Sciences
Institute, Marina del Rey, California.

The SSPHWG Editorial Board is at work developing a draft outline
from the 22 bullets we developed at the SSPHWG meeting in Pittsburgh.
They will have a draft outline of our handbook available to work on
at the USC/ISI meeting.  Paul and I feel the the real "meat" of our
work will be accomplished at this upcoming meeting.

Please send your RSVP's to me (jkrey@isi.edu).  I will send out
instructions on how to get to ISI from the Anaheim area, where USENIX
is to be held, or Los Angeles International Airport, or whatever!!

Deadline for RSVP's will be Friday, June 8th.

Thanks, Joyce


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa09381;
          24 May 90 12:48 EDT
Received: from WOTAN.NISC.SRI.COM by cert.sei.cmu.edu (5.61/2.2)
        id AA01380; Thu, 24 May 90 12:19:47 -0400
Received: by wotan.nisc.sri.com (5.61/SRI-NISC1.0)
	id AA00751; Thu, 24 May 90 09:18:19 -0700
Date: Thu, 24 May 1990 9:18:17 PDT
From: Fred Ostapik <fred@nisc.sri.com>;
To: jkrey@venera.isi.edu
Cc: fred@nisc.sri.com, ssphwg@cert.sei.cmu.edu, jkrey@venera.isi.edu, 
    ph@sei.cmu.edu
Subject: Re: RSVP - next SSPHWG mtg., June 12th 
In-Reply-To: Your message of Mon, 21 May 90 10:36:22 PDT 
Message-Id: <CMM.0.88.643565897.fred@wotan.NISC.SRI.COM>;

There will be one representative from the NIC attending this meeting.



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa09520;
          8 Jun 90 13:07 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA05312; Fri, 8 Jun 90 12:32:46 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA00174>; Fri, 8 Jun 90 09:32:45 -0700
Date: Fri, 8 Jun 90 09:33:54 PDT
From: jkrey@venera.isi.edu
Posted-Date: Fri, 8 Jun 90 09:33:54 PDT
Message-Id: <9006081633.AA03326@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA03326>; Fri, 8 Jun 90 09:33:54 PDT
To: ssphwg@cert.sei.cmu.edu
Subject: Attendees for 6/12 meeting at ISI
Cc: jkrey@venera.isi.edu, ph@cert.sei.cmu.edu

Enclosed is the current list of attendees for the next SSPHWG
meeting this coming Tuesday, 6/12 at USC/ISI in Marina del Rey.
During this session we will be handing out writing assignments
for the handbook.  If you cannot attend, and would like to 
participate in the researching/writing end, please let us know
so that we can add you to the "SSPHWG Editorial Board" list.

We will file the 6/12 meeting minutes with the IETF, with a cc to this
emailing list...so stay tuned!

Thanks, Joyce and Paul

==================================================================

1) J. Paul Holbrook (ph@sei.cmu.edu) - CERT/SEI
2) Joyce K. Reynolds (jkrey@isi.edu) - USC/ISI
3) Ray Bates (rbates@isi.edu) - USC/ISI
4) Fred Ostapik (fred@nisc.sri.com) - SRI/NIC
5) Bjorn Satdeva - (cadence!mips!sysadmin.com!bjorn@uunet.uu.net) - 
		   /sys/admin, inc.
6) Tom Longstaff - (longstaf@pantera.llnl.gov) - CIAC/LLNL
7) Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept.
8) Dave Dalva (dave@tis.com) - Trusted Information Systems, Inc.
9) Sean Kirkpatrick (sean@cam.unisys.com) - Unisys
10) Allen Sturtevant (sturtevant@ccc.nersc.gov) - LLNL
11) Keith Pilotti - (pilotti@ucsd.edu) - SAIC
12) Michael A. Contino - (MAC@PSUVM.PSU.EDU) - PSU


Cannot attend 6/12 meeting, but would like to be on the "SSPHWG
Editorial Board" to write sections:

Jeff Carpenter (jjc@unix.cis.pitt.edu) - Univ. of Pittsburgh
Greg Hollingsworth (gregh@janus.jhuapl.edu) - John Hopkins


Received: from [128.237.253.5] by NRI.NRI.Reston.VA.US id aa08396;
          28 Jun 90 18:15 EDT
Received: from CCC.Nersc.GOV by cert.sei.cmu.edu (5.61/2.2)
        id AA02729; Thu, 28 Jun 90 17:33:44 -0400
Received: from ccv.mfenet by CCC.MFENET with Tell via MfeNet ;
	Thu, 28 Jun 90 14:35:59 PDT
Date: 	  Thu, 28 Jun 90 14:35:59 PDT
From: STURTEVANT%CCV.MFENET@ccc.nersc.gov
Message-Id: <900628143559.28a0012f@CCC.NERSC.GOV>;
Subject:   A Security Checklist for the Internet.
To: ssphwg@cert.sei.cmu.edu
Comment: From STURTEVANT@CCV.MFENET on June 28, 1990 at 14:35 PDT

Hello,

Paul Holbrook asked me to provide the following information on the ssphwg
mailing list.  I have the following text (actually, Joyce Reynolds has it now):

  Wood, C. C., W. W. Banks, S. B. Guarro, A. A. Garcia, V. E. Hampel, H. P.
  Sartorio [1987], "Computer Security, A Comprehensive Controls Checklist",
  John Wiley & Sons, New York, New York.

I contains about 1000+ computer security check-list questions which deal with
personnel policies, systems development, training/awareness, organizational
structure, physical access, data and program access, input/output, processing
operations, database and systems software, telecommunications, visual display
terminals human factors, environment, and backup and recovery.

It also covers the legal aspects of purposes and basic principles of legal
protection, state computer crime laws, federal computer crime statutes, other
federal and state laws, legal protection and remedies, and a review of case
studies.

The best part about this text is that it comes with a floppy which has an IBM
PC compatible program with contains all of the questions found in the text.
Each question is rated very low, low, medium, high and very high.  After
answering each question on the PC, six different types of reports can be
generated showing the weaknesses (holes) in your computer security.

Unfortunately I haven't had the time the look at the text closely, but it seems
that putting the effort into creating a new computer security check list may be
redundant.  If this text covers the topics that we are specifically interested
in - maybe we could work out some sort of legal "borrowing" of the text.  But
since the text is written for profit, and RFCs are not, I don't know if this
can be done.  Does anyone know if this has been done before? 

By the way, if you are interested in ordering this text, DO NOT order it from
John Wiley & Sons - you won't get the PC floppies with it.  You have to order
it from C.D. Ltd., P.O. Box 58363, Seattle, WA 98138, (206) 243-8700 - they
will send the floppies and the text in a "neat" little package. 

Allen Sturtevant                 Lawrence Livermore National Laboratory
ESnet (Energy Sciences Network)  National Energy Research Supercomputer Center
Internet: sturtevantap@es.net    Phone: 415-422-8266
DECnet:   ESNIC::APS (42158::APS)

CC:
	ssphwg@cert.sei.cmu.edu


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa26054;
          2 Jul 90 17:25 EDT
Received: from CCC.Nersc.GOV by cert.sei.cmu.edu (5.61/2.2)
        id AA04653; Mon, 2 Jul 90 16:39:42 -0400
Received: from ccv.mfenet by CCC.MFENET with Tell via MfeNet ;
	Mon, 2 Jul 90 13:41:41 PDT
Date: 	  Mon, 2 Jul 90 13:41:41 PDT
From: STURTEVANT%CCV.MFENET@ccc.nersc.gov
Message-Id: <900702134141.28a0012f@CCC.NERSC.GOV>;
Subject:   UPDATE: Re: A Security Checklist for the Internet.
To: ssphwg@cert.sei.cmu.edu
Comment: From STURTEVANT@CCV.MFENET on July 2, 1990 at 13:41 PDT

Below is a message that I just received from Fuat of Columbia University.  It
was discovered that the price of the Security Checklist text and floppy disk
that I mentioned is $245 from C.D. Ltd., while just the text from John Wiley &
Sons is only $37.  $208 is a lot of money to pay for a floppy.  You may just
want to purchase the text initially, as Fuat did. 

I didn't realize that the floppy was so expensive, sorry about that.

Allen Sturtevant                 Lawrence Livermore National Laboratory
ESnet (Energy Sciences Network)  National Energy Research Supercomputer Center
Internet: sturtevantap@es.net    Phone: 415-422-8266
DECnet:   ESNIC::APS (42158::APS)

> From:	fuat%cunixf.cc.columbia.edu@CCC.NERSC.GOV
> Subject: Re: A Security Checklist for the Internet.
> Date:	Mon, 2 Jul 90 15:18:33 EDT
> To: STURTEVANT%CCV.MFENET@CCC.NERSC.GOV
> 
> >  Wood, C. C., W. W. Banks, S. B. Guarro, A. A. Garcia, V. E. Hampel, H. P.
> >  Sartorio [1987], "Computer Security, A Comprehensive Controls Checklist",
> >  John Wiley & Sons, New York, New York.
> >
> >The best part about this text is that it comes with a floppy which has an IBM
> >PC compatible program with contains all of the questions found in the text.
> >Each question is rated very low, low, medium, high and very high.  After
> >answering each question on the PC, six different types of reports can be
> >generated showing the weaknesses (holes) in your computer security.
> >
> >By the way, if you are interested in ordering this text, DO NOT order it from
> >John Wiley & Sons - you won't get the PC floppies with it.  You have to order
> >it from C.D. Ltd., P.O. Box 58363, Seattle, WA 98138, (206) 243-8700 - they
> >will send the floppies and the text in a "neat" little package. 
> 
> We called C.D. Ltd.  They're asking for $245.00 for the book and
> floppy!  The book directly from John Wiley is $36.95 and they haven't
> heard of a floppy.  For now, I think we'll order the book only.  I
> can't get authorization for the much money without knowing better what
> I am getting.
> 
> Just thought I'd let you know what the price was, in case you weren't
> aware.  (You might want to send a followup to ssphwg with the price.
> It may be out of a lot of people's price range.)
> 
> 							--Fuat
> 
> Internet: fuat@columbia.edu          U.S. MAIL: Columbia University
>   BITNET: fuat@cunixf                           Center for Computing Activities
>     UUCP: ...!rutgers!columbia!cunixf!fuat      712 Watson Labs, 612 W115th St.
>    Phone: (212) 854-5128  Fax: (212) 662-6442   New York, NY 10025



Received: from [128.237.253.5] by NRI.NRI.Reston.VA.US id aa10614;
          5 Jul 90 16:57 EDT
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA02216; Thu, 5 Jul 90 15:51:33 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA02892; Thu, 5 Jul 90 15:51:31 -0400
Message-Id: <9007051951.AA02892@taos.cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Subject: Minutes of 12-June ssphwg meeting
Date: Thu, 05 Jul 90 15:51:29 EDT
From: J Paul Holbrook <ph@cert.sei.cmu.edu>;

What follows is a draft of the minutes from the June 12 ssphwg meeting
from ISI.  Joyce Reynolds is on vacation; it's possible that there are
small corrections to this that she has already made that I don't have
in this copy.  None the less, I wanted to get this information out to
the group.

The main part of the minutes is a proposed outline for the handbook we
are working on.  A number of people at the meeting and from the list
have volunteered to help get a first draft of this document for the
next ssphwg meeting.  That meeting will be on August 1 as part of the
IETF in British Columbia.

Although people are working on writing to this outline, comments on
the quality and completeness are certainly welcome.  One comment,
however: the outline is far from perfect, and I'm certain it has holes
and omissions in many areas.  But the group agreed at the ISI meeting
that it was more important to get moving and produce something that
can be critiqued and improved than to spend all summer polishing the
outline.  With that in mind, any constructive comments would be
welcome.  Please copy the ssphwg list so others can react.  (Spelling
errors and nitpicks to jkrey@isi.edu and ph@cert.sei.cmu.edu rather
than the entire list, please.)

All that said, many thanks to all the people who have been working
hard to turn this idea into a reality.  

If you'd like to volunteer to take a more active part in the
production of this document, please message Joyce Reynolds or Paul
Holbrook.

Paul Holbrook
ssphwg co-chair

---------------------------------------------------------------------
DRAFT		DRAFT		DRAFT		DRAFT		DRAFT

 
    -- This draft dated 5 July 90

SSPHWG
Current Meeting Report
Reported by: Joyce K. Reynolds and J. Paul Holbrook

12 June 1190 - 9:00am-5:00pm 
USC/Information Sciences Institute - Marina del Rey, CA 

Agenda:

	1)  Discussion, review on current SSPHWG draft outline.

	2)  Additional needs, requirements, and amendments.

	2)  Writing assignments.

	4)  Timeframe for writing first pass draft submission for 
            the next IETF meeting.

	5)  Review of plans/action items for next round of meetings.

		a)  Next IETF meeting in August at University of
                    British Columbia.


Attendees:

1) J. Paul Holbrook (ph@sei.cmu.edu) - CERT/SEI
2) Joyce K. Reynolds (jkrey@isi.edu) - USC/ISI
3) Ray Bates (rbates@isi.edu) - USC/ISI
4) Fred Ostapik (fred@nisc.sri.com) - SRI/NIC
5) Bjorn Satdeva (cadence!mips!sysadmin.com!bjorn@uunet.uu.net) -
                   /sys/admin, inc.
6) Tom Longstaff (longstaf@pantera.llnl.gov) - CIAC/LLNL
7) Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept.
8) Dave Dalva (dave@tis.com) - Trusted Information Systems, Inc.
9) Sean Kirkpatrick (sean@nisd.cam.unisys.com) - Unisys
10) Frank Byrum  (byrum@decuac.dec.com) - DEC
11) Keith Pilotti (pilotti@ucsd.edu) - SAIC
12) Michael A. Contino (MAC@PSUVM.PSU.EDU) - PSU
13) Bruce Hamilton (Hamilton.osbuSouth@XEROX.COM) - Xerox


SSPHWG Minutes:

The following SSPHWG outline volunteers from the Pittsburgh IETF took
on the task of developing a draft outline which was presented at this
SSPHWG meeting:

	Aileen Yuan
        Greg Hollingsworth
        Jeff Carpenter
        Allen Sturtevant
        Joyce K. Reynolds


The draft outline was worked on section by section and reformatted
for more content and flow:

========================================================================
DRAFT		DRAFT		DRAFT		DRAFT		DRAFT

                      Site Security Policy Handbook
                                 Outline
		                5-July-90 


I.   INTRODUCTION

     A. Background

     B. Purpose

        1.  Provide decision strategy

        2.  Offer practical measures and suggestions

	3.  Address real threats:
	         a. Intrusions into single hosts, etc.
	         b. Denial of service
                 c. Fraud
		 d. Malicious code, eg viruses

	4.  Cover general issues such as:
	         a. Installation with security procedures
	         b. Educate users on proper points-of-contact

	5.  Realize that many large sites may have already developed
            their own site specific security policies and procedures
            handbook.

     C. Scope
	1.  Use of handbook:
	         a. For sites to set up security policies and
 		    procedures with recommendations from this handbook
		 b. By using scenarios and issues raised in this handbook

	2.  Deal with Internet Security Policy
		 a. Protect the Internet as a whole
        	 b. Not intended to be site specific

	3.  Not intended to tell how to protect databases, etc.

	4.  Provide practical guidelines and lessons learned

	5.  Handbook will not address in detail issues such as:
		 a. risk assessment
		 b. contingency plans

     D. Organization of Document

	1.  Six sections:
		 a. Establishing official site policy on computer security
		 b. Establishing procedures to prevent security problems
		 c. Incident Handling
		 d. Establishing post-incident procedures
                 e. Appendices
                 f. Annotated Bibliography

II.  Establishing official site policy on computer security:

     A. Brief Overview

	1. Organization Goals

	2. Who makes the policy?

	3. Who is involved?

        4. Responsibilities

     B. Risk Assessment

	1. General discussion
                 a. Don't spend more to protect something than the
		    asset is worth

	2. Possible problems
       		 a. Access points
			i.   Network links
			ii.  Dialups
		 b. Misconfigured systems
		 c. software bugs
		 d. "Insider" threats
		 e.  .. and so forth ..

	3. Threats
		 a. Denial of service
		 b. Unauthorized access
		 c. Disclosure of information
		 d.  .. and so forth ..

	4. Policy 

     C. Define authorized access to computing resources.

	1.  Basic Assumptions:
	         a. Connected to the Internet
	         b. Inventory of networked components including PCs, servers,
	            network devices, physical security
	         c. Introduce problem areas/assets
  	
	2.  Policy Issues:
		 a. Who is authorized to grant access and approve usage?
                 b. Who is it you're giving access to?
			 i.   Who gets system administrator privileges
			      or passwords?  
  	         c. What is the proper use of resources? 
	                 i.   Provide guidelines for acceptable use
	                 ii.  Exception cases like tiger teams and 
			      "License to Hack"
   			 iii. Define limits to access and authority
	         d. What to do with sensitive information?
		 e. Proper use of copyrighted/licensed software?

	3.  Ethical Behavior

	4.  Users' Rights and Responsibilities

	5.  Rights and Responsibilities of System Administrators vs.
            Rights of Users
	         a. Can an administrator monitor or read a user's
		    files for any reason?  Invasion of Privacy?
     	         b. Liabilities
	         c. Do net administrators have the right to examine 
                    network or host traffic?

     D. What happens when policy is violated. 

 	1. Define what to do when outsiders violate
           the access policy.	

	2. Define what to do when local users violate
           the access policy.
		  a. What to do for insider intrusion,
                     how to avoid libel and slander.

	3. Define what to do when local users violate the
           access policy of a remote site.

	4. Define contacts and responsibilities to outside organizations
	  	  a. Who is authorized to make outside contacts?
		  b. What are our obligations to those contacts?
		  c. What are the responsibilities to our neighbors and 
		     other Internet sites?
			i.  Ref Security Policy WG work on recommended
			    Internet security policy
		  d. Issues for incident handling procedures; see IV.C.4.

     E. Locking in or out.

        1. "Protect and proceed"

	2. "Pursue and prosecute"

     F. Publicizing the policy

        1. Ensure policy is widely known and understood by ALL
                a. Meetings or handouts
           	b. Don't forget higher management as well as 'troops'
		c. Should people 'sign off' that they understand?
		d. Make sure new employees see it

	2. Making sure people understand policy can be later key to 
           legal action if necessary

III. Establishing procedures to prevent security problems:
     
     A. Overview

        1. Policy identifies assets to protect

        2. Risk assessment establishes what's cost-effective to
	   protect

        3. Controls should be chosen to protect assets in
	   cost-effective way
                a. Many different ways to actually implement a policy;
                   need to choose the right set of controls.
                b. Use common sense -- no use using elaborate schemes
        	   if poor passwords can still be used to break system
	4. Use multiple strategies to protect assets: if one is
	   breached, another comes into play.

     B. System security audits.

	1.  Organize scheduled drills 

	2.  Test procedures

     C. Account management procedures.

	1.  Determine authorization of system or network use

     D. Password management procedures.

	1.  Determine authorization of system or network use

     E. Configuration management procedures.

	1.  Physical Security:
	         a. Security boundary, Site boundary
	         b. Definition of terms

	2.  Develop tools as preventative and reactive
	         a. Inventory of tools

        3.  Standard versus non-standard configuration

		a. Non-standard systems can thwart attackers who
		exploit well known problems.  e.g., use slightly
		different algorithm to encrypt passwords.
   	
		b. Sometimes used in gateway (firewall) systems that protect 
		   'interior' networks. (See III.I.1)

		c. However, can be hard to maintain
		   i.   Must be documented
		   ii.  Hard to upgrade software -- changes must be
		        made
		   iii. Specialized knowledge required

       F. Procedures to recognize unauthorized activity.
 
        1. Regularly monitor systems
           
        2. Tools that can be used
		a. Logging
		b. Monitoring tools
		c. Other tools? (wish list here)

 	3. Vary routine -- check different things so that intruder can't 
           predict your actions

     G. Define actions to take when unauthorized activity is
        suspected.

     H. Communicating lessons learned.
  
	1.  Educate users
	         a. Proper use of account/workstation
                 b. Account/workstation management procedures
                 c. Password management procedures
			i. Define how to compose a good password
			ii. Frequency to change
                 d. How to determine account misuse
                        i. Last login time/place
                        ii. Command histories
                 e. Problem reporting procedures

        2.  Educate Host Administrators
                 a. Account management procedures
                        i. Check "out of box" accounts, disable or
                           give new passwords
                        ii. Don't allow accounts without passwords
                        iii. Shadow passwords
                        iv. Keep track/lists of who has access to 
			    administrator accounts/passwords
                 b. Configuration management procedures
                        i. Check "out of box" configurations
                        ii. Examine network services
                        iii. Install bug fixes
                 c. Recovery procedures - Backups
                 d. Problem reporting procedures

     I. Resources to prevent security breaches

        1. Concept of "Inter-net" and "Outer-net" - Circles of trust,
	   "firewalls" of protection

	2. Confidentiality
    	         a. Encryption (hardware and software)
                         i. DES
			ii. crypt()
		 b. Privacy enhanced mail

	3. Origin authentication
		 a. RSA public key

	4. Information integrity
		 a. Checksums

	5. Limiting access
		 a. Router packet filtering
		         i. IP address
			ii. TCP/UDP port

	6. Authentication systems
		 a. Kerberos
		 b. Smart cards - Pseudo random number generators

	7. Books/lists/informational sources
		 a. Security mailing lists
		 b. Networking mailing lists
		 c. CERT
		 d. DDN Management bulletins
    		 e. System administration list
		 f. Vendor specific system lists

	8. Problem reporting tools

	9. Auditing
		 a. Verify security
		 b. Verify software configurations
		 c. Tools
			i. COPS
	
	10. Communication among administrators

	11. Secure operating systems

	12. Obtaining fixes for known problems
		 a. Trusted archive servers


IV.  Incident Handling

     A. Overview
  
  	1. Must have a plan to follow in case of an incident.

        2. Order of discussion in this session suggests an order for 
           a plan.
	
	3. Possible goals for incident handling (suggested by 
	   Russell Brand).
		a. Maintain and restore data.
		b. Maintain and restore service.
		c. Figure out how it happened.
		d. Avoid escalation and further incidents
		e. Avoid negative publicity
		f. Find out who did it
		g. Punish the attackers

     B.  Evaluation

        1. Is it real?
        
	2. Scope
                a. impact

     C.  Possible types of notification

	1. Explicit

	2. Factual

	3. Choice of language

	4. Notification of:
                a. POC people (Technical, Administrative, Response
                   Teams, Investigative, Legal, Vendors, 
                   Service providers)
		        i.   Which POCs are visible to whom
                b. Wider community (users)
                c. Other sites that might be affected

	5.  Public Relations - Press Releases
                 a. Sensitivity issues
                 b. Response team to get in touch? 

	6.  Who needs to get involved?
                 a. Response team
                 b. Understanding between you and the NICs and NOCs.

     D. Response

	1. What will you do?
                a. Restore control
                b. Relates to policy
                c. Which level of service is needed?
                d. Monitor activity
                e. Constrain or shut down system 

        2. Consider designating a 'single point of contact'
                a. Ideally person 'in charge' of handling incident,
                   but not necessary.
                b. Provides consistent communication, contact with law
                   enforcement
                c. If legal action later taken, a single person can
                   represent the site in court

     E. Legal/Investigative
        
        1. Establishing contacts with investigative agencies.
                a. Notification of site legal counsel.

	2.  Formal and Informal Legal Procedures
	         a. Verification of Contact - FBI, Secret Service, DoD agency
			i. What to do when government gets
			   involved (FBI, DoD, CIA, Local Police)?
			ii. What is liability when government
			    (FBI, DoD, CIA, Local Police) gets
                            involved, intervenes?
	         b. Natural conflicts, i.e., Site wants to get back to
                    business (and also wants to avoid negative publicity
                    and risk losing business or funding), but
                    investigative agency wants to collect evidence
	            and catch the intruder.

     F. Documentation Logs

	1.  Collection and protection of evidence and information
                a. Log of events, actions, reactions
                b. Differentiating between facts, assumptions,
                   and inferences
                c. Grabbing files for evidence
                      i.  Get evidence off-line ASAP
		      ii. Restrict access to evidence
                          (If legal action taken, you must prove
			   evidence was not tampered with)
                 
                d. Log all costs or time spent dealing with incident - may
                   be necessary for later legal action

V.   Establishing post-incident procedures

     A. Removing vulnerabilities.

	1.  Cleanup

	2.  Follow up

        3.  Keep a Security log

     B. Capturing lessons learned.

	1.  Resources:
	         a. Other security devices, methods
	         b. Repository of books, lists, information sources
	         c. Form a subgroup

     C. Upgrading policies and procedures

	1. Establish mechanism for updating policies and procedures, tools

	2. Problem reporting procedures

VI.  Appendices

	1. Tool Lists
	
	2. Legal Precedence

	3. Court Cases

	4. Laws

	5. List of Job Descriptions

	6. Glossary of Terms

VII.  Annotated Bibliography

========================================================================

Paul Holbrook worked on a draft Introduction to the Handbook.  This
was also briefly discussed, and will be incorporated with the
Introduction in the draft outline.

Writing assignments were made at this meeting, by outline section:

	SSPHWG Editorial Board Members' - Writing Assignments
			5 July 90


Section I.  INTRODUCTION

	J. Paul Holbrook (ph@sei.cmu.edu) - CERT/SEI


Section II.  Establishing official site policy on computer security

	Jeff Carpenter (jjc@unix.cis.pitt.edu) - Univ. of Pittsburgh
	Greg Hollingsworth (gregh@janus.jhuapl.edu) - John Hopkins
	Allen Sturtevant (sturtevant@ccc.nersc.gov) - LLNL
	Fred Ostapik (fred@nisc.sri.com) - SRI/NIC


Section III.  Establishing procedures to prevent security problems

	Allen Sturtevant (sturtevant@ccc.nersc.gov) - LLNL
	Sean Kirkpatrick (sean@nisd.cam.unisys.com) - Unisys
	Frank Byrum  (byrum@decuac.dec.com) - DEC
	Dave Curry  (davy@ITSTD.SRI.COM) - SRI


Section IV.  Incident Handling

	Tom Longstaff - (longstaf@pantera.llnl.gov) - CIAC/LLNL
	Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept.
	Keith Pilotti - (pilotti@ucsd.edu) - SAIC


Section V.  Establishing post-incident procedures

	Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept
	Frank Byrum  (byrum@decuac.dec.com) - DEC


Section VI.  Appendices

	SSPHWG Member contributions


Section VII.  Annotated Bibliography

	Joyce K. Reynolds (jkrey@isi.edu) - USC/ISI


Specific interest in the reseaching/writing/editing:

	C. Philip Wood (cpw@lanl.gov) - LANL
	Dave Curry (davy@itstd.sri.com) - SRI International


Specific interest in the reading/editing:

	Michael A. Contino - (MAC@PSUVM.PSU.EDU) - PSU


July 24th is the date set for the 1st pass draft of the Site Security
Handbook, to be presented at UBC for continued development.







Received: from venera.isi.edu by NRI.NRI.Reston.VA.US id aa25434;
          16 Jul 90 19:16 EDT
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA27736>; Mon, 16 Jul 90 16:13:08 -0700
Date: Mon, 16 Jul 90 16:14:32 PDT
From: jkrey@venera.isi.edu
Posted-Date: Mon, 16 Jul 90 16:14:32 PDT
Message-Id: <9007162314.AA03944@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA03944>; Mon, 16 Jul 90 16:14:32 PDT
To: gvaudre@NRI.Reston.VA.US
Subject: SSPHWG Minutes 12-Jun MEETING
Cc: crocker@tis.com, jkrey@venera.isi.edu, pgross@NRI.Reston.VA.US, 
    ph@sei.cmu.edu, ssphwg@cert.sei.cmu.edu

Greg and Phill,

The SSPHWG held a full day meeting at USC/ISI on 12 June 90.  
We would like to officially file the minutes with the IETF,
for inclusion in the next IETF Proceedings.

Thanks, Joyce and Paul

======================================================================

SSPHWG
Current Meeting Report
Reported by: Joyce K. Reynolds and J. Paul Holbrook

12 June 1990 - 9:00am-5:00pm 
USC/Information Sciences Institute - Marina del Rey, CA 

Agenda:

	1)  Discussion, review on current SSPHWG draft outline.

	2)  Additional needs, requirements, and amendments.

	2)  Writing assignments.

	4)  Timeframe for writing first pass draft submission for 
            the next IETF meeting.

	5)  Review of plans/action items for next round of meetings.

		a)  Next IETF meeting in August at University of
                    British Columbia.


Attendees:

1) J. Paul Holbrook (ph@sei.cmu.edu) - CERT/SEI
2) Joyce K. Reynolds (jkrey@isi.edu) - USC/ISI
3) Ray Bates (rbates@isi.edu) - USC/ISI
4) Fred Ostapik (fred@nisc.sri.com) - SRI/NIC
5) Bjorn Satdeva (cadence!mips!sysadmin.com!bjorn@uunet.uu.net) -
                   /sys/admin, inc.
6) Tom Longstaff (longstaf@pantera.llnl.gov) - CIAC/LLNL
7) Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept.
8) Dave Dalva (dave@tis.com) - Trusted Information Systems, Inc.
9) Sean Kirkpatrick (sean@nisd.cam.unisys.com) - Unisys
10) Frank Byrum  (byrum@decuac.dec.com) - DEC
11) Keith Pilotti (pilotti@ucsd.edu) - SAIC
12) Michael A. Contino (MAC@PSUVM.PSU.EDU) - PSU
13) Bruce Hamilton (Hamilton.osbuSouth@XEROX.COM) - Xerox


SSPHWG Minutes:

The following SSPHWG outline volunteers from the Pittsburgh IETF took
on the task of developing a draft outline which was presented at this
SSPHWG meeting:

	Aileen Yuan
        Greg Hollingsworth
        Jeff Carpenter
        Allen Sturtevant
        Joyce K. Reynolds


The draft outline was worked on section by section and reformatted
for more content and flow:

========================================================================

DRAFT		DRAFT		DRAFT		DRAFT		DRAFT

                      Site Security Policy Handbook
                                 Outline
		                5-July-90 


I.   INTRODUCTION

     A. Background

     B. Purpose

        1.  Provide decision strategy

        2.  Offer practical measures and suggestions

	3.  Address real threats:
	         a. Intrusions into single hosts, etc.
	         b. Denial of service
                 c. Fraud
		 d. Malicious code, e.g., viruses

	4.  Cover general issues such as:
	         a. Installation with security procedures
	         b. Educate users on proper points-of-contact

	5.  Realize that many large sites may have already developed
            their own site specific security policies and procedures
            handbook.

     C. Scope

	1.  Use of handbook:
	         a. For sites to set up security policies and
 		    procedures with recommendations from this handbook
		 b. By using scenarios and issues raised in this handbook

	2.  Deal with Internet Security Policy
		 a. Protect the Internet as a whole
        	 b. Not intended to be site specific

	3.  Not intended to tell how to protect databases, etc.

	4.  Provide practical guidelines and lessons learned

	5.  Handbook will not address in detail issues such as:
		 a. risk assessment
		 b. contingency plans

     D. Organization of Document

	1.  Six sections:
		 a. Establishing official site policy on computer security
		 b. Establishing procedures to prevent security problems
		 c. Incident Handling
		 d. Establishing post-incident procedures
                 e. Appendices
                 f. Annotated Bibliography

II.  Establishing official site policy on computer security:

     A. Brief Overview

	1. Organization Goals

	2. Who makes the policy?

	3. Who is involved?

        4. Responsibilities

     B. Risk Assessment

	1. General discussion
                 a. Don't spend more to protect something than the
		    asset is worth

	2. Possible problems
       		 a. Access points
			i.   Network links
			ii.  Dialups
		 b. Misconfigured systems
		 c. software bugs
		 d. "Insider" threats
		 e.  .. and so forth ..

	3. Threats
		 a. Denial of service
		 b. Unauthorized access
		 c. Disclosure of information
		 d.  .. and so forth ..

	4. Policy 

     C. Define authorized access to computing resources.

	1.  Basic Assumptions:
	         a. Connected to the Internet
	         b. Inventory of networked components including PCs, servers,
	            network devices, physical security
	         c. Introduce problem areas/assets
  	
	2.  Policy Issues:
		 a. Who is authorized to grant access and approve usage?
                 b. Who is it you're giving access to?
			 i.   Who gets system administrator privileges
			      or passwords?  
  	         c. What is the proper use of resources? 
	                 i.   Provide guidelines for acceptable use
	                 ii.  Exception cases like tiger teams and 
			      "License to Hack"
   			 iii. Define limits to access and authority
	         d. What to do with sensitive information?
		 e. Proper use of copyrighted/licensed software?

	3.  Ethical Behavior

	4.  Users' Rights and Responsibilities

	5.  Rights and Responsibilities of System Administrators vs.
            Rights of Users
	         a. Can an administrator monitor or read a user's
		    files for any reason?  Invasion of Privacy?
     	         b. Liabilities
	         c. Do net administrators have the right to examine 
                    network or host traffic?

     D. What happens when policy is violated. 

 	1. Define what to do when outsiders violate
           the access policy.	

	2. Define what to do when local users violate
           the access policy.
		  a. What to do for insider intrusion,
                     how to avoid libel and slander.

	3. Define what to do when local users violate the
           access policy of a remote site.

	4. Define contacts and responsibilities to outside organizations
	  	  a. Who is authorized to make outside contacts?
		  b. What are our obligations to those contacts?
		  c. What are the responsibilities to our neighbors and 
		     other Internet sites?
			i.  Ref Security Policy WG work on recommended
			    Internet security policy
		  d. Issues for incident handling procedures; see IV.C.4.

     E. Locking in or out.

        1. "Protect and proceed"

	2. "Pursue and prosecute"

     F. Publicizing the policy

        1. Ensure policy is widely known and understood by ALL
                a. Meetings or handouts
           	b. Don't forget higher management as well as 'troops'
		c. Should people 'sign off' that they understand?
		d. Make sure new employees see it

	2. Making sure people understand policy can be later key to 
           legal action if necessary

III. Establishing procedures to prevent security problems:
     
     A. Overview

        1. Policy identifies assets to protect

        2. Risk assessment establishes what's cost-effective to
	   protect

        3. Controls should be chosen to protect assets in
	   cost-effective way
                a. Many different ways to actually implement a policy;
                   need to choose the right set of controls.
                b. Use common sense -- no use using elaborate schemes
        	   if poor passwords can still be used to break system
	4. Use multiple strategies to protect assets: if one is
	   breached, another comes into play.

     B. System security audits.

	1.  Organize scheduled drills 

	2.  Test procedures

     C. Account management procedures.

	1.  Determine authorization of system or network use

     D. Password management procedures.

	1.  Determine authorization of system or network use

     E. Configuration management procedures.

	1.  Physical Security:
	         a. Security boundary, Site boundary
	         b. Definition of terms

	2.  Develop tools as preventative and reactive
	         a. Inventory of tools

        3.  Standard versus non-standard configuration

		a. Non-standard systems can thwart attackers who
		exploit well known problems.  e.g., use slightly
		different algorithm to encrypt passwords.
   	
		b. Sometimes used in gateway (firewall) systems that protect 
		   'interior' networks. (See III.I.1)

		c. However, can be hard to maintain
		   i.   Must be documented
		   ii.  Hard to upgrade software -- changes must be
		        made
		   iii. Specialized knowledge required

       F. Procedures to recognize unauthorized activity.
 
        1. Regularly monitor systems
           
        2. Tools that can be used
		a. Logging
		b. Monitoring tools
		c. Other tools? (wish list here)

 	3. Vary routine -- check different things so that intruder can't 
           predict your actions

     G. Define actions to take when unauthorized activity is
        suspected.

     H. Communicating lessons learned.
  
	1.  Educate users
	         a. Proper use of account/workstation
                 b. Account/workstation management procedures
                 c. Password management procedures
			i. Define how to compose a good password
			ii. Frequency to change
                 d. How to determine account misuse
                        i. Last login time/place
                        ii. Command histories
                 e. Problem reporting procedures

        2.  Educate Host Administrators
                 a. Account management procedures
                        i. Check "out of box" accounts, disable or
                           give new passwords
                        ii. Don't allow accounts without passwords
                        iii. Shadow passwords
                        iv. Keep track/lists of who has access to 
			    administrator accounts/passwords
                 b. Configuration management procedures
                        i. Check "out of box" configurations
                        ii. Examine network services
                        iii. Install bug fixes
                 c. Recovery procedures - Backups
                 d. Problem reporting procedures

     I. Resources to prevent security breaches

        1. Concept of "Inter-net" and "Outer-net" - Circles of trust,
	   "firewalls" of protection

	2. Confidentiality
    	         a. Encryption (hardware and software)
                         i. DES
			ii. crypt()
		 b. Privacy enhanced mail

	3. Origin authentication
		 a. RSA public key

	4. Information integrity
		 a. Checksums

	5. Limiting access
		 a. Router packet filtering
		         i. IP address
			ii. TCP/UDP port

	6. Authentication systems
		 a. Kerberos
		 b. Smart cards - Pseudo random number generators

	7. Books/lists/informational sources
		 a. Security mailing lists
		 b. Networking mailing lists
		 c. CERT
		 d. DDN Management bulletins
    		 e. System administration list
		 f. Vendor specific system lists

	8. Problem reporting tools

	9. Auditing
		 a. Verify security
		 b. Verify software configurations
		 c. Tools
			i. COPS
	
	10. Communication among administrators

	11. Secure operating systems

	12. Obtaining fixes for known problems
		 a. Trusted archive servers


IV.  Incident Handling

     A. Overview
  
  	1. Must have a plan to follow in case of an incident.

        2. Order of discussion in this session suggests an order for 
           a plan.
	
	3. Possible goals for incident handling (suggested by 
	   Russell Brand).
		a. Maintain and restore data.
		b. Maintain and restore service.
		c. Figure out how it happened.
		d. Avoid escalation and further incidents
		e. Avoid negative publicity
		f. Find out who did it
		g. Punish the attackers

     B.  Evaluation

        1. Is it real?
        
	2. Scope
                a. impact

     C.  Possible types of notification

	1. Explicit

	2. Factual

	3. Choice of language

	4. Notification of:
                a. POC people (Technical, Administrative, Response
                   Teams, Investigative, Legal, Vendors, 
                   Service providers)
		        i.   Which POCs are visible to whom
                b. Wider community (users)
                c. Other sites that might be affected

	5.  Public Relations - Press Releases
                 a. Sensitivity issues
                 b. Response team to get in touch? 

	6.  Who needs to get involved?
                 a. Response team
                 b. Understanding between you and the NICs and NOCs.

     D. Response

	1. What will you do?
                a. Restore control
                b. Relates to policy
                c. Which level of service is needed?
                d. Monitor activity
                e. Constrain or shut down system 

        2. Consider designating a 'single point of contact'
                a. Ideally person 'in charge' of handling incident,
                   but not necessary.
                b. Provides consistent communication, contact with law
                   enforcement
                c. If legal action later taken, a single person can
                   represent the site in court

     E. Legal/Investigative
        
        1. Establishing contacts with investigative agencies.
                a. Notification of site legal counsel.

	2.  Formal and Informal Legal Procedures
	         a. Verification of Contact - FBI, Secret Service, DoD agency
			i. What to do when government gets
			   involved (FBI, DoD, CIA, Local Police)?
			ii. What is liability when government
			    (FBI, DoD, CIA, Local Police) gets
                            involved, intervenes?
	         b. Natural conflicts, i.e., Site wants to get back to
                    business (and also wants to avoid negative publicity
                    and risk losing business or funding), but
                    investigative agency wants to collect evidence
	            and catch the intruder.

     F. Documentation Logs

	1.  Collection and protection of evidence and information
                a. Log of events, actions, reactions
                b. Differentiating between facts, assumptions,
                   and inferences
                c. Grabbing files for evidence
                      i.  Get evidence off-line ASAP
		      ii. Restrict access to evidence
                          (If legal action taken, you must prove
			   evidence was not tampered with)
                 
                d. Log all costs or time spent dealing with incident - may
                   be necessary for later legal action

V.   Establishing post-incident procedures

     A. Removing vulnerabilities.

	1.  Cleanup

	2.  Follow up

        3.  Keep a Security log

     B. Capturing lessons learned.

	1.  Resources:
	         a. Other security devices, methods
	         b. Repository of books, lists, information sources
	         c. Form a subgroup

     C. Upgrading policies and procedures

	1. Establish mechanism for updating policies and procedures, tools

	2. Problem reporting procedures

VI.  Appendices

	1. Tool Lists
	
	2. Legal Precedence

	3. Court Cases

	4. Laws

	5. List of Job Descriptions

	6. Glossary of Terms

VII.  Annotated Bibliography

========================================================================

Paul Holbrook worked on a draft Introduction to the Handbook.  This
was also briefly discussed, and will be incorporated with the
Introduction in the draft outline.

Writing assignments were made at this meeting, by outline section:

	SSPHWG Editorial Board Members' - Writing Assignments
			18-June-90


Section I.  INTRODUCTION

	J. Paul Holbrook (ph@sei.cmu.edu) - CERT/SEI


Section II.  Establishing official site policy on computer security

	Jeff Carpenter (jjc@unix.cis.pitt.edu) - Univ. of Pittsburgh
	Greg Hollingsworth (gregh@janus.jhuapl.edu) - John Hopkins
	Allen Sturtevant (sturtevant@ccc.nersc.gov) - LLNL
	Fred Ostapik (fred@nisc.sri.com) - SRI/NIC


Section III.  Establishing procedures to prevent security problems

	Allen Sturtevant (sturtevant@ccc.nersc.gov) - LLNL
	Sean Kirkpatrick (sean@nisd.cam.unisys.com) - Unisys
	Frank Byrum  (byrum@decuac.dec.com) - DEC
	Dave Curry  (davy@ITSTD.SRI.COM) - SRI


Section IV.  Incident Handling

	Tom Longstaff - (longstaf@pantera.llnl.gov) - CIAC/LLNL
	Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept.
	Keith Pilotti - (pilotti@ucsd.edu) - SAIC


Section V.  Establishing post-incident procedures

	Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept
	Frank Byrum  (byrum@decuac.dec.com) - DEC


Section VI.  Appendices

	SSPHWG Member contributions


Section VII.  Annotated Bibliography

	Joyce K. Reynolds (jkrey@isi.edu) - USC/ISI


Specific interest in the reseaching/writing/editing:

	C. Philip Wood (cpw@lanl.gov) - LANL
	Dave Curry (davy@itstd.sri.com) - SRI International


Specific interest in the reading/editing:

	Michael A. Contino - (MAC@PSUVM.PSU.EDU) - PSU


July 24th is the date set for the 1st pass draft of the Site Security
Handbook, to be presented at UBC for continued development.



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa25786;
          16 Jul 90 20:17 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA14877; Mon, 16 Jul 90 19:13:11 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA27736>; Mon, 16 Jul 90 16:13:08 -0700
Date: Mon, 16 Jul 90 16:14:32 PDT
From: jkrey@venera.isi.edu
Posted-Date: Mon, 16 Jul 90 16:14:32 PDT
Message-Id: <9007162314.AA03944@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA03944>; Mon, 16 Jul 90 16:14:32 PDT
To: gvaudre@NRI.Reston.VA.US
Subject: SSPHWG Minutes 12-Jun MEETING
Cc: crocker@tis.com, jkrey@venera.isi.edu, pgross@NRI.Reston.VA.US, 
    ph@sei.cmu.edu, ssphwg@cert.sei.cmu.edu

Greg and Phill,

The SSPHWG held a full day meeting at USC/ISI on 12 June 90.  
We would like to officially file the minutes with the IETF,
for inclusion in the next IETF Proceedings.

Thanks, Joyce and Paul

======================================================================

SSPHWG
Current Meeting Report
Reported by: Joyce K. Reynolds and J. Paul Holbrook

12 June 1990 - 9:00am-5:00pm 
USC/Information Sciences Institute - Marina del Rey, CA 

Agenda:

	1)  Discussion, review on current SSPHWG draft outline.

	2)  Additional needs, requirements, and amendments.

	2)  Writing assignments.

	4)  Timeframe for writing first pass draft submission for 
            the next IETF meeting.

	5)  Review of plans/action items for next round of meetings.

		a)  Next IETF meeting in August at University of
                    British Columbia.


Attendees:

1) J. Paul Holbrook (ph@sei.cmu.edu) - CERT/SEI
2) Joyce K. Reynolds (jkrey@isi.edu) - USC/ISI
3) Ray Bates (rbates@isi.edu) - USC/ISI
4) Fred Ostapik (fred@nisc.sri.com) - SRI/NIC
5) Bjorn Satdeva (cadence!mips!sysadmin.com!bjorn@uunet.uu.net) -
                   /sys/admin, inc.
6) Tom Longstaff (longstaf@pantera.llnl.gov) - CIAC/LLNL
7) Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept.
8) Dave Dalva (dave@tis.com) - Trusted Information Systems, Inc.
9) Sean Kirkpatrick (sean@nisd.cam.unisys.com) - Unisys
10) Frank Byrum  (byrum@decuac.dec.com) - DEC
11) Keith Pilotti (pilotti@ucsd.edu) - SAIC
12) Michael A. Contino (MAC@PSUVM.PSU.EDU) - PSU
13) Bruce Hamilton (Hamilton.osbuSouth@XEROX.COM) - Xerox


SSPHWG Minutes:

The following SSPHWG outline volunteers from the Pittsburgh IETF took
on the task of developing a draft outline which was presented at this
SSPHWG meeting:

	Aileen Yuan
        Greg Hollingsworth
        Jeff Carpenter
        Allen Sturtevant
        Joyce K. Reynolds


The draft outline was worked on section by section and reformatted
for more content and flow:

========================================================================

DRAFT		DRAFT		DRAFT		DRAFT		DRAFT

                      Site Security Policy Handbook
                                 Outline
		                5-July-90 


I.   INTRODUCTION

     A. Background

     B. Purpose

        1.  Provide decision strategy

        2.  Offer practical measures and suggestions

	3.  Address real threats:
	         a. Intrusions into single hosts, etc.
	         b. Denial of service
                 c. Fraud
		 d. Malicious code, e.g., viruses

	4.  Cover general issues such as:
	         a. Installation with security procedures
	         b. Educate users on proper points-of-contact

	5.  Realize that many large sites may have already developed
            their own site specific security policies and procedures
            handbook.

     C. Scope

	1.  Use of handbook:
	         a. For sites to set up security policies and
 		    procedures with recommendations from this handbook
		 b. By using scenarios and issues raised in this handbook

	2.  Deal with Internet Security Policy
		 a. Protect the Internet as a whole
        	 b. Not intended to be site specific

	3.  Not intended to tell how to protect databases, etc.

	4.  Provide practical guidelines and lessons learned

	5.  Handbook will not address in detail issues such as:
		 a. risk assessment
		 b. contingency plans

     D. Organization of Document

	1.  Six sections:
		 a. Establishing official site policy on computer security
		 b. Establishing procedures to prevent security problems
		 c. Incident Handling
		 d. Establishing post-incident procedures
                 e. Appendices
                 f. Annotated Bibliography

II.  Establishing official site policy on computer security:

     A. Brief Overview

	1. Organization Goals

	2. Who makes the policy?

	3. Who is involved?

        4. Responsibilities

     B. Risk Assessment

	1. General discussion
                 a. Don't spend more to protect something than the
		    asset is worth

	2. Possible problems
       		 a. Access points
			i.   Network links
			ii.  Dialups
		 b. Misconfigured systems
		 c. software bugs
		 d. "Insider" threats
		 e.  .. and so forth ..

	3. Threats
		 a. Denial of service
		 b. Unauthorized access
		 c. Disclosure of information
		 d.  .. and so forth ..

	4. Policy 

     C. Define authorized access to computing resources.

	1.  Basic Assumptions:
	         a. Connected to the Internet
	         b. Inventory of networked components including PCs, servers,
	            network devices, physical security
	         c. Introduce problem areas/assets
  	
	2.  Policy Issues:
		 a. Who is authorized to grant access and approve usage?
                 b. Who is it you're giving access to?
			 i.   Who gets system administrator privileges
			      or passwords?  
  	         c. What is the proper use of resources? 
	                 i.   Provide guidelines for acceptable use
	                 ii.  Exception cases like tiger teams and 
			      "License to Hack"
   			 iii. Define limits to access and authority
	         d. What to do with sensitive information?
		 e. Proper use of copyrighted/licensed software?

	3.  Ethical Behavior

	4.  Users' Rights and Responsibilities

	5.  Rights and Responsibilities of System Administrators vs.
            Rights of Users
	         a. Can an administrator monitor or read a user's
		    files for any reason?  Invasion of Privacy?
     	         b. Liabilities
	         c. Do net administrators have the right to examine 
                    network or host traffic?

     D. What happens when policy is violated. 

 	1. Define what to do when outsiders violate
           the access policy.	

	2. Define what to do when local users violate
           the access policy.
		  a. What to do for insider intrusion,
                     how to avoid libel and slander.

	3. Define what to do when local users violate the
           access policy of a remote site.

	4. Define contacts and responsibilities to outside organizations
	  	  a. Who is authorized to make outside contacts?
		  b. What are our obligations to those contacts?
		  c. What are the responsibilities to our neighbors and 
		     other Internet sites?
			i.  Ref Security Policy WG work on recommended
			    Internet security policy
		  d. Issues for incident handling procedures; see IV.C.4.

     E. Locking in or out.

        1. "Protect and proceed"

	2. "Pursue and prosecute"

     F. Publicizing the policy

        1. Ensure policy is widely known and understood by ALL
                a. Meetings or handouts
           	b. Don't forget higher management as well as 'troops'
		c. Should people 'sign off' that they understand?
		d. Make sure new employees see it

	2. Making sure people understand policy can be later key to 
           legal action if necessary

III. Establishing procedures to prevent security problems:
     
     A. Overview

        1. Policy identifies assets to protect

        2. Risk assessment establishes what's cost-effective to
	   protect

        3. Controls should be chosen to protect assets in
	   cost-effective way
                a. Many different ways to actually implement a policy;
                   need to choose the right set of controls.
                b. Use common sense -- no use using elaborate schemes
        	   if poor passwords can still be used to break system
	4. Use multiple strategies to protect assets: if one is
	   breached, another comes into play.

     B. System security audits.

	1.  Organize scheduled drills 

	2.  Test procedures

     C. Account management procedures.

	1.  Determine authorization of system or network use

     D. Password management procedures.

	1.  Determine authorization of system or network use

     E. Configuration management procedures.

	1.  Physical Security:
	         a. Security boundary, Site boundary
	         b. Definition of terms

	2.  Develop tools as preventative and reactive
	         a. Inventory of tools

        3.  Standard versus non-standard configuration

		a. Non-standard systems can thwart attackers who
		exploit well known problems.  e.g., use slightly
		different algorithm to encrypt passwords.
   	
		b. Sometimes used in gateway (firewall) systems that protect 
		   'interior' networks. (See III.I.1)

		c. However, can be hard to maintain
		   i.   Must be documented
		   ii.  Hard to upgrade software -- changes must be
		        made
		   iii. Specialized knowledge required

       F. Procedures to recognize unauthorized activity.
 
        1. Regularly monitor systems
           
        2. Tools that can be used
		a. Logging
		b. Monitoring tools
		c. Other tools? (wish list here)

 	3. Vary routine -- check different things so that intruder can't 
           predict your actions

     G. Define actions to take when unauthorized activity is
        suspected.

     H. Communicating lessons learned.
  
	1.  Educate users
	         a. Proper use of account/workstation
                 b. Account/workstation management procedures
                 c. Password management procedures
			i. Define how to compose a good password
			ii. Frequency to change
                 d. How to determine account misuse
                        i. Last login time/place
                        ii. Command histories
                 e. Problem reporting procedures

        2.  Educate Host Administrators
                 a. Account management procedures
                        i. Check "out of box" accounts, disable or
                           give new passwords
                        ii. Don't allow accounts without passwords
                        iii. Shadow passwords
                        iv. Keep track/lists of who has access to 
			    administrator accounts/passwords
                 b. Configuration management procedures
                        i. Check "out of box" configurations
                        ii. Examine network services
                        iii. Install bug fixes
                 c. Recovery procedures - Backups
                 d. Problem reporting procedures

     I. Resources to prevent security breaches

        1. Concept of "Inter-net" and "Outer-net" - Circles of trust,
	   "firewalls" of protection

	2. Confidentiality
    	         a. Encryption (hardware and software)
                         i. DES
			ii. crypt()
		 b. Privacy enhanced mail

	3. Origin authentication
		 a. RSA public key

	4. Information integrity
		 a. Checksums

	5. Limiting access
		 a. Router packet filtering
		         i. IP address
			ii. TCP/UDP port

	6. Authentication systems
		 a. Kerberos
		 b. Smart cards - Pseudo random number generators

	7. Books/lists/informational sources
		 a. Security mailing lists
		 b. Networking mailing lists
		 c. CERT
		 d. DDN Management bulletins
    		 e. System administration list
		 f. Vendor specific system lists

	8. Problem reporting tools

	9. Auditing
		 a. Verify security
		 b. Verify software configurations
		 c. Tools
			i. COPS
	
	10. Communication among administrators

	11. Secure operating systems

	12. Obtaining fixes for known problems
		 a. Trusted archive servers


IV.  Incident Handling

     A. Overview
  
  	1. Must have a plan to follow in case of an incident.

        2. Order of discussion in this session suggests an order for 
           a plan.
	
	3. Possible goals for incident handling (suggested by 
	   Russell Brand).
		a. Maintain and restore data.
		b. Maintain and restore service.
		c. Figure out how it happened.
		d. Avoid escalation and further incidents
		e. Avoid negative publicity
		f. Find out who did it
		g. Punish the attackers

     B.  Evaluation

        1. Is it real?
        
	2. Scope
                a. impact

     C.  Possible types of notification

	1. Explicit

	2. Factual

	3. Choice of language

	4. Notification of:
                a. POC people (Technical, Administrative, Response
                   Teams, Investigative, Legal, Vendors, 
                   Service providers)
		        i.   Which POCs are visible to whom
                b. Wider community (users)
                c. Other sites that might be affected

	5.  Public Relations - Press Releases
                 a. Sensitivity issues
                 b. Response team to get in touch? 

	6.  Who needs to get involved?
                 a. Response team
                 b. Understanding between you and the NICs and NOCs.

     D. Response

	1. What will you do?
                a. Restore control
                b. Relates to policy
                c. Which level of service is needed?
                d. Monitor activity
                e. Constrain or shut down system 

        2. Consider designating a 'single point of contact'
                a. Ideally person 'in charge' of handling incident,
                   but not necessary.
                b. Provides consistent communication, contact with law
                   enforcement
                c. If legal action later taken, a single person can
                   represent the site in court

     E. Legal/Investigative
        
        1. Establishing contacts with investigative agencies.
                a. Notification of site legal counsel.

	2.  Formal and Informal Legal Procedures
	         a. Verification of Contact - FBI, Secret Service, DoD agency
			i. What to do when government gets
			   involved (FBI, DoD, CIA, Local Police)?
			ii. What is liability when government
			    (FBI, DoD, CIA, Local Police) gets
                            involved, intervenes?
	         b. Natural conflicts, i.e., Site wants to get back to
                    business (and also wants to avoid negative publicity
                    and risk losing business or funding), but
                    investigative agency wants to collect evidence
	            and catch the intruder.

     F. Documentation Logs

	1.  Collection and protection of evidence and information
                a. Log of events, actions, reactions
                b. Differentiating between facts, assumptions,
                   and inferences
                c. Grabbing files for evidence
                      i.  Get evidence off-line ASAP
		      ii. Restrict access to evidence
                          (If legal action taken, you must prove
			   evidence was not tampered with)
                 
                d. Log all costs or time spent dealing with incident - may
                   be necessary for later legal action

V.   Establishing post-incident procedures

     A. Removing vulnerabilities.

	1.  Cleanup

	2.  Follow up

        3.  Keep a Security log

     B. Capturing lessons learned.

	1.  Resources:
	         a. Other security devices, methods
	         b. Repository of books, lists, information sources
	         c. Form a subgroup

     C. Upgrading policies and procedures

	1. Establish mechanism for updating policies and procedures, tools

	2. Problem reporting procedures

VI.  Appendices

	1. Tool Lists
	
	2. Legal Precedence

	3. Court Cases

	4. Laws

	5. List of Job Descriptions

	6. Glossary of Terms

VII.  Annotated Bibliography

========================================================================

Paul Holbrook worked on a draft Introduction to the Handbook.  This
was also briefly discussed, and will be incorporated with the
Introduction in the draft outline.

Writing assignments were made at this meeting, by outline section:

	SSPHWG Editorial Board Members' - Writing Assignments
			18-June-90


Section I.  INTRODUCTION

	J. Paul Holbrook (ph@sei.cmu.edu) - CERT/SEI


Section II.  Establishing official site policy on computer security

	Jeff Carpenter (jjc@unix.cis.pitt.edu) - Univ. of Pittsburgh
	Greg Hollingsworth (gregh@janus.jhuapl.edu) - John Hopkins
	Allen Sturtevant (sturtevant@ccc.nersc.gov) - LLNL
	Fred Ostapik (fred@nisc.sri.com) - SRI/NIC


Section III.  Establishing procedures to prevent security problems

	Allen Sturtevant (sturtevant@ccc.nersc.gov) - LLNL
	Sean Kirkpatrick (sean@nisd.cam.unisys.com) - Unisys
	Frank Byrum  (byrum@decuac.dec.com) - DEC
	Dave Curry  (davy@ITSTD.SRI.COM) - SRI


Section IV.  Incident Handling

	Tom Longstaff - (longstaf@pantera.llnl.gov) - CIAC/LLNL
	Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept.
	Keith Pilotti - (pilotti@ucsd.edu) - SAIC


Section V.  Establishing post-incident procedures

	Jim Duncan (jim@augusta.math.psu.edu) - Penn State Math Dept
	Frank Byrum  (byrum@decuac.dec.com) - DEC


Section VI.  Appendices

	SSPHWG Member contributions


Section VII.  Annotated Bibliography

	Joyce K. Reynolds (jkrey@isi.edu) - USC/ISI


Specific interest in the reseaching/writing/editing:

	C. Philip Wood (cpw@lanl.gov) - LANL
	Dave Curry (davy@itstd.sri.com) - SRI International


Specific interest in the reading/editing:

	Michael A. Contino - (MAC@PSUVM.PSU.EDU) - PSU


July 24th is the date set for the 1st pass draft of the Site Security
Handbook, to be presented at UBC for continued development.



Received: from [128.237.253.5] by NRI.NRI.Reston.VA.US id aa01426;
          17 Jul 90 15:14 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA17733; Tue, 17 Jul 90 14:36:32 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA09886>; Tue, 17 Jul 90 11:36:31 -0700
Date: Tue, 17 Jul 90 11:37:57 PDT
From: jkrey@venera.isi.edu
Posted-Date: Tue, 17 Jul 90 11:37:57 PDT
Message-Id: <9007171837.AA04447@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA04447>; Tue, 17 Jul 90 11:37:57 PDT
To: ssphwg@cert.sei.cmu.edu
Subject: SSPH Annotated Bibliography
Cc: jkrey@venera.isi.edu

Hi.  Our editorial board members are working briskly on their writing 
assignments.  My assignment is to pull together the Annotated 
Bibliography section of the handbook. 

I have received input from the SSPHWG members who were at our 
12 June meeting here at ISI and have an extensive 15 page 
Bibliography from RFC1135 that I can use.  I've been going through 
various on-line libraries and plan to head on up to the UCLA Research 
Library to do some digging.

I would also like to enlist the rest of the WG for any additional 
input that you all may think would be appropriate for our Bibliography
section in the handbook.  I'd rather weed out duplicates, than have 
a partial listing. 

If you have a "fave" citation that you would like to submit as a 
candidate for the SSPH Bib section, please send them to me 
(jkrey@isi.edu).

Thanks, Joyce  



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa04854;
          18 Jul 90 17:40 EDT
Received: from sh.cs.net by cert.sei.cmu.edu (5.61/2.2)
        id AA22010; Wed, 18 Jul 90 16:57:00 -0400
Message-Id: <9007182057.AA22010@cert.sei.cmu.edu>;
Received: by SH.CS.NET id aa25947; 18 Jul 90 16:48 EDT
To: jkrey@venera.isi.edu
Cc: ssphwg@cert.sei.cmu.edu, gwilliam@sh.cs.net
Subject: Re: SSPH Annotated Bibliography 
In-Reply-To: Your message of Tue, 17 Jul 90 11:37:57 -0700.
             <9007171837.AA04447@akamai.isi.edu>; 
Date: Wed, 18 Jul 90 16:41:03 -0400
From: George Williams <gwilliam@sh.cs.net>;


 Hello,
 
 Though this is probally a duplicate.....

 C.C. Wood, W. Banks, S. Guarro, A. Garcia, V. Hampel, H. Sartoro, " Computer
 Security A Comprehensive Checklist "; John Wiley & Sons.
 
 Good Luck,
 G. Williams


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa09430;
          25 Jul 90 14:02 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA04104; Wed, 25 Jul 90 13:13:53 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA23358>; Wed, 25 Jul 90 10:10:45 -0700
Date: Wed, 25 Jul 90 10:15:16 PDT
From: jkrey@venera.isi.edu
Posted-Date: Wed, 25 Jul 90 10:15:16 PDT
Message-Id: <9007251715.AA08160@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA08160>; Wed, 25 Jul 90 10:15:16 PDT
To: ssphwg@cert.sei.cmu.edu
Subject: SSPHWG Agenda - IETF UBC
Cc: craig@bbn.com, crocker@tis.com, jkrey@venera.isi.edu, ph@sei.cmu.edu


			SSPHWG Agenda - UBC
		Wednesday, August 1, 9:15-12Noon
			Co-Chairs:  
		J. Paul Holbrook, CERT (ph@cert.sei.cmu.edu)
		Joyce K. Reynolds, USC/ISI (jkrey@isi.edu)


	This session of the SSPHWG will be fully devoted to going
	through the first pass rough draft of our Handbook, and a
	review of plans/action items for the next IETF.





Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa14230;
          26 Jul 90 20:47 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA03527; Thu, 26 Jul 90 20:15:25 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA26399>; Thu, 26 Jul 90 17:12:08 -0700
Date: Thu, 26 Jul 90 17:16:40 PDT
From: jkrey@venera.isi.edu
Posted-Date: Thu, 26 Jul 90 17:16:40 PDT
Message-Id: <9007270016.AA09178@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA09178>; Thu, 26 Jul 90 17:16:40 PDT
To: ssphwg@cert.sei.cmu.edu
Subject: SSPH draft
Cc: jkrey@venera.isi.edu, ph@cert.sei.cmu.edu

Hi.  A very rough draft of the SSPH is available via anonymous
ftp from venera.isi.edu, in the directory: in-notes,
file: ssphwg-draft-1.txt.

This file may be amended between this afternoon and tomorrow, 
before we head out to UBC, as additional input is received.

Joyce and Paul


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa11695;
          27 Jul 90 18:25 EDT
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA06833; Fri, 27 Jul 90 17:16:37 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA10965; Fri, 27 Jul 90 17:16:35 -0400
Message-Id: <9007272116.AA10965@taos.cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Cc: jjc@unix.cis.pitt.edu, jkrey@isi.edu
Subject: Focus of SSPH
Date: Fri, 27 Jul 90 17:16:34 EDT
From: J Paul Holbrook <ph@cert.sei.cmu.edu>;

Folks,

Here are some messages exchanged privately (fwded with permssion)
about what the focus of the site security policy handbook should be.
If you're coming to BC next week, please read if you get a chance
because we'll probably have some discussion on the issue there.
(Sorry to send these out so late in the week, but it just came up.)

Please reply to the list so we can get the discussion going.

   Paul Holbrook


Date: Tue, 24 Jul 90 17:42:00 -0400 (EDT)
From: "Jeffrey J. Carpenter" <jjc@unix.cis.pitt.edu>;
To: jkrey@ISI.EDU
Subject: Re: Bilbiography
References: <9007242106.AA07800@akamai.isi.edu>;

[... other stuff removed by ph ...]

In the beginning of the outline, there is some discussion about this
document not intending to be site specific, but I didn't see anything
about a disclaimer.  This may have been discussed at the June meeting or
between you and Paul, but I think we need some sort of disclaimer
stating that this document is definitely not intended to advise people
as to the content of their policies -- it is meant to advise people as
to the options they have and what the consequenses of them (or not
having them) are.

Later,

	jeff

------- Message 2

To: jkrey@venera.isi.edu
cc: jjc@unix.cis.pitt.edu
Subject: Re: "disclaimer" in SSPH 
In-reply-to: Your message of "Tue, 24 Jul 90 14:54:46 PDT."
             <9007242154.AA07851@akamai.isi.edu>; 
Date: Fri, 27 Jul 90 15:42:10 EDT
From: J Paul Holbrook <ph@taos.cert.sei.cmu.edu>;

I was sitting here about to put in the 'disclaimer' that we discussed
earlier this week.  But upon thinking about it I'm not so sure I
agree with the idea.  Or at least the particular thrust of what Jeff
was saying -- I'm not sure we should say we make no recommendations.

Jeff said: 

    ..  but I think we need some sort of disclaimer
stating that this document is definitely not intended to advise people
as to the content of their policies -- it is meant to advise people as
to the options they have and what the consequences of them (or not
having them) are.

We are actually making recommendations.  Perhaps not on the content of
all the points, but certainly on the structure and scope of the
policy.  The whole document says "If you want to build a good policy
and procedures, you should consider these issues."  What we don't do
is say "You should pursue intruders with vigor."  Or something like
that.   

So I agree that we have to be careful to delimit the scope of what
we're doing.  A document with no recommendations, no guidance
whatsoever is not very useful.  But recommending the content of the
policy is a job that the SPWG is doing.

I guess I'd like to talk this over a little more.  Joyce, perhaps we
could talk about this at UBC; Jeff, if you have any thoughts, please
let me know before end of day Monday.  

So for the moment I'm going to leave out a disclaimer until I can get
clearer on what it should be.

Paul

------- Message 3

Message-Id: <Uag_ad8_V000MF1mMT@unix.cis.pitt.edu>;
Date: Fri, 27 Jul 90 16:52:57 -0400 (EDT)
From: "Jeffrey J. Carpenter" <jjc@unix.cis.pitt.edu>;
To: jkrey@venera.isi.edu, J Paul Holbrook <ph@cert.sei.cmu.edu>;
Subject: Re: "disclaimer" in SSPH
In-Reply-To: <9007271942.AA10751@taos.cert.sei.cmu.edu>;
References: <9007271942.AA10751@taos.cert.sei.cmu.edu>;


Ok.  I have thought about this also.  I was under the impression that we
were not going to make recommendations on what their policy should be. 
We would recommend that they address something in their policy, however.
 I thought we were simply going to tell people what their options were
for various items that should be covered in a security policy.  For each
item, we would list the options and the consequences/benefits of
selecting the option they select.

I think that if the focus is shifted in the text from advising what the
security measures the administrators should take to how they should
address it in their security policy, you will see that we aren't really
directly recommending what their policy should be. However, by listing
what the consequences/benefits of selecting various positions on
individual security issues will have the same effect without us telling
them what to do.  It will basically tell them what bad things/good
things can happen if they don't/do address them.

I think that advising people on what they should do is close to what the
Security Policy Working Group is doing now, and we need to watch what we
are doing compared with what they are doing.

Let me list a few examples of what I am talking about.  I am examining
two extracts from the draft (I just randomly picked them not to pick on
someone):


>  Accounts without passwords should never be allowed on the system,
>    regardless of how "harmless" they are.  Even accounts which do not
>    execute a command interpreter can be compromised if set up
>    incorrectly.

As this is, it is recommending that administrators do not allow accounts
without passwords.  Alternatively, it could be written as possible:

> You need to determine what your policy concerning having accounts
> without passwords.  Permitting accounts without passwords can present a
> security risk to your services, even if they do not execute a command
> interpreter since they can be compromised if set up incorrectly.

With this excerpt, you are not recommending that they not have accounts
without passwords.  You are telling them they should address it in their
policy and you are telling them what the consequences are if they do
permit accounts without passwords.


Draft:
>    Keep track of who has access to privileged user accounts (e.g. "root"
>    on UNIX or "MAINT" on VMS).  Whenever a privileged user leaves the
>    organization or no longer has need of the privileged account, the
>    passwords on all privileged accounts should be changed.

New:
> Your policy should provide for a mechanism for tracking who has access
> to privileged accounts on your services and needs to list what your
> procedures are when one of these people leave your organization or are
> reassigned to duties that do not require privileged access.  If your
> policy does not provide for the changing of passwords or removing of
> privileges when a member of your organization leaves, you run the risk
> of unauthorized use of privileges...



I guess this all boils down to one question.  Is this document (a) a
document to assist site administrators in drafting their own security
policies, (b) a document advising users on what their security policies
should be, or (c) both.  I thought it was (a) and think we designed the
outline based on that.  I am not necessarily opposed to (c), but I think
if it is (c), we need to clarify that and change the focus
appropriately.  I am opposed to (b) because it does not include (a),
which I think is important.  I also think that if it is (c), we will
need to make some adjustments to the outline.

I hope you will (I am sure you will) discuss and clarify this next week.

You can post this to the list if you want to make other members aware of
this before the meeting.

Good Luck at the meeting - sorry I can't make this one.


	jeff



Jeff Carpenter

University of Pittsburgh, Computing and Information Services
600 Epsilon Drive, Pittsburgh, Pennsylvania 15238
jjc+@unix.cis.pitt.edu,   +1 412 624 6424,    FAX +1 412 624 6436

[An Andrew ToolKit view (a raster image) was included here, but could
not be displayed.]

------- End of Forwarded Messages



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa12029;
          27 Jul 90 19:02 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA07096; Fri, 27 Jul 90 18:22:45 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA06207>; Fri, 27 Jul 90 15:22:42 -0700
Date: Fri, 27 Jul 90 15:24:06 PDT
From: jkrey@venera.isi.edu
Posted-Date: Fri, 27 Jul 90 15:24:06 PDT
Message-Id: <9007272224.AA09616@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA09616>; Fri, 27 Jul 90 15:24:06 PDT
To: ssphwg@cert.sei.cmu.edu
Subject: re: SSPHWG - first pass DRAFT
Cc: jkrey@venera.isi.edu, ph@sei.cmu.edu

More input has been amended to our SSPH.  If you're interested,
use anonymous ftp to venera.isi.edu, directory in-notes, file:

		ssphwg-draft-1.txt


I'm outta here.  See some of you at UBC, "talk" to the rest of you
later!   Joyce


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa12526;
          27 Jul 90 20:07 EDT
Received: from CCC.Nersc.GOV by cert.sei.cmu.edu (5.61/2.2)
        id AA07316; Fri, 27 Jul 90 19:36:01 -0400
Date:    Fri, 27 Jul 90 16:38:11 PDT
From: Allen Sturtevant - ESnet <sturtevant@ccc.nersc.gov>;
Message-Id: <900727163811.21c00a7c@CCC.NERSC.GOV>;
Subject: Section II D.
To: ssphwg@cert.sei.cmu.edu
X-St-Vmsmail-To: st%"ssphwg@cert.sei.cmu.edu";


Hello,

Here is my (*very* small) contribution to Section II D.  I haven't had the time
to complete it -- sorry.  See you in UBC!

Allen Sturtevant / LLNL
SturtevantAP@es.net

-------------------------- Cut Here For Section II D ---------------------------

     D.  What Happens When The Policy Is Violated [AS]
 
         The following items discuss some ideas that  one  should  consider
         when  enforcing  a  computer security policy.  Defining the actual
         computer security policy enforcement methods is beyond  the  scope
         of this document since computer security requirements vary greatly
         depending on the type of electronic data to be protected.   As  an
         example,  a  DoD  computer facility performing top secret research
         would have far more stringent  requirements  than,  let's  say,  a
         collection  of universities sharing unclassified information about
         joint biological research over the Internet.
 
         It is obvious that when any type of official policy is defined, be
         it  related  to  computer  security  or not, it will eventually be
         broken.  This is guaranteed.  The violation may occur  due  to  an
         individual's  negligence,  accidental  mistake,  having  not  been
         properly informed of the current policy or not  understanding  the
         current  policy.   It  is  equally possible that an individual (or
         group of individuals) may knowingly perform  an  act  that  is  in
         direct violation of the defined policy.
 
         When a policy violation has been detected, the immediate course of
         action   should   be  pre-defined  to  ensure  prompt  and  proper
         enforcement.  An investigation should be  performed  to  determine
         how   and  why  the  violation  occurred.   Then  the  appropriate
         corrective action should be executed.  The type  and  severity  of
         action  taken varies depending on how the violation was performed.
         For the few types of violations mentioned above,  there  would  be
         different forms of actions needed.
 
         1.  What To Do When Outsiders Violate The Policy [AS]
 
             What is an "outsider"?  Depending on your perception, the term
             outsiders  may  mean,  for  example, another group within your
             organization,  another  organization  within  your   division,
             another  division  within  your  company  or  another  company
             altogether.  This  word  actually  refers  to  many  kinds  of
             outsiders,    with   each   kind   being   defined   by   your
             administrative,  legal   or   political   boundaries.    These
             boundaries  imply what type of action must be taken to correct
             the offending party; from  a  written  reprimand  to  pressing
             legal  charges.   So  not  only  do you need to define actions
             based on the type of  violation,  you  also  need  to  have  a
             clearly  defined  series  of  actions  based  on  the  kind of
             outsider violating your computer security  policy.   This  all
             seems  rather complicated, but should be addressed long before
             the need becomes necessary.
 
             One point  to  remember  about  your  policy  is  that  proper
             education  is  your  best  defense.  For the outsiders who are
             using your computer legally,  it  is  your  responsibility  to
             verify  that  these individuals are aware of the policies that
             you have set forth.  Having this proof may assist you  in  the
             future if legal action becomes necessary.
 
             As for outsiders who are using your  computer  illegally,  the
             problem is basically the same.  What type of outsider violated
             the policy and how and why did they do it?  Depending  on  the
             results  of  your investigation, you may just prefer to "plug"
             the hole  in  your  computer  security  and  chalk  it  up  to
             experience.   Or if a significant amount of loss was incurred,
             you may wish to take more a drastic action.  [add more here]
 
         2.  What To Do When Local Users Violate The Policy [AS]
 
             The  term  "local  user"  (or  "insider")  falls  under   same
             definition rules mentioned for "outsiders".  Anyone who is not
             an outsider is a  local  user  as  far  as  this  document  is
             concerned.
 
             a.  What To Do For Insider Intrusion - Libel And Slander [AS]
 
                 [to be completed]
 
         3.  What To Do When Local Users Violate The  Policy  Of  A  Remote
             Site [AS]
 
             [to be completed]
 
         4.  Define Contacts And Responsibilities To Outside  Organizations
             [AS]
 
             [to be completed - talk about policy,  escalation  procedures,
             who  is allowed to talk to outsiders, who performs which role,
             etc...]
 
             a.  Who Is Authorized To Make Outside Contacts?  [AS]
 
                 [to be completed]
 
             b.  What Are Your Obligations To Those Contacts?  [AS]
 
                 [to be completed]
 
             c.  What Are The Responsibilities To Our Neighbors  And  Other
                 Internet Sites?  [AS]
 
                 [to be completed - reference Security Policy Working Group
                 work on recommended Internet security policy]
 
             d.  Issues For Incident Handling Procedures [AS]
 
                 [to be completed - reference Section IV C 4]

--------------------------------------------------------------------------------




Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa16728;
          29 Jul 90 22:18 EDT
Received: from wolfen.cc.uow.edu.au by cert.sei.cmu.edu (5.61/2.2)
        id AA00640; Sun, 29 Jul 90 21:31:57 -0400
Received: by wolfen.cc.uow.edu.au (5.61+IDA+MU) 
	id AA03966; Mon, 30 Jul 1990 11:31:28 +1000
	(from ian@wolfen.cc.uow.edu.au for ssphwg@cert.sei.cmu.edu)
From: Ian Piper <ian@wolfen.cc.uow.edu.au>;
Message-Id: <9007300131.AA03966@wolfen.cc.uow.edu.au>;
Subject: subscribe
To: ssphwg@cert.sei.cmu.edu
Date: Mon, 30 Jul 90 11:31:25 EST

Please add me to the mailing list.
-- 
=========================================================================
# Ian Piper                # ACSnet:    ian@wolfen.cc.uow.oz            #
# Senior Consultant        #                                            #
# Information Technology   # Internet:  ian@wolfen.cc.uow.edu.au        #
#    Services              #                                            #
# University of Wollongong # Phone: +61 42 270828                       #
# N.S.W.  2500  Australia  # Fax :  +61 42 297768                       #
=========================================================================



Received: from venera.isi.edu by NRI.NRI.Reston.VA.US id aa12050;
          8 Aug 90 14:57 EDT
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA29600>; Wed, 8 Aug 90 11:56:55 -0700
Date: Wed, 8 Aug 90 11:56:53 PDT
From: jkrey@venera.isi.edu
Posted-Date: Wed, 8 Aug 90 11:56:53 PDT
Message-Id: <9008081856.AA02153@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA02153>; Wed, 8 Aug 90 11:56:53 PDT
To: gvaudre@NRI.Reston.VA.US, ssphwg@cert.sei.cmu.edu
Subject: Minutes - SSPHWG session at UBC
Cc: craig@bbn.com, crocker@tis.com, jkrey@venera.isi.edu, 
    ph@cert.sei.cmu.edu, us-wg@nnsc.nsf.net

Greg,  

Enclosed is the SSPHWG's UBC minutes.

Joyce and Paul
===================================================================

SSPHWG Minutes - UBC
Wednesday, August 1, 9:15-12Noon
Reported by Co-Chairs:  

	Joyce K. Reynolds, USC/ISI (jkrey@isi.edu)
	J. Paul Holbrook, CERT (ph@cert.sei.cmu.edu)


Attendees:


	(filled in by NRI - they have the list)


Minutes:


        The first pass draft of the Handbook was well received,
	and the general concensus of attendees is to keep with
	the direction of the document, with one more pass at the
	next IETF in Colorado.  Submission of the Handbook to the 
	Internet Draft process is projected to be in mid-December,
	for publication as an RFC FYI at the end of 1990.




Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa15243;
          8 Aug 90 17:29 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA19396; Wed, 8 Aug 90 16:44:25 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA29600>; Wed, 8 Aug 90 11:56:55 -0700
Date: Wed, 8 Aug 90 11:56:53 PDT
From: jkrey@venera.isi.edu
Posted-Date: Wed, 8 Aug 90 11:56:53 PDT
Message-Id: <9008081856.AA02153@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA02153>; Wed, 8 Aug 90 11:56:53 PDT
To: gvaudre@NRI.Reston.VA.US, ssphwg@cert.sei.cmu.edu
Subject: Minutes - SSPHWG session at UBC
Cc: craig@bbn.com, crocker@tis.com, jkrey@venera.isi.edu, 
    ph@cert.sei.cmu.edu, us-wg@nnsc.nsf.net

Greg,  

Enclosed is the SSPHWG's UBC minutes.

Joyce and Paul
===================================================================

SSPHWG Minutes - UBC
Wednesday, August 1, 9:15-12Noon
Reported by Co-Chairs:  

	Joyce K. Reynolds, USC/ISI (jkrey@isi.edu)
	J. Paul Holbrook, CERT (ph@cert.sei.cmu.edu)


Attendees:


	(filled in by NRI - they have the list)


Minutes:


        The first pass draft of the Handbook was well received,
	and the general concensus of attendees is to keep with
	the direction of the document, with one more pass at the
	next IETF in Colorado.  Submission of the Handbook to the 
	Internet Draft process is projected to be in mid-December,
	for publication as an RFC FYI at the end of 1990.




Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa05753;
          6 Sep 90 14:53 EDT
Received: from localhost by cert.sei.cmu.edu (5.61/2.2)
        id AA02557; Thu, 6 Sep 90 14:22:26 -0400
Message-Id: <9009061822.AA02557@cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Subject: Administrivia: small reorg on ssphwg archive directory
Date: Thu, 06 Sep 90 14:22:23 EDT
From: ph@cert.sei.cmu.edu

As you probably know, I maintain an archive directory for the SSPHWG
on cert.sei.cmu.edu:/pub/ssphwg.  I've done a couple of small things
to clean up the directory.

The main changes:

The ssphwg.collection file which holds the SSPHWG mail archive has
been cleaned up and put into MH packf format.  There were a number of
requests to be added to the list and a entire copy of Dave Curry's
paper in the archive, which made it much harder to find the useful
messages in the archive.  The messages in the archive are now
separated by Control-A characters, which is the standard used by MH
and several other mailers to pack messages into a file.  Now you can
retrive the mail file and let your mailer split it apart.

I've also created a ssphwg.short.collection which is an abridged
version of the entire mail file.  I've removed old messages about (no
longer) upcoming meetings and such.  The original full mail archive
was about 250k, the cleaned up archive described above is about 150k,
and this shorter archive is about 100k.

I've also put a README in the directory.

The directory also contains a copy of the handbook outline we've been
working on and a copy of the August 90 handbook draft.

Thanks -- 

J. Paul Holbrook
ssphwg co-chair
ph@cert.sei.cmu.edu


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa08996;
          21 Sep 90 15:41 EDT
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA08683; Fri, 21 Sep 90 15:04:01 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA14420; Fri, 21 Sep 90 15:03:48 -0400
Message-Id: <9009211903.AA14420@taos.cert.sei.cmu.edu>;
To: jkrey@isi.edu
Cc: ssphwg@cert.sei.cmu.edu
Subject: Bib reference on secure gateways
Date: Fri, 21 Sep 90 15:03:47 EDT
From: J Paul Holbrook <ph@cert.sei.cmu.edu>;

Just to remind folks, the site security policy handbook will contain a
bibliography.  The quality of this bib will depend on the
contributions you make.  Please send contributions to Joyce Reynolds,
and consider copying the ssphwg list.

To help get the ball rolling, here's a useful reference from the Summer
90 Usenix conference.

Cheswick, Bill, "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990.

Brief abstract (slight paraphrase from the original abstract): AT&T
maintains a large internal Internet that needs to be protected from
outside attacks, while providing useful services between the two.
This paper describes AT&T's Internet gateway.  This gateway passes
mail any many of the common Internet services between AT&T internal
machines and the Internet.  This is accomplished without IP
connectivity using a pair of machines: a trusted internal machine and
an untrusted external gateway.  These are connected by a private link.
The internal machine provides a few carefully-guarded services to the
external gateway.  This configuration helps protect the internal
internet even if the external machine is fully compromised.


Holbrook's comments:  This is a very useful and interesting design.
Most firewall gateway systems rely on a system that, if compromised,
could allow access to the machines behind the firewall.  Also, most
firewall systems require users who want access to Internet services to
have accounts on the firewall machine.  AT&T's design allows AT&T
internal internet users access to the standard services of telnet and
ftp from their own workstations without accounts on the firewall
machine.  A very useful paper that shows how to maintain some of the
benefits of Internet connectivity while still maintaining strong
security.



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa12967;
          25 Sep 90 21:52 EDT
Received: from msr.EPM.ORNL.GOV by cert.sei.cmu.edu (5.61/2.2)
        id AA28215; Tue, 25 Sep 90 21:19:15 -0400
Received: by msr.EPM.ORNL.GOV (5.61/1.34)
	id AA07861; Tue, 25 Sep 90 21:19:13 -0400
Date: Tue, 25 Sep 90 21:19:13 -0400
From: "Rob Sargent, Ph: 615-482-1999/615-675-7629" <gfy@msr.epm.ornl.gov>;
Message-Id: <9009260119.AA07861@msr.EPM.ORNL.GOV>;
To: ssphwg@cert.sei.cmu.edu
Subject: FYI: Clifford Stoll on PBS NOVA

PBS TV will be showing a NOVA program on the re-enactment Clifford
Stoll's (author of "The Cuckoo's Egg") efforts to catch a hacker
stealing data from military and research computers.  The program is
called "The KGB, the Computer and Me."  It is scheduled for Tuesday,
October 2nd at 8:00 pm EDT, check your local station listings for exact
time in your area.


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07528;
          17 Oct 90 12:21 EDT
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA28915; Wed, 17 Oct 90 11:36:10 -0400
Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3)
        id AA00932; Wed, 17 Oct 90 11:36:09 -0400
Message-Id: <9010171536.AA00932@taos.cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Subject: Ptr to Internet Security Policy discussion
Date: Wed, 17 Oct 90 11:36:05 EDT
From: J Paul Holbrook <ph@cert.sei.cmu.edu>;

I believe most people on this list are aware of the IETF Security
Policy Working Group (SPWG) chaired by Rich Pethia.  That group is the
logical companion group to the SSPHWG in that they are working on a
recommended security policy for the Internet.  The word 'recommended'
is the key; since no one organization 'owns' the Internet, no single
group can impose a single security standard.  However, the hope is
that the Internet Security Policy will serve as a model for
resource-owning organizations to create their own security policies.

Within the next few days (probably early next week), a draft of the
this proposed Internet Security Policy will be sent the SPWG mailing
list.  If you're interested in following that discussion and you're
not on the SPWG mailing list, you can be added to that list by sending
a message to spwg-request@nri.reston.va.us.  To avoid duplicating
efforts, discussion on the proposed policy should be limited to the
SPWG list rather than the SSPHWG list.  I will put the SPWG proposal
out for anonymous FTP.

There is a strong relationship between the SPWG work and the policy
handbook we're trying to produce.  Once the SPWG work has been
approved, we will include the recommended Internet Security Policy in
the handbook, and discuss how the various aspects might apply to a
site considering it's own policies and procedures.  In effect, the
Internet Security Policy is a template sites can use, and the Site
Security Policy Handbook is the 'how-to' guide that leads people
through all of the issues and nuances.

J. Paul Holbrook
ssphwg co-chair
Internet: <ph@cert.sei.cmu.edu>;
(412) 268-7720



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa13619;
          19 Oct 90 18:29 EDT
Received: from venera.isi.edu by cert.sei.cmu.edu (5.61/2.2)
        id AA01779; Fri, 19 Oct 90 17:52:20 -0400
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA15139>; Fri, 19 Oct 90 14:52:15 -0700
Date: Fri, 19 Oct 90 14:52:21 PDT
From: jkrey@venera.isi.edu
Posted-Date: Fri, 19 Oct 90 14:52:21 PDT
Message-Id: <9010192152.AA09341@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA09341>; Fri, 19 Oct 90 14:52:21 PDT
To: ssphwg@cert.sei.cmu.edu
Subject: re: Bib references for SSPH
Cc: jkrey@venera.isi.edu

We're still collecting submissions (with abstracts) for the 
SSPH Bib.  Again, as I stated last June, I'd prefer duplications
then no input at all.

Joyce (SSPH co-chair)


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa13826;
          31 Oct 90 16:56 EST
Received: from cucom.canterbury.ac.nz by cert.sei.cmu.edu (5.61/2.2)
        id AA29900; Wed, 31 Oct 90 16:22:37 -0500
Message-Id: <9010312122.AA29900@cert.sei.cmu.edu>;
Date: Thu, 1 Nov 90 10:16 +1200
From: "Jason Haar, Network Consultant, UoC, NZ" <CCTR127@canterbury.ac.nz>;
Subject: help
To: ssphwg@cert.sei.cmu.edu
X-Vms-To: IN%"ssphwg@cert.sei.cmu.edu";
Reply-To: j.haar@canterbury.ac.nz

help


Received: from venera.isi.edu by NRI.NRI.Reston.VA.US id aa02602;
          16 Nov 90 15:33 EST
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA00669>; Fri, 16 Nov 90 12:31:35 -0800
Date: Fri, 16 Nov 90 12:31:35 PST
From: jkrey@venera.isi.edu
Posted-Date: Fri, 16 Nov 90 12:31:35 PST
Message-Id: <9011162031.AA11415@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA11415>; Fri, 16 Nov 90 12:31:35 PST
To: ssphwg@cert.sei.cmu.edu
Subject: SSPHWG Agenda - Boulder IETF
Cc: gvaudre@NRI.Reston.VA.US, jkrey@venera.isi.edu, mdavies@NRI.Reston.VA.US

crocker@tis.com, ph@cert.sei.cmu.edu, rdp@cert.sei.cmu.edu


			SSPHWG Agenda - Colorado
		Thursday, December 6, 9:00am-12Noon
			Co-Chairs:  
		J. Paul Holbrook, CERT (ph@cert.sei.cmu.edu)
		Joyce K. Reynolds, USC/ISI (jkrey@isi.edu)


	This session of the SSPHWG will be fully devoted to going
	through the current draft of our Handbook, with the intent
        of finalizing the document in preparation for submission
	to the IETF Internet-Drafts process.

	Discussion will also focus on ways to "beta test" the document
        (i.e., who can we give it to, who can review that is actually 
        in the position of having to implement site security policies).

	We will be posting the most current draft of the Handbook
	on Monday, November 26th.  Stay tuned for further information
	on where to obtain the document, and please make time to
	READ, before we meet at the Boulder IETF.

	Thanks, Joyce and Paul



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07306;
          16 Nov 90 21:29 EST
Received: from VENERA.ISI.EDU by cert.sei.cmu.edu (5.61/2.2)
        id AA02181; Fri, 16 Nov 90 15:31:41 -0500
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA00669>; Fri, 16 Nov 90 12:31:35 -0800
Date: Fri, 16 Nov 90 12:31:35 PST
From: jkrey@venera.isi.edu
Posted-Date: Fri, 16 Nov 90 12:31:35 PST
Message-Id: <9011162031.AA11415@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA11415>; Fri, 16 Nov 90 12:31:35 PST
To: ssphwg@cert.sei.cmu.edu
Subject: SSPHWG Agenda - Boulder IETF
Cc: gvaudre@NRI.Reston.VA.US, jkrey@venera.isi.edu, mdavies@NRI.Reston.VA.US

crocker@tis.com, ph@cert.sei.cmu.edu, rdp@cert.sei.cmu.edu


			SSPHWG Agenda - Colorado
		Thursday, December 6, 9:00am-12Noon
			Co-Chairs:  
		J. Paul Holbrook, CERT (ph@cert.sei.cmu.edu)
		Joyce K. Reynolds, USC/ISI (jkrey@isi.edu)


	This session of the SSPHWG will be fully devoted to going
	through the current draft of our Handbook, with the intent
        of finalizing the document in preparation for submission
	to the IETF Internet-Drafts process.

	Discussion will also focus on ways to "beta test" the document
        (i.e., who can we give it to, who can review that is actually 
        in the position of having to implement site security policies).

	We will be posting the most current draft of the Handbook
	on Monday, November 26th.  Stay tuned for further information
	on where to obtain the document, and please make time to
	READ, before we meet at the Boulder IETF.

	Thanks, Joyce and Paul



Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa02391;
          26 Nov 90 16:12 EST
Received: from venera.isi.edu by cert.sei.cmu.edu (5.65/2.2)
        id AA17736; Mon, 26 Nov 90 15:36:41 -0500
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA25215>; Mon, 26 Nov 90 12:36:42 -0800
Date: Mon, 26 Nov 90 12:36:46 PST
From: jkrey@venera.isi.edu
Posted-Date: Mon, 26 Nov 90 12:36:46 PST
Message-Id: <9011262036.AA14978@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA14978>; Mon, 26 Nov 90 12:36:46 PST
To: ssphwg@cert.sei.cmu.edu
Subject: Security Policy Handbook - draft
Cc: crocker@tis.com, jkrey@venera.isi.edu, ph@cert.sei.cmu.edu


			SSPHWG Reading List
		for Thursday, December 6, 9:00am-12Noon


	The current draft of the Handbook can be obtained via
	anonymous FTP from host venera.isi.edu, with the pathname:

		pub/ssph-draft-26nov.txt  
	
	(Caution, file contains 249,218 bytes.)  Please bring your 
	copy along with you, as there will be a limited number of
	hardcopies available for distribution.


        This session of the SSPHWG will be fully devoted to going
        through the current draft of our Handbook, with the intent
        of finalizing the document in preparation for submission
        to the IETF Internet Drafts process.  Please devote some
	time to read the draft document before we meet on Thursday
	morning, 6-Dec-90.	






Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa02774;
          26 Nov 90 16:28 EST
Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.65/2.2)
        id AA17879; Mon, 26 Nov 90 15:58:28 -0500
Received: from localhost by taos.cert.sei.cmu.edu (5.65/2.3)
        id AA04576; Mon, 26 Nov 90 15:58:28 -0500
Message-Id: <9011262058.AA04576@taos.cert.sei.cmu.edu>;
To: ssphwg@cert.sei.cmu.edu
Subject: draft handbook availability and kudos
Date: Mon, 26 Nov 90 15:58:27 EST
From: J Paul Holbrook <ph@cert.sei.cmu.edu>;

To follow up on Joyce's message, you can also get a copy of the draft
handbook from via anonymous FTP from
cert.sei.cmu.edu:/pub/ssphwg/ssph-draft-26nov.txt.

I also want to publically who worked on this draft of the handbook.
The handbook is substantially improved over the first draft, and it
all comes from some hard work put in by people over the past weeks and
months.

Paul Holbrook







Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa14430;
          20 Dec 90 16:51 EST
Received: from VENERA.ISI.EDU by cert.sei.cmu.edu (5.65/2.2)
        id AA03508; Thu, 20 Dec 90 16:28:00 -0500
Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local)
	id <AA05022>; Thu, 20 Dec 90 13:27:55 -0800
Date: Thu, 20 Dec 90 13:27:49 PST
From: jkrey@venera.isi.edu
Posted-Date: Thu, 20 Dec 90 13:27:49 PST
Message-Id: <9012202127.AA02343@akamai.isi.edu>;
Received: by akamai.isi.edu (4.1/4.0.3-4)
	id <AA02343>; Thu, 20 Dec 90 13:27:49 PST
To: mdavies@NRI.Reston.VA.US, ssphwg@cert.sei.cmu.edu
Subject: SSPHWG minutes - Colorado
Cc: crocker@tis.com, jkrey@venera.isi.edu, ph@sei.cmu.edu


			SSPHWG Minutes - Colorado
		Thursday, December 6, 9:00am-12Noon
			Co-Chairs:  
		Joyce K. Reynolds, USC/ISI (jkrey@isi.edu)
		J. Paul Holbrook, CERT (ph@cert.sei.cmu.edu)


	This session of the SSPHWG was fully devoted to going
	through the current draft of the Handbook, with the intent
        of finalizing the document in preparation for submission
	to the IETF Internet-Drafts process by March 1991.

	Discussion will also focused on ways to "beta test" the 
        document.  

	The most current draft of the Handbook
	can be located on the machine: venera.isi.edu, 
	pub/ssph-draft-26nov.txt.


Attendees:

"Crocker, Steve"             <crocker@tis.com>;
"Dray, James"                <dray@st1.ncsl.nist.gov>;
"Fraser, Barbara"            <byf@sei.cmu.edu>;
"Holbrook, J. Paul"          <ph@sei.cmu.edu>;
"Kinley, Darren"             <kinley@crim.ca>;
"Kutz, William"              <Kutz@dockmaster.ncsc.mil>;
"Linn, John"                 <linn@zendia.enet.dec.com>;
"Long, Daniel"               <long@bbn.com>;
"Martin, Marilyn"            <martin@netcom.ubc.ca>;
"McKelvey, Karen"            <karen@cerf.net>;
"Ostapik, Fred"              <fred@nisc.sri.com>;
"Pethia, Richard"            <rdp@cert.sei.cmu.edu>;
"Reynolds, Joyce"            <jkrey@isi.edu>;
"Salo, Timothy"              <tjs@msc.edu>;
"Schiller, Jeffrey"          <jis@mit.edu>;
"Seaver, Tim"                <tas@mcnc.org>;
"Wood, C. Philip"            <cpw@lanl.gov>;

  




Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa11067;
          5 Mar 91 13:34 EST
Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2)
        id AA28329; Tue, 5 Mar 91 12:55:38 -0500
Received: by cic.net (4.1/SMI-4.1)
	id AA23467; Tue, 5 Mar 91 12:57:03 EST
Message-Id: <9103051757.AA23467@cic.net>;
To: ssphwg@cert.sei.cmu.edu, us-wg@nnsc.nsf.net
Cc: mdavies@NRI.Reston.VA.US, saag@tis.com
Subject: SSPHWG meeting agenda
Reply-To: holbrook@cic.net, jkrey@isi.edu
Date: Tue, 05 Mar 91 12:57:00 -0500
From: J Paul Holbrook <holbrook@nic.cic.net>;

The Site Security Policy Handbook Working Group (SSPHWG) will meet at
the IETF meeting in St. Louis on Tuesday, March 12 from 1:30 to
3:30pm.

The meeting will continue the review and revision of the Site Security
Policy Handbook.

Required reading: the Site Security Policy Handbook draft of November
28, 1990.  You can fetch this with anonymous ftp from
cert.sei.cmu.edu:/pub/ssphwg/ssph-draft-28nov.txt.

Warning: the draft is almost 250k, and more than 100 pages.  Please
bring your own copy of the document, as we will only have a limited
number available in St. Louis.


	J. Paul Holbrook
        CICNet
	holbrook@cic.net

	Joyce K. Reynolds
	USC/ISI
	jkrey@isi.edu

	ssphwg co-chairs




Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa12516;
          5 Mar 91 14:50 EST
Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2)
        id AA28329; Tue, 5 Mar 91 12:55:38 -0500
Received: by cic.net (4.1/SMI-4.1)
	id AA23467; Tue, 5 Mar 91 12:57:03 EST
Message-Id: <9103051757.AA23467@cic.net>;
To: ssphwg@cert.sei.cmu.edu, us-wg@nnsc.nsf.net
Cc: mdavies@NRI.Reston.VA.US, saag@tis.com
Subject: SSPHWG meeting agenda
Reply-To: holbrook@cic.net, jkrey@isi.edu
Date: Tue, 05 Mar 91 12:57:00 -0500
From: J Paul Holbrook <holbrook@nic.cic.net>;

The Site Security Policy Handbook Working Group (SSPHWG) will meet at
the IETF meeting in St. Louis on Tuesday, March 12 from 1:30 to
3:30pm.

The meeting will continue the review and revision of the Site Security
Policy Handbook.

Required reading: the Site Security Policy Handbook draft of November
28, 1990.  You can fetch this with anonymous ftp from
cert.sei.cmu.edu:/pub/ssphwg/ssph-draft-28nov.txt.

Warning: the draft is almost 250k, and more than 100 pages.  Please
bring your own copy of the document, as we will only have a limited
number available in St. Louis.


	J. Paul Holbrook
        CICNet
	holbrook@cic.net

	Joyce K. Reynolds
	USC/ISI
	jkrey@isi.edu

	ssphwg co-chairs




Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa09065;
          11 Mar 91 20:51 EST
Received: from BITNET.CC.CMU.EDU by cert.sei.cmu.edu (5.65/2.2)
        id AA26019; Mon, 11 Mar 91 20:28:33 -0500
Received: from HDETUD1.TUDelft.NL (MAILER@HDETUD1) by BITNET.CC.CMU.EDU with
 PMDF#10110; Mon, 11 Mar 1991 20:20 EST
Received: from hdetud11.TUDelft.NL by HDETUD1.TUDelft.NL (Mailer R2.07) with
 BSMTP id 0592; Mon, 11 Mar 91 21:15:05 MET
Received: by HDETUD11 (Mailer R2.07) id 2780; Mon, 11 Mar 91 21:16:23 MET
Date: Mon, 11 Mar 91 21:09:31 MET
From: Marnix Klooster <MARNIX%hdetud11.TUDelft.NL@bitnet.cc.cmu.edu>;
Subject: About Security Policy Handbook..
To: SSPHWG@cert.sei.cmu.edu
Message-Id: <66EEB07700003434@BITNET.CC.CMU.EDU>;

 
Hello!
 
We (two students Computer Science) are doing an investigation into
the security of a couple of systems at our University. This is the
Delft University of Technology in Delft, Holland.
 
For this investigation we would like to have the newest version of
your Security Policy Handbook. We couldn't get access to it using
anonymous ftp. The thing we are especially interested for is the
NCSC Evaluated Product List. So our question is:
- Would you please send us the newest version of the Security Policy
  Handbook?
- Or, would you please tell us where we can find that newest version?
- Or, would you please point us to the newest NCSC EPL?
 
We need this doc very fast; we hope you'll help us.
 
Awaiting your answer,
 
Marnix Klooster
Bob Lubbers


Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa08415;
          12 Mar 91 13:59 EST
Received: from msr.EPM.ORNL.GOV by cert.sei.cmu.edu (5.65/2.2)
        id AA29033; Tue, 12 Mar 91 13:30:12 -0500
Received: by msr.EPM.ORNL.GOV (5.61/1.34)
	id AA05462; Tue, 12 Mar 91 13:30:04 -0500
Date: Tue, 12 Mar 91 13:30:04 -0500
From: "Rob Sargent, Ph: 615-482-1999/615-481-6567" <gfy@msr.epm.ornl.gov>;
Message-Id: <9103121830.AA05462@msr.EPM.ORNL.GOV>;
To: ssphwg@cert.sei.cmu.edu
Subject: Change of address
Cc: sargentrl@ornl.gov

Please change my e-mail address in your records as follows:

Current address:
	gfy@msr.epm.ornl.gov

New Address:
	sargentrl@ornl.gov

Thanx - Robert L. Sargent


Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa11227;
          11 Apr 91 10:19 EDT
Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2)
        id AA01725; Thu, 11 Apr 91 09:49:08 -0400
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA12140; Thu, 11 Apr 91 09:51:46 EDT
Message-Id: <9104111351.AA12140@nic.cic.net>;
To: ssphwg@cert.sei.cmu.edu
Subject: Call for papers: Incident Handling Workshop
Date: Thu, 11 Apr 91 09:51:45 -0400
From: J Paul Holbrook <holbrook@cic.net>;

FYI.  


From: Richard Pethia <rdp@cert.sei.cmu.edu>;
Date: Wed, 10 Apr 91 17:3:27 EDT
Subject: call for papers


____________________________________________________________________________
                               Call for Papers

             Third Workshop on Computer Security Incident Handling
____________________________________________________________________________


Location and Dates:

Hyatt Dulles                                     August 6-8, 1991
At Dulles International Airport
Herndon, Virginia


Description:

The Third Workshop on Computer Security Incident Handling will consist
of tutorials, invited addresses, paper sessions, and workshop/
discussion sessions on topics relevant to responding to computer
security incidents. The presentations will provide a forum to discuss
advances in theory and practice that improve the state of this field.
Theoretical, applied, tutorial, or descriptive papers selected for
presentation will appear in the conference proceedings to be published
after the Workshop.  The Third Workshop on Computer Security Incident
Handling is sponsored by Carnegie Mellon University's Software
Engineering Institute.  Submissions are solicited for the following
sessions:

Tutorials (half-day):

Tutorials should cover topics such as network security and
methodologies/strategies for incident handling.  The purpose of each
tutorial should be to allow someone who has little or no knowledge
about incident handling to learn the basic issues/concepts in this
arena.

Paper Sessions:

Proposals for paper sessions (approximately 30 minutes in length)
should address one of the following areas:

   o Network intrusions (including case studies, etiologies, and 
       intrusion detection efforts)
   o Vendor activities
   o Procedures and policies for responding to incidents
   o Threats (including threat and attack models, descriptions of 
       coordinated efforts to intrude into networks, and cracking tools)
   o Legal issues
   o Tools
   o Vulnerabilities and malicious code
   o Ethical issues

Workshops (half-day):

Proposals to lead workshop sessions covering topics such as network 
security, relationships between incident response teams, and lessons 
learned from responding to incidents are also solicited.

Submissions:

Proposals should be 300 - 500 words in length. Please do not send
submissions that are significantly shorter or longer.  Papers must not
have been previously presented or published, nor currently submitted
for journal publication. Each manuscript will be submitted to a
rigorous refereeing process.  Proposals should have a title page that
includes the title of the paper, full name of its author(s),
affiliation(s), complete physical and electronic address(es), telephone
number(s), and a 300-500 word description of the purpose and major
ideas to be presented.

Deadlines:

May 17, 1991
Deadline for receipt of proposal

June 7, 1991 
Notification of accepted proposals

July 15, 1991
Camera-ready manuscripts must be received


Address for Submissions:

Send all submissions and questions to one of the Workshop Co-Chairs:

Richard Pethia
Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA  15213-3890
E-mail:  rdp@cert.sei.cmu.edu
Phone:  (412) 268-7739

or

Eugene Schultz
Lawrence Livermore National Laboratory
P.O. Box 808, L-303
Livermore, CA  94550
E-mail:  gschultz@cheetah.llnl.gov
Phone:  (415) 422-7781


Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa12039;
          7 May 91 14:21 EDT
Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2)
        id AA08793; Tue, 7 May 91 13:50:14 -0400
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA07344; Tue, 7 May 91 13:59:05 EDT
Message-Id: <9105071759.AA07344@nic.cic.net>;
To: ssphwg@cert.sei.cmu.edu
Subject: SSPH: last call for input is 5/15
Date: Tue, 07 May 91 13:59:02 -0400
From: J Paul Holbrook <holbrook@cic.net>;

May 15th is the deadline for input to the Site Security Policy
Handbook.  Once we have all the input, the goal is to get the SSPH
submitted as an Internet Draft by 6/1.  We'll allow one month for
comments from the general public, take that input, and work on getting
this submitted as an RFC by August, in time for the IETF in Atlanta.

So if you have any input (suggestions, additions to the bibliography,
corrections), please send them to your fearless editors Joyce Reynolds
and Paul Holbrook by 5/15.

Thanks,

Paul Holbrook   	holbrook@cic.net
Joyce K. Reynolds	jkrey@isi.edu

Site Security Policy Handbook Working Group co-chairs



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa09609;
          24 Jul 91 10:27 EDT
Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2)
        id AA05005; Wed, 24 Jul 91 09:59:59 -0400
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA25773; Wed, 24 Jul 91 10:03:02 EDT
Message-Id: <9107241403.AA25773@nic.cic.net>;
To: ssphwg@cert.sei.cmu.edu
Cc: mdavies@NRI.Reston.VA.US
Subject: SSPHWG Atlanta IETF meeting: agenda
Date: Wed, 24 Jul 91 10:03:00 -0400
From: J Paul Holbrook <holbrook@cic.net>;

The Site Security Policy Handbook Group will meet Tuesday, July 30
from 1:30 to 3:30pm. 

The agenda topic will be the future efforts of this group.  Now that
the Site Security Handbook (RFC1244) has been published, what should
the group do now?

Here are some possibilities.  We will discuss these and more in
Atlanta.  Discussion on the email list is also encouraged.

   -  The group could disband.

   -  The model used by groups such as the NOC Tools group is that we
start up again in about a year to produce a revision of the document.
The group could remain dormant until then.

   -  At the St. Louis meeting, Vint Cerf suggested that we might
sponsor a workshop based on this work to get representatives in to
work on creating their own site policies.  

   -  There was some talk of creating a Postscript version of the
document; we could still use some help with that task.

   - Several people have noted that the current document is much too
long to use to sell a decision maker on the idea of creating local
security policies.  We could create an executive summary of the
document; this would be useful to many people.


Optional reading: RFC1244, the Site Security Handbook.  We won't
discuss the contents of the handbook, but the handbook has been
revised extensively since the draft of November 28th which some may
have read.



Received: from [192.88.209.5] by NRI.NRI.Reston.VA.US id aa12207;
          27 Jul 91 19:04 EDT
Received: from relay1.UU.NET by cert.sei.cmu.edu (5.65/2.2)
        id AA07917; Sat, 27 Jul 91 18:32:05 -0400
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA27636; Sat, 27 Jul 91 18:32:06 -0400
Received: from nuchat.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 183131.14522; Sat, 27 Jul 1991 18:31:31 EDT
Received: by nuchat.sccsi.com (/\=-/\ Smail3.1.18.1 #18.3)
	id <m0k3ZeD-0000PgC@nuchat.sccsi.com>;; Fri, 26 Jul 91 16:24 CDT
Message-Id: <m0k3ZeD-0000PgC@nuchat.sccsi.com>;
Date: Fri, 26 Jul 91 16:24 CDT
From: Sam Parker <samp@nuchat.sccsi.com>;
To: ssphwg@cert.sei.cmu.edu
Subject: General Disscussion


Please put this address inside the maillist.  Thank you.



Received: from nic.cic.net by NRI.NRI.Reston.VA.US id aa14282;
          6 Aug 91 16:54 EDT
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA09660; Tue, 6 Aug 91 16:55:56 EDT
Message-Id: <9108062055.AA09660@nic.cic.net>;
To: ssphwg@cert.sei.cmu.edu
Cc: us-wg@nnsc.nsf.net, crocker@tis.com, ietf-manager@NRI.Reston.VA.US
Subject: Thanks to JKRey for a job well done
Reply-To: holbrook@cic.net, jkrey@isi.edu
Date: Tue, 06 Aug 91 16:55:54 -0400
From: J Paul Holbrook <holbrook@cic.net>;

Now that the Site Security Handbook has been released, Joyce Reynolds,
who has been co-chair of the Site Security Handbook Working Group
(SSPHWG) for the past year plus has decided to "retire" from
the group.  I will remain as the chair of the group.

With this message, I'm also requesting that the master lists of
working groups be updated to reflect Joyce's retirement from the
SSPHWG.  

The SSH would not have been published without Joyce's efforts.  I
couldn't have got such a monumental task done without her, and the any
usefulness the document has owes a large debt to her.

Thanks, Joyce!


J. Paul Holbrook
ssphwg (no-longer-co) chair
Internet: <holbrook@cic.net>;
(313) 998-7680


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa15012;
          6 Aug 91 17:18 EDT
Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2)
        id AA29189; Tue, 6 Aug 91 16:50:11 -0400
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA09660; Tue, 6 Aug 91 16:55:56 EDT
Message-Id: <9108062055.AA09660@nic.cic.net>;
To: ssphwg@cert.sei.cmu.edu
Cc: us-wg@nnsc.nsf.net, crocker@tis.com, ietf-manager@NRI.Reston.VA.US
Subject: Thanks to JKRey for a job well done
Reply-To: holbrook@cic.net, jkrey@isi.edu
Date: Tue, 06 Aug 91 16:55:54 -0400
From: J Paul Holbrook <holbrook@cic.net>;

Now that the Site Security Handbook has been released, Joyce Reynolds,
who has been co-chair of the Site Security Handbook Working Group
(SSPHWG) for the past year plus has decided to "retire" from
the group.  I will remain as the chair of the group.

With this message, I'm also requesting that the master lists of
working groups be updated to reflect Joyce's retirement from the
SSPHWG.  

The SSH would not have been published without Joyce's efforts.  I
couldn't have got such a monumental task done without her, and the any
usefulness the document has owes a large debt to her.

Thanks, Joyce!


J. Paul Holbrook
ssphwg (no-longer-co) chair
Internet: <holbrook@cic.net>;
(313) 998-7680


Received: from [192.88.209.5] by NRI.NRI.Reston.VA.US id aa15180;
          9 Aug 91 14:31 EDT
Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2)
        id AA00500; Fri, 9 Aug 91 14:02:56 -0400
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA13732; Fri, 9 Aug 91 14:08:44 EDT
Message-Id: <9108091808.AA13732@nic.cic.net>;
To: mdavies@NRI.Reston.VA.US
Cc: saag@tis.com, ssphwg@cert.sei.cmu.edu
Subject: SSPHWG Atlanta IETF minutes
Date: Fri, 09 Aug 91 14:08:40 -0400
From: J Paul Holbrook <holbrook@cic.net>;

MINUTES

The "Site Security Handbook", RFC 1244/FYI 8, was released just prior
to the Atlanta IETF meeting.

The SSH was the topic of a plenary presentation by Holbrook at the
Atlanta IETF meeting.

The SSPHWG met in Atlanta with the goal of deciding what to do next.
The meeting was attended by about five people, so the discussion was
limited.  

The group did agree to generate an executive summary of the document.
Al Hoover of ANS volunteered to work with Paul Holbrook on this
document.  The intent is to turn the summary into an informational RFC
as well.  The summary would be something you could give to local
decision makers to explain what the Site Security Handbook is all
about and what the general approach is.

There was some agreement that once the executive summary is available,
we can start pushing getting the word out about this document.  We
will almost certainly contact trade press, for example.

The group was vaguer about whether a workshop would be useful.  Unless
there are people to push on that issue, it won't happen.

At the conclusion of the meeting, Joyce K. Reynolds announced that she
would be 'retiring' as co-chair of the SSPHWG.  Joyce was truly the
glue that held the SSPHWG together; without her efforts, the Site
Security Handbook would never have been published.  Thanks, Joyce!


ATTENDEES

[To be included by Megan.]


Received: from [192.88.209.5] by NRI.NRI.Reston.VA.US id aa06849;
          13 Aug 91 9:45 EDT
Received: from ST1.NCSL.NIST.GOV by cert.sei.cmu.edu (5.65/2.2)
        id AA18481; Tue, 13 Aug 91 09:11:20 -0400
Received: by st1.ncsl.nist.gov (4.0/NBS-rbj.11)
	id AA20033; Tue, 13 Aug 91 09:22:13 PDT
Date: Tue, 13 Aug 91 09:22:13 PDT
From: Arthur (Arch)Oldehoef <oldehoef@st1.ncsl.nist.gov>;
Organization: National Institute of Standards and Technology
	formerly National Bureau of Standards
Disclaimer: Opinions expressed are those of the sender
	and do not reflect NIST policy or agreement.
Message-Id: <9108131622.AA20033@st1.ncsl.nist.gov>;
To: ssphwg@cert.sei.cmu.edu
Subject: Security Policy Handbook

Please email to me the latest copy (in postscript form)
of the
 


	Security Policy Handbook
	Eds. Holbrook and Reynolds

I currently have a working draft of the handbook that
was emailed to me in early June, but I understand that a
newer edition has been created.  Thanks.

Arthur E. Oldehoeft
National Computer Systems Laboratory
National Institute of Standards and Technology
Gaithersburg, MD

Internet: oldehoeft@ncsl.nist.gov


Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa09138;
          13 Aug 91 10:46 EDT
Received: from ST1.NCSL.NIST.GOV by cert.sei.cmu.edu (5.65/2.2)
        id AA18782; Tue, 13 Aug 91 10:15:25 -0400
Received: by st1.ncsl.nist.gov (4.0/NBS-rbj.11)
	id AA20296; Tue, 13 Aug 91 10:26:14 PDT
Date: Tue, 13 Aug 91 10:26:14 PDT
From: Arthur (Arch)Oldehoef <oldehoef@st1.ncsl.nist.gov>;
Organization: National Institute of Standards and Technology
	formerly National Bureau of Standards
Disclaimer: Opinions expressed are those of the sender
	and do not reflect NIST policy or agreement.
Message-Id: <9108131726.AA20296@st1.ncsl.nist.gov>;
To: ssphwg@cert.sei.cmu.edu
Subject: Security Policy Handbook

Please email to me the latest copy (in postscript form)
of the
 


	Security Policy Handbook
	Eds. Holbrook and Reynolds

I currently have a working draft of the handbook that
was emailed to me in early June, but I understand that a
newer edition has been created.  Thanks.

Arthur E. Oldehoeft
National Computer Systems Laboratory
National Institute of Standards and Technology
Gaithersburg, MD

Internet: oldehoeft@ncsl.nist.gov



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07001;
          5 Sep 91 8:38 EDT
Received: from mcsun.EU.net by cert.sei.cmu.edu (5.65/2.2)
        id AA00494; Thu, 5 Sep 91 07:58:39 -0400
Received: from kestrel.ukc.ac.uk by mcsun.EU.net with SMTP;
	id AA01203 (5.65a/CWI-2.106); Thu, 5 Sep 1991 03:33:26 +0200
Received: from datasci.co.uk by kestrel.Ukc.AC.UK   via PSS (UKC CAMEL FTP)
           id aa19206; 4 Sep 91 16:16 BST
From: Dave Roberts <dwr@datasci.co.uk>;
Date: Wed, 4 Sep 91 16:15:05 GMT
Message-Id: <9054.9109041615@sun20.datasci.co.uk>;
Comments: NOTE the change of NAME in case of problems try
X1:         UK.CO.DATASCI@UK.AC.UKC
To: ssphwg@cert.sei.cmu.edu
Subject: Comments on SITE SECURITY HANDBOOK


Network Working Group
Request for Comments:  1244 
FYI:  8 
Site Security Handbook


You say that
>   ....  we encourage feedback from users of this
>   handbook.  In particular, those who utilize this document to craft
>   their own policies and procedures.

I hope the following comments are of some use, based on some experience
of writing a book on Security Policies and co-authoring a set of Government
sponsored Commercial Computer Security Evaluation Criteria.

>1.3  Definitions
>
>........
>
>   The term "decision maker" refers to those people at a site who set or
>   approve policy.  These are often (but not always) the people who own
>   the resources.

The term "owner" is very technical and, in my experience, oddly emotional
in its effect on documents.  I suggest it is avoided whenever possible.
Suggested new last sentence:
<<These are often (but not always) different from the "system
administrator(s)">>

---------------------------------------

>1.7  Basic Approach
>
>   .....  One old truism in security is that the cost of
>   protecting yourself against a threat should be less than the cost
>   recovering if the threat were to strike you.  

This may be true in simple cases, like jewellery theft, but compusec is often
concerned with intangibles such as loss of confidentiality, loss of trust, etc.
which cannot easily be costed.  When there is no obvious cash-dependent way of
fixing the problem it tends to be regarded as priceless or worthless;  neither
of these fits your alleged truism.

---------------------------------------

>1.8  Organization of this Document
>
>    ..............
>
>     The rest of this document provides references and an annotated
>     bibliography.

One of the annexes should contain a model policy;  or, at least, a model
contents list for use as a checklist of "have we thought of everything?"

I could suggest one, but it would be from my own book and I hesitate to push
that far!  If you want my model policy, I will send it on request!

--------------------------------------

>   2.1.2  Who Makes the Policy?
>
>      Policy creation must be a joint effort by technical personnel, who
>      understand the full ramifications of the proposed policy ...... 

Ho! Ho! Ho!  -  I have yet to meet technical staff who can understand the
technical ramifications of security policy, let alone the legal, fiscal,
moral, commercial, etc.

-------------------------------------

>   2.2.1  General Discussion
>
>     ..........
>      The old security adage
>      says that you should not spend more to protect something than it
>      is actually worth.

Another "old security adage" which does not cope with intangibles.

-------------------------------------

>   2.2.2  Identifying the Assets
>
>      One list of categories is suggested by Pfleeger [16, PFLEEGER,
>      page 459]; this list is adapted from that source:

Pfleeger also ignores the intangibles.  An academic example is if someone
gets hold of the unique experimental results on which my Ph.D. is to be based
and publishes first!

-------------------------------------

>    2.2.3  Identifying the Threats
>
>      The following sections describe a few of the possible threats.
>

I suggest that there is another subparagraph here as follows:

<<2.2.3.4  Loss of Integrity

If an intruder amends a file in a small, but obvious, way there will be a
doubt in the users' minds about all the rest of the data.  This can be a
catastrophe in business.  Think of your own reaction to a bank whose computer
randomly adds or subtracts a few pennies on every tenth, or so, transaction.>>

------------------------------------

>   2.3.3  Who Is Authorized to Grant Access and Approve Usage?
>
>     .............
>
>      Some
>      sites choose to disable accounts that have never been accessed,
>      and force the owner to reauthorize opening the account.

Please suggest that this is done within a limited time, say 24hrs, after
the issue of the account.

------------------------------------

>   2.3.5  What Are The Users' Rights and Responsibilities?

Please put in a note that US laws on privacy are not universal;  in most 
European countries there is NO equivalent right to privacy whatsoever.

------------------------------------

> Same section
>
>         4. Does the policy deal appropriately with all different
>            forms of communications and record keeping with the office?

I do not understand this question; it is fine if you delete the last three
words, but they don't seem to mean a thing as they are written!

------------------------------------

>    2.4.3  Defining Contacts and Responsibilities to Outside
>          Organizations
>
>    ..............
>
>         o Can data be released?  What kind?
>
>      Detailed contact information should be readily available along
>      with clearly defined procedures to follow.

To whom such data may be released is an important problem.  The difficulty
experienced in authenticating the authorities at a remote and unrelated site
should not be forgotten.  The data must not be released to the hacker
masquerading as the remote system manager.

-------------------------------------  

>2.5  Locking In or Out
>
>   .............
>
>   The alternate approach, "Pursue and Prosecute", adopts the opposite
>   philosophy and goals.  The primary goal is to allow intruders to
>   continue their activities at the site until the site can identify the
>   responsible persons.  This approach is endorsed by law enforcement
>   agencies and prosecutors.  The drawback is that the agencies cannot
>   exempt a site from possible user lawsuits if damage is done to their
>   systems and data.

There is a possible problem of tacit approval being claimed by the hacker
if he can show that you let him in repeatedly just to watch what he did.
I believe that this is a facet of "entrapment" in US law.

-----------------------------------

>  same section
>
>   Prosecution is not the only outcome possible if the intruder is
>   identified.  If the culprit is an employee or a student, the
>   organization may choose to take disciplinary actions.  The computer
>   security policy needs to spell out the choices and how they will be
>   selected if an intruder is caught.

This depends on the legal position in the country concerned.  It may be 
illegal to conceal a crime.

------------------------------

>  same section
>
>   Protect and Proceed
>
>      2. If continued penetration could result in great
>         financial risk.

Not just financial - see comments about intangibles above.

-----------------------------

>  same section
>
>   Protect and Proceed
>
>      3. If the possibility or willingness to prosecute
>         is not present.

May be compulsory - security policy should not contravene national law.

-----------------------------------  

>  same section
>
>   Protect and Proceed
>
>      4. If user base is unknown.

How can this possibly be?  Do you mean nobody logs in, in which case your
security policy is to let anybody do anything????!!!!

-----------------------------------


>   Pursue and Prosecute
>
>      10. If there is willingness on the part of management to
>          prosecute.

At the risk of repetitiveness -- they may have no choice.

-----------------------------------

>2.6  Interpreting the Policy
>
>   It is important to define who will interpret the policy.  This could
>   be an individual or a committee. 

NEVER let a single individual have unique power.  This is creating what an
engineer would call a "single point of failure" and is a vulnerability.
Quite apart from the 100% trust you are placing in this person's honesty, 
what happens if he/she visits a circus and is eaten by a lion? (Or something)

-----------------------------------

>   3.2.3  Software Bugs
>
>      Software will never be bug free.  Publicly known security bugs are
>      common methods of unauthorized entry.  Part of the solution to
>      this problem is to be aware of the security problems and to update
>      the software when problems are detected.  When bugs are found,
>      they should be reported to the vendor so that a solution to the
>      problem can be implemented and distributed.

Be aware that vendors often don't.  By all means report what you find but do
NOT assume that the vendor will volunteer information which you need.

----------------------------------

>   3.2.4  "Insider" Threats
>
>      An insider to the organization may be a considerable threat to the
>      security of the computer systems.  ....
>                                                       Access to a
>      local area network provides the ability to view possibly sensitive
>      data traversing the network.

This is a very important point and should be given much more emphasis.

---------------------------------

>3.5 Physical Security
>
>   .......
>
>
>   For machines that seem or are intended to be physically secure, care
>   should be taken about who has access to the machines.  Remember that
>   custodial and maintenance staff often have keys to rooms.

Do not forget that rooms need to be cleaned!  In a secure room ONLY trusted
personnel push a broom.

---------------------------------

>      3.6.2.1  Logging
>
>        .....
>
>
>            - Compare lists of currently logged in users and past
>              login histories.  Most users typically log in and out
>              at roughly the same time each day.  

Certainly untrue in many industrial situations, although probably generally
true for office environments.
            
-------------------------------

>       same section
>
>
>                                        For example, a large number of
>              failed login attempts in a short period of time may
>              indicate someone trying to guess passwords.

A large number of failed login attempts in a very short time (eg more than 
one attempt per second) usually means a noisy carrier or a loose connection!

-------------------------------

>        same section
>
>            - Operating system commands which list currently executing
>              processes can be used to detect users running programs
>              they are not authorized to use, as well as to detect
>              unauthorized programs which have been started by an
>              intruder.
>

We have two problems here:

a)	If a user is not authorised to use a particular program then
	why does he/she have execute access to it?

b)	If an intruder is running ANYTHING then he/she is obviously authorised
	to run that "thing" and hence is known to the system and hence NOT an
	intruder.  (Login always excepted, of course).

--------------------------------   

>      3.8.2.1  Account Management Procedures
>
>         ...........
>
>         Accounts without passwords are generally very dangerous since
>         they allow anyone to access the system.  
>         ...........
>                                 You should carefully weigh the benefits
>         that an account without a password provides against the
>         security risks of providing such access to your system.

THEN you should ALWAYS decide not to have any.

-------------------------------

>        same section
>
>         ..........
>
>                                        Whenever a privileged user
>         leaves the organization or no longer has need of the privileged
>         account, the passwords on all privileged accounts should be
>         changed.

For emphasis change to "Whenever ANY privileged user ..."

-------------------------------

>   3.9.3  Origin Authentication
>
>      ......
>
>                           The Internet standard for privacy enhanced mail
>      makes use of the RSA system.

Some mention should be made here of the fact that RSA is a privately owned
crypto algorithm and can only be used with an appropriate license.

-------------------------------


>   3.9.4  Information Integrity
>
>      Information integrity refers to the state of information such that
>      it is complete, correct, and unchanged from the last time in which
>      it was verified to be in an "integral" state.  

Please replace "integral" with "correct" and avoid the mathematicians getting 
confused.

---------------------------

>     same section
>
>      .........
>
>      It should be noted that there are other aspects to maintaining
>      system integrity besides these mechanisms, such as two-person
>      controls, and integrity validation procedures.  These are beyond
>      the scope of this document.

WHY????  The use of two-person creation of new accounts on a system is now
in widespread use. So is the propose/authorise sequence for fiscal transactions
in banks, etc.  It is simple enough to explain.

----------------------------

>   3.9.6 Authentication Systems
>
>      .............
>
>      Challenge/Response mechanisms improve upon passwords by prompting
>      the user for some piece of information shared by both the computer
>      and the user (such as mother's maiden name, etc.).

?????  easily discovered information - even a password is safer than this.

-----------------------------

>   3.9.7.1 Security Mailing Lists
       TO
>   3.9.7.7 Professional Societies and Journals

These lists should be in section 8 with the other references and contacts.
(indeed, some entries are duplicated there!

------------------------------

>   3.9.9  Communication Among Administrators

Good - but

>      3.9.9.1  Secure Operating Systems

does not fit here;  again move to section 8

------------------------------  

>   4.3.1  Password Selection
>
>      ............
>
>      Some systems provide software which forces users to change their
>      passwords on a regular basis.  Many of these systems also include
>      password generators which provide the user with a set of passwords
>      to choose from.  The user is not permitted to make up his or her
>      own password.  There are arguments both for and against systems
>      such as these.  On the one hand, by using generated passwords,
>      users are prevented from selecting insecure passwords.  On the
>      other hand, unless the generator is good at making up easy to
>      remember passwords, users will begin writing them down in order to
>      remember them.

Another disadvantage is that most of these use concatenations from syllable
lists and these can all be tried mechanically, just as the dictionary attacks 
can try all English words.

------------------------

> 5. Incident handling

SOMEWHERE in this section, probably in 5.1 it is essential to have the most 
obvious piece of advice:

Do not leave the only copy of "WHAT TO DO IN CASE OF FIRE IN THE COMPUTER ROOM"
in the computer room!

------------------------

> 5.2  Evaluation

Please re-title as "5.2 Incident Evaluation" to avoid confusion with "Security
Evaluation".

------------------------

>   5.2.1  Is It Real?
>
>    ............
>
>         o Changes in file lengths or dates (e.g., a user should
>           be suspicious if he/she observes that the .EXE files in
>           an MS DOS computer have unexplainedly grown
>           by over 1800 bytes).

Not just be "over 1800 bytes" - some viruses can lengthen by as little as
60 or so bytes.

-------------------------

> 5.3  Possible Types of Notification

Somewhere in this section there should be a note on having preset ways of
proving the authenticity of notifications.  Round about 1st April it is 
important to know whether the notification I have just received is real - or 
a joke.

--------------------------

>   5.4.2  Consider Designating a "Single Point of Contact"

This has its attractions - but do not let the "Single Point of Contact" become
either a "single point of failure" or a "bottleneck".

---------------------------

> 8.2  Computer Security

You could add:

   [ROBERTS]
           Roberts, D.W., "Computer Security; Policy, Planning and Practice", 
           NCC Blackwell, ISBN 0 86353 180 6.

           This is a really practical guide to planning and implementing a
           comprehensive company security policy.


but I think I have a cheek suggesting it!

---------------------------

I hope that these comments are of some use to you.

I think that the draft I have seen has the makings of a very useful document
if the user community can be persuaded to read it and to apply it.

Regards

David Roberts



Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa11112;
          5 Sep 91 10:48 EDT
Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2)
        id AA01246; Thu, 5 Sep 91 10:10:25 -0400
Received: by nic.cic.net (4.1/SMI-4.1)
	id AA15653; Thu, 5 Sep 91 10:11:08 EDT
Message-Id: <9109051411.AA15653@nic.cic.net>;
To: Dave Roberts <dwr@datasci.co.uk>;
Cc: ssphwg@cert.sei.cmu.edu
Subject: Re: Comments on SITE SECURITY HANDBOOK 
In-Reply-To: Your message of "Wed, 04 Sep 91 16:15:05 GMT."
             <9054.9109041615@sun20.datasci.co.uk>; 
Date: Thu, 05 Sep 91 10:11:07 -0400
From: J Paul Holbrook <holbrook@cic.net>;

David Roberts,

Thank you for your many insightful comments.

We certainly appreciate getting comments from someone who has
obviously spent a great deal of time thinking about these issues.

The current document has closed, but we do intend to revisit the
document in about a year to update and improve it with the comments
we hope to receive.

When we get to the point of revising the document again, would you be
willing to help review changes?

J. Paul Holbrook
ssphwg chair
Internet: <holbrook@cic.net>;
(313) 998-7680