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 sra@mbunix.mitre.org
Tom Bajzek twb@andrew.cmu.edu
Pat Barron pat@transarc.com
Glee Cady ghc@merit.edu
Jeff Carpenter jjc@unix.cis.pitt.edu
John Cavanaugh john.cavanaugh@stpaul.ncr.com
Andrew Cherenson arc@sgi.com
Richard Colella colella@osi3.ncsl.nist.gov
Curtis Cox zk0001@wnyosi4.navy.mil
Steve Crumb scrumb@mot.com
Hunaid Engineer hunaid@opus.cray.com
James Galvin galvin@tis.com
Jonathan Goldick goldick!b.psc.edu
Martyne Hallgren martyne@tcgould.tn.cornell.edu
Greg Hollingsworth gregh@mailer.jhuapl.edu
Tracy Laquey tracy@emx.utexas.edu
Marilyn Martin martin@cdnnet.ca
Donald Morris morris@ucar.edu
Gerard Newman gkn@sds.sdsc.edu
Marc-Andre Pepin pepin@crim.ca
Marsha Perrott mlp@andrew.cmu.edu
Richard Pethia rdp@sei.cmu.edu
Tod Pike tgp@sei.cmu.elu
Michael Reilly reilly@nsl.dec.com
Robert Reschly reschly@brl.mil
Tim Seaver tas@mcnc.org
Pat Smith psmith@merit.edu
Mary Stahl stahl@nisc.sri.com
Allen Sturtevant sturtevant@ccc.nmfecc.gov
C Wood cpw@lanl.gov
Aileen Yuan aileen@gateway.mitre.org
7