CURRENT MEETING REPORT Reported by Erik Guttman and Barbara Fraser Minutes of the G and R for Security Incident Processing (GRIP) List is at grip-wg@uu.net request at grip-wg-request@uu.net Archives ftp.cert.dfn.de The GRIP working group met once during this IETF. The agenda for the meeting was the following: Find a volunteer note taker - Erik Guttman was wonderful to volunteer Review the current Internet Draft Develop outline for the vendor document The group spent the first 15 minutes or so discussing the audience for the document. The goal is to provide a document that accomplishes several things: - sets community expectations for a security incident response team - provides a description of what it means to be a response team - provide a template to facilitate the definition of any given response team. So, the audience is primarily response teams even though members of the Internet community will also find it useful. The descriptions in the document should help set a constituent's/customer's expectations of the team. This document discusses all the many aspects of incident response that need to be defined. Therefore, a constituent/customer should be able to read a team's template and discover what to expect, for example, in such areas as privacy and confidentiality of information, and if the response team will be contacting downstream sites. In terms of expectations, the discussion was in terms of "what should I expect of my own IRT?" and how does this differ from what I expect from other organizations and groups. The basic philosophy will have to be "If you tell us things (in the filled out template), we will expect you to follow through with what was stated. Another point that was brought up about follow-through was that users should be encouraged by their IRT to report incidents so that appropriate actions can be taken. Without active participation (ie. reporting) from users, IRTs can't do much good. Thus, the users need to know how and when to report. There was considerable discussion about the definition of an incident. Another way of stating this is what should users be trained to do? In a review of Section 4.4 it was asked if we should continue to keep the document OS neutral. Folks agreed but decided that it would be helpful to provide examples when needed for clarification. For example "root compromise" and "writable FTP area" when distinguishing between types of violations. These examples are rathery UNIX specific. There was no clear resolution on this, but we agreed to keep the OS neutrality in mind whenever possible. The difference between inappropriate disclosure and unauthorized use got discussed: The two categories entail different loss of confidentiality. Inappropriate disclosure would be to grab stuff and make it more visible than originally intended. Text is needed to bring out the differences. The disclosure issue is further complicated by the fact that disclosure could be intentional or unintentional. There was some discussion as to whether the document should discuss what is out of the scope of an IRT? It was decided that it is easier to say things are definitely in the scope/charter of an IRT. It is important to define what the IRT considers worth their involvement, or at least to put bounds on what they consider to be an incident. A VULNERABILITY is important to know about and an IRT *may* provide analysis of the vulnerability. On the other hand it may only do this if the vulnerability was discovered during a security breach, etc. It was reaffirmed that vulnerability analysis isn't required of IRTs but the analysis of vulnerabilities which do not occur within the framework of an incident may or may not be a service provided by IRTs. Examples include pc viruses and malicious programs. These are not really an incident on 1 or 2 machines. But if they are brought in deliberately they can become full scale incidents. If merely an accident, generally no. But, the decision is ultimately with the IRT. Some IRTs handle all virus cases, etc. This seemed to be the case in private IRT set ups (within one corporation.) Others, like the CERT Coordination Center have traditionally not handled viruses. There was discussion about nailing down the expectations questions: - What response level can we expect from the team, what will not be dropped? - What kind of response can we expect? - How should one report? (This is perhaps handled in the SSH user doc) - Notification (of up/downstream sites, press, government) - What is the default reporting a constituency can expect, what exceptions are there? - How and when should I, as a member of an IRT's constituency, report an incident? * NOTE: Corporate network and physical security should be coordinated. An IRT may be called when a computer is physically taken/broken into, the watchmen may be called due to a computer security intrusion. While we aren't providing an end-user's document we do need to grapple with the work that an IRT does as well as it's interface to the outside. One person suggested we could look at it as different management: managing inward and outward. - manage the inward vs. outward sides of incident handling - start on the inward side: Want it to be clear exactly where to go if there is a (suspected) incident - each topic can be seen from either or both sides. Ask "Is this an inward or outward issue?" Lots of the discussion focused on the differences between commercial incident response and incident response defined by a particular entity. There were member of the working group from both categories and the discussion was interesting. For example, if the policy is clear (as in a corporate case) it should not be necessary to think. You should CONTACT SO AND SO as your whole range of choices. This is harder when it comes to commercial enterprises like Internet service providers, value-added service providers, and commercial IRTs. It seems the outward side comes down to: - "As a user you should read this and that policy document. This will make clear what we will provide you with and what you need to deal with on your own." * The document must be clear(er) about what effects the user community vs. what is addressed directly to the user community Upshot to consituents is: READ YOUR FILLED IN IRT TEMPLATE AND "DO THAT FIRST". IRTs *can* set up a policy which says: If you have ignored my advice, my future commitment may be limited. It was also restated that many IRTs have no prosecuting authority to get people to follow advice when they give it. * Defining what constituencies are is out of the scope of the RFC, it will be done by the IRT or corporate policy in a very individual way. Then there was discussion about what we should include concerning the question: How do you find your IRT? - ask your ISP - ask an IT security officer [? I don't know what this means] - put hints into the User SSH Note: IRTs have a responsibility to advertise themselves to users/IRTs Dissemination of info about IRTs: First my constituents then outward. Since there is a trust issue (is this really an IRT?) it makes sense to send information out in a 'tree' like manner, using trust along the way of the direct source of info. It was mentioned that the trust model for IRTs is the same as that for PGP, a web of trust. The most challeging piece is to fine the first entity that you truly trust. The info about IRTs and IR techniques needs to be in the hands of tech support, as they will be faced with incidents on the front lines. Most important is that IRTs publish to their constituencies. This is really according to a "push model," as they will not be in a position to really ask until it is too late. There was discussion about a central repository, but the bottom line is that the IRT in question needs to make it's information available. First, it should publish its template on its own information server. Everyone also acknowledged that the FIRST repository is a good thing, but that there may be teams that aren't members of FIRST so we can't count on that 100%. We might point folks to the FIRST archives, their Internet service provider, and other known response centers. One of the primary jobs an IRT must succeed in is making upstream sites aware of how to contact them. International audience: The IRTs and users of the template should/must work sensitively to local laws and regulations. * It is probably important to clarify any local regulations which will effect the primary operation of the IRT to those who may have very different expectations in different countries, etc. * It is very possible that a team will want to have internal and external versions of their policy. One may be for corporate use only on the one hand, and the other for general consumption/cooperation guidelines on the other. Getting back to knowing who the response teams are brought out some further discussion. We decided that we would provide a list of the current IRTs in the document as a starting point, along with a pointer to first.org. In general the idea of a central repository presents some challenges. The repository may be very difficult to keep current and to keep filled with accurate information. (Bad guys can create 'IRT' facades, etc.) Who will 'vet' the response teams/classify them officially? Note this is a very sticky area that will have liability issues associated with it, as business will claim to be able to do this. Who will have the right or claim to have the right to deny them? There was even discussion as to whether someone could go to an investigative agency in their country to see if a particular team was legitimate. May be valuable to enlist the aid of a national (law enforcement) agency to maintain a list of contacts and act as a clearing house. Right now, the list of members in FIRST is a good start, but some mentioned that there will inevitably be IRTs that are really just an individual who has contracted with some organizations to provide incident response services. So, we need to be sensitive to future needs. There was some discussion concerning categories of vulnerabilities, and one member of the group suggested there are 3 general kinds: - vendor/os vulnerability - those used from a local host targeted at another site 1:1 or thereabouts - those used internally, internal matter in an organization. The first may or may not be an incident. It will be if it was exploited. Otherwise it falls into the category of a vulnerability. If it is wide- spread in consequences it should be dealt with. If it is a 1:1 or 1:many incident you deal with them and or their IRT, as well as local law enforcement since there may be a concern for liabilities if you don't and the downstream sites find out later. If it is an internal compromise, it should be dealt with internal security mechanisms in place. Commercial response teams will broaden the field of who should be tracked. The quality of sources may not be all good or bad, there is a gray area. Teams have the template to - give to constituencies (private part) - give to public (public part) * Idea: use a 'keytag' to classify the document so that yahoo/infoseek/etc info directory scans will make them available to the network community. The search engines out there will help the incident sufferer. Alternatively the list at FIRST should be on the web... * There was some discussion as to whether to change the title to "Expectations for Internet Security Incident Response" . We'll decide on the list. The following were some specific edits: - intro: add "dealing with internet but concepts apply to closed nets." add "formulate expectations" - S 1.1: rename Template Repository to Central Repository - pg 4 : "distribution of template updates" tell you where to get new templates - S 3, pg 5: primary purpose: set expectations of constituents & customers "A second document...vendors to help them with security incidents" Actually it is much broader than that: should we really have this pointer here? - S 4.2, pg 6: "Partner Team" what is this? Omit it. - S 4.3: Goes away - S 4.4: Incident should be Incident Response --------------------------------------------------------------------------- At this point in time, the time alotted to the working group session was about over and we didn't have time to do any real work on the second document. The following are some comments on the outline. - The outline can be thought of as the consumers life cycle of relationship with a vendor vis-a-vis possible security issues. - OPTIONAL COMPONENTS section comments - features like NIS and NIS+ which you may use, make it very clear what known security problems will be taken on if they are turned on. - INSTALLATION section comments - make it very clear what you have to do right away before the system is really usable (change certain passwords for example) - eliminate guest/no password accounts [isn't this section really DEFAULT CONFIGURATION by another name?] - Most of the discussion was on the DEFAULT CONFIGURATION - security features need a lot of attention - x is a 'good idea', y is a 'bad idea' notes are useful - be clear this is not unix based nor is it a 'security engineering handbook' - [the fellow from TI's IRT asked] should group passwords even be turned on? - how to disable promiscuous internet connections and make it hard for users to get access to such facilities. - do not use cleartext passwords on the wire if at all possible - no trust should be the default - GET MORE IDEAS FROM THE MAILING LIST Next Steps: 1. Nevil will create a new draft by mid-January for everyone to review before the March meeting. We hope to have a stable document by then so that only small editorial changes will be needed before we can advance it. 2. We'll discuss the vendor document on the list. We are working on selecting the document editor(s) for that document. 3. We are planning two sessions in Los Angeles, 1 to complete the IRT document, and a second one to work on the vendor document.