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 1990 14:20:26 -0700
From: Eliot <lear@turbo.bio.net>
To: ssphwg@cert.sei.cmu.edu, TYSON@warbucks.ai.sri.com
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
- Systems staff policy guidelines Mabry Tyson
- re: Systems staff policy guidelines Bryan Koch
- Re: Systems staff policy guidelines Eliot