Programmers can assist in the effort of security by reducingthe chance that a potential intruder can exploit a hole or bugthat is coded into locally developed software.  There is probablya lot that can be said about this, and their are probably manybooks on the subject somewhere.  But, here are some commonrecommendations:  (a) Never create a SETUID shell script.  Thereare well-known techniques used by intruders to gain access to ashell program that is running as root; (b) List the complete filename, including the full path in any system() or popen() call;and (c) Since there is no reason for users to have read access toa SETUID file (or any exectuble for that matter), set permissionsto 4711 (SETUID) or 711 (Non-SETUID).<P><H4> 3.5.8  Counterintelligence</H4><P>     To extend your security program to seek out, identify, andlocate intruders;  you may want to modify some of the securitytools (especially those proxy service daemons and event-drivenauditors) to trace intruders back to their source, and otherwisemaintain logs of data on intrusion attempts.  This informationcan prove vital in taking an offensive stance against securitybreak-in's and can help prosecute offenders.<P><H4>3.5.9  Other Possibilities</H4><P>     Depending on your requirements you might look intospecialized solutions such as Compartmented Mode Workstations(CMW), end-to-end Data Link Encryption (STU-III, Motorola NES,and XEROX XEU are examples), and TEMPEST.  The NCSC (RainbowSeries) and ITSEC specifications can help you define what levelof need you have for security and help lead you to additionaltypes of solutions.<P><H3>3.6  SECURITY POLICY</H3><P>     Everything discussed in layers {1...5} (sections 3.1 to 3.5)above involve specific things you can do, tools and techniques toimplement, to address a particular area or "hole" in security.   Your SECURITY POLICY is what ties all of that together into acohesive and effective SECURITY PROGRAM.  There are many diverseissues to consider when formulating your policy, which alone isone of the biggest reasons why you must have one:<P><pre>         What are the functional requirements of your          network?         How secure do you need to be?  What needs to          be protected?         How will you handle incident reporting and          prosecution?         What does the law require you to do?  What          about privacy?  Since break-ins often occur          via multiple hops on computers throughout the          US and the rest of the world, you will need          to consider a variation of federal, state,          local, as well as foreign laws.         Make security a dedicated and deliberate          effort.         User training and security awareness.         What is considered acceptable use for users?             Do the users understand what it is they are          permitted to do and what it is they are not          permitted to do?         What is considered acceptable use for system          administration staff?  Is using Crack to test          passwords okay?  Is giving friends outside          the organization accounts okay?         Maintain a working relationship with the          Computer Emergency Response Team (CERT) at          Carnegie Mellon University (CMU) and your          Forum of Incident Response and Security Teams          (FIRST) regional representative "CERT" team.         PLUS a myriad of different issues too          numerous to go  into in a summary paper.</pre><P>     By answering these questions you determine what packages andmethods in layers {1...5} (or their equivalent) that you want toimplement, and in what ways you want to modify or configure them.   "A security policy is a formal specification of the rules bywhich people are given access to a computer and its resources."   (and to extend that to say...a network and its resources).   Whatever tools you install to help you maintain the security ofyour network and monitor it, they must be configured to implementYOUR POLICY, or else they are not doing the whole job that needsto be done.  Therefore, you must first have a POLICY.<P>     For additional help in the area of policy development,contact cert@cert.org.  They can direct you to usefuldocumentation on the subject and guide you to your FIRST regionalCERT team representative.  A good starting point is Request ForComments (RFC) 1244 "Site Security Handbook" (96 pages), which isavailable via anonymous FTP from numerous RFC archive sites (forexample:  nic.ddn.mil).<P><H2>4.  SUMMARY OF AVAILABILITY</H2><P><pre>Section   Name           Availability3.2       Router         Cisco, Wellfleet, Proteon3.3.1     Tcp_wrapper    cert.org:/pub/tools/tcp_wrappers3.3.2     Socks          s1.gov:/pub/socks.tar.Z3.3.3     Kernel_wrap    eecs.nwu.edu:/pub/securelib3.3.4     Swatch         sierra.stanford.edu:/pub/sources3.3.5     CAP            e-mail to thompsond@orvb.saic.com3.3.6     Mail Gateway3.3.7     Tty_wrapper3.3.8     HSC-Gatekeeper e-mail to Herve.Schauer@hsc-sec.fr3.3.9     AT&T INET      e-mail to ches@research.att.com3.4.1     COPS           cert.org:/pub/tools/cops3.4.2     Chkacct        cc.perdue.edu:/pub/chkacctv1.1.tar.Z3.4.3     Crack          cert.org:/pub/tools/crack/crack_4.1-tar.Z3.4.4     Shadow         comp.sources.misc (jfh@rpp386.cactus.org).3.4.5     Passwd+        dartmouth.edu:/pub/passwd+tar.Z3.4.6     Audit          e-mail to bjorn@sysadmin.com3.4.7     Miro           e-mail to miro@cs.cmu.edu3.5.1     Key-card       e-mail to cert@cert.org3.5.2     TIS/PEM        e-mail to pem-info@tis.com3.5.3     Kerberos       athena-dist.mit.edu:/pub/kerberos53.5.4     Private-key    contact Don Davis, at Geer Zolot Assoc.3.5.5     MLS            contact your UNIX vendor3.5.6     File encrypt   contact your UNIX vendor3.5.7     Programming3.5.8     Counter-Intel3.5.9     Other Poss.    research and contact various vendors3.6       Policy         RFC 1244 and cert@cert.org</pre><P><H2>5.  ADDITIONAL SOURCES OF INFORMATION</H2><P>     There are several primary sources of information that you cantap into (and correspond with) to keep up to date with currenthappenings in the general network security and in specific the"firewall" community.  I recommend subscribing to the followingmailing lists:  (a) cert-advisory-request@cert.org; (b) cert-tools-request@cert.org, and (c) firewalls@greatcircle.com.  In additionto that read and participate in the following USENET newsgroups:   (a) comp.security.announce (which echos the CERT advisory mailinglist); (b) comp.security.misc; (c) alt.security (frequentlydissolves into "flame wars"); (d) comp.risks; and (e) comp.virus(almost exclusively for discussing PC and MAC viruses).  Also, youcan copy files from the CERT USENET Clipping Archive via anonymousFTP from cert.org.<P><pre>CERT Contact Information:Emergencies:   +1 412 268-7090FAX:           +1 412 268-6989E-mail:        cert@cert.org</pre><P><pre>U.S. Mail:     CERT Coordination Center               Software Engineering Institute               Carnegie Mellon University               4500 Fifth Avenue               Pittsburgh, PA 15213-3890, USA</pre><P>USENIX Papers are available directly from USENIX:<P>The USENIX Association<br>2560 Ninth Street, Suite 215<BR>Berkeley, CA 94710, USA<P><H2>6.  Acknowledgements</H2><P>     The author extends thanks to several of the authors of thetools discussed in this paper and others for providing feedbackthat effected several changes in the first couple drafts of thispaper.  This includes but, is not limited to the following:  EdDeHart (CERT), Jim Ellis (CERT), David and Michelle Koblas (SOCKS),Herve Schauer (Gatekeeper), Dan Farmer (COPS), D. Brent Chapman(firewalls@greatcircle.com), and Matt Bishop (Editor).<P><H2>7.  References</H2><P><pre>[1]  S. Carl-Mitchell and John S. Quarterman, Building Internet        Firewalls. UnixWorld; February, 1992; pp 93-102.[2]  Wietse Venema.  TCP Wrapper: Network Monitoring, Access     Control and Booby Traps.  USENIX Proceedings, UNIX Security     Symposium III; September 1992.[3]  David and Michelle Koblas.  SOCKS.  USENIX Proceedings, UNIX     Security Symposium III; September 1992.[4]  William LeFebvre.  Restricting Access to System Daemons Under     SunOS.  USENIX Proceedings, UNIX Security Symposium III;     September 1992.[5]  D. Brent Chapman.  Network (In)Security Through IP Packet     Filtering.  USENIX Proceedings, UNIX Security Symposium III;     September 1992.[6]  Stephen E. Hansen and E. Todd Atkins.  Centralized System     Monitoring with Swatch.  USENIX Proceedings, UNIX Security     Symposium III; September 1992.[7]  J. David Thompson and Kate Arndt.  A Secure Public Network     Access Mechanism.  USENIX Proceedings, UNIX Security Symposium     III; September 1992.[8]  Herve Schauer.  An Internet Gatekeeper.  USENIX Proceedings,     UNIX Security Symposium III; September 1992.[9]  William Cheswick.  The Design of a Secure Internet Gateway.        Murray Hill, NJ:  AT&T Bell Laboratories.[10] Garfinkel, Simson, and Gene Spafford.  Firewall Machines.        Practical UNIX Security.  Sabastopol, CA: O'Reilly and     Associates, Inc., 1991.[11] Shabbir J. Safdar.  Giving Customers the Tools to Protect     Themselves.  USENIX Proceedings, UNIX Security Symposium III;     September 1992.[12] John F. Haugh, II.  Introduction to the Shadow Password Suite.        USENIX Proceedings, UNIX Security Symposium III; September     1992.[13] Matt Bishop.  Anatomy of a Proactive Password Checker.  USENIX     Proceedings, UNIX Security Symposium III; September 1992.[14] Bjorn Satdeva.  Audit: A Policy Driven Security Checker for a     Heterogeneous Environment.  USENIX Proceedings, UNIX Security     Symposium III; September 1992.[15] Allan Heydon and J.D. Tygar.  Specifying and Checking UNIX     Security Constraints.  USENIX Proceedings, UNIX Security     Symposium III; September 1992.   [16] James M. Galvin and David M. Balenson.  Security Aspects of a     UNIX PEM Implementation.  USENIX Proceedings, UNIX Security     Symposium III; September 1992.[17] Don Davis.  Network Security Via Private-Key Certificates.        USENIX Proceedings, UNIX Security Symposium III; September     1992.</PRE><P>------------------------NOTICE---DISCLAIMER------------------------<br>The contents of this paper do not necessarily reflect the opinionsof my employer or anyone else that I know.  Nothing in this papershould be construed as a product endorsement.  No warranty isexpressed or implied.  Any comments?  Please send me e-mail.-------------------------------------------------------------------<P>------------------------NOTICE---COPYRIGHT-------------------------<br>(c) Copyright 1992,1993 Robert B. Reinhardt.  This paper may bedistributabed freely as long as the paper is not modified in any way,includes this notice, and is provided without guarantee or warrantyexpressed or implied.  E-mail comments to breinhar@access.digex.com-------------------------------------------------------------------</pre></body>