log files (was: Re: dbts: Cryptographic Dog Stocks, The Dirigible Biplane, and Sending the Wizards Back to Menlo Park )
It strikes me that while Mr. Hettinga and other e$ seers may have spent the past decade considering how to allow transactional exchanges to escape a human linkage, most professional sysops and network managers have been concerned with how to strengthen the linkage between on-line accounts, actions, and audit trails -- and the humans to which a user's account has been assigned.
Leaving aside the rest of this discussion, Vin touches on a point that I think has been ignored by some: operations demand log files. That is -- and I'm doffing my security hat here and donning the hat of someone who has been running computer systems and networks for 30+ years -- when I'm trying to manage a system and/or troubleshoot a problem, I *want* log files, as many as I can get and cross-referenced 17 different ways. This isn't a security issue -- most system administrator headaches are due to the "benign indifference of the universe", or maybe to Murphy's Law -- but simply a question of having enough information to trace the the perturbations caused to the system by any given stimulus. The more anonymity, and the more privacy cut-outs, the harder this is. I claim, therefore, that the true cost of running such a system is inherently *higher*. There may be, as some have claimed, offesetting operational advantages. But the savings from those advantages need to be balanced against losses due to hard-to-find bugs, or even bugs that one isn't aware of because there's insufficient logging. Remember that double-entry bookkeeping catches all sorts of errors, not just (or even primarily) embezzlement. To be sure, one can assert that the philosophical gains -- privacy, libertarianism, what have you -- are sufficiently important that this price is worth paying. With all due respect, I will assert that that debate is off-topic for this list, and is best discussed over large quantities of ethanol.
At 05:26 PM 10/26/98 -0500, Steve Bellovin wrote:
Leaving aside the rest of this discussion, Vin touches on a point that I think has been ignored by some: operations demand log files. That is -- and I'm doffing my security hat here and donning the hat of someone who has been running computer systems and networks for 30+ years -- when I'm trying to manage a system and/or troubleshoot a problem, I *want* log files, as many as I can get and cross-referenced 17 different ways. This isn't a security issue -- most system administrator headaches are due to the "benign indifference of the universe", or maybe to Murphy's Law -- but simply a question of having enough information to trace the the perturbations caused to the system by any given stimulus.
The more anonymity, and the more privacy cut-outs, the harder this is.
With respect to Steve's vast experience on this subject, I must disagree. Managing and tracking systems and networks does require monitoring and logging of traffic. However, the information of interest is confined to the headers. There is no need to examine the body of user messages for these purposes. Even less would their be a need to "crack" some kind of bearer token. (Of course this implies that crypto should be applied as far up the stack as possible, ideally in the application. But that is another debate.) I hear you saying, "but what if the guy is trying to break into my system." I would argue, that if you are using strong cryptographic authentication (whether his identity can be mapped to a human being or not) then either 1) he will fail, in which case you don't care or 2) he will succeed, in which case he must have used some technique like stealing a key which cannot be detected by monitoring. I raise this point, because I see it as part of a current trend to resist stong security measures in preference to weak ones. The current industry facination with weak measures, like firewalls and intrusion detection systems has caused some people to resist the introduction of strong measures, such as cryptographic authentication and data protection. The most popular example of this is the foolish practice of putting an SSL server, with its vital server private key, outside the firewall in a DMZ. But I have also heard system administrators protest the introduction of cryptographic solutions because some current half measure will no longer work. There are even misguided individuals who have proposed putting master decryption keys at vulnerable locations like border routers, so that messages can be inspected in the fly. Like many people here, I live in the practical world and read dbs for serious amusement (see Darwin on Malthus). However in both worlds I spend a lot of time trying to distingush the sound from the foolish. Regards, Hal ==================================================================== Harold W. Lockhart Jr. PLATINUM technology Chief Technical Architect 8 New England Executive Park Email: Harold.Lockhart@platinum.com Burlington, MA 01803 USA Voice: (781)273-6406 Fax: (781)229-2969 ====================================================================
participants (2)
-
Hal Lockhart -
Steve Bellovin