39th IETF, Munich, August 1997 ****** Site Security Handbook (SSH) ========= Agenda ====== o status of SSH draft o discuss and review comments on USH draft o idea of a firewall policy document o review schedule and task assignments 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, into it. Once the last call expires, the document will progress to informational RFC. Discuss and Review Comments on USH Draft ======================================== There was some discussion was about the document structure. Erik came up with the idea of splitting in two parts. The first part would cover all users, and the second part would concern only those users who also had administrative control over their computer. It was decided definitely not to split the document into two documents. One concern of the group was 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 concensus 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 using 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 the terms for the reader. There was also a problem with the introduction of Trojan Horses that will be fixed. One subject that was 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 worthwile 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 more clear that we are talking about computers in general which were left alone by the user. It was also mentioned that simply locking a door can 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 softed 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 how to handle application modules which 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 rised the discussion about 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 WWWW 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. 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 address 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 may not need any separation after all. 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 which 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 around the scope of the guidelines given. To be able to ask the right questions would be the main benefit for the administrators. In comparision to existing books the benefits would be that it is free and it would give the people a document that had 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 to be submitted 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 associated the ssh working group name yet. 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