ftp.intel.com/2015-02-03.ftp.intel.com.tar/ftp.intel.com/Pub/papers/horses.txt

Text File | 2010-04-27 | 36KB | 864 lines

This ascii version of the paper is missing the graph which
shows the growth of our Internet usage.  This growth mirrors
the growth of Internet usage in general.  The text is the
same as the Postscript version.



                            Horses and Barn Doors:
              Evolution of Corporate Guidelines for Internet Useage


                                Sally Hambridge
                              Jeffrey C. Sedayao

                                  Intel Corp.
**********************************************************************
cc:Mail is a registered trademark of Lotus Corporation.
**********************************************************************

Abstract:

    Intel's Internet usage policy evolved from practically
non-existant to explicitly defined - all in reaction to
changing conditions and security threats.  This paper covers
the evolution of Intel Internet access policy, a continual
struggle to close the barn doors before the horses get out.
Throughout the paper, we outline key lessons we have
learned during the policy-making process.
It discusses Intel's first taste of the Internet,
Intel's policy-making process, the open access policy of
that period, and the resulting security challenges.
It then covers the imposition of a stricter
policy and implementing a firewall to enforce that policy.
The paper proceeds to describe today's problems, the majority
of which center around Intel people accessing the Internet.
In response to this problem and growing numbers of people wanting
to use the Internet, Intel has drawn up explicit corporate guidelines
on Internet use.  These guidelines are then compared to various
Acceptable Use Policies and Netiquette guides.  The paper concludes
with some additional tasks Intel is planning in order to keep the barn
doors closed.

Intel's Introduction to the Internet:

Intel Corporation has had access to the Internet since 1987.
At that time, we had a dial-up connection to the now defunct CSNET.
We dialed Boston from Santa Clara, California several times a day
to pick up and drop off mail.  We did not have any kind of Internet
access policy.  We felt secure in having complete copies of all
messages sent in and out and having our modems block dial-ins.

While the dial-up connection provided much-needed mail access
to and from customers, vendors, and research partners, functionality
was too limited.  Delivery was so slow at times (days!) that paper
proved a quicker and more reliable communication medium.  Users
complained that carrier pigeons would deliver mail faster.
The long distance calls grew to be expensive.
Because of these concerns and the desire for direct FTP and telnet
access to the Internet, in 1989 we traded our CSNET dial-up connection
for one with direct IP access over a leased line.  An increase in
functionality always means an increase in risk, as we will see in
the next section.


The Challenges of an open door:

Our first policy was this:  anyone in the company could go out on the
Internet, and rlogin, telnet and FTP access into Intel would be blocked.
WE were the access providers, and so we imposed this policy
unilaterally.  The only place this was written down was in the router
access list configuration.

What were the results of our (wide) open door?  We received many
complaints about Internet access from various system administrators
around the company.  They did not like the gaping door.  Later, with
unsolicited help from federal agents, we found some crackers who did.

Key Lesson #1 - Research Policy Issues

Key Lesson #2 - Consult with users and stakeholders on policy decisions

Key Lesson #3 - Make the policy available and readable.

Our policy was incredibly naive.  We did not think it through in
depth and did not realize how easy it would be for intruders to exploit
gaping holes.  Furthermore, we did not have buy-in to our policy.
System administrators weren't comfortable with it.  Even worse, they
were uncomfortable with a policy they couldn't even read.  Things had to
change.


Shutting the door part way:

The problems we encountered forced us to realize our mistakes.  We looked
into Internet access schemes implemented at other companies.  We wrote
down and proposed a limited access policy.  This document was circulated
for comment by electronic mail and presented at various user forums within
Intel.  Finally, we had the policy approved by an internal change
control group.  This was an official stamp that gave us legitimacy.

Our new policy restricted outbound Internet access to specific systems.
Inbound access was limited to certain protocols going to dedicated servers.
The outbound systems, controlled by site administrators, would be tightly
controlled.  Applications for Internet access systems would have to be signed
by site network managers, the system administrator's manager, and our internal
Information Security group.  Applicants promised to read and obey
our policy, which was circulated with the application forms.

Key Lesson #4 - Get key people to buy into a policy.  Better yet, get some
                kind of official stamp of approval.

Key Lesson #5 - Forms with signature loops are a way of making sure that
                people are serious about wanting something.  It is also a
                way to inform key parties of change and get
                their buy-in.

We managed to get people involved in making our policy.  They bought
into it, and we got an official stamp of approval from a internal group.
By using forms, we weeded out people who weren't serious about managing
Internet access systems.  Moreover, we gave our Information
Security group a chance to review and buy into the decision of
who would want access.

Key Lesson #6 - Provide metrics on usage and quality of service.

We made the decision that we would track how much the gateway was used
and who was using it.  We look at sheer volume, such as how many bytes
each access system exchanges with the Internet and how many messages
are exchanged through the gateway mail servers.  We also decided to
track some service metrics like mail delay through the gateway.
An Internet gateway status and usage report is produced and widely
distributed every quarter.

Keeping metrics has proven to be a good decision.  We can track
utilization, which helps us with capacity planning and with justifying
new equipment.  Management, initially unsure about funding our
gateway, is
usually persuaded when they see how much their people are using the
Internet.  Finally, keeping metrics gives us some idea how well we are
managing the gateway.

Ironically, by shutting the door part way, usage boomed.
Throughout the 6 years we have had mail capability,
we have witnessed an exponential growth in the amount of mail
coming into and going out of the company.  This growth
is consistent with Internet growth trends industry
wide. (See figures 1 and 2.) [1]  Since Intel is a multi-site,
multinational operation, almost all Intel sites dedicated
a number of machines to provide ftp and telnet capability
for groups within the site.

With growth in the number of Internet knowledgeable employees,
(as well as those who have heard of the Internet but know little)
we've seen demands for accounts on these machines skyrocket.
We've also seen a corresponding growth in different kind of
security problems - from Intel instead of to Intel.  Most of these
problems stem from people attempting logins to defunct accounts,
or naively trying to telnet to ftp machines and vice versa.
Still, even these innocent mistakes mean time and trouble.
This is time and trouble for the system manager of the machine
where the "break-in" is attempted as well as Intel's Internet
contact and the system administrator of the internal Intel machine
from which the "attempt" occurred. Intel personnel must then check
system logs to determine who was logged in at the time, then
contact those people to find out whether intent was indeed malicious.
All of this takes time from resources which function better as
network and system managers than High School Vice Principals.

We discovered that almost all of our policy focused on system and network
administrators and not on users.  Although we put conditions on how the
access systems should be administered, we did not provide any tools or
help to do so.  We should not have been surprised that some of the
Internet access systems were far more open than we liked.  The
incidents with misguided users sparked another fear.  We could
conceive scenarios [2] where a user could create an incident severe enough
to cause Intel to shut down or tremendously restrict our Internet connection.


Getting the horses to behave:

To combat these problems, an Internet Security Task Force was
formed.  This ad hoc group consists of representatives from Corporate
Information Security and system managers and users.
We had learned from past experience that
only by getting people involved could we create workable policies.

Corporate Information Security bears the responsibility of protecting
Intel's intellectual property assets.  This group sets policy and
procedures for Information Security, publishes a yearly summary of
those policies, and has recently developed a class on information
security for Intel employees.

In its Internet Policies, the Task Force has tried
to maintain a balance between getting people to information (and
information to people) and maintaining reasonable security.
First, although most of us eschew bureaucracy, we ask those
users requesting accounts on machines which have Internet
telnet and ftp access to justify having an account.  We have found
that many people think they need direct access to the Internet in
order to send Internet mail.  Since sending Internet mail is possible from
any networked machine at Intel, we inform the user how to send mail and this
eliminates the need for the account.  We do ask that the user
have a legitimate business reason for telnet and ftp access before we
grant the account.

Second, accounts on Internet accessible machines are set to expire
at 6 months.  If a user doesn't use the account enough to
notice it has expired, it will not be an open door.
This is a minor inconvenience to users who need
their accounts (especially compared to the benefits).

Key Lesson #7 - User education is critical

Key Lesson #8 - Create explicit and enforceable policies

Third, Intel has created a set of Internet Etiquette
Guidelines for Internet users (contained in appendix A).
The Task Force felt it needed
a distinct set of guidelines for a number of reasons:  First,
policies need to be explicit.  Tradition and word-of-mouth fail
to carry any legal consequence.  Second, existing Acceptable
Use Policies [3,4] are too generic.  Although most of these provide
good general guidelines, they do not deal with circumstances
specific to Intel or even specific to a business environment.
Third, we've found that Netiquette Guides [5] are good for beginning
users, but may not necessarily address behavior problems of the more
knowledgeable.

Increasingly, we have found that Intel employees fall
into 3 camps: those that know everything about the Internet;
those that know about the Internet but feel it's "just like
the computer bulletin boards I've used from home";
and those that have heard of it, know
that "good stuff is out there," but have no idea how
to proceed.  Although these groups
have very different levels of understanding all
indulge in behaviors which need governance.

The experienced user may have had access to the
Internet in previous jobs or in college.  That previous
experience may have been in an environment less demanding  than
Intel's, since the Corporation emphasizes a stringent work ethic
and places heavy demands on employee time.  Those employees
familiar with bulletin boards may have no clue as to the
global community in which they now find themselves,
and those new to the 'Net just have no clue.  Each needs help
understanding the environment.

Experienced users should be informed that Internet
use should indeed be work related.  Wanting to get to
Usenet Newgroups to keep up with discussions on rec.whatever is
not an acceptable reason for 'Net access, although needing to
stay current with comp.sys.intel certainly is.  Experienced
users should also understand that their role and responsibility
has changed.  As students at Wherever.edu no one cared what
they said in postings, but people form opinions of a company
based on its employee's communications.  Disclaimers don't
seem to matter, no matter how sincerely stated.  Strongly offended
readers focus on "intel.com" in mail and article headers.

Half-way knowledgable users need to be educated to
the ways of the Internet.  These users may be familiar with
other forums of computer communication, most likely PC-type
bulletin boards, or Prodigy/Compuserve models.  These users need
to know that their postings span countries and continents,
rather than a local community or even the US.
They need to learn the jargon and the context of
discussion groups.  They should "lurk" for a while before
jumping into discussions.

Inexperienced users need all the help available.
They need to know what kinds of  services are available, what
the community is, and how to interact with it.
With these communities in mind, the guidelines Intel provides
fall roughly into those covering technical/security issues,
those covering etiquette, and those to help new users. They are
broken into categories for electronic mail, mailing lists and
newsgroups, ftp, and telnet.

The electronic mail section covers such new user
concerns as SENDING MESSAGES IN CAPITALS, use of the smiley face
:-),  and watching punctuation and spelling while not
criticizing others' mistakes.  Etiquette, such as letting a
sender know a message was received (especially when one cannot
respond immediately) and having a signature file, is also
defined.  Issues such as taking care when sending replies,
sending plain ascii text (as many Intel users often
send PC file attachments in cc:Mail (r) ), and being aware
of system etiquette on their native system comprise the
technical issues addressed.  Finally we remind users that
electronic mail is unencrypted  and easily readable.

The section of the guidelines on Internet mailing lists and
Usenet News groups references the section on electronic mail.
This is by far the longest section of the guidelines since
all employees can send and receive Internet mail.  They are also
most likely to make
mistakes in this area, although in general these mistakes will
be less catastrophic than in telnet or ftp.  Here, we inform
users to disclaim speaking for Intel, and that even if they do,
they will represent the company de facto through having "Intel"
in the mail header.  Along with that technical warning, we
direct users to watch verbosity since many Internet sites pay by
the byte, to obey copyright law, and to be careful using
auto-reply features in mail.  We also tell them to change their
addresses with mailing lists when they change accounts.  There
are many guidelines covering straight etiquette: Monitor any
group you join for a while, No advertising of Intel products,
Don't re-post without permission, Summarize if you survey,
Indicate quoted material, No anonymous postings, and No postings
about that dying child in England (he got better)!  New users
are cautioned to make sure the subject of messages is clear in
the Subject: line, to think about how much time mailing lists or
news groups will absorb, to read the FAQs, to be careful of
flaming, and not to go overboard if they're flamed.

The section on ftp leans heavily toward technical
issues.  The only point of etiquette is that users should type
in real Internet addresses for passwords when accessing
anonymous ftp sites.  The other issues covered: do not
deliberately ftp to machines without ftp access, random
net-hunting is not approved; observe working or posted hours for
ftp sites and observe any restrictions posted at those sites;
look locally for ftp materials (where items are posted more than
once); and finally don't ftp on the "off chance you'll need the
information someday."

The telnet section is even more succinct, covering
posted restrictions, using only authorized ports, not not
deliberately telnetting into machines with no guest account.

There is a final section, listing a bibliography of
Internet resources for beginners.  It lists Kehoe [6], Krol [7] ,
LaQuey [8], and Tennant, et al [9].  Hopefully, the beginning
users armed with the Guidelines, and one of these publications,
can survive on the 'Net.

There is another section of the Guidelines listing
behavior which is subject to disciplinary action.   Here is where
our Guidelines differ most dramatically from generic Netiquette
guides, since these are areas where we do more than recommend
behavior.  The guidelines promise action for sending chain letters,
for using Intel equipment for personal gain, for sending sexually
or racially harassing messages, for unauthorized attempts to break
into any system (since Corporate Information Security occasionally
gets authorization to attempt break-ins), theft, or copying electronic
files without permission, sending Intel confidential materials
outside of Intel, and refusing to cooperate with a reasonable security
investigation.  These guidelines were specifically derived from the
Corporate Information Security guideline on mail and from the Human
Resources general guidelines.  Since this is policy and not procedure,
it does not include specific disciplinary actions which might be taken
but leaves that for Human Resources to sort out at the time of the incident.

The guidelines were drafted by one person and submitted to an
internal mailing list which included the Internet Security Task Force
and system managers of machines which have Internet access.  This draft
gathered comments from "It's fine the way it is" to "Change everything
about it".  Comments were incorporated into a second draft, which was
again circulated to the group.  Comments on this draft were minor, although
Corporate Information Security made a few specific requests, most having to
do with making implicit statements more explicit. (MAIL ON THE INTERNET
IS NOT SECURE being the major one.)  The final version was sent to the
internal mailing list of system managers for distribution to their users.
It was also made available for anonymous ftp within the company.

Finally, the policy was adopted as a formal Intel Policy.
We did have to get it approved by Intel's
legal staff.  Now we'd had our policies ratified.


Keeping the Barn Doors Closed:

Key Lesson #9 - Policy transitions can be hard, especially when you have
                to take something away.

Although we have drawn up new "official" policies, we find that it
can be hard to get people to transition to them.  It is especially
difficult when people lose privileges they once had.  For example,
we would like to reduce the number of Internet access machines at each
site.  Getting groups to give up their access is not easy, especially if
they have had their own access system for several years.  We have found
the best time to get people to implement policy changes is after
an incident has occurred.  While this truly is closing the barn doors
after the horses are out, it definitely prevents any more horses from leaving.
After implementing the policy on some of the major access nodes, we have
had a drop in reported incidents from them.

We need to improve our user education.  Although we have created
guidelines and even an Intel Internet user guide, it is obvious to us
(as indicated by gross violations of Netiquette) that this information
has not propagated widely.  Getting users to read and understand the
policies is a major challenge.  One bright spot is a class that
Intel has created on Information Security for its employees.  Information
Security is planning to include the policy in the next edition of its
booklet distributed to all employees.

Unfortunately, closing the door to the Internet means keeping some of
those resources unavailable to Intel employees.
Intel still needs to maintain a competitive edge.  In order to allow
additional access to Internet resource, we are considering
and implementing alternatives.  We have implemented an
internal ftp machine, which holds internal information for the
company, provides mailing list capability,
and caches and mirrors external archives.  This capability allows us
to fill many information needs without having to grant full internet
access to the entire company (it also helps us to conserve the
bandwidth of our Internet connection).  Employees who have one-time
needs can send mail to an ftp-admin account with their request and the
ftp administrator will search the Internet and mail the results to
the employee.

Key Lesson #10 - Policies are exist to serve.  They should be changed
                 when circumstances warrant.

Many employees still find our policies limiting.
Having someone else search for you is never as satisfying as
searching for something yourself.  Users have been clamoring
to run Gopher, WAIS, World Wide Web clients from their own PCs.
We are looking at alternatives like proxy agents for these services.
We are also evaluating easing some of our policies for WAIS and Gopher
access.  The Internet is a constantly changing environment, with new
services springing up all the time.  We will need to make changes to our
policies, but when we do so, we will not ignore the many lessons we learned.


                     FIGURE 1

RFC 1296              Internet Growth (1981-1991)           January 1992


                        Number of Internet Hosts (linear)
800|
780|
760|
740|                                                                  *
720|
700|
680|                                                                 .
660|
640|
620|
600| T                                                              *
580| h
560| o
540| u
520| s                                                             *
500| a
480| n                                                            .
460| d
440| s
420|                                                             .
400| o
380| f
360|                                                            *
340| H                                                         .
320| o
300| s                                                        *
280| t
260| s                                                       .
240|                                                        .
220|                                                       .
200|                                                      .
180|                                                     .
160|
140|                                                    *
120|                                                   *
100|                                                 ..
 80|                                                *
 60|                                               .
 40|                                              *
 20|                                       ..*...*
  0|...*....*......*......*.....*.*....*...
    -------------------------------------------------------------------
    8     8     8     8     8     8     8     8     8     9     9     9
    1     2     3     4     5     6     7     8     9     0     1     2
                                   Date
    "*"  = data point,  "." = estimate
This graph is a linear plot of the number of Internet hosts.  [1]


                     FIGURE 2

    [Figure 2 is a Postscript file.  It is available from
     Jeff Sedayao.]




References

[1]  Lotor, Mark.  "Internet Growth (1981-1991); RFC 1296," January
     1992.  Available via anonymous ftp at ftp.nisc.sri.com
     rfc/rfc1296.txt.

[2]  Holbrook, J.P.; Reynolds, J.K. "Site Security Handbook; RFC 1244,"
     July 1991.  Available via anonymous ftp at ftp.nisc.sri.com
     rfc/rfc1244.txt.

[3]  "Acceptable Use Policy for NSFNET Backbone".  February 1992.
     Available via anonymous ftp at is.internic.net
     infosource/nsf-nren-nii-info/ nsfnet/acceptable-use-policy.

[4]  "Corporation for Research and Educational Networking (CREN)
     Acceptable Use Policy".  January 1993.  Available via anonymous
     ftp at cren.net
     pub/cren-doc/cren.net_use.

[5]  Von Rospach, Chuq, Gene Spafford. "A Primer on How to Work
     with the Usenet Community".  January, 1991.  Available via
     anonymous ftp at ftp.eff.org
     pub/internet-info/usenet.etiquette.

[6]  Kehoe, Brendan P. _Zen and the Art of the Internet: A Beginner's
     Guide_.  Englewood Cliffs, NJ: Prentice Hall, 1993.

[7]  Krol, Ed.  _The Whole Internet: User's Guide and Catalog_.
     Sebastopol, CA: O'Reilly & Associates, 1992.

[8] LaQuey, Tracy.  _The Internet Companion: A Beginner;s Guide to
    Global Networking_.  Reading, MA: Addison-Wesley, 1993.

[9] Tennant, Ron, John Ober & Anne G. Lipow.  _Crossing the Internet
    Threshold: An Instructional Handbook_.  Berkeley, CA: Library
    Solutions Press: 1993.


                Appendix A



        |
  intel |     cover sheet                                    No. 193016
        |                                     Rev.1          Page 1 of 6
-------------------------------------------------------------------------------
TITLE: INTERNET GUIDELINES
-------------------------------------------------------------------------------

EFFECTIVE DATE OF CURRENT REVISION: 6/93

LATEST REVIEW APPROVE DATE:

NEXT DATE TO BE REVIEWED:

SOURCE FUNCTION:    Internet Security Task Force

KEYWORDS/PHRASES:    Internet; Netiquette; Acceptable Use Policy

IPP'S REFERENCED:       184912, 191008, 182607

Revisions:









THIS DOCUMENT APPLIES TO:

    FUNCTIONS:    All

    OPERATIONS:    All

    SITES:        All

COORDINATOR: Internet Education

RESPONSIBLE REVIEW MANAGER: Intel Security

1.0  PURPOSE/SCOPE

These guidelines set the standards for appropriate behavior of an Intel
employee when accessing the Internet.  These guidelines apply to all
Intel employees.  Intel specifically reserves the right to modify,
change or discontinue any portion of the Internet guidelines from
time to time at its sole discretion.

2.0 DEFINITIONS

o Cracking - attempting to break into another system on which you
             have no account, and is treated as malicious intent.

o Netiquette - a word made from combining "Network Etiquette."
           The practice of good manners in a network environment.

o MIME - Multipurpose Internet Mail Extension.  The format for Internet
         mail which includes objects other than just text.


3.0 GENERAL

4.0 GUIDELINES

    4.1    Behavior resulting in disciplinary action.

        The following behaviors are examples of actions
        or activities which can result in disciplinary
        action.  Because all possible actions cannot be
        contemplated, the list is necessarily incomplete.
        Thus, disciplinary action may occur after other
        actions when the circumstances warrant it.
        Disciplinary actions range from verbal warnings
         to termination; the severity of the mis-behavior
        governs the severity of the disciplinary action.

        o  Unauthorized attempts to break into any computer whether
           of Intel or another organization.  (Cracking).

        o  Using Intel time and resources for personal gain.

        o  Sending threatening messages.

        o  Sending racially and/or sexually
           harrassing messages.

        o  Theft, or copying electronic files without
           permission.

        o  Sending or posting Intel confidential materials
           outside of Intel, or posting Intel confidential
           materials inside Intel to non-authorized personnel.

        o  Refusing to cooperate with a reasonable security
           investigation.

        o  Sending chain letters through electronic mail.


    4.2    Behavior considered prudent, good manners, etiquette.

        The following behaviors are recommended for sending
        Internet mail, participating in Internet mailing
                lists and Usenet groups, ftp, and telnet.  Lack
        of conformance may result in loss of Internet access.
        These guidelines have been gleaned from a variety of
          Internet Guides.  A bibliography follows these guidelines,
          and we recommend you acquire one (or more) of these guides.


        4.2.1    Electronic Mail (Email)
            The following guidelines cover the sending
            of electronic mail outside of Intel.

            o MAIL ON THE INTERNET IS NOT SECURE.
              Never include in a Email message anything which
              you want to keep private and confidential.  Email
              is sent unencrypted, and is easily readable.

            o Be cognizant of any system etiquette.  The computer
              on which you reside may have quotas on disk space
              usage.  Mail takes up space.  It's best not to
              save every message you receive.

            o Do not attempt to send anything but plain ascii
              text as mail.  Recipients may not have the ability
              to translate Word or WP documents. MIME format
              messages are encouraged. (MIME=Multipurpose
              Internet Mail Extension).

             o Be careful when sending replies - make
              sure you're sending to a group when you
              want to send to a group, and to an individual
              when you want to send to an individual.
              It's best to address directly rather
              than use the reply command.

            o Include a signature which contains
              methods by which others can contact you.
              (Usually your Email address.)

            o Let senders know you've received their mail, even
              if you can't respond in depth immediately.  They'll
              need to know their mail hasn't gotten lost.

            o Watch punctuation and spelling.

            o Remember that the recipient is a human being.
              Since they can't see you, they can't tell when
              you're joking.  Be sure to include visual clues.
              Convention indicates the use of the smiley face.
              :-) (Look sideways).

            o DO NOT SEND MESSAGES ALL IN CAPITALS.  It looks
              as if you're shouting.  Use capitals for emphasis
              or use some other symbol for emphasis.  That IS
              what I meant.  That *is* what I meant.


        4.2.2    Internet mailing lists and Usenet News Groups.
            All the guidelines covering Email should apply
            here as well.

            o Actively disclaim speaking for Intel.
              Note that if you use an Intel system
              to post an article, Intel's name is carried
              along with what you post in (at least)
              the headers.  The "standard" disclaimers
              attached to many articles are meaningless
              if the reader finds the article offensive.

            o Remember that some people have to pay for each byte
              of data they receive.  Keep messages to the point
              without being so terse as to be rude.

            o Obey copyright laws.

            o Be sure to change your mailing address if your
              account changes.  Do not simply forward your
                   mail from your old account to your new one.
              This creates a burden on Intel machines.

            o Be careful using auto-reply features in mail
              when you belong to mailing lists.  These replies
              are often sent to the entire list, and most don't
              care that you're on vacation.

            o As a new member of a group, monitor the messages
              for a while to understand the history and personality
              of the group.  Jumping right into the discussion
              may make you look foolish if you have no context.

            o Do not advertise Intel products.  This violates
              the Internet Acceptable Use Policy.

            o Do not re-post any messages without permission.

            o Avoid cross-posting whenever possible.  When not,
              apologize, especially if the groups seem to have
              a lot of overlap.  Of course, apologize for any
              mistakes in posting.

            o Do not post personal messages to a group.

            o If you survey the group, post a summary.

            o Indicate quoted material.

            o Do not post any messages anonymously.  This
              is viewed as bad form by the Usenet community
              and system managers are asked to track down
              offenders.  This wastes Intel's time and
              resources.

            o Do not re-post any requests for a dying child
              in England to get postcards to get into the
              Guiness Book of World Records.  The child got
              well, and the category has been removed from
              Guiness.

            o Make sure the subject of your message is clear
              in the Subject: line.

            o Join lists or monitor newsgroups giving thought
              to how much time these activities absorb.  Also
              for Usenet, look at the news.announce.newusers
              group.  It contains good information on getting
              started.  There are also local Intel groups which
              are good for new people.

            o Be sure to read the FAQs (Frequently Asked
              Questions) for your group(s).

            o If provoked, do not send angry messages (flames)
              without waiting overnight.  If you still think
              a flame is warranted, label your message with
              "flame on".  If you receive a flame, don't
              go overboard in reaction.  Remember that not
              everyone is as polite as you are.


        4.2.3    FTP
            These guidelines cover file transfer protocol.

            o Do not ftp to any machines on which you do
              not have an account, or which doesn't
              advertise anonymous ftp services.  Random
              net-hunting is not approved.

            o Observe working hours or posted hours for
              ftp sites.  Most sites request you NOT
              ftp between their local hours of 8-5.

            o Don't ftp during your site's prime hours
              as well.

            o Look locally before ftping something from
              a site geographically remote.  Your system
              manager can help you find the closest site.


            o Don't ftp on the off chance you'll "need
              it someday." Conversly, don't hunt around
              for "neat stuff" to ftp.  If you discover
              that you don't need what you've ftp'ed,
              delete it.  You can always get it again if
              you discover you do need it.

            o Observe any posted restrictions on the ftp
              server.

            o Use your real username and node as your password
              on anonymous ftp servers.


        4.2.4    TELNET
            These guidelines cover telnetting to remote
            systems.

            o Do not telnet to machines on which you have
              no account, or there is no guest account.
              Do not attempt to telnet deliberately into
              anonymous ftp servers.

            o Observe any posted restrictions on the machine
              to which you're telnetted.

            o Do not try to telnet into miscellaneous ports;
              use only authorized ports for access.



5.0    Selected Bibliography

        LaQuey, Tracy.  _The Internet Companion_.  Reading, MA:
           Addison-Wesley, 1993.

        Kehoe, Brendan.  _Zen and the Art of the Internet_.
          Englewood Cliffs, NJ: Prentice-Hall, 1992.

        Krol, Ed.  _The Whole Internet: User's Guide and
          Catalog_.  Sebastopol, CA: O'Reilly & Associates,
          1992.

        Tennant, Ron, John Ober & Anne G. Lipow.  _Crossing
          the Internet Threshold: An Instrustional Handbook_.
          Berkeley, CA: Library Solutions Press, 1993.





BIOGRAPHIES

Sally Hambridge received her BA in English from UCLA in 1970 and
her MLS also from UCLA in 1979.  She worked as a contract employee
for Xerox. Joining USC/ISI in 1980, she got her first taste of the
Internet.  She moved to Atari in 1982, then joined Intel in 1984.
There, she has been librarian, database analyst, currently runs
an internal ftp server.  Reach her via U.S. Mail at Intel Corp;
SC3-15; 2880 Northwestern Parkway; Santa Clara, CA 95052-8119.
Reach her electronically at [e-mail].

Jeff Sedayao received a B.S.E in Computer Science from Princeton
University in 1986 and a M.S. in Computer Science from the University of
California at Berkeley in 1989.  He has worked at Intel Corporation
since 1986, spending most of his time running Intel's main Internet
gateway.  Reach him at Intel Corp; SC9-37; 2250 Mission College
Boulevard; Santa Clara, CA 95052-8119.  Reach him electronically at
[e-mail].