[Fwd: USH handbook draft - comments]
Eric Luiijf <luiijf@fel.tno.nl> Wed, 23 September 1998 07:42 UTC
Received: from po1.cert.org (po1.cert.org [192.88.209.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA03853 for <ssh-archive@odin.ietf.org>; Wed, 23 Sep 1998 03:42:22 -0400 (EDT)
Received: from smtp.cert.org (smtp.cert.org [192.88.210.47]) by po1.cert.org (8.8.8/8.8.8) with ESMTP id DAA16276; Wed, 23 Sep 1998 03:41:16 -0400 (EDT)
Received: from po1.cert.org (po1.cert.org [192.88.209.10]) by smtp.cert.org (8.8.8/8.8.8) with ESMTP id DAA05004 for <ssh@smtp.cert.org>; Wed, 23 Sep 1998 03:38:52 -0400 (EDT)
Received: from dewey.fel.tno.nl (donald.fel.tno.nl [134.221.46.5] (may be forged)) by po1.cert.org (8.8.8/8.8.8) with SMTP id DAA16234 for <ssh@cert.org>; Wed, 23 Sep 1998 03:38:36 -0400 (EDT)
Received: by dewey.fel.tno.nl; id JAA26841; Wed, 23 Sep 1998 09:38:36 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1) id xma026825; Wed, 23 Sep 98 09:38:33 +0200
Received: from fel.tno.nl (pc1076 [134.203.33.202]) by s00sn1.fel.tno.nl (8.8.5/8.8.5) with ESMTP id JAA04913 for <ssh@cert.org>; Wed, 23 Sep 1998 09:38:04 +0200 (MET DST)
Message-ID: <3608A5DE.5FBC22D2@fel.tno.nl>
Date: Wed, 23 Sep 1998 09:40:14 +0200
From: Eric Luiijf <luiijf@fel.tno.nl>
Reply-To: luiijf@fel.tno.nl
Organization: TNO-FEL
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: ssh@cert.org
Subject: [Fwd: USH handbook draft - comments]
Content-Type: multipart/mixed; boundary="------------2795606157BB25B1F73DA954"
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Eric Luiijf TNO Physics and Electronics Laboratory Telematics and Information Security P.O. Box 96864, 2509 JG The Hague Webmaster http://www.tno.nl/instit/fel The Netherlands Phone: +31 70 3740312 Email: luiijf@fel.tno.nl Fax: +31 70 3740653
--- Begin Message ---Dear Lorna and Erik, One again I have gone through the draft USH as well as through Erik's proposed changes. I agree with other's that the USH is almost complete. There are, however, a number of issues to be resolved to complete the USH, see my comments below: 1. The index is not up-to-date and contains section titles that differ from the 'real ones'. 2. In the introduction, the text speaks of the "the first part" as well as the "second" part. This is confusing as the Introduction is "Part 1". Actually, the "first part" points at "part 2", the "second part" at "part 3". I suggest to remove the "Part 1" and renumber Part 2 into 1, 3 into 2. 3. READ.ME, first line: to the Internet (add) "or any other network using Internet technology" Rationale: the USH should not restrict its 'best practice' for the Internet environment only. 4. Part two: Keep password secret; (add) "at any time" to stress the importance of this 5. Par 3.2: ...execute programs on your behalf, (add) "both automatically and after manual intervention." Rationale: the user should be aware of the automatic thing. Last line (add): " Note however, that the strength of the encryption mechanism might be dependent on the version one use due to legal import and/or export restriction." (ref: 40 bits encryption export control by the US) 6. Par 3.9: "forbid" => "forbid or restrict" is more precise as some countries allow e.g. >= 40 bits encryption when a license is given. 7. Par 5: .. to this decision. (add) "Review risks at regular intervals as well as need arises to do so.". "machine" => "system" "You take" => "You unavoidably take" 8. Par 6: "In many cases.." is too blunt. "When you do not know who your security POC, you should try to call ..... 9. Par 6.1: From a blue sky, when reading the bullet items, the virus topic pops up and is discussed in great detail. Better is to put this in a separate section with a proper introduction. "of the origin" even when you know the origin, this is not always safe... (know who made you ill does not help, better do not have a relationship...) I suggest: "of the trusted origin". "computer" => "system" (2*) Virus item 2: (add) "Install updates regularly and keep watch for new types of virii threats." Rationale: pop-up of BIOS virus and the travelling WORD <=> Excel macro virus types) The numbered list about virii has three items to "avoid problems" (line introducing the start of the list). The next paragraph, however, says "the best way to avoid problems".... This is inconsistent and confusing! The paragraph that follows is an additional item. A little clean-up is required here. 10.Appendix Auditing Tool Mentioning "SATAN" causes this issue to be too much UNIX only. One should mention tools for Windows/NT as well and probably point to e.g. the COAST list for various tools. Compound documents "is a file used by application software to save user information" .. this is a very confusing definition. First of all, the document might be hardware recorded measurement data (no application software..), secondly the user might not be the owner, thirdly the information might have been saved very long ago: "to save" is the wrong wording. "A document is a file containing a set of data (that is regarded as an information object)". "A compound document is a file consisting of multiple parts. A part might be: empty, a document, an encrypted document, a digitally signed document or a compressed document. Processing these parts might require a variety of programs....." One-Time Password (add) "(OTP)" Terminal this definition is a little outdated and confusing. Most hardware terminals have been replaced by PC's offering "Terminal" window (access). Thus, a smart(er) interface or device. Question: is this definition really required? Virus [which are shared] .. that is the ultimate wish of the virus constructor. The definition should also hold in one "system". [which are shared] => may be shared Key escrow... "third parties"... Note that the third party might one's organisation itself. The third party is then the 'third party' to the information exchange between individuals/org. parts! (add) ActiveX: Microsoft's system that allows webpages to run application (active) code from a websource on the client system, bypassing various controls. Email bombs A denial-of-service attach caused by too many Emails being received by a site. The server runs out of resources. Cookies Cookies register information about a visit to a web site for future use by the server side. The server might receive information of cookies at other sites as well, causing a breach of privacy. Security Policy A security policy is written by organisations to address security issues in the form of "do's" and "don'ts" for their users with respect to physical security, data security, information security and content. E.g. sites that have a sex content should not be visited and when downloading software, copyrights are to be honored. Add appropriate credits.... Regards, Eric -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Eric Luiijf TNO Physics and Electronics Laboratory Telematics and Information Security P.O. Box 96864, 2509 JG The Hague Webmaster http://www.tno.nl/instit/fel The Netherlands Phone: +31 70 3740312 Email: luiijf@fel.tno.nl Fax: +31 70 3740653--- End Message ---
- [Fwd: USH handbook draft - comments] Eric Luiijf