NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
Louis Mamakos <louie@uu.net>
Barbara Fraser <byf@cert.org>
K.P. Kossakowski <kpk@cert.dfn.de>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Mailing Lists:
General Discussion:grip-wg@uu.net
To Subscribe: grip-wg-request@uu.net
Archive:
Description of Working Group:
The full name of this working group is Guidelines and Recommendations for Security Incident Processing.
This working group is co-chartered by the Security Area.
The purpose of the GRIP Working Group is to provide guidelines and recommendations to facilitate the consistent handling of security incidents in the Internet community. Guidelines will address technology vendors, network service providers, response teams in their roles assisting organizations in resolving security incidents. These relationships are functional and can exist within and across organizational boundaries.
The working group will produce two quality documents:
1) Guidelines for security incident response teams.
2) Guidelines for vendors (this will include both technology producers and network service providers).
Goals and Milestones:
Feb 95 |
|
Produce document describing problem statement and document taxonomy/vocabulary. Also cite the Site Security Handbook documents to make clear the relationship and scope between the two working groups and documents. |
Feb 95 |
|
Produce draft outline for remainder of Response Team Document. |
Done |
|
Meet at Danvers IETF to review full Internet-Draft of Response Team Document. |
Jun 95 |
|
Produce Internet-Draft on Guidelines for vendors. |
Jun 95 |
|
Produce final version of Response Team Internet-Draft. |
Done |
|
Meet at Stockholm IETF. Review vendor Guideline Internet-Draft. |
Sep 95 |
|
Produce final version of Vendor Guideline Internet-Draft. Submit to IESG for review. |
Internet-Drafts:
Request For Comments:
RFC |
Status |
Title |
RFC2350 |
Expectations for Computer Security Incident Response | |
GRIP WORKING GROUP
WEDNESDAY, December 9, 1998, Orlando, Florida
1530-1730 Ft. Lauderdale
Tristan Debeaupuis (Tristan.Debeaupuis@hsc.fr)
1. Modifying the draft
The current draft is draft-ietf-grip-isp-06.txt. It has been posted on the GRIP mailing list on Dec, 3rd, but is not available on the IETF ftp site due to short time.
Some people in the groups thinks the current draft is too long, not really adapted to a specific reader. We are facing the need to split the document into separate documents.
Three drafts will be created :
- ISP good citizenship : not just safewarding, but incidents have an effect on the entire community. How ISP need to behave.
- expectations of ISPs on other ISPs
- how to get a reaction from them e.g. cooperation on events that traverse multiple nets
2. Consumer checklist e.g. :
- what do you do to protect my data from your other customers
- how much multiplexing are you doing
- policy of disclosing security breaches
- privacy considerations
- channels for communicating securely
- etc.
3. Expectations of ISPs on other ISPs
- how to get a reaction from them e.g. cooperation on events that traverse multiple nets
4. SSH addendum for ISPs
- technical operations of services
- security issues surrounding the way they manage and operate their network
- section 7,8,9,10
5. Split
It is decided to take the table of contents of the current draft and to move sections to the three new drafts.
E = Expectations of ISPs,
C = Consumer Checklist;
S = SSH Addendum for ISPs
1. Introduction
A 1.1 Conventions Used in this Document
2. Incident Response
CSE 2.1 ISPs and Security Incident Response Teams (SIRTs)
SC 2.2 Assistance with Inbound Security Incidents
SC 2.3 Assistance with Outbound or Transit Security Incidents
E 2.4 Notification of Vulnerabilities and Reporting Incidents/affected customers/
SCE 2.5 Contact Information /availability/
E 2.6 Communication and Authentication /+ policy for sharing info/
SC 2.4 /Non-disclosures - disclosure of customer info/
CE
3. Appropriate Use Policy
3.1 Announcement of Policy /, public/
3.2 Sanctions
4. Protection of the Community
4.1 Cooperation (DELETED)
ES 4.2 Data Protection /privacy + log (compliance w/ gov't regulation, balance to find all around the world)
S 4.3 Training /- social engineering/
E 4.4 Registry Data Maintenance (Balance, need consensus decision)
SC
5. Network Infrastructure
S 5.1 Routers \
S 5.2 Switches, Terminal Servers, Modems and other Network Devices !
S 5.3 Anonymous telnet and other unlogged connections !
S 5.4 The Network Operation Centre (NOC) and Network Management !Manos
S 5.5 Physical Security ! for
S 5.6 Routing Infrastructure ! new
S 5.7 Ingress Filtering on Source Address / ideas
S 5.8 Egress Filtering on Source Address
S 5.9 Route Filtering
S 5.10 Directed Broadcast
6. Systems Infrastructure
6.1 Policy
6.2 System Management
6.3 Backup
6.4 Software Distribution
S
7. Domain Name Service (DNS)
7.1 DNS Server Management
7.2 Authoritative Domain Name Service
7.3 Resolution Service/update to remove entries when no longer auth./
CS
8. Email and Mail Services
8.1 Mail Server Administration
8.2 Secure Mail
E 8.3 Open Mail Relay
8.4 Message Submission
8.5 POP and IMAP Services futur avail & smtp-auth
9. News Service (NNTP)
9.1 News Server Administration
9.2 Article Submission
9.3 Control Messages
9.4 Newsfeed Filters
/E - global stay up to date whith new secure methods as they become avail/
S
10. Web-related Services
C 10.1 Webhosting Server Administration
10.2 Server Side Programs
10.3 Data and Databases
10.4 Logs and Statistics Reporting
10.5 Push and Streaming Services
10.6 Commerce
10.7 Content Loading and Distributed Authoring
10.8 Search Engines and other tools
/C - include something about understanding impact of your requets/
/C - own platform or sharing with others/
Other subjects are discussed, like the need of more than one legal authorization to perform an inquiery on more than one operator to trace a line from end-to-end.
Add : /S 11 NTP to synchronise logs/
The chair encourage people to join or participate in the mailing list : grip-wg@uu.net
None received.