home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / security / misc / 2259 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  2.8 KB
  1. Xref: sparky comp.security.misc:2259 alt.comp.acad-freedom.talk:3762
  2. Path: sparky!uunet!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!uka!s_titz
  3. From: s_titz@ira.uka.de (Olaf Titz)
  4. Newsgroups: comp.security.misc,alt.comp.acad-freedom.talk
  5. Subject: Re: Security vs usefulness (was Re: reasons
  6. Date: 15 Dec 1992 14:25:26 GMT
  7. Organization: Fachschaft math/inf, Uni Karlsruhe, FRG
  8. Lines: 52
  9. Message-ID: <1gkpsmINNn05@iraul1.ira.uka.de>
  10. References: <1992Dec14.173636.10834@ncsa.uiuc.edu> <1992Dec14.211255.15839@lambda.msfc.nasa.gov>
  11. NNTP-Posting-Host: irau31.ira.uka.de
  12.  
  13. In article <1992Dec14.211255.15839@lambda.msfc.nasa.gov> palmer@Trade_Zone.msfc.nasa.gov writes:
  14.  ^^^^^^^^
  15. You see that the following applies largely to government/military only?
  16.  
  17. >>The main job of security is to stop the user from getting his work
  18. >>done.
  19. >
  20. >I disagree, security is not a win/lose scenario...granted when the
  21. >security officer takes the easy way out when fixing a problem, the end
  22.  ^^^^^^^^^^^^^^^^
  23.  
  24. I really don't know about installations where the security people are
  25. officers...
  26.  
  27. >user usually loses functionality or useability.  But when the careful
  28. >security officer carefully considers the situation, there is almost
  29. >always a win/win solution.
  30.  
  31. ...but here (academic) every "security" effort has always been
  32. inevitably a lose/lose situation. More hassle to deal with on one
  33. side, less usability on the other.
  34.  
  35. You run into this as soon as you start thinking, "the less I allow to
  36. the users the less damage can/will they do", which is wrong, imho.
  37.  
  38. >It is especially important to inform the users of changes mandated by
  39. >security requirements and to provide them with methods to perform their
  40. >duties that are not impacted by the change.  Often the changes that are
  41. >necessary do not impact the user at all (like activating auditing, or
  42. >applying the NIS patch to implement "securenets").
  43.  
  44. I'm not sure about audits (at least they give the system management
  45. more control over the users, which *can* by itself be bad, depending
  46. on the admin people). But if the changes involve (e.g.) hiding an
  47. entire subnetwork behind a firewall, this *does* affect the users. And
  48. if you argue, "these particular users have all data they ever have to
  49. deal with on their local machines and may not do anything else", well,
  50. you're talking government, I'm talking academic. But we (academic)
  51. have to live with people and OSs who confuse security and unusability,
  52. too.
  53.  
  54. >System security is one of the toughest jobs I have ever performed, which
  55. >consequently makes it one of the easiest to perform badly.
  56.  
  57. Agreed.
  58.  
  59. Olaf
  60. -- 
  61. | Olaf Titz - comp.sc.student  |   o     | uknf@dkauni2.bitnet | old address |
  62. | univ. of karlsruhe - germany |  _>\ _  | s_titz@ira.uka.de   | is still    |
  63. | +49-721-60439                | (_)<(_) | praetorius@irc      | valid       |
  64.   "My heart is human - my blood is boiling - my brain IBM" - Mr. Roboto
  65.