2.8.3 Site Security Handbook (ssh)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

Chair(s):

Barbara Fraser <byf@sei.cmu.edu>

User Services Area Director(s):

Joyce K. Reynolds <jkrey@isi.edu>

User Services Area Advisor:

Joyce K. Reynolds <jkrey@isi.edu>

Mailing Lists:

General Discussion: ssh@cert.org
To Subscribe: ssh-request@cert.org
Archive: ftp://info.cert.org/pub/ietf/ssh

Description of Working Group:

The Site Security Handbook Working Group is chartered to create two documents: (1) a revised handbook that will help system and network administrators develop their own site-specific policies and procedures to deal with computer security problems and their prevention and (2) a new handbook for users. The text of these documents will be developed from the existing RFC 1244, plus needed revisions and additions.

Goals and Milestones:

Done

  

Meet at the San Jose IETF and (1) make a decision about which document to produce first, (2) create an SSH editorial board and (3) create a draft outline of the first document.

Done

  

Prepare a final outline of the first document.

Done

  

Meet at the Danvers IETF and create a rough draft of the first document.

May 95

  

Submit the first document as an Internet-Draft, with comment and review happening on the SSH mailing list.

Jul 95

  

Submit first document as an Internet-Draft.

Done

  

Meet at the Stockholm IETF meeting and create an outline for the second document.

Dec 95

  

Submit the second draft of the first document as an Internet-Draft.

Dec 95

  

Meet at IETF and review the second Internet-Draft of the first document.

Feb 96

  

Submit a revised Internet-Draft of the first document, with review happening on the SSH list.

Mar 96

  

Meet at IETF and do a final review of the Internet-Draft of the first document. Develop outline for second document.

Apr 96

  

Submit Internet-Draft of first document to IESG for publication as Informational RFC.

May 96

  

Submit draft of second document to Internet-Drafts.

Jun 96

  

Meet at IETF to review and edit draft.

Jul 96

  

Submit second draft of document to Internet-Drafts.

Oct 96

  

Submit final version of document to Internet-Drafts.

Dec 96

  

Submit Internet-Draft of second document to IESG for publication as an Informational RFC.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2196

PS

Site Security Handbook

Current Meeting Report

Minutes of the Site Security Handbook Meeting

Agenda

I. Status of SSH draft
II. Discuss and review comments on USH draft
III. Idea of a firewall policy document
IV. Review schedule and task assignments

I. Report on Status of SSH Draft

SSH Document went out for Last Call (expires 22nd August 1997) The editor, Barbara Fraser, has incorporated all comments and corrections submitted from the list or through other correspondence. Once the last call expires, the document will progress to informational RFC.

II. Discuss and Review Comments on USH Draft

There was some discussion was about the document structure. Erik came up with the idea of splitting it into two parts. The first part would cover all users, and the second part would concern only those users who also have administrative control over their computer. It was decided definitely not to split the document into two documents.

One concern of the group is that to split content into all users and "power" users might have the result that "power" users wouldn't read the portion for all users. There was some consensus that a statement upfront could be provided that would guide the reader.

The group then decided to review the document in two passes. The first pass would be spent discussing content issues, and the second pass would focus on what content should be moved to the administrative user section.

First Pass

There was discussion concerning use of the term "administrators" when we are really talking about a special class of users. It was felt that using the term in this context made it conflict with the usage of the term in the SSH document. Therefore, it was decided not to use the term "administrator" in this context.

In section 5.2 about Viruses and other Illnesses, it was felt that the last paragraph should be moved to the beginning of this section to explain terms for the reader. There was also a problem with the introduction of Trojan Horses that will be fixed. One subject missing from this section was a discussion about viruses introduced through email documents and attachments. The editors will add some text on this subject.

Section 5.3 about modems should have a statement added about the "Auto answer mode." Additionally, it might be worthwhile to add something about informing the system administrator whenever a modem is added to a desktop computer.

Section 5.4 is missing content. It covers destruction of information but fails to mention that unauthorized persons could simply access information or make modifications to data or systems. The second paragraph starts with something about physical security and it should be made clear that we are talking about computers in general which the user left alone. It was also mentioned that simply locking a door could help prevent unauthorized access to such computers. Given all the discussion, it was felt that the title of this section should be changed, and the editors will try to come up with something more appropriate, like "Don't leave me..."

Use of encryption by the user was discussed a little bit, and it was clear for the WG, that it is important to have this topic covered in the document. Some changes were suggested concerning the corporate user who might have the only knowledge about the encryption password. It was felt that we should include suggestions about safeguarding encryption keys to prevent loss of data due to loss of key.

The start of section 5.6 should be changed, since the phrase "third category" is awkward grammatically. The language is also rough on system administrators and tends to paint them as the bad guys. This will be changed. Encryption will be presented as just one additional measure to protect private information. It should also be made clear that there are different objectives when protecting the files with operating system mechanisms (access rights) and protecting files' content (encryption). PGP will be used as an example and we will include comments cautioning users about weak mechanisms.

Section 5.7 will be extended to include warnings to the users about adequately wiping disk files to prevent the availability of previously deleted data.

Section 5.8 contains a very extreme sentence about never sending sensitive information by email. But by using strong encryption it might be acceptable. Adding such a remark would fit with the following paragraph nicely. It was mentioned that the privacy of email on company computers might be handled very different from country to country and the statements concerning this subject should be softened a little bit.

There was some duplication noted between the three sections dealing with viruses, unknown programs and possibilities to execute unknown content. There was considerable discussion about how to warn users about what they are downloading and executing. However, it was also felt that we shouldn't get too technical in our discussion of the issues because we'll lose the reader. For example, a user might not consider a PostScript file as "code" necessarily. There was discussion of how to handle application modules that are necessary to download in order to be able to obtain the full effect out of a WWW page or other document. It was also mentioned that a major point we need to make is that many problems arise by downloading from the net from unknown sources. There are better chances to get "good" software from a well-known server affiliated with a product. Or, the local administrator might set up a WWW page with commonly needed software already collected on a local server. The paragraph about Trojan horses using the name of well-known applications will be moved to the section about Downloading.

Erik discussed the different mechanisms to protect the download: JAVA and ACTIVE X. It was decided not to include such details in the document, as the average user will probably not understand the concepts. Since this subject is very specific to the Web, any treatment of it will be handled in the WWW section anyway. It was decided that we should alert the users about the dangers, but we will not be able to protect them from using the dangerous and unprotected features. Upcoming technology might help to solve the problems. It was also mentioned that problems with downloading are also connected to downloading too much at the same time.

The section about encryption keys (5.11) should go into the relevant section and should be shortened. Details about key length will not be understood by the user and are not necessarily important to get the idea right: encryption can be weak and might be weaker because of export restrictions.

In 7.1 some statements suggesting that users be aware of last log in messages on UNIX boxes, changes in the user environment, and the addition of new files or directories (and other specific things) should be included. Examples should be used instead of fuzzy statements.

Reading the policies of the local site might fit in 7.3 here, especially in case of incidents. Before informing the whole community (about Good Times for example), the user should inform the system administrator. This will prevent users from propagating erroneous information.

Something about how to respond to security alerts should be included, but it will fit more for the power user section, since most end users will not install software or be responsible for the status of the software.

Discussion about section 8.1 was that if we get rid of shell accounts and SLIP, it is really more about services (daemons) and there is no longer any content. The most important issue to convey is that PPP creates a two-way connection. "How to pick an ISP" is too limited and there might be other issues which could be handled under a different heading. We should alert the user that the ISP network should be handled as a public network. However, it will be very difficult to obtain information concerning the security mechanisms in use by an ISP. Underlying this is that the user should make sure that they understand the policies of the ISP and ask questions as needed.

Erik promised to complete a new draft pretty soon (in September). The section about commandments needs some checks and editing. It should be addressed in every section and topic covered in the document.

Second Pass

The second pass was supposed to identify the content to be separated into a section on administrative users. However, after the discussion, we deferred this discussion until another draft is available. The thought was that we might not need any separation after all.

III. Firewall Policy Document

A presentation was given on a possible firewalls framework document. Firewall policies are very difficult and desperately needed. Often the firewall is the only security mechanism between the local network and the public network. There are some typical questions that can be addressed to help the administrator. Guidelines - not necessarily all answers - for these questions are needed. There was some discussion as to whether such a document belonged in this working group. Since it would be an extension of the material in the SSH document, the thought was that if it was to be, it did belong in the working group. It was also suggested that we might incorporate the material into the firewalls section of the SSH document. But, since this would cause a new Last Call and delay the release of the SSH document, this suggestion was rejected.

Discussion centered on the scope of the guidelines given. To be able to ask the right questions would be the main benefit for the administrators. In comparison to existing books, the benefits would be that it is free and it would give the people a document that has established quality (because it had gone through the IETF process) and could be used as a starting point for further reading. After hearing a presentation on the proposed content outline, it was decided that a first draft would be constructed for submission to the list by the next IETF meeting. The group will review the content and decide at that time how it wants to proceed.

Marc Blanchet will carry on as editor of the firewalls document but we won't associate the ssh working group name yet.

IV. Update Schedule and Task Assignments

22. August 1997: End of last call for SSH document
30. September 1997: New draft of USH document
31. October 1997: First draft of Firewall document
13. December 1997: Last input to USH document during December IETF
31. December 1997: Last ID version and submit to IESG as informational RFC

One slot (two hours) will be requested for the next IETF in December.

Current Maintainer: DFN-CERT / info@cert.dfn.de Less thanFDFMR
d

Slides

None Received

Attendees List

go to list

Previous PageNext Page