30th IETF, Toronto, Canada. - July 1994
Guidelines and Recommendations for Incident Processing (GRIP) BOF
The GRIP BOF meet to discuss forming a working group which would produce
guidelines and recommendations for use when dealing with security
related incidents. The scope was to produce recommendations suitable
for use by response teams (RTs), Internet users and vendors of hardware
and software products.
The participants decided that the scope of the BOF would address only
security related issues rather than, e.g., legal issues such as use of
the Internet for the commission of crimes and how to interact with law
enforcement agencies. This should be thought about, and perhaps another
effort can be spun off in a year when the issues in that area are better
We need to define what an ``incident'' is (e.g., break-ins, denial of
service attacks, etc). If we consider the attributes of integrity,
confidentiality and availability, loss or attack on any one of these
might be considered a ``security incident.''
The BOF felt that a working group should address response to incidents
and what response teams (RTs) should do, rather than an education or
prevention effort. It was felt that the Site Security effort would
address this, and there there was already plenty of response activities
- How is a response team established (for example, an in-house response
team)? How does one response team interact with others?
- What sort of information is needed for a response team to respond?
- How about mandatory auditing and other tools which users can be expected
to have? Should there be recommendations made in the site security
- Should have response team recommendations vs. external procedures; that
is, the team itself rather than how one response team interacts with
another response team.
- Need a single framework for a response team; this could make it easier
for one RT to communicate with another like group since the expectations
and procedures could be similar.
- Include expectations on RT capabilities, e.g., secure communications.
- It might be useful to have a government entity maintain a registry of
identified, certified or somehow blessed response teams. This could
provide liability protection. ``Launder your liability.''
- Should a security organization hierarchy be defined or referenced? This
would include a site security officer, organizational-wide security
people. Should investigate existing organizations and structures, such
as those in place for the DDN, for further ideas.
- A response team acts as a proxy for their constituency, and need to have
some authority to do so. The mandate and authority need to come from
high enough in the organization.
- ``Vendors'' would include entities such as Internet service providers,
and other things which can have broken security.
- There are, perhaps, multiple classes of vendors and RTs.
- Advice to software authors: how to package software with signatures.
- Should describe methods for users and vendors interact on security
- Should describe methods for response teams and vendors to interact on
- Response teams should have secure communications at their disposal for
communicating with other response teams and their users.
- How should incidents which are submitted from outside be handled; that
is, how does an incident get handed off to another response team.
- Need to define constituency of a response team - the users which they
are to address and the technology (hardware, operating systems, etc.)
which they can support.
- Define a plan of action and procedures for escalation of security
- RTs have to have sufficient resources available to be able to function
- RTs need to somehow establish credibility.
- Each response team needs to define its authority to operate on behalf of
a constituency, and the responsibility that it has.
- User's are expected to know their RT contact.
- Should list some recommended tools for RT use.
- Need to document RT contact procedures and opportunities (i.e., 9-5 or
complete 24x7 coverage) and what sort of responses are expected.
Vendor Response Guidelines
- Are ISPs ``vendors''?
- Define a scale of security incident severity which can be used to label
a particular incident and which can be used to gauge an appropriate
- What about ``network harm'' issues, where a site has been compromised
and is a source of further attacks. When do you pull the plug?
- Need a system to measure vendor response to security incidents at a
particular severity level.
- Software packages (commercial, freely available) need to have strong
signature verification. This can be use to detect versions of software
which have been tampered with. One approach might be to approach FTP
archive sites and other software distribution points and have them
require or attach signatures.
- Software documentation should include security contact points and
procedures in their documentation. Should this documentation, where
appropriate, also include RT information and procedures?
- This should include hardware and software vendors, as well as ``free''
- Need to develop a scale or table for relating RT timing for their
actions vs. vendor response timing. That is, once a vendor has been
notified, a sequence of events is might be set into motion which will
occur even if a vendor doesn't respond in time.
The participants of the BOF agreed that there was sufficient interest in
the issues discussed to establish a working group.
A mailing list, firstname.lastname@example.org, will be set up. Requests to be
added or removed should be sent to email@example.com. Any
requests which are sent to the whole mailing list, rather than the
request mailbox, will be cheerfully ignored. The attendees of this
meeting will be automatically added to the mailing list.
The first order of business is to produce a charter for the working
group and a schedule of milestones. This will be discussed on the
Please send questions, comments, and/or suggestions regarding the
GRIP working group to the open mailing list
All issues regarding these web pages should be directed to
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.)