This article just confirms my belief that a good security professional needs to have destructive mindset. You need to feel the urge to abuse the system as soon as you have seen it. I was not good at it, quit security research to join development!

Okay, I'm not Bruse, but I'll explain. If I open my wireless network, I know it's open. I can secure the computers behind with the knowledge that the wireless system is wide open. This is not really any different then securing the whole internal network against internet based problems. And, on the off chance that he really does have a single AP/router combo with the other computers connected directly to it, then the computers all need to be secured. How does this differ from securing a laptop that you use while traveling, connecting to what ever unsecured wireless signal you can pick up, except that you have to do it to all the devices involved?

So, let's say you keep your wireless system closed. What happens when someone cracks the encryption key and gets access anyways? What happens when an internet bot net gets turned on your router because someone found a vulnerability in it? Lots of people kept secured computers before home routers and NAT became a real necessity. Doing so hasn't really gotten that much tougher. Just more constant.

My real guess, though, is that he keeps the wireless and wired networks separated. Internet->wifi AP ->wired router+NAT+firewall-> computers. Given that he's a pro, the wifi AP and wired router might not even be connected to each other at all.

Anyone can do what Bruce implies only "special security people" can do. It's just that most people don't because there is no incentive to. You might as well announce that your special security mindset has noticed how easy it would be to go into restaurants and put poison in the salt shakers. Hell they are wide open! What were the salt shaker designers thinking of! But of course normal people are just not interested in doing that.

"This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail"

In my opinion, good engineering involves thinking that things _will_ eventually fail, how it can be made to fail _safely_ if possible and figuring out what the acceptable risk is given the cost. Modern engineers don't normally design stuff to last for 1000 years (some of it might last that long - distribution curves and all that).

I do crypto for a living .... my bank really really wants me to to use their web banking service - but I have a dilemma - is it safe? if I try and break their security to test them a couple of things might happen: if it's any good they'll catch me and I might go to jail .... if it's crap there's no point in me using their service - so I can't win and can't use their service

Yes, but more like "ooooh look at the dark and deep mind of Bruce Schneier, he is so briliiant." He's so dramatic about it. Jesus, a lot of people do security, why does he think he understands all of them ? It's another branch of computer science - not being James Bond. In fact I went into security after college because of the allure, but in fact the daily things that have to be done are not that glamorous, and have little to do with his strange psychological theories. And I agree, the book is overrated.

I think its all about having written a fat book at the right time and place. I can't stand it, but all my friends have it - yet none of them have read it! It has become the book you have on your shelf to look cool. Another Bruce Schneier, pronouncement about his superiority, ah yes...It would be nice if there were more articles here about current developments in cryptography. I've heard more than enough from Schneier. There are MANY other interesting security people out there to read, who aren't confused.

I used to look forward to reading what he had to say - in the 1990's. Now when I see these articles about what the almightly Bruce Schneier says I cringe.

You cringe because he keeps saying the same things over and over again.

He keeps saying the same things over and over again because people keep making the same dumb mistakes over and over again.

Tell you what, when you've written a book that gives a tenth of the useful advice, interesting information and insightful analysis of a single issue of CryptoGram [counterpane.com], come back and tell us about it. Until then, your words serve only to make you look bad.

And then the snipers would shoot them as they were packed like sardines into the busses. Me, I would pull one of 50 cards with random "evacuation plans" out of a hat and did what it said on the card. I'd include an "ignore the bomb threat" card in there as well.

In fact I went into security after college because of the allure, but in fact the daily things that have to be done are not that glamorous, and have little to do with his strange psychological theories.

Implementing security procedures is not at all glamorous, and does not require more than understanding the system to which they apply. Writing security procedures in such a way that they will be difficult to abuse requires a twisted mind. Doing it correctly, so the procedures properly balance security and availability, requires a mind that is twisted and straight at the same time.

While I agree with many points of the article - specifically that a security professional must have an unusual mindset - I am troubled that the examples leave out the cost-benefit analysis. As an example, the article correctly points out the vulnerability associated with picking up "your car" from a service department. All you need is a last name, no ID. This is an obvious vulnerability. On the other hand, the service department is motivated to make the process as streamlined as possible for its customers. Demanding IDs, etc., will slow down the process. The more cumbersome the process, the more likely customers are to use a competitor. Therefore, they need to trade security with cars to the cost of loosing customers.

I am reminded of the time that I test drove a new car. All the dealership wanted was a photocopy of my driver license, and they let me drive the car off the lot for an extended test drive. Since driver licenses are relatively easy to fake, I wondered how often cars are stolen. I asked, and was told they are stolen on occasion, but insurance covers it. My point, they did the cost-benefit analysis, and decided on an insecure method.

No need to call in the busses. Just tell everyone that they may go home for the day. They will disperse randomly in every direction, quicker than any school administrator can administer their movements and in ways that no terrorist can predict.

That's basically the answer it would have to come down to as far a secure response would go. The constant issue in the grandparent's scenarios has been that the same thing will always happen. Call in a threat, watch them load the buses... bomb the buses the next time.

Much like the pre-2001 response of "we'll sit and wait for the hijacking to end," bomb threats are dealt with as if the threat is honest. Once somebody has a case of a bomb under a bleacher to remember, we may act differently.

Security tends to be reflexive.

At least he has accomplished something notable, which is a heck of a lot more than can be said for an anonymous post criticizing said noteworthiness.

This article just confirms my belief that a good security professional needs to have destructive mindset. You need to feel the urge to abuse the system as soon as you have seen it. I was not good at it, quit security research to join development!

I would not say a destructive mindset but rather an inquisitive one - that asks "What possibilities does this open up and how can I use this to other ends?"

The challenge is to turn that mindset to productive, rather than destructive ends.

Speaking as one who has done that work; a little paranoia is a good thing as well; because some people are out to get you (and even more are just plain stupid enough to do a dumb thing).

I have written a long long reply to his article at my blog [blogspot.com] (no ads, etc.)
Short summary:
In my opinion, security in real life is not about "what can go wrong". It is about "how often and how much can it go wrong and am I prepared to handle those cases". In short it is more about how to calculate risks accurately and knowing when to take them.

I would say quite the opposite. I think it's well documented that Mr Schneier used to think that cryptography would solve all our security woes, and then he realised this was only a small part of the picture. You may have preferred him when he was all gung-ho on the deeply technical and fascinating aspects of crypto - I love that stuff too - but you are not his audience anymore.

Things that you may think are obvious are just not to most people. He's trying to reach normal people, business leaders, politicians - people who don't get it, or still think security is just boring techy stuff that doesn't work very well. He's trying to show it's also a mindset, a way of seeing the world, that anyone can understand. I think he's doing pretty good, but again, we are not his primary audience.

I take the third view. I believe you need the ability to (forgive the overused phrase) "think different". 100% of what we do every day in life is based on a world of assumptions. To be a good security researcher requires distancing yourself from the assumptions, breaking out of the ruts in the road, and trying different things. The majority of security holes exist because the developers and defenders are making the same assumptions as everyone else. Buffer overflows are the classic example, and we still see them constantly even though they've been recognized for years as a major security risk.

I did in-house beta testing for a time, and used to really piss off the developers because I had a knack for knowing what they weren't planning for. I wasn't so much looking for security holes, but rather ways to crash the app. (which probably many of which were exploitable) A classic I heard was a developer submitting a bug report for "program crashes when it says Press Any Key and you press letter A". The developer called her back to his cubicle, why did you press "A"??? She said her name was Alice, and it said press ANY KEY so she hit "A". "But you're not SUPPOSED to hit "A", you're SUPPOSED to hit the space bar!" At which point the other developer stood up from his cubicle and said "oh? I thought it meant RETURN?" This perfectly illustrates how persistent assumptions are in coding. Not only are they all making assumptions, but they aren't even making the same assumptions.

That's the sort of testing I did. Deleting the last element in a list, Select all in empty lists, saving a form before completing it, entering a 200 character filename for save, taking advantage of assumptions that the user knew what they were doing and would not ask the program to do something that was certain to produce undesirable results.

One example used was getting the car from the repair shop, with just a last name.

Where I get my car serviced, I know both guys who might be behind the desk, and they both know me, my wife, and son. They won't hand over the car keys on just a last name. Which brings it all back to a frequent point of Bruce's writings - all of the security razzle-dazzle in the world doesn't make a bit of difference compared to a knowledgeable person in the right spot.

Good engineers need to look for how things can fail, too. They need to look for small parts that children may swallow, weak latches that can allow lids to fall open, weak load-bearing structures... how the environment can make their products fail. They need to look for how things can be made to fail, as well, because the hostile human element is always part of the environment... the same factors that make someone a good engineer make them a good security expert.

The problem isn't that good security professionals have a different mindset from good engineers, it's that both good security professionals and good engineers are rarer than people think, and that engineers are not as often held responsible for how their stuff fails when someone gains an advantage by deliberately making them fail.

As in many other areas of life, I try to ask myself, WWFD? What Would Feynman Do?

Speaking of security analysis, there are scripts from 9 different domains on that page, none of which are required to read the article. WTF. Thank god for noscript.

In my opinion, good engineering involves thinking that things _will_ eventually fail, how it can be made to fail _safely_ if possible and figuring out what the acceptable risk is given the cost.

Murphy [wikipedia.org] was an engineer after all.

Without disagreeing with anything at all the article, I'd like to raise the point that an awful lot of things have no security, or very porous security.

What saves society is three things.

First, mischief and curiosity aren't a powerful enough motivator to create a real problem. I don't know whether Schneier ever sent live ants to strangers... or how many Slashdot readers will try it... but most likely not very many.

Second, for most security holes it is difficult to think of a way to make money from the exploits.

Third, even if you can make money, it's even more difficult to find a way that will make significant amounts of money and to repeat the exploit often enough to make a living wage, without being caught.

Case in point: newspaper vending boxes which allow you to pay for one newspaper and access a whole stack of them. If you have a "security mindset" (or even if you don't), it occurs to you that you could pay for one and take two... or ten... or the whole stack. And, indeed, you can. The problem is that it doesn't benefit you to get more than one newspaper. So, can you take two and sell the extra? Maybe. Net profit $0.50. Could you take the entire stack out of the machine and dress up as a street vendor and sell them on a street corner? Maybe. Net profit $25. Could you do it more than half-a-dozen times? Probably not.

How about self-checkout lines in supermarkets? You can buy produce at them, and the produce isn't bar-coded. So, you can buy orange bell peppers at $3.99 a pound, put them on the scanner scale, and enter the code for green peppers at $1.69 a pound. Most supermarkets seem to rely on someone at a nearby counter keeping an eye on the self-checkout lanes while doing other things, and they don't usually come over unless a customer calls or the machine goes into an error state. Again, it's hard to see how you can make money, rather than saving a little on your grocery bill... and if you managed to do this to the extent where you were stealing hundreds of dollars, I think your chances of being detected get to be high. (I'm thinking of people who got caught recently pasting barcodes for two-dollar items over things like boom-boxes and DVD players...).

Security and crypto are not branches of computer science. They both existed before CS and are widely application outside of CS.

You sound bitter. Life's a bitch, and then you die. (This being /. you can skip the "marry one" part) Get over it.

I would agree. I've got the "security mindset". I used to work in security on the consulting side, trying to fix up people's stuff. Thought about getting into research, but the culture of the security community at the time (right before 9/11) drove me away before I could. A kind of self-hating trifecta of ex-military intelligence grunts looking at disdain at anyone that didn't come out of the armed services, genius technical boffins with all the interpersonal skills of Rain Man, or wild-eyed "Information must be free, damn the consequences" idealogues. Since I don't fit into any one of those stereotypes, I made a lot more enemies than friends (though I did make plenty enough friends, and there are many exceptions to the rule), and decided once it was nigh impossible to find work after 9/11, that a change in direction wasn't such a bad thing after all.

Now I don't make nearly as much money, but I'm both a lot happier, and my work is a lot more helpful than it was when I was a part of the "security community". Working with little companies, a security mindset can go a very long way. I don't worry about intrusion detection or policy enforcement, or priviledges, or password strength, or encryption keys even a quarter as much as I had to before. Not when no one I deal with has a backup system that actually backs anything up (if they have a backup system) when I first walk in the door, or a simple switch of web browsers or e-mail clients will eliminate the lion's share of reasonable attack vectors into their network. Not when they don't understand the concept of patching their operating system. Not when a hands on explanation of what a phishing e-mail exactly is, what they look like, and what not to do.

Not that the more complicated stuff doesn't ever come up, because it does, and often I bring it up. I've set up a lot of VPNs lately, stopping people from what they had been doing, which is exposing their file servers directly to the outside world, with no encryption or really ANYTHING other than bad passwords stopping entry. Passwords is a big pet peeve of mine. So many of my customers have passwords that so many people know, or are trivial to guess, that they've started prefacing telling me what a new password is with "I know you're going to hate me" when they tell me the password is something that every employee that has ever been there knows, including the ones that hate the owner's guts. However, I choose to see that as a glass half full. They may not be doing the right thing, but THEY KNOW they're not doing the right thing, and have chosen to continue doing things a different way. Before I showed up and spoke to them in language they understood and took the time to explain how things work, the jargon and fearmongering of the public infosec community (including antivirus software companies) helped them nil. Maybe that kind of stuff works better in bigger organizations (heck, maybe it's the only thing that has any effect in big organizations). Perhaps that's why I couldn't handle bigger organizations and have found a lot more success with the personal touch.

You may have preferred him when he was all gung-ho on the deeply technical and fascinating aspects of crypto ... but you are not his audience anymore.

I have nothing to add, other than preach on, brother.

It is always unfair to criticize a work which was never intended for you in the first place. Schneier has long since lost his faith in strong crypto as security's holy grail. He now writes, often, that security problems will not be solved with technical tools because they aren't technical problems. They are economic, political, psychological problems. In short, security problems are people problems. And he is absolutely right.

If you have a critique of his writing on these people-problems subjects, then please say so. But if you're annoyed that he has moved on from the technology aspect of security, then it's okay to say that this isn't your cup of tea, but please acknowledge that you aren't in his target audience.

He isn't writing for the math geeks anymore, and hasn't for quite some time.