CURRENT_MEETING_REPORT_ Reported by Barbara Fraser/CERT Coordination Center and Klaus-Peter Kossakowski/DFN-CERT Minutes of the Guidelines and Recommendations for Security Incident Processing Working Group (GRIP) Due to many new participants which were unfamiliar with the past activities of this working group, a short overview of the activities of the working group was provided. The first meeting was spent reviewing the outline of the document on incident response teams and proposing material for the sections. The second meeting focused on the development of an outline for the document on vendor requirements. Incident Response Team Document Status of the Document After the discussion during the last IETF meeting there was supposed to be a draft for this meeting. Due to the time schedule of the editor he was unable to fulfill this role. A volunteer for the position of the editor was requested. Nevil Brownlee volunteered for this position later in the meeting and he is now our new document editor for the response team document. There was some discussion regarding the relationship of the template and the document itself. It was emphasized that the document serve two purposes: to provide guidance to organizations that want to form a response team so that they will be able to describe themselves in terms of the template, and to help the reader (or client or potential client) of a team understand the content of a given team template. One of the main primary purposes of the document is to help new teams. During the discussion a split of the IRT document into a document about forming an IRT and into another document about the team template was proposed. No decision was made by the group. There was discussion as to whether this document will provide to response teams, minimum community expectations. In earlier meetings, this was to be the case. At this meeting there was a difference of opinion. This is something that we will settle on the mailing list or (in the worst case) at the next meeting. One of the other purposes of this working group and its documents was named: to get other groups to use this template. This should be included in the introduction. Short Review of Team Template During the review various issues came up. One of the discussions was devoted to the availability of the team templates. A central repository is needed to provide easy access to the templates of (most) teams. It was thought that some of the existing archive areas could include such templates. It was recommended that digital signatures be used to protect the provided template against modifications. (This was also included in the team template). Each team will be responsible for ensuring that its own template is available to its cooperating partners and its constituency. Another discussion involved the meaning of several terms: ``constituency'', ``sponsor'' and ``authorization''. Due to many different situations for the teams it is important to allow a consistent description. Therefore, we will provide definitions of these terms within the context of the document. They should be included in the introductory section along with the others that have already been identified. After reviewing the already discussed and outlined chapters, the discussion of the other chapters followed with the the goal to get more content and keywords which could help the editor of the document. Discuss Various Topics of the Document During the last IETF the first chapters of the document (``Introduction'' and ``Defining a Charter'') were discussed in more detail. During this meeting the remaining chapters were handled in detail. Policies The problem of incident reports and requests, and their handling was discussed in more detail. It was felt that each team has to choose its policy, but it should be clearly stated in the team template. To avoid the ``black hole'' phenomenon, a team might choose to provide a minimal feedback even to sites without their constituency. Due to the impact on the team's constituency (incidents) reports from outside the constituency must be handled very carefully. We discussed that there are several ways that these reports may impact the response teams constituency: o reports from outside effecting inside inside hosts/sites o reports from outside that do not effect inside hosts/sites Interestingly, there is also the possibility that reports from inside the constituency only effect outside sites. A team must determine how they are going to handle these types of reports and make it known. The item ``reporting requirements'' is confusing due to the relation to things like ``quarterly reports''. This item was reworded to ``incident reporting requirements''. Similar confusion arose from ``points of contact''. It was changed to ``points of customer contacts''. Standard bodies were added as possible cooperation partners. A new, important issue came up related to the team template itself. Changes of policy must be distributed to the constituency (and other relevant parties). Without that, it is clear that misunderstanding and misconceptions will arise, whenever policies are changed. It was also felt by the group that vulnerabilities are sometimes not related to incidents and their handling needs to be addressed. As at the last meeting, the group decided to categorize vulnerability response as an optional service and this topic has to be analyzed in more detail later. Vulnerability reports not related to actual incidents might be addressed to avoid possible incidents (this behavior is sometimes categorized under ``pro-active measures''). The next major topic addressed in the discussion was ``disclosure''. The group felt comfortable with the actual items and several others were added: o Vulnerabilities discovered in the process of handling an incident and the distribution of relevant information. There are several relationships that have to be addressed here: to constituency to vendor o A team will normally collect statistics. If they are distributed, this should be stated in the policy section under this topic. o Because feedback to a reporter will disclose information, this has to be handled, too. It is important to set the right expectations. o If conflicts of interests are identified for a single team which might interfere with the disclosure of information this must be handled here. The group felt it is unnecessary to address this issue within the template explicitly. o Legal requirements for disclosure might be different for the various teams. Due to the interference with user expectations, these should be outlined. One specific kind of request is related to contact information for other teams, organizations or parties. The distribution of this information might be important (e.g., contacts to the law enforcement) or it might be helpful to the reporter if a team will not deal with the request (because it is outside of the scope or the reporter is outside its constituency). Each team can decide to put other contact addresses into the appendix of its template. This topic will also fit under disclosure. Services During the first review a little confusion arose surrounding some of the items within this section. These were later clarified: o ``verification'' was renamed to ``verification of incident'' o ``optional'' was renamed to ``optional activities'' It was noted that all pro-active services, if offered, are optional. It was suggested that the group be very careful in the wording of the section about optional services to avoid the misconception that such services are mandatory in order to be perceived as a ``good'' (or quality) IRT. Even legal conflicts can arise because of such misunderstanding. Examples for other optional activities might include but are not limited to: o firewall consulting o security tools packages o information about security software (e.g., tcp-wrapper) One of the services during handling an incident is to help the victim to understand the problem and the extent of the impact and/or damage. This fits under ``understanding of activity'' as opposed to under an optional activity. The group felt uncomfortable with the topic ``coping''. This was changed and divided into ``eradication'' and ``recovery''. Recovery may or may not include education. The closing of an incident as an explicit service (i.e., letting all involved parties know, that the IRT considers an incident closed) is important and clearly an instance of the incident handling process. This also helps the IRT to avoid the black hole phenomenon. Procedures This section has no relevance for the team template. Policies stated in the template have to be implemented as procedures internally. Some procedures were discussed in more detail. o Keeping statistics was already addressed under disclosure, but a team needs a procedure for doing this. o Keeping track of lessons learned seems trivial but it is important in helping the team handle similar incidents more efficiently the next time. o It was decided that we should not include too much guidance concerning securing a team's infrastructure since we can point them to ``The Site Security Handbook'' as a resource. There might exist IRT-specific security demands which are not usually considered for other sites and those might be important to handle in this section. o Another topic was the use of the network itself as an information resource for the teams. In using it they have to realize that they might be vulnerable to faked information which might lead to damage if it was used for part of the incident handling process by the team (e.g., wrong contact information for contacting involved sites). After reviewing the first document and in lack of more input to the group, it was decided was to focus on the second document. Vendor Document The discussion started with a kind of reality check. The original question was what can be achieved through such a document? The users need something to point to. The community has to develop an understanding of what can be expected from the vendor (technology producer) side. Leading the way to best current practise is a good description for the purpose of this document. The discussion of experiences of the audience revealed the following thoughts: o Getting an understanding of what the larger community really needs is most important. The needs might be very different for users outside the more technical community of the IETF. o Users have to deal with a highly hierarchical system of vendor, seller and reseller. o The users will need a document in simple language, so that everybody can understand it and use it. o There is a special situation outside the US, where even the vendor, seller and reseller have no access to the technical information and the detailed knowledge. For example, it is a wrong assumption that every party has access to source code. Scope of Document Get an understanding of what users can expect from a vendor when a product security problem is reported for: o software o hardware Clearly this document therefore has to reflect the community's expectations of how vendors should respond to and handle reports of security problems in their products. The producers are the audience, but users will read it. This will lead to the use of the document to in some ways force the technology producer to a specific behavior. A question was raised if the document will address the areas of secure: o packaging o distribution o installation o default configuration Is the development of the software within the scope or not? The field of software engineering clearly does not fit into this document. But perhaps a document about ``best current practise'' for software developers is needed. This topic will probably not be included in this document and the decision to write yet another document will be decided after we have these two completed (or at least well underway). The distribution of software (especially in the public domain area) often leads to flaws and therefore advice in this area would be worthwhile. The normal answer on a security hole is the suggestion to use an update/revised version of the product. However, internal technology constraints may make this impossible to use or not advisable. Some vendors stop supporting patches for software products and the change to a new major version would force the victim organization to change the whole setup. Therefore the sites need updates (especially in complex system setups) not a new version. The question of how long a specific system is supported is important. Especially in the case of large organizations the amount of work for ``regular'' updates is immense. Folks are interested in the length of time as measured in calendar time as opposed to versions. So, for example, some vendors state that they support the current versions and the two preceding ones. The problem is that the buyer does not know how long a period of time this might cover. From a strategic and financial planning point of view it would be very helpful to know, rather, how long in real time an organization can count on support for the product. What about products that are sold but are no longer supported or dropped from the list of supported products shortly after purchase. What are the implications for security patches in these cases? The feeling was also that security problems have to be addressed, even without a service agreement. Security patches are expected to be free. However, this will not hold forever since vendors must be able to stop support on old products at some point in time. The point is that they need to clearly state what their support policy is so that a buyer can make informed decisions. The distribution of security information has to be addressed, too. This is a sensitive subject but the group came up with a starting point for further discussions in this area. In general, enough information has to be shared so that it is possible to find out if a site is vulnerable. This may be especially important if no patch is available and the knowledge about a security bug can be serious to a site. If informed, a site would perhaps decide to disconnect from the net. It was brought up that there may be liability involved with the disclosure of such information and what is the responsibility for side effects of patches (like it is done on prescription medications). The distribution of more detailed security related information to (major) customers was approached by at least one major vendor. Due to the transfer of the liability for misuse of this information to the customers, no one was eager to sign the contract. One solution was proposed: o If no exploitation, company provides fix, but does not disclose before fix is available. o If being exploited, disclose the information. It was quickly noted that we are not attorneys, and we cannot possibly set policy. However the discussion was good because it pointed out the areas where vendors need to their policies. Resellers are problematic, too. They might be responsible for security flaws the end user will contact the vendor of single components. Network providers may claim to be technology providers (aka vendors), but they are not. Even if they are responsible for things like router configurations, this has to be separated from the hardware and software component. Purpose Statement Primary Purposes Reflect the community's expectations of what consumers can expect from a vendor to address the security issues related to their products during the product's lifetime (excluding the software development process). To include: o distribution o default configuration o optional components (e.g., debugging) o installation o normal use o response to security problems (known by the vendor and reported by customers) o support for old versions, duration of support o documentation Secondary Purposes Raise the awareness both on vendor and consumer sides that addressing security issues is worthwhile. Outline of Draft Document Suggestion for the title of the document: ``Internet Technology Producers Guide to Good Security Practice'' o Introduction - purpose - statement of intended audience - basic definitions * vendor * security bug - relationship to other documents * site security handbook (SSH) * vendor document (GRIP) o Distribution o Default configuration o Optional components o Installation o Normal use o Response to security problems known by the vendor reported by customers o Duration of support o Documentation Discuss Various Topics of the Document The following definitions were discussed: o Vendor -- Entities that produce technology and are responsible for the technical content. o Security Bug -- No definition was given during the 33rd IETF. If it is felt that there would be the need for such (maybe under a different term) we will get a definition later. Administrivia Incident Response Teams Document September 1995 -- First draft November 1995 -- Internet-Draft December 1995 -- 34th IETF, review of draft January 20, 1996 -- Final draft Mid-February 1996 -- Final call Internet Technology Provider Document September 1995 -- Draft outline