I am writing to express my utter disgust with your corporation's heavy handed
tactics against innocent programmers trying to use the CueCat on other
operating systems. The free CueCat software that has been developed and
posted to the Internet in no way infringes on your intellectual property. It
is simply a driver for the device! I am certain that no use was made of your
copyrighted material (i.e. software that came with the cuecat) to learn to
decode the cuecat's output. (It really is not a difficult thing to do simply
by analyzing the output of the device.) Also, note that users of the cuecat
are not required to sign any form of non-disclosure agreement so no
"intellectual property" could be released there. As for Trade Secrets, do you
think that someone broke into your property to steal a secret that could be
decoded by anyone with a pencil, paper, and a bit of time?
Obviously, we aren't talking about patents here or trademarks. So nothing is
left. Your use of the legal system to stifle free development of software that
supports your device is utterly reprehensible and you deserve to be sued for
harassment!
I worked on the COAST (now CERIAS) Vulnerability Database as an academic for about a year. COAST was probably the best known academic security lab in the world and even we had trouble getting good information on vulnerabilities.
Frankly, partial or non-disclosure keeps the information from the people who really need it. Academics need the information to keep up with and understand what a vulnerability really is. Things like CERT advisories are useless for this. They don't have the information needed to figure out what the vulnerability really is and how to classify it. Another group hurt by partial or non-disclosure is sysadmins. If a sysadmin scans bugtraq even weekly, he can often have a patch or workaround for a vulnerability in his systems long before the vendor releases anything. Open source really rules here where there are usually alternatives such as fixing the code or getting a different free package put up instead.
Even if there exists some cabal of fully informed individuals, they are always going to leave out many of the folks that need the info. Face it, most vulnerability information is useless without enough info to exploit it.
Anonymity is the problem. Even if the system is 100% secure against unauthorized voting and ballot box stuffing, we still need a system that prevents the goverment or voting authority from tying votes to the voter.
Sure, there exist hypothetical systems for secure anonymous voting, but they are atrociously unscalable. See Schneier's book for the details on these schemes.
The problem boils down to "How do we ensure that only citizens vote, each only votes once, and still not be able to tell for whom they voted?" Oh, and you want it scaleable????
Others have tried this and are doing it correctly, but it's difficult. What the insurer must do is go in and analyze the insuree and then institute proper security policy, controls, and enforcement. Only after a revamp of the insuree, from management infrastructure and policy down to best practices by sysadmins, will the policy be written. Of course, the insuree must pay for all of this. This is what they mean by "managing risk."
For some companies, this makes a lot of sense. Others take their chances. In any event, I foresee many other insurers and insurees getting in on this soon.
Look folks, Gene Kim, the primary author of the original version of TW is friend of mine. The other author, Gene Spafford, is my Ph.D. advisor. I've also met the CEO of Tripwire, the company. The reason that they were violating the LGPL was that they were having difficulty supporting all of the various libc versions found on Linux platforms.
I think it took them quite a while to decide to just give away the Linux codebase via GPL, solving the problem this way. They knew they were hag problems with the GPL and they fixed it.
This is why they are initially only GPL'ing the Linux codebase. It fixes their licensing problems. The upshot is that now we're free to port the Linux version back to all the other Unices.
(for non-anonymous uses anyway) I do incident response on a University campus regularly. I use ssh exclusively and my center, CERIAS, does as well. The problem is that the widespread use of telnet and ftp and pop on some university networks is that once one a machine is broken into, hundreds if not thousands of others are taken as well. This is because the first thing the 3l33t k1dd13 does is install a sniffer. I've seen sniffer logs that were many megs of just username/password pairs.
You see the problem is that the use of "password in the clear" protocols allows one person's poor maintenance to undermine many other hosts that are just accessed via the original host's network.
Keep in mind, anonymous ftp and telnet for use of anonymous services isn't really the issue. I wouldn't even block the ports on a router. Instead, I'd simply institute the policy of scanning the network and coming down hard on anyone running the daemon. Not perfect, but doable.
Well, IANACEBIHTGC. (I am not a crypto expert but I've had two graduate classes. In cryptographic protocols and advanced cryptanalysis. These strings of numbers are very likely to be from a one time pad which given certain assumptions are fundamentally unbreakable. The assumptions are: you never lose the pad (codebook), you never reuse the pad, the pad is truly cryptographically random. The proof of this is fundamental information theory.
If they are not one time pads, then it is possible, but a brute force attack like distributed net only works when you know the algorithm or the general family of them anyway. Also, it helps alot if you know something of the plaintext that you're after. If say, the number stations are transmitting encrypted random data such as the encryption keys for other other communications, then how the hell would you know that you'd found something when you decrypted it.
There just isn't enought information to do anything but put a bunch of smart people in front of the data and see what they can figure out.
Forgiving! -- You don't want simple errors to cause major debugging/compile problems for the kiddies. No one should have to use full-blown pointers/memory allocation to write simple programs.
Instant Gratification -- Either interpreted or fast compiles.
Simple, English-like Syntax -- symbols are hard to remember unless they are obvious.
Eye candy and sound -- some easy to use graphics primitives are nice as are simple sound
Teaches good programming practice
Basic (most of them anyway) fulfills most of these except for teaching good programming practice. (although, QB isn't bad with explicit everything and no line numbers or gotos)
Pascal works well here compiles fast, etc.
Java compiles slowly, and kind of gives the kiddies too many modules.
Let's see if other can come up with other needed properties and lets see how existing languages turn out.
I have this straight from one of Intel's senior researchers. The original concept was that the CPU ID would be used for tracking assets in an organization. Inventory type stuff. This was actually asked for by major IT departments.
Then: The marketing dept. got hold of the ID number and started asking around about what it could be used for and someone said oooh, e-commerce! It was then that things got out of control and everyone got onto Intel for tracking them, etc.
The sad thing is that you don't need a CPU id if you allow your adversary to execute arbitrary code on your machine.(which you would have to do to allow someone to read your ID #) I mean a nice unique ID number is available by running/sbin/ifconfig
- Workstation installs no longer install networking daemons
- Many system daemons turned off by default
One or two traditional unices tried this at some point and were chastised by users for it. I can't wait to install 6.2 to see what it enables by default. This is a big security win for newbies and other clueless installers.
Noticed the included kerberos stuff, that's nice too, but I wonder if openssh is included.
Some experts cite the poor/widely spread/differently formatted documentation as a sign that open source software in general and Linux specifically isn't a mature platform. I personally haven't found this to be the case, for example the Linux HOWTO pages are more useful than most manuals for closed source OS's.
Do you think that unification of format, centralization of availability, or improvement in quality are the real issues here? How can we best address these issues?
At the CERIAS Security Seminar last fall, David Aucsmith from Intel gave a talk about the history of crypto export regulation. He is on one of the advisory boards that discuss this sort of regulation with the government. He foretold these changes except for the parts about open source software.
According to his talk the plans at the time involved the following: Vendors of crypto products simply needed to submit information about the algorithms that they were using. (Typically, the marketing literature was sufficient) This is the review that the document refers to. We then asked him about open source software, and he said he was hopeful of changes to help the open source community.
From what the article says, it appears that all you have to do to post open source crypto software to the net is to send an email to an address with a link inside. Boy, now that's easy!
If you don't get the reference, consider the following moral statement that I make every morning before I leave the house.
"I swear by my life and my love of it that I will never live for the sake of another man, nor ask another man to live by me."
Both of these are quotes from _Atlas Shrugged_ by Ayn Rand. She would, and I as well, would consider you much more evil than anything else. You would make slaves of those who achieve to those who do not! You would point guns at the heads of those who can produce in order to force them to work for those who do not produce! This is the greatest evil that can be spoken. It would be more humane to kill the producer quickly instead of taking his life slowly by making him feed those who have no claim to his wealth.
Consider that most home networks set up by novices are trivially breakable, and now multiply the number of devices by 10-100 with them all on the net. Admittedly, many of these devices should be simple and we can hope that to some extent that they are failsafe, i.e. overheat shutoff on toasters, safety ranges (40 F to 90 F) on furnaces, etc, but this still doesn't solve the problem.
It's not even enough that these devices be safe from changing of settings, though. Even the reading settings must be strictly controlled. For instance, your furnace programming might make a perfect day schedule for a burglar looking for a score. Hell, even the time you have your toast every day might be used by marketing bozos.
So, we need strict access control and authentication, but make it easy. Smart cards or similar tokens are probably part of the answer, but there is still a long way to go before this is viable.
What I'm afraid of is that the industry will pull another SNMP nightmare. SNMP was in a huge demand and so it was rushed out the standards door with no real security. After that, it took two tries to get it even close to right and that assumes the v3.0 is actually good. And get this, SNMP let's you configure and view information on your network infrastructure! The very first thing of interest to an attacker!
If everything in the house wired is going to be a good thing, we need a nice standard for a cryptographic token and its use over an open network. It has to provide for lightweight servers (appliances) and be easy enough that Joe normal can use it. Finally, we need some sort of standard about how these devices come configured: for instance, a default safe mode where the user actually has to work to shoot himself in the foot.
OK, time for a lesson on Digital Signatures! Copying of a digital signature is very, very, very difficult. You must get or subvert the signer's private key which would be kept on the Pilot. Presumably, the user would use a passphrase to encrypt the private key on the pilot, and the private key would only be decrypted when the passphrase was entered so that something could be signed.
You can't just copy a digital signature from another document because it is inextricably linked to every bit in the signed document. The process for document D is as follows: 1. Take a cryptographic Hash of D to get H(D) (It is very hard to make another D with the same H(D)) 2. Prompt user for passphrase P. Take a hash of passphrase H(P) and use it to decrypt the encrypted private key E(H(P), private). So, D(H(P), E(H(P), private) ) == private Encrypt H(D) with the signer's private key and include it as the signature. E(private, H(D)) == signature 3. Now anyone who knows the public key of the user can verify the signature by decrypting the signature using the user's public key and hashing the document itself and then comparing. E(public, signature) == H(D) =?= H(D) If it matches, the signature is valid, if one bit is changed in D, then it is incredibly unlikely that the H(D)'s will match.
I do agree that a poor implementation and poor passphrases from the user do make this scheme a bit troublesome. Assuming good passphrases are used, you would need to borrow the pilot and subvert it in someway. Or... look for emissions from the pilot and try to steal the passphrase or private key that way. Either are more likely to work than breaking the signature scheme. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -----Benjamin Franklin
How is someone cracking your system and looking through your files any different than someone breaking into your house and looking through your filing cabinet? (ethically, that is.)
It's true that intellectual electronic property can be copied without denying it of the producer, but this is quite different than saying that its ok for anyone to steal someone else's work or information. People have the rights to their own work. This is what allows you to put your work under the GPL, for instance. But regardless of what all the socialists will tell you, you do not have the right to my work. That's the difference.
Oh, and BTW, This holds equally as well for any kind of information digital or otherwise.
All that such a program needs to do is stress that electronic property is the same as "real property." In other words: There is no difference between the crook who breaks into your house and the crook who breaks into your computer. BOTH ARE WRONG. (and don't bother telling me about how computer systems are wide open and everything, so are houses. How many of you live underground with bulletproof locks on the doors?) At CERIAS, there are plans to build an outreach program for school age kids. I suspect that this will be one theme of the outreach program once it gets set up.
While you may debate the effectiveness of DARE and othter programs like it, I would argue that you're comparing apples to apricots.
Finally, I think you should consider that when this article says "hacking" they are definitely implying "cracking." An illegal and unethical act and if you have any doubts about the ethics, you should look up some of Gene Spafford's papers on the ethical nature of cracking.
This is a much bigger problem than the petty dispute about cracker/hacker terminology. (flames>/dev/null)
The problem is that science requires specific meanings for measurement units. Mega means 10**6, not 2**20. No one may use the new units in popular press, but it'd be great for publication. There would be no doubt that 25 Kibibytes is 25 * 2**10 bytes. It's a shame that they didn't do this 20 years ago.
The literature is full of attempts at systems like this. Some of them fairly old. This kind of modification needs to be thoroughly researched before it's just tossed out willy nilly. It's likely that a good deal of insight can be had by just checking the journals.
You miss part of the point. First, security is never going to be perfect. All we can do is raise the bar. Making the attack more difficult or time consuming is important. Script kiddies might get much more bored if their favorite root exploit took 3 hours to succeed.
2nd missed point: You changing the config files is not a problem since, sendmail isn't doing it! i.e., their work implicitly handles this because they look per subsystem for patterns, not the whole system.
3rd: Ramping up an attack here isn't such a problem unless your system is adaptive. Frankly, I don't want my system for checking Sendmail for instance to be adaptive. It should stay the same until a new version of the package comes out, then the patterns can be regenerated. (BTW, this is more or less automatic.)
There is a great deal of literature on the problem you present. (I've done research and journal publication in the area.)
Forrest (and her grad students, one of whom I've met) have discovered that relatively short patterns of self-like behavior are easy to spot and cover most normal behavior of a system. For instance, system calls in Sendmail. You might find 20 some patterns of system calls that correspond to almost all of legitimate behavior. But, when someone hacks or tries to hack Sendmail, the known patterns don't match anymore. After this happens for a bit, the system can sound an alarm.
This works very well in several different areas and they have published many papers on the topic.
Now, getting this to work for viruses might be a bit more difficult. But for misuse detection, it may be just what the doctor ordered.
Also, I wish that more posters would read the article closely. Some of the responses are way off base.
First: Closed source encryption products shouldn't be trusted. There are quite a few stories about leaking key bits in headers and the like. None are confirmed, but the NSA did manage to infiltrate Crypto AG. One of the "merits" of the Digital Signature Algorithm is that there is the possibility of a subliminal channel where key bits are leaked in a cryptographically secure way to an eavesdropper. This is possible by very careful choice of the random number used in the signing.
Second: Open source ones must be closely scrutinized. Consider that it took 10 years for anyone to find a problem in the key generator in Kerberos IV. (Lodin and Dole at COAST, 94?) Everyone assumed that it was safe because it was open and many people had surveyed the code. Lodin and Dole could break the session keys in ~1 second on a Sparc 5.
The security of systems is about much, much more than the theft of information. The losses by companies whose machines have been broken are often more in terms of man-hours to recover the system. Why??? Because once a script kiddie has played with your toy, you have to clean it off before you use it. This means: drive reformats, OS reinstalls, bring patches up to date, get your apps reinstalled, etc. All from a "trusted" source. Why? Trojan horses, back doors, etc.
Plus, it's not uncommon for the little bastards to DoS attack other sites. This leaves the administrator saying "I'm sorry" and dealing with complaints from other sysadmins.
All of this takes lots of time that the sysadmin should be using to do real work and TIME==MONEY!
It doesn't matter what you call someone who breaks into your house, rifles through your drawers, and then throws tacks in your neighbor's driveway. I call him a criminal, and he's usually a dumb one at that!
Slashdot Mirror
I am writing to express my utter disgust with your corporation's heavy handed
tactics against innocent programmers trying to use the CueCat on other
operating systems. The free CueCat software that has been developed and
posted to the Internet in no way infringes on your intellectual property. It
is simply a driver for the device! I am certain that no use was made of your
copyrighted material (i.e. software that came with the cuecat) to learn to
decode the cuecat's output. (It really is not a difficult thing to do simply
by analyzing the output of the device.) Also, note that users of the cuecat
are not required to sign any form of non-disclosure agreement so no
"intellectual property" could be released there. As for Trade Secrets, do you
think that someone broke into your property to steal a secret that could be
decoded by anyone with a pencil, paper, and a bit of time?
Obviously, we aren't talking about patents here or trademarks. So nothing is
left. Your use of the legal system to stifle free development of software that
supports your device is utterly reprehensible and you deserve to be sued for
harassment!
Frankly, partial or non-disclosure keeps the information from the people who really need it. Academics need the information to keep up with and understand what a vulnerability really is. Things like CERT advisories are useless for this. They don't have the information needed to figure out what the vulnerability really is and how to classify it. Another group hurt by partial or non-disclosure is sysadmins. If a sysadmin scans bugtraq even weekly, he can often have a patch or workaround for a vulnerability in his systems long before the vendor releases anything. Open source really rules here where there are usually alternatives such as fixing the code or getting a different free package put up instead.
Even if there exists some cabal of fully informed individuals, they are always going to leave out many of the folks that need the info. Face it, most vulnerability information is useless without enough info to exploit it.
Anonymity is the problem. Even if the system is 100% secure against unauthorized voting and ballot box stuffing, we still need a system that prevents the goverment or voting authority from tying votes to the voter.
Sure, there exist hypothetical systems for secure anonymous voting, but they are atrociously unscalable. See Schneier's book for the details on these schemes.
The problem boils down to "How do we ensure that only citizens vote, each only votes once, and still not be able to tell for whom they voted?"
Oh, and you want it scaleable????
This is very difficult.
Others have tried this and are doing it correctly, but it's difficult. What the insurer must do is go in and analyze the insuree and then institute proper security policy, controls, and enforcement. Only after a revamp of the insuree, from management infrastructure and policy down to best practices by sysadmins, will the policy be written. Of course, the insuree must pay for all of this. This is what they mean by "managing risk."
For some companies, this makes a lot of sense. Others take their chances. In any event, I foresee many other insurers and insurees getting in on this soon.
Well, here goes my karma....
Gee...Animals killing animals and plants. Hmm... that never happened before humans came along.
You know, recently it was discovered that animals were killing each other millions of years before the first humans came along.
More seriously, when I hear something like this, it just starts to fade off into a high-pitched dog whine.
Look folks, Gene Kim, the primary author of the original version of TW is friend of mine. The other author, Gene Spafford, is my Ph.D. advisor. I've also met the CEO of Tripwire, the company. The reason that they were violating the LGPL was that they were having difficulty supporting all of the various libc versions found on Linux platforms.
I think it took them quite a while to decide to just give away the Linux codebase via GPL, solving the problem this way. They knew they were hag problems with the GPL and they fixed it.
This is why they are initially only GPL'ing the Linux codebase. It fixes their licensing problems. The upshot is that now we're free to port the Linux version back to all the other Unices.
You see the problem is that the use of "password in the clear" protocols allows one person's poor maintenance to undermine many other hosts that are just accessed via the original host's network.
Keep in mind, anonymous ftp and telnet for use of anonymous services isn't really the issue. I wouldn't even block the ports on a router. Instead, I'd simply institute the policy of scanning the network and coming down hard on anyone running the daemon. Not perfect, but doable.
Well, IANACEBIHTGC. (I am not a crypto expert but I've had two graduate classes. In cryptographic protocols and advanced cryptanalysis.
These strings of numbers are very likely to be from a one time pad which given certain assumptions are fundamentally unbreakable. The assumptions are: you never lose the pad (codebook), you never reuse the pad, the pad is truly cryptographically random. The proof of this is fundamental information theory.
If they are not one time pads, then it is possible, but a brute force attack like distributed net only works when you know the algorithm or the general family of them anyway. Also, it helps alot if you know something of the plaintext that you're after. If say, the number stations are transmitting encrypted random data such as the encryption keys for other other communications, then how the hell would you know that you'd found something when you decrypted it.
There just isn't enought information to do anything but put a bunch of smart people in front of the data and see what they can figure out.
Forgiving! -- You don't want simple errors to cause major debugging/compile problems for the kiddies. No one should have to use full-blown pointers/memory allocation to write simple programs.
Instant Gratification -- Either interpreted or fast compiles.
Simple, English-like Syntax -- symbols are hard to remember unless they are obvious.
Eye candy and sound -- some easy to use graphics primitives are nice as are simple sound
Teaches good programming practice
Basic (most of them anyway) fulfills most of these except for teaching good programming practice. (although, QB isn't bad with explicit everything and no line numbers or gotos)
Pascal works well here
compiles fast, etc.
Java compiles slowly, and kind of gives the kiddies too many modules.
Let's see if other can come up with other needed properties and lets see how existing languages turn out.
I have this straight from one of Intel's senior researchers. The original concept was that the CPU ID would be used for tracking assets in an organization. Inventory type stuff. This was actually asked for by major IT departments.
/sbin/ifconfig
Then: The marketing dept. got hold of the ID number and started asking around about what it could be used for and someone said oooh, e-commerce! It was then that things got out of control and everyone got onto Intel for tracking them, etc.
The sad thing is that you don't need a CPU id if you allow your adversary to execute arbitrary code on your machine.(which you would have to do to allow someone to read your ID #) I mean a nice unique ID number is available by running
- Workstation installs no longer install networking daemons
- Many system daemons turned off by default
One or two traditional unices tried this at some point and were chastised by users for it. I can't wait to install 6.2 to see what it enables by default. This is a big security win for newbies and other clueless installers.
Noticed the included kerberos stuff, that's nice too, but I wonder if openssh is included.
Do you think that unification of format, centralization of availability, or improvement in quality are the real issues here? How can we best address these issues?
According to his talk the plans at the time involved the following: Vendors of crypto products simply needed to submit information about the algorithms that they were using. (Typically, the marketing literature was sufficient) This is the review that the document refers to. We then asked him about open source software, and he said he was hopeful of changes to help the open source community.
From what the article says, it appears that all you have to do to post open source crypto software to the net is to send an email to an address with a link inside. Boy, now that's easy!
"Who is John Galt?"
If you don't get the reference, consider the following moral statement that I make every morning before I leave the house.
"I swear by my life and my love of it that I will never live for the sake of another man, nor ask another man to live by me."
Both of these are quotes from _Atlas Shrugged_ by Ayn Rand. She would, and I as well, would consider you much more evil than anything else. You would make slaves of those who achieve to those who do not! You would point guns at the heads of those who can produce in order to force them to work for those who do not produce! This is the greatest evil that can be spoken. It would be more humane to kill the producer quickly instead of taking his life slowly by making him feed those who have no claim to his wealth.
Look at the OPUS project done by my advisor, Gene Spafford. Consider the kinds of passwords that people use based upon the research--they're abominal!
Consider that most home networks set up by novices are trivially breakable, and now multiply the number of devices by 10-100 with them all on the net. Admittedly, many of these devices should be simple and we can hope that to some extent that they are failsafe, i.e. overheat shutoff on toasters, safety ranges (40 F to 90 F) on furnaces, etc, but this still doesn't solve the problem.
It's not even enough that these devices be safe from changing of settings, though. Even the reading settings must be strictly controlled. For instance, your furnace programming might make a perfect day schedule for a burglar looking for a score. Hell, even the time you have your toast every day might be used by marketing bozos.
So, we need strict access control and authentication, but make it easy. Smart cards or similar tokens are probably part of the answer, but there is still a long way to go before this is viable.
What I'm afraid of is that the industry will pull another SNMP nightmare. SNMP was in a huge demand and so it was rushed out the standards door with no real security. After that, it took two tries to get it even close to right and that assumes the v3.0 is actually good. And get this, SNMP let's you configure and view information on your network infrastructure! The very first thing of interest to an attacker!
If everything in the house wired is going to be a good thing, we need a nice standard for a cryptographic token and its use over an open network. It has to provide for lightweight servers (appliances) and be easy enough that Joe normal can use it. Finally, we need some sort of standard about how these devices come configured: for instance, a default safe mode where the user actually has to work to shoot himself in the foot.
Nuff ranting for now,
Tom
You can't just copy a digital signature from another document because it is inextricably linked to every bit in the signed document. The process for document D is as follows:
1. Take a cryptographic Hash of D to get H(D) (It is very hard to make another D with the same H(D))
2. Prompt user for passphrase P. Take a hash of passphrase H(P) and use it to decrypt the encrypted private key E(H(P), private). So, D(H(P), E(H(P), private) ) == private
Encrypt H(D) with the signer's private key and include it as the signature. E(private, H(D)) == signature
3. Now anyone who knows the public key of the user can verify the signature by decrypting the signature using the user's public key and hashing the document itself and then comparing. E(public, signature) == H(D) =?= H(D)
If it matches, the signature is valid, if one bit is changed in D, then it is incredibly unlikely that the H(D)'s will match.
I do agree that a poor implementation and poor passphrases from the user do make this scheme a bit troublesome. Assuming good passphrases are used, you would need to borrow the pilot and subvert it in someway. Or... look for emissions from the pilot and try to steal the passphrase or private key that way. Either are more likely to work than breaking the signature scheme.
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -----Benjamin Franklin
Well, I think you've gotten a bit mixed up.
How is someone cracking your system and looking through your files any different than someone breaking into your house and looking through your filing cabinet? (ethically, that is.)
It's true that intellectual electronic property can be copied without denying it of the producer, but this is quite different than saying that its ok for anyone to steal someone else's work or information. People have the rights to their own work. This is what allows you to put your work under the GPL, for instance. But regardless of what all the socialists will tell you, you do not have the right to my work. That's the difference.
Oh, and BTW, This holds equally as well for any kind of information digital or otherwise.
While you may debate the effectiveness of DARE and othter programs like it, I would argue that you're comparing apples to apricots.
Finally, I think you should consider that when this article says "hacking" they are definitely implying "cracking." An illegal and unethical act and if you have any doubts about the ethics, you should look up some of Gene Spafford's papers on the ethical nature of cracking.
This is a much bigger problem than the petty dispute about cracker/hacker terminology. (flames>/dev/null)
The problem is that science requires specific meanings for measurement units. Mega means 10**6, not 2**20. No one may use the new units in popular press, but it'd be great for publication. There would be no doubt that 25 Kibibytes is 25 * 2**10 bytes.
It's a shame that they didn't do this 20 years ago.
The literature is full of attempts at systems like this. Some of them fairly old. This kind of modification needs to be thoroughly researched before it's just tossed out willy nilly. It's likely that a good deal of insight can be had by just checking the journals.
You miss part of the point. First, security is never going to be perfect. All we can do is raise the bar. Making the attack more difficult or time consuming is important. Script kiddies might get much more bored if their favorite root exploit took 3 hours to succeed.
2nd missed point: You changing the config files is not a problem since, sendmail isn't doing it! i.e., their work implicitly handles this because they look per subsystem for patterns, not the whole system.
3rd: Ramping up an attack here isn't such a problem unless your system is adaptive. Frankly, I don't want my system for checking Sendmail for instance to be adaptive. It should stay the same until a new version of the package comes out, then the patterns can be regenerated. (BTW, this is more or less automatic.)
There is a great deal of literature on the problem you present. (I've done research and journal publication in the area.)
Forrest (and her grad students, one of whom I've met) have discovered that relatively short patterns of self-like behavior are easy to spot and cover most normal behavior of a system.
For instance, system calls in Sendmail. You might find 20 some patterns of system calls that correspond to almost all of legitimate behavior. But, when someone hacks or tries to hack Sendmail, the known patterns don't match anymore. After this happens for a bit, the system can sound an alarm.
This works very well in several different areas and they have published many papers on the topic.
Now, getting this to work for viruses might be a bit more difficult. But for misuse detection, it may be just what the doctor ordered.
Also, I wish that more posters would read the article closely. Some of the responses are way off base.
First: Closed source encryption products shouldn't be trusted. There are quite a few stories about leaking key bits in headers and the like. None are confirmed, but the NSA did manage to infiltrate Crypto AG. One of the "merits" of the Digital Signature Algorithm is that there is the possibility of a subliminal channel where key bits are leaked in a cryptographically secure way to an eavesdropper. This is possible by very careful choice of the random number used in the signing.
Second: Open source ones must be closely scrutinized. Consider that it took 10 years for anyone to find a problem in the key generator in Kerberos IV. (Lodin and Dole at COAST, 94?) Everyone assumed that it was safe because it was open and many people had surveyed the code. Lodin and Dole could break the session keys in ~1 second on a Sparc 5.
The security of systems is about much, much more than the theft of information. The losses by companies whose machines have been broken are often more in terms of man-hours to recover the system. Why??? Because once a script kiddie has played with your toy, you have to clean it off before you use it. This means: drive reformats, OS reinstalls, bring patches up to date, get your apps reinstalled, etc. All from a "trusted" source. Why? Trojan horses, back doors, etc.
Plus, it's not uncommon for the little bastards to DoS attack other sites. This leaves the administrator saying "I'm sorry" and dealing with complaints from other sysadmins.
All of this takes lots of time that the sysadmin should be using to do real work and TIME==MONEY!
It doesn't matter what you call someone who breaks into your house, rifles through your drawers, and then throws tacks in your neighbor's driveway. I call him a criminal, and he's usually a dumb one at that!