Slashdot Mirror
Inside The Twisted Mind of Bruce Schneier
I Don't Believe in Imaginary Property writes "Bruce Schneier has an essay on the mind of security professionals like himself, and why it's something that can't easily be taught. Many people simply don't see security threats or the potential ways in which things can be abused because they don't intend to abuse them. But security pros, even those who don't abuse what they find, have a different way of looking at things. They always try to figure out all the angles or how someone could beat the system. In one of his examples, Bruce talks about how, after buying one of Uncle Milton's Ant Farms, he was enamored with the idea that they would mail a tube of live ants to anyone you asked them to. Schneier's article was inspired by a University of Washington course in which the professor is attempting to teach the 'security mindset.' Students taking the course have been encouraged to post security reviews on a class blog."
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!
It seems like ever since Bruce left the cryptography world for general security consulting, he's become less interested in giving useful advice and more interested in self-aggrandizing.
Such a personality may be disastrous in many other cases but works well when it comes to security work.
And remember that most computer viruses in the beginning weren't really malicious - they just were there "because I can". Even those cases has to be taken into account by security people.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
You can get a port-a-potty delivered without ever providing positive identification. You don't even have to pay for it until it shows up, and they'll happily deliver while you're at work. They're quite used to people preparing to have renovations done by contractors.
Of course, I would never decide someone else needed a port-a-potty on their front lawn. But, much like the ants, it's something you can't help but notice if you have the right mindset.
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.
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
RTFA! "There's nothing magical about this particular university class; anyone can exercise his security mindset simply by trying to look at the world from an attacker's perspective."
"I have downloaded hundreds and hundreds of records, why would I care if somebody downloads ours?" Robin Pecknold
"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
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.
My instincts on this are more of "how would a criminal or terrorist" behave in this setting" because I grew up in a law enforcement family (both parents plus extended family). I've made a few "regular people" upset in the past by pointing out the idiocy of their evacuation plans to them in pointed detail. One example comes from high school when the school shootings were just starting to disappear from the news.
Our school gets a bomb threat, and the teachers and administrators are freaked out. They move us all, I kid you not, to the football field where we are fenced in by chain link fence, about 1/3 of which is covered by barbed wire. So I point out to my history teacher, one of the only genuinely intelligent public school teachers I have ever met that we had been corralled into an enclosed area, surrounded by strong sniper nests (there were many points where a shooter with a 30.06 and a few mags could have unloaded with impunity), and that ironically, if there were a bomb, and the person who planted it were clever, they'd have put it under the bleachers where about 200-300 of us were sitting.
He nodded his head in agreement that were this a real thing, we'd probably be fucked because of our administrators' plan, but the one or two regular teachers not far away who overheard acted like I was the real danger for pointing out what should been "the obvious" about this plan. Me? I'd have called in the buses, and shipped everyone off property to be safe right away.
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.
I have written a long long reply to his article at my blog (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.
Sadly the world we live in today has massively overestimated the possiblity of problems and hugely inflates the effects they will have (in the tiny percent of occasions when they happen). I think this is a side-effect of improved communications: we all get to hear about the 1 in a million disaster stories, but never about all the other times, when everything goes right. This leads us to think that problems are more common than they actually are.
The great thing about being a security professional is that you can never be proved wrong. If you claim a security hole and it is never exploited, no-one will say you're wrong - just that it hasn't been exploited yet. If we beleived everything these guys say, no-one would ever do anything as we'd all be too scared. Personally I think we should avoid the obvious problems, get on with our lives and accept that on a few, very few, occasions we might have to spend a little time sorting out a problem.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Over the Christmas holidays, when work is always slow, I have a long habit of putting on my hacker hat and seeing what our vulnerabilities are. I think every developer owes it to their sanity to do this regularly. You will find so many opportunities for SQL Injection--no matter how careful your developers are--and Cross-Site Scripting and just a bunch of other holes. You do not want to be in a conference room some day explaining to your boss's boss why your program allowed a hacker to gain access to the company's systems through your app. This is a no-brainer.
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.
The living have better things to do than to continue hating the dead.
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.
Give me Classic Slashdot or give me death!
> 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.
You're thinking like an engineer: "How is this supposed to work?"
Try thinking like an enemy: "How could this be exploited to harm Bruce Schneier?"
The most obvious thing is to get a rental car, drive it through some mud until the plates aren't legible, and sit across the street from the guy's house and use his wireless network for... nefarious purposes. Sending spam via his ISP's mail server? Peer-to-peer child porn? Attacking government networks in a way that's likely to get noticed? So many possibilities.
And sitting across the street in a car for a while is only the really obvious attack. There are much more interesting things that can be done over the long term.
Cut that out, or I will ship you to Norilsk in a box.
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...).
"How to Do Nothing," kids activities, back in print!
This had me flashing back to elementary school arithmetic. It happened to me a hundred times. The textbook showed an equation and made a statement about it. The textbook showed another equation and made a statement about it. Then the textbook showed a third equation and asked "What can we say about this equation?"
My answers always started the same way. "It's printed in ink on paper." I don't really think that the textbook author expected people to do anything other than to extend whatever line of reasoning had been presented in the previous examples (and I always got around to that) but the open-ended question "What can we say about this equation?" always struck me as license to comment on the clarity of the typesetting or anything else.
My teachers thought I was weird.
Later in life, I became involved in competitive pistol shooting. I loved the rule books. They were just collections of hidden loopholes begging to be found. And then came the problems. In some sports it was called the "engagement" rule. In others, it was the "spirit of the rules" rule. They were all the same sort of thing - a way to say you couldn't do anything unexpected. If you looked at a practical defensive scenario and found some completely whacky way to beat it by, say, running between cover in an odd sequence, you'd be found guilty by the officials of "failure to engage" the scenario. No points for you. A guy I knew had trouble seeing sights too close to his face but the rules forbid changing the sight radius (distance between the sights) making it impossible for him to move the rear sight further from his face. He responded by cantilevering both sights forward so that the sight radius stayed unchanged but both sights were now completely forward of the muzzle. It was perfectly legal under the rules as written but his pistol was declared illegal because it violated the "spirit of the rules."
What amazes me is the hostility this mindset engenders. I'm not shy about saying that I love to parse out the rules and find advantages. I'm not shy about saying that a "spirit of the rules" rule is really just saying "You're not allowed to be smarter than the people writing the rules and running the match." The reaction I get is flaming on message boards and accusations of poor sportsmanship. There are actually people out there who want to punish innovation; at least, that's the way I look at it.
"Thinking different" makes people feel threatened and act nervous and hostile. I don't understand that. Am I weird, or are they?
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.
You've got to be kidding. Maybe it's not natural for most software "engineers", but I bet it's pretty natural for engineers in general.
Indeed.
I was tempted to take issue with Bruce on that point. After I cut my programming teeth in classified research I built a career in automobile automation engineering. I was ALWAYS looking at all the things that could go wrong, through bugs, mischance, or malice, and insuring that they were properly handled.
And this was expected. And it was honored, and the extra time required was paid for gladly. (I happened to be better at it than most, but everybody at least tried.)
But then I got out to Silicon Valley. And here I discovered that there was another, and much lower, standard of reliability when it came to software. The contrast was almost painful. (One of my colleagues once remarked that I was the only guy he would trust to program his pacemaker. B-) )
And I finally realized what it was:
In Detroit, virtually ANY hunk of software can be life-critical. A bug in the idle speed control might result in a year's production of cars that tend to stall a car's length into the intersection when accellerating from a stop sign. A bug in the factory energy management system might shut off the lights in the plant while the machines are still moving and the workers are within inches of them. A bug in the alarm on the annealing oven's flame curtain could let the plant fill with hot gas loaded with carbon monoxide, then blow the roof into the next county. A bug in the airbag tester program could fire the bag with the worker inside the test cell trying to hook it up. (To name four that I actually worked on.)
In Silicon Valley, on the other hand, there is massive pressure to get the product out marginally ahead of the competitors. And there are business models that turn product bugs into revenue streams via maintenance services and updates. (I finally switched to "the hard side of the force" - chip design - where a million dollars of nonrecurring expenses per bug-fix chip spin and months of lead time promotes the same sort of attention to perfection that I was used to.)
Bruce lives and works out here in the land of fruits, nuts, flakes - and software engineers that treat bugs as features and ship dates as the holy grail. So perhaps most of his experience is with "software engineers" of that sort, leading him to make an overgeneralization.
(Then again, while I apply that sort of thinking to my software and now hardware work, Bruce lives it 24/7. So perhaps he has a point. B-) )
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way