home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / cud / cud436d.txt < prev    next >
Text File  |  1995-01-03  |  4KB  |  68 lines
  1. Date: Tue, 11 Aug 92 09:01:16 PDT
  2. From: jmcarli@SRV.PACBELL.COM(Jerry M. Carlin)
  3. Subject: File 4--Bell System Policies (Jerry's Response 2)
  4.  
  5. > From zygot!john@apple.com Mon Aug 10 17:48:25 1992
  6. >
  7. > jmcarli@SRV.PACBELL.COM(Jerry M. Carlin) writes:
  8. > [Lots of stuff about how Bellcore and Pac*Bell give major lip service
  9. > to security.]
  10.  
  11. I don't consider spending tens of millions of dollars over the past
  12. few years as "lip service".  If you wonder what on: such things as RACF
  13. for MVS is not cheap. SecureID cards cost quite a bit when multiplied by
  14. 10,000 people. Getting lots of shredders costs money. Could we have spent
  15. it more wisely. Of course, but what else is new. IMHO we've done pretty well.
  16.  
  17. > But the truth of the matter is that while Bellcore may have written a
  18. > book on the matter of security, it apparently forgot to read it. Even
  19. > to this day, it is more or less a trivial matter for a knowledgeable
  20. > person to get into things he shouldn't.
  21.  
  22. It's neither easy nor quick to plug all the holes in 'swiss cheese'. The
  23. point I'm trying to make is that we've been working on it for a number
  24. of years and are continuing to work on it and that we've made good progress.
  25.  
  26. > ... Good for you. It is about time. Why has it taken so long?
  27.  
  28. Some of the reasons are our fault and some are not.
  29.  
  30. We have been yelling at vendors to deliver operating systems with adequate
  31. security features and bug fixes for a number of years now. I'm REALLY
  32. tired of having stupidities like /etc/hosts.equiv "+" and initial ID's
  33. without passwords forcing us to do work we should not have to do to clean
  34. it up.
  35.  
  36. Some of the problems require new technology. We REALLY want Kerberos
  37. and/or OSF DCE but they are not ready yet.  We're just getting to the
  38. point of having secure SNMP. When the protocols are full of security holes
  39. it makes it kind of difficult to have true security.
  40.  
  41. By the way, my personal opinion is that the biggest security problem is
  42. people. We can have the most secure systems in the world, and they can
  43. even be maintained in a secure state but one successful "social engineer"
  44. can knock all of that into a cocked hat. It is a non-trivial problem to
  45. make sure that all legitimate calls from one employee to another get
  46. responded to without delay while at the same time catching all those
  47. trying to talk employees out of confidential information or into opening
  48. up some access in the name of a (bogus) emergency.
  49.  
  50. There is a public trust issue here. If someone gets the unlisted number
  51. of a public figure and then uses that to harass the person, it's a serious
  52. matter. If the 911 service is disrupted lives are at stake. If someone's
  53. conversations are intercepted illegally, we've violated an expectation of
  54. privacy if not various laws.
  55.  
  56. While I obviously believe that John is overemphasizing the negative, his
  57. feeling that security is vital and that we need to finish the job is one
  58. that I share. I think it is mandatory that we do so if we want to succeed
  59. in the coming era where any customer will have a choice between several
  60. vendors for basic dial tone. We're getting close now with cellular and
  61. will get closer with the next generation mobile technology.  Even the
  62. hard-wired local loop will be opened up. We can no longer be arrogant
  63. since "we're the phone company, after all". It's not true now and it will
  64. be less true in the future. We're "A" phone company not "THE" phone
  65. company.
  66.  
  67. Downloaded From P-80 International Information Systems 304-744-2253
  68.