30th IETF, 31st IETF, 32nd IETF, 33rd IETF, 34th IETF, 35th IETF, 36th IETF, 38th IETF, 39th IETF,
40th IETF, 41st IETF, 43rd IETF, 44th IETF, 45th IETF and 46th IETF
Due to many new participants which were unfamilar 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.
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 fullfill this role. A volunteer for the position of the editor was requested. Nevil Brownlee (firstname.lastname@example.org) volunteered for this position later on during 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. A second purpose to 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 and in the worst cast 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.
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. There 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.
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.
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 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:
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 analysed in more detail later. Vulnerability reports not related to actual incidents might be addressed to avoid possible incidents (this behavior is sometimes categorized under "proactive measures").
The next major topic addressed in the discussion was "disclosure". The group felt comfortable with the actual items and several other were added:
During the first review a little confusion arose surrounding some of the items within this section. This was clarified later on:
Examples for other optional activities might include but are limited to:
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.
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.
The discussion started with a kind of reality check. The original question was, what can be archieved through such a document. The users need something to point to. The community has to develop an understanding of 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:
Get an understanding of what users can expect from a vendor when a product security problem is reported for:
A question was raised if the document will address the areas of secure:
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 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 doesn't know how long a period of time this might cover. From a strategic and financial planning point of view if 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 won't 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:
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 provider (aka vendor), 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.
Reflect the community's expectations 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).
Raise the awareness both on vendor and consumer sides that addressing security issues is worthwhile.
Suggestion for the title of the document:
"Internet Technology Producers Guide to good Security Practice"
Please send questions, comments, and/or suggestions regarding the GRIP working group to the open mailing list email@example.com.
All issues regarding these web pages should be directed to firstname.lastname@example.org.
These pages are hosted on http://www.kossakowski.de and are provided on an "AS IS" basis without any explicite or implicite responsibility, liability, etc. (For a more fully understanding please refer to the legal statements within the Impressum, which is only available in German.)