Re: log files (was: Re: dbts: Cryptographic Dog Stocks, The Dirigible Biplane, and Sending the Wizards Back to Menlo Park )

In message <3.0.1.32.19981028093825.00a3f2d0@pop.bos.platinum.com>, Hal Lockhar
Why do you assume that the flaw that lets the bad guy in is cryptographic? I recently analyzed every CERT advisory ever issued. 85% of them described problems that crypto couldn't fix. Buffer overflow is the culprit du jour, but it's hardly the only one. (This year, the prize for second place -- admittedly a distant second -- went to crypto modules.)
That's only a flaw if you assume that there are other weak points on the Web server that a firewall can protect. If you lock down the host so that only port 80 is exposed (and maybe a cryptographically protected administrative port), what good does the firewall do? The weakest point is probably the CGI scripts, and those have to be exposed in any event.
There are no panaceas, there is no single technology (and that emphatically includes crypto) that will solve this problem. Defense in depth is our best hope, which means firewalls plus crypto plus IDS plus better operating systems and programming languages. Most of all, it means engineering a solution -- making the right set of tradeoffs, even if unobvious. Let me give an analogy. On most electrical equipment, the ground pin is useless -- *unless* there has been another insulation or air gap failure within the device, a failure that would render the frame "hot". But because of the ground pin, such a failure will instead short the hot lead to ground, tripping the breaker. It thus takes two failures to electrocute someone. *But* -- toasters and other devices with exposed heating elements don't use this technique. Why not? Well, with an exposed electrode, the probability of direct contact with a live wire is much greater. And if you ground the frame of the toaster, there's now a direct, high-quality path to ground that in turn is in contact with the other hand of the poor fool who is poking at a piece of bread with a fork. In other words, what's a safety mechanism in your refrigerator is a danger in your toaster -- and sometimes, that can be true of crypto as well. For another analogy, think of insecurity as entropy. You can't destroy it, but you can move it around. Using crypto moves the problem from the (in)security of the links to the (in)security of the keys. If you can't protect your keys -- and that generally takes much more than crypto -- using cryptography hasn't bought you anything.

Steve, I think in general we are in violent agreement, as are most real world practitioners I have spoken to. I won't even argue about whether your original comment constituted "resisting a strong measure in favor of a weak measure". Let's just say that your comment brought to mind certain unnamed persons who have done this. However, I believe you missed my points in several other areas, so I will try to clarify what I was saying. Out of courtesy to the numerous lists we are cross posting to, after your next response, if any, I suggest we take this off list. At 12:13 PM 10/28/98 -0500, Steve Bellovin wrote:
I never said that the flaw was cryptographic. The idea I was trying to express was that are two cases: 1) (Today) Let in unauthenticated or weakly authenticated users. There is a (relatively) high probability that they are attackers who will try to exploit some weakness like a buffer overflow. In this case it is useful to observe their application level traffic in order to detect this or learn of the existence of the new crack they are using. 2) (Future) Allow only strongly authenticated users. Either a) they are legitimate users whose identity is known and will presumably not try to hack the system, or b) they are attackers who have done something like steal the key of a legitimate user. In the later case, I admit you might want to see what they are typing, but it will not give you any information about the underlying problem -- their ability to obtain unauthorized keys.
I agree with that. It is amazing to me how many people enable crypto like a talisman without locking down the rest of the system. However, my point was that as I understand the theory behind a DMZ, you put systems there that you think might get overrun. You do not put the mainframe that runs payroll in the DMZ. Yet, I assert, the server private key, which represents the identity of the organization ought to fall in under the same classification and receive the same protection. (Its actually worse than I indicated, since if you want your server to restart without human intervention, you generally have to put the pass phrase in a script file or something.
Agreed. I have no problem with defense in depth. Only, as I said, limiting the use of a strong technique because it interferes with the use of a weak one.
I guess I don't see the case where the use of crypto decreases security, except if a mis-design causes complacency. In my mind, strong security begins with strong (cryptographic) authentication. [Calm down Bob, I am not ruling out non-biologic identities.] If we have authentication, we can have access control, audit trails, etc. We can certainly add heuristic measures like firewalls and IDS and potentially detect additional problems. However, I have met more that a few people who want to play with an IDS because it is cool, rather than go through the hard and unsexy work of locking down their systems.
For another analogy, think of insecurity as entropy. You can't destroy it, but you can move it around.
Do you have any evidence for this remarkable assertion? It sounds like a council of despair to me. Are you saying that no matter what we do or how much we spend, we can not make systems more secure. Say it ain't so!
I agree that as we raise the bar, new attacks become the weakest link, but that does not mean you have not increased security. The new weakest links are no weaker in an absolute sense. A better analogy is computer performance improvement. If we speed up the current bottleneck, something else becomes the bottleneck, but that doesn't mean the system won't run faster. The practical reality of the Internet today is best illustrated by the story of the hikers and the mountain lion. When the hikers encounter a mountain lion one begins to tie on his running shoes. The other says "you can't outrun him with or without running shoes." The first answers "I don't have to outrun him, just you." The serious hackers don't waste their time trying to break into AT&T, they pick some place easier. (like the CIA ;-) 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 ====================================================================

At 12:35 PM -0800 10/28/98, Hal Lockhart wrote:
There is a long history of legitimate users who attempt to exceed their authorization. Double agents in the intelligence community and embezzlers in the commercial world both come to mind. ------------------------------------------------------------------------- Bill Frantz | Macintosh: Didn't do every-| Periwinkle -- Consulting (408)356-8506 | thing right, but did know | 16345 Englewood Ave. frantz@netcom.com | the century would end. | Los Gatos, CA 95032, USA
participants (3)
-
Bill Frantz
-
Hal Lockhart
-
Steve Bellovin