home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / security / misc / 2312 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  4.7 KB
  1. Xref: sparky comp.security.misc:2312 alt.comp.acad-freedom.talk:3789
  2. Path: sparky!uunet!mcsun!Germany.EU.net!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: 17 Dec 1992 11:25:56 GMT
  7. Organization: Fachschaft math/inf, Uni Karlsruhe, FRG
  8. Lines: 85
  9. Message-ID: <1gpo44INNe27@iraul1.ira.uka.de>
  10. References: <1992Dec14.211255.15839@lambda.msfc.nasa.gov> <1gkpsmINNn05@iraul1.ira.uka.de> <1992Dec16.173049.19678@oracle.us.oracle.com>
  11. NNTP-Posting-Host: irau31.ira.uka.de
  12.  
  13. In article <1992Dec16.173049.19678@oracle.us.oracle.com> mfriedma@uucp
  14. (Michael Friedman) writes:
  15.  
  16. >>I really don't know about installations where the security people are
  17. >>officers...
  18. >
  19. >Personally, I don't think that you know about any installation where
  20. >there is any need for security, period.
  21.  
  22. You surely may be right. There is no need for this kind of "security"
  23. they're talking about here, *here*. I'll state more precisely.
  24.  
  25. >>You run into this as soon as you start thinking, "the less I allow to
  26. >>the users the less damage can/will they do", which is wrong, imho.
  27. >>But if the changes involve (e.g.) hiding an
  28. >>entire subnetwork behind a firewall, this *does* affect the users. And
  29. >...
  30. >
  31. >Olaf, do you really believe that an academic site should put computers
  32. >that students can access on the same network as the ones containing
  33. >grades, financial data, and medical records without putting in major
  34. >firewalls between the networks?
  35.  
  36. No, but:
  37.  
  38. 1. "Students can access": You risk of getting me angry if you put up
  39. the implication "student => security risk". I really do not want to
  40. fire up a flame war, and I well recognize that there are some people
  41. who are students and who are a security risk, especially when it comes
  42. to networks (don't tell me, we had an incident like this just
  43. yesterday :-( ) But the kind of thinking, "we put students on this
  44. machine, therefore we have implemented stiff security, tell me if
  45. something doesn't work anymore"(*) - the kind of labeling ANY student
  46. a potential network disrupter and malicious cracker *in the first
  47. place* - this discriminatory thinking against students IN GENERAL, is
  48. a major problem, imho. It is "guilty-until-proven-innocent" thinking.
  49.  
  50. (*) This is an actual case. Exactly this message has been issued to
  51. all NON-student users of the system I'm on now, about a year ago. And
  52. they still wonder why students who accidentally heard of this message
  53. feel pissed off.
  54.  
  55. 2. Firewalls where firewalls are due, but not between two neighbouring
  56. departments at the same university (also an actual case).  (Don't get
  57. me wrong - not a medical department; rather two branches of the
  58. Computer Science Dept.)  Sites that *have* sensitive data are to
  59. protect *themselves*, and if you boil it down to firewalls, then they
  60. should firewall themselves.  Turned around: Does a machine whose only
  61. work is to maintain a database about medical records for exclusive use
  62. in that hospital have to be hooked on a world-wide network which is
  63. known for its lack of inherent security, which is known for many
  64. people being around who can be malicious (NOT ALL OF THEM BEING
  65. STUDENTS) and for a general open-ness of services which implies that
  66. there are many services most people don't know of? I doubt.  And I've
  67. never said that all machines are to be treated equal regardless of the
  68. data they work on. But just a little care has to be applied on either
  69. side.
  70.  
  71. 3. Disrupting users: yet another actual case. You wonder why that
  72. program didn't compile and discover that <curses.h>, like almost any
  73. other file on that machine, is mode 640 and you're not in the right
  74. group, because all "security" on this Unix system is based on groups
  75. (not a bad idea at all, but it can be implemented more or less
  76. reasonably.) Security????
  77. This is the kind of cases I thought of with my statement that a
  78. certain misconception of "security", not security in general, serves
  79. no good, especially in places that have no inherent need for enhanced
  80. security.
  81.  
  82. I'm very concerned about security in general, e.g. for privacy
  83. matters. Something is absolutely necessary in this field. But for
  84. security concerns to be accepted by the users, the implementation has
  85. to be done carefully so that legitimate use is NOT disrupted, and this
  86. makes me worry insofar as I from my (admittedly limited) experience
  87. know of more cases where this went wrong than where it went right.
  88. Unfortunately.
  89.  
  90. Olaf
  91.  
  92.  
  93. -- 
  94. | Olaf Titz - comp.sc.student  |   o     | uknf@dkauni2.bitnet | old address |
  95. | univ. of karlsruhe - germany |  _>\ _  | s_titz@ira.uka.de   | is still    |
  96. | +49-721-60439                | (_)<(_) | praetorius@irc      | valid       |
  97.   "My heart is human - my blood is boiling - my brain IBM" - Mr. Roboto
  98.