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