CURRENT_MEETING_REPORT_



Reported by Joyce K. Reynolds/ISI and J. Paul Holbrook/ CERT

Agenda


 1. SSPHWG Charter
 2. Discussion on current security policy and relationship to the
    Security Policy Working Group (SPWG).
 3. Goals and directions of the SSPHWG (strawman proposal by J. Paul
    Holbrook)**.
    **NOTE: The strawman proposal is included at the end of this
    report.
 4. Needs and requirements.
 5. Timeframe for writing and submission for publication of the
    handbook.
 6. 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.


Needs:

If there is a ``real threat'', who are the legitimate contact points:


  o technical
  o 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??

                                  1






Overview

Who are the customers of our Handbook:

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

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


  o risk assessment
  o 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:

  o prevention
  o response
  o cleanup/followup

Assumptions:

  o network-connected
  o hosts
  o network devices
     -  terminal servers
     -  modems

Point out ``natural'' conflicts that will occur.

Physical security statement in this handbook (??)  We could point out
some of the risks.

  o What kinds of items should be in the handbook??
  o What issues should be addressed??



                                  2






List and discussion of issues


 1. Physical Security
 2. Site Security Boundary

      o Model :  definition of terms
      o Clues on what to do when you must cross organizational
        boundaries:
      o defining contact points
       (a) technical
       (b) administrative
       (c) response teams
       (d) investigative
      o Invisible/Visible
       (a) legal
       (b) vendors (products or providers)
       (c) press (policy and procedures)
       (d) service providers

 3. Updates
      o Procedures
      o 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

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

10. Concept of ``Inter-net'', ``Outer-net''
      o circles of trust
      o ``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 (?)
      o is the access really authorized?
      o how do you know if you're authorized?
16. Guidelines for acceptable use?
17. Configuration management

      o passwords
      o bug fixes

18. Tools


                                  3






      o preventive
      o response
      o inventory of tools?
19. Education
      o legal
      o administrators
      o users (How do they deal with different kinds of threats and
        risks?
20. Decision making authority

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

21. Emergency response
22. Resources
      o other security devices
      o other books/lists/informational sources
      o 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.



                                  4






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?


  o 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.
  o 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.
  o 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.
  o 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?


                                  5






THE CUSTOMERS OF THIS WORK

Customers of what we're trying to do:


  o Systems administrators
  o Site decision makers
  o 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:

  o Programmers
  o 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:


  o suggested policies and procedures (perhaps whatever the Security
    policy WG produces)
  o bibliographies of other information to read
  o pointers to tools to help with site security



                                  6






ATTENDEES

   Stan Ames                 [email protected]
   Tom Bajzek                [email protected]
   Pat Barron                [email protected]
   Glee Cady                 [email protected]
   Jeff Carpenter            [email protected]
   John Cavanaugh            [email protected]
   Andrew Cherenson          [email protected]
   Richard Colella           [email protected]
   Curtis Cox                [email protected]
   Steve Crumb               [email protected]
   Hunaid Engineer           [email protected]
   James Galvin              [email protected]
   Jonathan Goldick          goldick!b.psc.edu
   Martyne Hallgren          [email protected]
   Greg Hollingsworth        [email protected]
   Tracy Laquey              [email protected]
   Marilyn Martin            [email protected]
   Donald Morris             [email protected]
   Gerard Newman             [email protected]
   Marc-Andre Pepin          [email protected]
   Marsha Perrott            [email protected]
   Richard Pethia            [email protected]
   Tod Pike                  [email protected]
   Michael Reilly            [email protected]
   Robert Reschly            [email protected]
   Tim Seaver                [email protected]
   Pat Smith                 [email protected]
   Mary Stahl                [email protected]
   Allen Sturtevant          [email protected]
   C Wood                    [email protected]
   Aileen Yuan               [email protected]



                                  7

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.