CURRENT_MEETING_REPORT_
Reported by Barbara Fraser/CERT Coordination Center
Minutes of the Guidelines and Recommendations for Security Incident
Processing Working Group (GRIP)
The GRIP Working Group met twice during the 32nd IETF. A lot was
accomplished and the group hopes to complete the work on the first
document by the next IETF meeting.
The agenda for the two sessions was:
o Title change
o Team template
o Outline of document
o Discuss current material
o Update milestones and administrativia
A new title for the document being written, ``Framework for Security
Incident Response Teams,'' was suggested and accepted. Team template,
document outline and current material were covered in both meetings from
different perspectives. At last the proposed milestone plan was
revised.
To avoid any misunderstandings we will refer to ``security incident
response team'' or just ``incident response team'' (abbreviated as IRT)
throughout all relevant documents. A definition for this term (see
below) was proposed and accepted by the participants.
Team Template
It was decided that the group would define a Team Template and use it to
direct the development of the document. The working group agreed to
proceed with the following template.
o Name of the team
o Date of last update
o Charter
- mission statement
- constituency
- sponsor/affiliation
- authority
o Policies
- types of incidents
- level of support
- disclosure
* of compromised site's information
* the compromise of IRT site to constituency
- cooperation/interaction with
* incident response teams
* vendors
* investigative agencies
* involved sites
* press
- communication/authentication
- point of contacts
- reporting requirements
o Services
- incident response
* verification
* understanding
* coping
* notification
- proactive activities
o Appendix
o Contact Information
- name
- address
- telephone
- telefax
- other telecommunication like STU-III
- electronic mail
- encryption methods for communication: PGP, PEM, MOSS, etc.
- actual list of members on demand (optional)
o Information Services
- URL for team information (this document)
- mailing lists
- information servers
o Incident Reporting Forms
o Disclaimers
Discussion of Team Template
During the last IETF a decision was made to provide a team information
template within the document. Team descriptors which are of interest to
constituencies and other parties interacting with an IRT should be
covered there. A draft for this template was presented, discussed and
improved. The template also served as the framework for the proposed
outline of the document. To allow easier access for the working group
the template is also available as a single document within the archive
(see below).
The main interest during this discussion was the section about policies.
The relationship between press and an IRT was identified as an
additional area where at least the expectations for the constituency has
to be set in the right way.
The goals and purpose of a team are especially important. In addition,
there might exist different levels of support for different kinds of
incidents, and this must be handled.
During the past meetings, vulnerabilities were treated as separate
topics (in addition to incidents). If an IRT handles isolated
vulnerabilities, which are independent from incidents, it should be a
decision made by the individual team itself. If so, it is considered an
optional service not related to the core activities which were
identified for IRTs. It was further decided that if a team does handle
vulnerabilities, they should include a statement to that effect in the
policy section.
Services can be split in two sections. The core activities (i.e., those
included in the definition of an IRT) are the main interest for the
scope of this document. All other services should be seen as optional
services. To keep the document as clear as possible, the inclusion of
information, not directly related to the mission of a team should be
disregarded. The question was raised, if the service section can be
used as a marketing tool. The bottom line is, that nobody can protect
against this. But it is clearly not the intent of the working group to
propose such a use. Services can be separated into incident response
and proactive activities. Other services can be added as optional
features. The document will provide discussions as to why a team might
include or exclude particular services.
There was discussion concerning liability problems that might arise due
to the information a team may provide. Although the document forms no
contract, liability might arise due to the description of services and
purposes. The inclusion of a disclaimer at the end of the template was
suggested. It should be up to the team as to how to handle this
subject.
An expiration date for a team's template information was proposed.
Discussing the tradeoff in having recent reviews or forged dates it was
decided to incorporate a date of last update. This should be sufficient
to allow the constituency to evaluate the currency of the document. The
problem of storing and distributing the team information is still open.
The question was raised to think about FYI or RFC mechanisms. Other
approaches include the collecting of documents through a neutral
organization like ISOC or FIRST.
Document Outline
After settling on a team template, the group then moved to a discussion
of the document outline. The following outline was agreed upon by the
group.
o Introduction
- purpose
* statement of intended audience
* pointers to background material
- basic definitions
* constituency
* incident
* security incident response team (IRT)
* site
* provider
* vendor
- relationship to other documents
* site security handbook (SSH)
* vendor document (GRIP)
o Defining a Charter
- constituency
- core activities and mission statement
- (functions necessary to be considered as IRT)
- sponsoring organization/affiliation
- authority
* scope
* perimeter
o Policies
- types of incidents and level of support
- disclosure
* reporting incidents to other teams
* handling of incidents from sites outside the team's
constituency
- interaction with other organizations
* incident response teams
* vendors
* investigative agencies
* involved sites
* press
- communication/authentication
- points of contact
- reporting requirements
o Services
- direct incident response
* verification
* understanding of activity
* coping
* notification
- optional
- (describe other activities)
o Procedures
- external
* support for incident response (e.g., registration service)
* secure communication
* information that a side must/should provide
- internal
* secure infrastructure
* protecting information servers
* protecting sensitive data
* expiring sensitive data
* disposal of sensitive data
o Tips, Tricks and Pitfalls (the name of the chapter should be
changed later to something more suitable like ``Miscellaneous...'')
- handling the media
- social engineering
- cellular phones
o Appendix
- Team Template
Discussion of Document Outline
For the document, an RFC oriented text style should be used to allow a
differentiation for ``must,'' ``should'' and ``can.'' The rational for
using a special mode must be given in the document, due to the overall
goal of this document in assisting persons not necessarily experts in
the field of incident response.
An interesting topic was how teams would handle calls from a site within
the constituency of a different team. The group decided that this topic
fits under disclosure and relationship in the policy section but it may
also be necessary to include some statements in the procedures section.
One aspect of this problem is, if the other team is told about the call
thereafter. This should be covered as ``reporting to other teams'' and
``handling incidents from sites outside a team's constituency.''
Some policies outlined during the discussion:
o It is a ``should'' to announce the compromise of an IRT (at least)
to the constituency.
o The authority about the IRT should also be covered here.
Some chapters of the document are structured in the same way as the team
template. ``Procedures'' is an additional section. It is not necessary
to go into details about procedures within the template but it is
important for the document.
The classification of data should be handled along with the internal
procedures.
Which information about incidents is required must be handled in the
procedures section. The template can focus on that in the services
section and special forms for incident reporting can be included as
appendices. The problem here is that commercial IRTs may choose a
different perspective, therefore all these topics are ``shoulds,'' but
rationals for good practice must be provided.
A minimum set of information for customer and/or incidents might be
required. A rational should be included on how to handle the problems
related to that.
Under ``Tips, Tricks and Pitfalls'' all ``mine fields'' should be
covered. (The chapter will get a better name later.) For example, the
treatment of calls from people not within a specific constituency fits
into this chapter.
John Wack (NIST) volunteered to write some stuff about media under this
section.
Some aspects of the document were further discussed and material for the
various sections was collected. The outcome can be found in the
relevant sections of the upcoming draft.
Purpose of the IRT Document
The discussion revealed primary and secondary purposes, which should be
clearly separated.
The primary purposes are as follows:
o It is clearly a framework for IRTs to help them describe themselves
and their services and functions.
o It should improve the way IRTs operate and interface with their
constituency in setting expectations and defining policies.
o It should improve interactions between different IRTs and between
IRTs and other organizations (e.g., vendors, investigative
agencies).
o Help new teams to understand what it takes to became or start a new
team.
Among the secondary purposes the following were mentioned:
o As the document will provide a framework, which topics are covered,
it will be usable for comparing different teams. It can be used as
a marketing tool in comparing the services. It can also be used
for setting customer's requirements.
o It should be clearly stated that marketing use (or abuse) is not
intended by the working group.
o Users may find the document educational in helping them understand
the purposes and activities of an IRT. They may also learn about
the different policies and services which are possible.
Definitions
During the last meetings, a lot of definitions were assumed necessary to
be included in this document. But in relation to the purpose of the
document only a limited list is really needed. This should help to keep
the focus on the purpose of the document and prevent a duplication of
other definitions or -- even worse -- a different definition. Some
discussion was devoted to the term ``security'' which seems necessary
for defining ``incident.'' A decision was made not to define security,
but to include pointers to other definitions like the user glossary.
The audience agreed on the following list and definitions.
o Constituency
Inherent to the purpose of a Security Incident Response Team is the
existence of a constituency: the group of users, sites, networks
or organizations served by the team.
o Incident
For the purpose of this document the term incident implies an
incident related to computer and network security.
A computer security incident is any event whereby some aspect of
computer or network security is compromised.
The definition of an incident may vary for each organization
depending on many factors. At least the following categories are
generally applicable:
Loss of confidentiality
Compromise of integrity
Denial of service
Misuse
Damage
o Security Incident Response Team
Based on the two definitions given above, a Security Incident
Response Team can be defined as:
A Security Incident Response Team should be capable of dealing with
incidents that occur within its defined constituency. It should
provide a means for reporting suspected incidents and offer
technical assistance to help sites handle these incidents. Teams
should also disseminate important incident-related information to
relevant parties.
o Site
A collection of equipment and personnel in a manner as to provide a
point of contact for the handling of security incidents.
o Vendor
Entities that produce technology in such a manner that they are
responsible for the technical content.
Within the definition of an incident, the statement ``is compromised''
is used. Sometimes an administrator may only ``suspect'' an incident.
During the handling of a call, it will be established whether or not an
incident really occurred.
To avoid any problems with already existing definitions for site and
vendor, other references should be checked. The term ``provider'' was
not defined, because there is not a real need given the purpose of the
IRT document. In case there is an incident at a service provider it
will be handled the same as it would be for any other type of site.
The definition of a vendor took quite a while and was not finished. The
definition above should therefore be seen as a working statement which
has to be reviewed later. Nevertheless the audience felt that it is
especially important to keep a close relation to the purpose of the
document. There was discussion as to whether a supplier of a technology
was the ``vendor'' of the technology. It was generally agreed that this
was not the case. So, for example, if a network service provider
provides Cisco routers to each of their customers, Cisco is determined
to be the ``vendor'' and not the service provider (since Cisco is the
one responsible for the technical content of the product).
Defining a Charter
At the end of the second meeting this chapter was only briefly
discussed. In regard to the constituency the following topics seem
important:
o Constituency means who you will provide service to.
o This can be a company's employees or paid subscribers.
o It may be defined in terms of a technological focus, e.g., a
particular operating system.
Define the constituency to get a perimeter that defines to whom do you
will provide the service. You may also get requests from other parties
not within this border. How an IRT handles this should be covered in
the policy section. Another problem is the fact that people within the
constituency have to learn that there is an IRT for their purposes. The
building of a trusted relationship to the constituency is an ongoing
process which never ends.
The mission statement will have to focus on the core activities already
stated in the definition of an IRT. One point the group wants to
emphasize is that in order to be considered a security incident response
team, the team must provide incident response, by definition.
The sponsoring organization should be given next. In defining the
affiliation it is simply stated ``Who is your God?'' Any kind of
verification, that the IRT is really what it claims to be, is beyond the
scope of this document.
Core activities are necessary to ``be'' an IRT. The ``musts'' are the
real interesting ones.
Administrivia
The mailing list will be updated to include the new people who attended
these meetings.
Mailing list: grip-wg@uu.net
Subscription: grip-wg-request@uu.net
Archives will be setup in the US and Europe. The document outline, the
template and the definitions will be provided as separate information.
The drafts will be available also.
US: ftp://info.cert.org/pub/ietf/grip/
Europe: ftp://ftp.cert.dfn.de/pub/ietf/grip/
Access to the GRIP charter and minutes is possible via the World Wide
Web, too.
http://www.cert.dfn.de/eng/resource/ietf/grip/
Other documents of interest for the discussion of incident response
teams and their tasks are available for anonymous FTP. A collection
might be found on:
ftp://ftp.cert.dfn.de/pub/csir/docs/
Some of the especially interesting documents are:
o CERT-NL Framework
ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt
o FIRST Potential Members
ftp://ftp.cert.dfn.de/pub/csir/docs/first.potential.members.txt
ftp://ftp.cert.dfn.de/pub/csir/docs/first.members.profile.txt
o Bibliography
http://www.cert.dfn.de/eng/team/kpk/certbib.html
Milestones and Next Meeting
The proposed milestones were revised. Up to now there are no changes
necessary. It was decided that we will strive to have two drafts
between now and the next IETF. Proposed dates for the drafts were the
first of May and the first of June. Peter Berger, editor of the
document, will send out the next draft.
At the Stockholm IETF in July there should be two meetings, one for the
review of the first document, one for the outline of the second
document.