Slashdot Mirror
Bruce Schneier Interview on Salon
citmanual wrote to us with the Schneier interview on Salon. He's promoting his new book Secrets and Lies. I'm just about finished with it, and will be doing a review soon - it's quite good.
← Back to Stories (view on slashdot.org)
For example, it is possible to easily execute money transfers and stock trades as someone else at A Large Internet Broker Who Will Remain Unnamed. This sounds bad, and it is bad, but it isn't much worse than the equivalent security at non-Internet banks and brokerages. At my bank, I can execute a money transfer by simply sending a fax with my signature to the bank. Now, any waiter, billing clerk, or grocery checkout monkey to whom I have ever given a check has my account number, the name of my bank, the bank's routing number, and an original of my signature. Photo reproduction is more than good enough for a forged fax, so it would be trivial to walk down to the local copy shop and start faxing money transfers to people's banks.
Credit cards are even worse. You need only possess the physical card, or a reproduction thereof, to use the card fraudulently. The number of register operators who actually check the card signature against positive identification and then note the form and number of the identification is incredibly small. With near-full employment here in the U.S.A., the diligence of the rank register operator has become even worse in recent years. Fraud is trivially perpetrated in real-world banking and retail.
My final example involves my own clients. I am in a line of business that automates business processes in medium and large companies. Invariably, the client wants to ensure that the computer-automated process is totally secure. This is good and I applaud their concern. However, it is funny to note that the manual processes they are replacing haven't the least bit of security at all. Often, the "process" involves one person rubber-stamping a piece of paper and placing it in an open bin on some other person's desk. Yet they insist on impenetrable electronic security.
Or the coder throws in a 1024 byte buffer and says to himself "I'll go make this more robust once it is working". A couple days latter, he's got the system working, so he runs off, shows it to his boss, and moves on to the next project, forgetting about the work he has left to do on the program that "works".
Usually the tradeoff isn't program performance vs. security but coding time vs. security/performance/whataver.
The cake is a pie
Salon takes this quote out of context. Schneier goes on to say:
I haven't read the book yet, but my understanding from what Schneier says regularly on his very interesting mailing list is that he and others had been looking at security the wrong way. The analogy he uses frequently is to safes. Safes don't claim to be uncrackable; instead they come with ratings specifying how many minutes it would take a skilled safecracker to open them. Schneier's argument is that this is the same approach we should be taking to information security. Not "this security is crackable and that security isn't," but "this security can be cracked by a skilled intruder after X minutes/hours, giving you that much lead time to respond. Plan accordingly."
-
-
Give me liberty or give me something of equal or lesser value from your glossy 32-page catalog.
Bruce simply has given up on the idea of perfect security. I don't think that he (or anyone) will be accepting some black box that promises magic. Why? Having to fight (in public) against all kinds of agencies wanting to restrict our personal freedoms is another matter. This will not change with or without Bruce's book.
In my opinion, many of the security problems that plague the internet (and computers in general) are caused by the fact that companies still put their priorities in the wrong place. Most programmers still choose performance over stability and security.
An example:
The article mentions buffer overflows, which, in my experience, have been virtually deleted in a language like Java. Sure, checking array bounds every single time may be a performance hit, but I will choose a performance hit over a security hit any day.
Basically, when you write software, don't make assumptions. Not on anything. I've seen plenty programs crash because they tried to access the network and found that it was not installed, or play a sound and find the device busy.
We may not be able to fix the people, but I think fixing the the software is possible. All it requires is ridding the world of software licences that deny responsibility. Once financial gain is at stake, corporations will put a lot more time into security, and hopefully a lot less in screwing eachother for financial gain.
Simply because it's not possible to create perfect security does not mean that we should give up the ghost and go home. Quite the contrary, it is simply an indication that computers are indeed a part of the real world. Are real world banks 100% secure? Do the never get robbed? Obviously not, but we still have trust in them. Simply because "you cannot build a robbery proof bank" does not mean that we should give up banks (and their like) alltogether. And, while the Fort Knox gold repository isn't precisely invulnerable, it is sufficiently close to being so for the purposes necessary.
Computer security will necessarily ebb and flow as people recognize the issues and concerns and understand how to deal with them, etc., etc. Currently, there are many examples of poor and lax security because A) the favored model for computing has many security problems, B) unix is not a very secure operating system (face it guys, I love unix to death, but in many ways it is fundamentally broken when it comes to security [luckily, unix is so flexible that you can patch up the huge gigantic rents enough to make it pretty a box pretty damn secure]), C) everyone and their mother has some sort of semi-important server, which when combined with D) very few people actually understand even the basics of making a network / server / system secure can only cause problems.
In the semi near term, one of two things will most likely happen. Either 1) people will in general become more security concious, or 2) programs and systems will be made more inherently secure. I think 2 is much more likely, though a combination of 2 and a little bit of 1 would go a very long way.
A long, long time ago I was utterly taken with formal methods. I lived and breathed Z and VDM.
Then one day I read a paper about the *limits* of formal methods. The one phrase summary of the article was that once a formally-verified program meets the real world, each time it's executed is a conjecture.
The paper seemed to be an argument against formal methods and as you might guess, all the heavy hitters with PhDs and post-doctoral work to defend generated a storm of complaint, the one phrase summary of which was that while formal methods might not be perfect, they shouldn't be abandoned.
I mention this because of the author's original notion of protecting ourselves by wrapping ourselves in mathematics, and his current appearance of despair.
It appears to me that the book's more a reaction to a crisis in faith than anything else. I don't think anyone really expects security to be uncrackable - we're got history going back to the pharaohs on that one, but neither should we throw the baby out with the bath water. I mean, I think I've seen at least one reaction that uses this article to predict the *imminent* *death* *of* *the* *internet*. As if!
668: Neighbour of the Beast