So I'm waiting for the iPhone to "activate", by which I mean get a signal from at&t that will tell the phone to start its web-browser and wifi interfaces. That doesn't appear to be happening any time soon, but I feel I have to blog something related to the iPhone.
This article from Slate.com has an interesting comment about the social norms of waiting in line. The article points out that while it's rude to jump ahead of people to buy the first iPhone, it's not illegal.
This is a good starting point to ask what sorts of social norms should be regulated by the government. Stephen Landsburg points out that our social norm may be the best way, and using economic theory, it might be better to always put the latest arrivals at the head of the line. Computer scientists who study queuing theory have their own ideas of a "fair" way to stand in line. Other cultures have different social norms. For example, the Chinese government is now worried that Western norms will clash with Chinese norms (they take cuts) during the Olympic games in a couple years. Governments attempting to regulate social norms are in danger of forcing us to follow what may turn out to be bad norms.
Despite this, a lot of people want social norms regulated. The British government is heading that direction. Lawrence Lessig, board member of the EFF, argues that the government should regulate social norms on the Internet.
In many ways, the government is already regulating the social norms of the Internet without people quite realizing it. Electronics Arts (EA) have published their Terms of Service that you must agree to in order to play their games. Among those terms are: You will not exploit any bug in the Service or in any EA product to gain unfair advantage in the game and you will not communicate the existence of any such bug (either directly or through the public posting) to any other user of the Service. This a good social norm on one hand (we don't like cheaters) and a bad one on the other (we don't like restriction in our freedom to speak). Unfortunately, the courts have ruled in the Bnetd case that such restrictions might be enforceable. Before you argue that the government should regulate social norms, you might ask yourself if you are willing to have the government side with the wrong norm (pro-speech or anti-cheating).
As we ask the government more and more to regulate and police the Internet, how much longer are we going to get away with not paying for those services? What I mean here is that the more the government gets involved in governing the Internet, the more they are going to want to tax it. If companies like EA want the government to regulate virtual money in their games, the government is going to want to tax that virtual money.
What we have here is both the right (businesses like EA) and the left (groups like the EFF) campaigning for the government to regulate and police social norms on the Internet. I predict the situation will get worse. I'm suggesting that we should resist all such attempts by the government, even if we agree with the norm they want to regulate (such talk won't make you NetNeutrality guys happy).
Grr. I've written this long diatribe and my iPhone STILL hasn't activated. Maybe I should fuzz something else this weekend. I wonder if anybody has tested Opera recnetly...
Saturday, June 30, 2007
Thursday, June 28, 2007
And now...something light...
http://legal.ea.com/legal/legal.jsp?language=en
"You will not exploit any bug in the Service or in any EA product to gain unfair advantage in the game and you will not communicate the existence of any such bug (either directly or through the public posting) to any other user of the Service."
Gee, I was just about to tell my online gaming clan, SecuritySucks, how to totally own in the Sims online, but after reading this I will not give anybody any exploits. I am just relieved I saw this before I started handing out code...
A nod to Mr. Stepto, for this heads up!
"You will not exploit any bug in the Service or in any EA product to gain unfair advantage in the game and you will not communicate the existence of any such bug (either directly or through the public posting) to any other user of the Service."
Gee, I was just about to tell my online gaming clan, SecuritySucks, how to totally own in the Sims online, but after reading this I will not give anybody any exploits. I am just relieved I saw this before I started handing out code...
A nod to Mr. Stepto, for this heads up!
The Purple Pill?
This story highlights one of the problems in Internet security.
Joanna Rutkowska has been talking about "hypervisor rootkits", a way of creating undetectable malware on a machine. It's pretty cool stuff, regardless how you look at it. However, she describes it as being "100% undetectable", which of course, challenges other researchers to prove that it is indeed detectable. They have challenged her to infect one of their systems at random, and that they can detect it.
However, Joanna has already admitted that her Blue Pill can be detected in a laboratory setting. What she is claiming is that vendors won't be able to ship a product that will detect it in practice.
What this is highlighting is how much that happens in our industry is done in "bad faith". One of those challenging Joanna is Nate Lawson. If you'll remember earlier this year, Lawson attacked Barnaby Jack claiming that he unjustly hyped a presentation for CanSecWest. As it turns out, Barnaby's presentation was about something new and interesting, and the press article talking about it was 100% non-hype. Banarby delivered, as promised, a "new class of attacks target[ing] embedded devices". Lawson was wrong.
In much the same fashion, Lawson is ignoring Joanna's comments that her stuff can be detected in a laboratory, and challenged her with a laboratory setting. They created rules that do not address what Joanna has already claimed. They bet her that if she installs a hypervisor rootkit on one of their machines that they can detect it in the laboratory.
What would a good-faith bet be? They should publish a hypervisor detection tool on their website, then challenge Joanna to create a hypervisor that evades it. They should challenge the rest of us to install it on our machines to prove that it is robust and doesn't cause problems (like slowing our machines down). Better yet, they should provide source for their tool with BSD licensing so that anti-virus vendors can include it with their offerings.
All of this is largely theoretical. I don't see botnets using Blue Pill technology yet (although that's because it's so easy to evade detection they don't need more advanced techniques). I likewise don't see vendors providing defense for this. The entire debate is like betting whether Batman could beat Spiderman in a fight. The only relevancy that this debate has is to the spooks at the NSA worried about Chinese hackers installing rootkits in the DoD. And for the NSA, Joanna has an easy answer: don't worry about detection, just worry about defense and install a hypervisor on all your machines that prevents another hypervisor from being loaded.
Joanna Rutkowska has been talking about "hypervisor rootkits", a way of creating undetectable malware on a machine. It's pretty cool stuff, regardless how you look at it. However, she describes it as being "100% undetectable", which of course, challenges other researchers to prove that it is indeed detectable. They have challenged her to infect one of their systems at random, and that they can detect it.
However, Joanna has already admitted that her Blue Pill can be detected in a laboratory setting. What she is claiming is that vendors won't be able to ship a product that will detect it in practice.
What this is highlighting is how much that happens in our industry is done in "bad faith". One of those challenging Joanna is Nate Lawson. If you'll remember earlier this year, Lawson attacked Barnaby Jack claiming that he unjustly hyped a presentation for CanSecWest. As it turns out, Barnaby's presentation was about something new and interesting, and the press article talking about it was 100% non-hype. Banarby delivered, as promised, a "new class of attacks target[ing] embedded devices". Lawson was wrong.
In much the same fashion, Lawson is ignoring Joanna's comments that her stuff can be detected in a laboratory, and challenged her with a laboratory setting. They created rules that do not address what Joanna has already claimed. They bet her that if she installs a hypervisor rootkit on one of their machines that they can detect it in the laboratory.
What would a good-faith bet be? They should publish a hypervisor detection tool on their website, then challenge Joanna to create a hypervisor that evades it. They should challenge the rest of us to install it on our machines to prove that it is robust and doesn't cause problems (like slowing our machines down). Better yet, they should provide source for their tool with BSD licensing so that anti-virus vendors can include it with their offerings.
All of this is largely theoretical. I don't see botnets using Blue Pill technology yet (although that's because it's so easy to evade detection they don't need more advanced techniques). I likewise don't see vendors providing defense for this. The entire debate is like betting whether Batman could beat Spiderman in a fight. The only relevancy that this debate has is to the spooks at the NSA worried about Chinese hackers installing rootkits in the DoD. And for the NSA, Joanna has an easy answer: don't worry about detection, just worry about defense and install a hypervisor on all your machines that prevents another hypervisor from being loaded.
Thursday, June 14, 2007
A really good question deserves an answer…
As a comment to our previous Safari post I got a really good question from Jeffrey Hawkins and exploit terminology. His question reads:
Weaponized basically means you have found a remote execution bug that you can successful and reliable get code execution (not just theoretical or in a lab environment) that requires little or no effort on the part of the attacker to successfully exploit. The exploit will also take application or operating system versions into account and can work on a variety. The Metasploit project is an example of high quality weaponized exploits.
“I notice you found 2 remote execution bugs, but said one of them wasFirst of all not all software bugs all vulnerabilities, sometimes a bug is just a bug and nothing useful can be done with them. One step up from useless bugs are Denial-of-Service (DoS) bugs that while MAY have some security impact in reality are mostly annoying and are often caused by things like NULL pointer dereferences. Most researchers think a DoS is lame. Then we have code execution vulnerabilities. These are software flaws that allow the flow of execution of a program to be redirected to whatever arbitrary code an attacker chooses. These are what most people search for however just because you find a bug like this doesn’t mean it’s exploitable or reliable. There are several factors that can cause a code execution bug not to be exploitable such as the process dying before execution has been achieved (remember to get execution often times you are overwriting parts of the process memory that may be relied upon later), nothing useful to overwrite, thread problems, and hardware or software based anti-exploitation technology like NX or DEP.
"weaponizable". What does that mean?Specifically, how can one remote execution
bug be weaponizable, while the other is not?”
Weaponized basically means you have found a remote execution bug that you can successful and reliable get code execution (not just theoretical or in a lab environment) that requires little or no effort on the part of the attacker to successfully exploit. The exploit will also take application or operating system versions into account and can work on a variety. The Metasploit project is an example of high quality weaponized exploits.
HD's new groove...
https://strikecenter.bpointsys.com/
Check this site in the future for fun stuff from the Breakpoint Systems research team headed up by none other that everyone’s favorite prom date, HD Moore. Expect a lot of cool stuff as some of the fun things they are working on become public.
Check this site in the future for fun stuff from the Breakpoint Systems research team headed up by none other that everyone’s favorite prom date, HD Moore. Expect a lot of cool stuff as some of the fun things they are working on become public.
Monday, June 11, 2007
Niiiice...
**PLEASE DO NOT POST A COMMENT IF ITS ABOUT SAFARI IN BETA**
These bugs have been verified in the current PRODUCTION copy on OSX (Safari 2.0.4).
Apple just released a Safari for Windows beta at http://www.apple.com/safari. Using publicly available tools we had a DoS in no time. Keeping with our disclosure policy, we do not report bugs to Apple.
UPDATE: Whoops, sorry, thats not a DoS, its memory corruption.
UPDATE 2: Per Request....WinDBG output of a new bug. These are popping out like hotcakes.
UPDATE 3:
It appears I am not the only person who had this idea today?
http://aviv.raffon.net/CommentView,guid,54A1DB79-0ECB-4F13-99AE-45BAB70C4256.aspx#a0ac5417-013d-43ae-9abc-7d265113892c
UPDATE 4: Thor Larholm has also found a bug.
http://larholm.com/2007/06/12/safari-for-windows-0day-exploit-in-2-hours/
I'd like to note that we found a total of 6 bugs in an afternoon, 4 DoS and 2 remote code execution bugs. We have weaponized one of those to be reliable and its diffrent that what Thor has found. I can't speak for anybody else but the bugs found in the beta copy of Safari on Windows work on the production copy on OSX as well (same code base for alot of stuff). The exploit is robust mostly thanks to the lack of any kind of adanced security features in OSX, I write about it here.
UPDATE 5: I've been asked what our disclosure policy is. Its pretty simple, in most cases we will give vendors as long as they need to fix problems. If the vendor is unresponsive or make threats, we will give them 30 days then release details. If a vendor answers a vulnerability disclosure with marketing and spin attempts, we no longer report vulnerabilities to that vendor but the information goes into our Hacker Eye View program for customers and will be used in pentesting. We do not sell the vulnerabilities to any 3rd party.
These bugs have been verified in the current PRODUCTION copy on OSX (Safari 2.0.4).
Apple just released a Safari for Windows beta at http://www.apple.com/safari. Using publicly available tools we had a DoS in no time. Keeping with our disclosure policy, we do not report bugs to Apple.
UPDATE: Whoops, sorry, thats not a DoS, its memory corruption.
UPDATE 2: Per Request....WinDBG output of a new bug. These are popping out like hotcakes.
UPDATE 3:
It appears I am not the only person who had this idea today?
http://aviv.raffon.net/CommentView,guid,54A1DB79-0ECB-4F13-99AE-45BAB70C4256.aspx#a0ac5417-013d-43ae-9abc-7d265113892c
UPDATE 4: Thor Larholm has also found a bug.
http://larholm.com/2007/06/12/safari-for-windows-0day-exploit-in-2-hours/
I'd like to note that we found a total of 6 bugs in an afternoon, 4 DoS and 2 remote code execution bugs. We have weaponized one of those to be reliable and its diffrent that what Thor has found. I can't speak for anybody else but the bugs found in the beta copy of Safari on Windows work on the production copy on OSX as well (same code base for alot of stuff). The exploit is robust mostly thanks to the lack of any kind of adanced security features in OSX, I write about it here.
UPDATE 5: I've been asked what our disclosure policy is. Its pretty simple, in most cases we will give vendors as long as they need to fix problems. If the vendor is unresponsive or make threats, we will give them 30 days then release details. If a vendor answers a vulnerability disclosure with marketing and spin attempts, we no longer report vulnerabilities to that vendor but the information goes into our Hacker Eye View program for customers and will be used in pentesting. We do not sell the vulnerabilities to any 3rd party.
Friday, June 08, 2007
Amero, part 2
Brian Krebs has posted an update to the Julie Amero case (the teacher convicted of harming students by letting them see porn). Krebs also links to an e-mail exchange between Nancy Willard and the prosecution's expert witness Mark Lounsbury (the guy who made the technical error).
The fun little bit is that Nancy Willard has a website and books that deal with the issue of "cyberbullying", which she defines as:
This case is a good example of why company management does not listen to technical experts. Technical experts are angry because they understand how spyware and popups can lead to porn arriving on people's machines. They believe that Mark Lounsbury was wrong about this fact.
However, the case didn't hinge on that point. What was far more important was the testimony from children saying they watched the teacher click on porn. While the corrected technical analysis shows that the porn almost certainly started with the spyware/popups in the morning, it does not disprove the children's testimony that Amero was intentionally surfing porn later in the day.
Even that isn't the most important issue in the case. The biggest issue is that Amero did not prevent children from seeing the porn throughout the day. She didn't turn the computer off, she didn't even put a piece of paper in front of the monitor, stack books in front of it, put her purse in front, or do much of anything. Children viewed porn, she could have prevented it, but she didn't. (And that was against the law).
Corporate management doesn't listen to the technical staff for precisely this reason. The technical staff believes that everything hinges on the small technical details they are experts in. They refuse to confine their advice to the areas where they are competent ("porn first arrived due to standard spyware/popups"), but instead insist on advising in areas where they are not competent ("Julie Amero is innocent").
Its good that's she's getting a second trial where the correct information about spyware/popups is presented, but chances are good that she will still be found guilty. The students testified that Amero was more interested in watching the popups than noticing that the children were also seeing the same popups. Nothing on the disk drive would ever disprove the children's assertion that she was scrolling through porn-filled webpages (and letting the children watch her do it).
The fun little bit is that Nancy Willard has a website and books that deal with the issue of "cyberbullying", which she defines as:
Cyberbullying is being cruel to others by sending orCompare that definition to the e-mail she sent to Mark Lounsbury:
posting harmful material or engaging in other forms
of social aggression using the Internet or other digital
technologies.
Mark,The thing about bullies is that they don't know that they are bullies. Nancy Willard certainly doesn't believe she is a cyberbully.
You did not present FACTS at trial. You are either totally stupid and naïve cop who should have never been given the keys to a $300,000 Internet safety van or you committed perjury.
I hope you find the strength to face the facts and to take responsibility for your words and actions, someday. I do believe that in the end you will be held accountable.
Nancy
This case is a good example of why company management does not listen to technical experts. Technical experts are angry because they understand how spyware and popups can lead to porn arriving on people's machines. They believe that Mark Lounsbury was wrong about this fact.
However, the case didn't hinge on that point. What was far more important was the testimony from children saying they watched the teacher click on porn. While the corrected technical analysis shows that the porn almost certainly started with the spyware/popups in the morning, it does not disprove the children's testimony that Amero was intentionally surfing porn later in the day.
Even that isn't the most important issue in the case. The biggest issue is that Amero did not prevent children from seeing the porn throughout the day. She didn't turn the computer off, she didn't even put a piece of paper in front of the monitor, stack books in front of it, put her purse in front, or do much of anything. Children viewed porn, she could have prevented it, but she didn't. (And that was against the law).
Corporate management doesn't listen to the technical staff for precisely this reason. The technical staff believes that everything hinges on the small technical details they are experts in. They refuse to confine their advice to the areas where they are competent ("porn first arrived due to standard spyware/popups"), but instead insist on advising in areas where they are not competent ("Julie Amero is innocent").
Its good that's she's getting a second trial where the correct information about spyware/popups is presented, but chances are good that she will still be found guilty. The students testified that Amero was more interested in watching the popups than noticing that the children were also seeing the same popups. Nothing on the disk drive would ever disprove the children's assertion that she was scrolling through porn-filled webpages (and letting the children watch her do it).
Wednesday, June 06, 2007
How to become a "security guru"
A comment on my last post claimed that every company needs a "security guru". This is a good idea, but the problem is that technical experts rarely have the "people skills" to be effective gurus.
The most important issue facing you experts is that people aren't going to listen to you most of the time. It doesn't matter if you are the summer intern or the CEO: getting people to listen is hard. It's not your job to "tell" people what the right answer is, but to "sell" your idea. If you get angry and poison your working relationships, you are not going to be an effective salesman. The reason experts get angry or frustrated is because they blame others for not listening to the "truth", rather than blaming themselves for their inability to sell their ideas.
The second most important issue is that there is no such thing as a "right" answer. Technical people fail because they always strive for the optimal solution to a problem, but as Voltaire says "perfect is the enemy of good enough". Your job as the guru isn't to steer to the organization toward the best solutions, but to steer them away from those that aren't good enough. Frankly this is because while you are often correct about what is "good enough", you are probably wrong about what is "best".
The geek's approach to selling ideas is to construct a logical proof of their idea such that nobody can disagree. This never works. Selling your ideas means you have to social engineer your co-workers. People make decisions for emotional reasons more than logical ones.
The most important social engineering technique is to shut up. The human emotion that drives most arguments is that we just want the other person to listen to us. The reason that somebody opposed your expert advice isn't so much that they don't like it, but that they wanted you to listen to their point of view. Often all it takes is win acceptance of your idea is to listen to your opponents. When you talk, you should ask pertinent questions or paraphrase what they've said in your own words. It doesn't matter whether you care about what they are saying or agree with it, what matters is that you prove them that you are listening. Objecting or arguing with them, no matter how wrong they are, puts you into the "not listening" mode, and should be avoided.
Your success often depends upon how well you deal with objections by others. Your instinct is to respond like you've been attacked, to go on the defensive, and respond with an argument. Resist that urge.
Try to figure out the reason for the objection. For example, the person may actually support your idea, but be looking for any problems before publicly endorsing you. Angrily counterattacking will, of course, be precisely the wrong thing to do in that situation. Some objections come from people who just like to hear themselves talk. When you argue with an idiot like this, most observers will assume you both are idiots. A big reason is for objections is that the person has some other agenda: your goal is to deal with that agenda, not with the individual objections that the person brings up.
Following the "shut up" principle above, the best way to deal with objections is not to argue. Your first instinct should be instead to ask questions. Good questions to ask are "Can you be more specific?", "Can you give an example?", "Is that your only objection?", "How would you fix it?", "I have no solution to that objection, does this mean that my idea has no merit?". The last one is one of the best: it social engineers the objector into feeling uncomfortable, and encourages them to overcome their own objection so that you don't have to. Remember: when you are listening to them talk, you are winning, when you are arguing, you are losing.
Don't go all emo. People pick up on your emotional state. You want to project a "calm-assertive" attitude. I get that term from "The Dog Whisperer" TV show, where the dog trainer tells owners to be calm-assertive with their pets, but the same applies to dealing with computer geeks. Showing emotion occasionally is okay, but only if you are in control of the emotion you are displaying, rather than letting the emotion control you. Remember that people pick up on subtle emotions well. You may be sitting quietly in the room, but be loudly projecting your sullen anger or agitation. When you can project an attitude that you don't seem upset by the fact that many (or all) disagree with you, then you've won half the battle. When you project the attitude that you are in control, then others will believe you.
I describe this as "social engineering", but you've probably guessed is that it really more than that. My previous company, Network ICE, had three founders. The reason we got along so well was because of instead of angry arguments, we aggressively attempted to social engineer each other. A typical "argument" would go like: "(Alice) What is your idea? (Bob) No, you tell me what your idea first! (Alice) No, I don't think you'll like my idea, so I think we should start with yours first.". Arguments where two people are trying to out-listen each other always end better than those where they talk to out-talk each other.
I could write a whole book on the topic, but these are the essentials:
- sell your idea, don't tell
- accept that there is no "best" solution
- listen, listen, listen
- don't get drawn into futile arguments
- stay calm and assertive
The most important issue facing you experts is that people aren't going to listen to you most of the time. It doesn't matter if you are the summer intern or the CEO: getting people to listen is hard. It's not your job to "tell" people what the right answer is, but to "sell" your idea. If you get angry and poison your working relationships, you are not going to be an effective salesman. The reason experts get angry or frustrated is because they blame others for not listening to the "truth", rather than blaming themselves for their inability to sell their ideas.
The second most important issue is that there is no such thing as a "right" answer. Technical people fail because they always strive for the optimal solution to a problem, but as Voltaire says "perfect is the enemy of good enough". Your job as the guru isn't to steer to the organization toward the best solutions, but to steer them away from those that aren't good enough. Frankly this is because while you are often correct about what is "good enough", you are probably wrong about what is "best".
The geek's approach to selling ideas is to construct a logical proof of their idea such that nobody can disagree. This never works. Selling your ideas means you have to social engineer your co-workers. People make decisions for emotional reasons more than logical ones.
The most important social engineering technique is to shut up. The human emotion that drives most arguments is that we just want the other person to listen to us. The reason that somebody opposed your expert advice isn't so much that they don't like it, but that they wanted you to listen to their point of view. Often all it takes is win acceptance of your idea is to listen to your opponents. When you talk, you should ask pertinent questions or paraphrase what they've said in your own words. It doesn't matter whether you care about what they are saying or agree with it, what matters is that you prove them that you are listening. Objecting or arguing with them, no matter how wrong they are, puts you into the "not listening" mode, and should be avoided.
Your success often depends upon how well you deal with objections by others. Your instinct is to respond like you've been attacked, to go on the defensive, and respond with an argument. Resist that urge.
Try to figure out the reason for the objection. For example, the person may actually support your idea, but be looking for any problems before publicly endorsing you. Angrily counterattacking will, of course, be precisely the wrong thing to do in that situation. Some objections come from people who just like to hear themselves talk. When you argue with an idiot like this, most observers will assume you both are idiots. A big reason is for objections is that the person has some other agenda: your goal is to deal with that agenda, not with the individual objections that the person brings up.
Following the "shut up" principle above, the best way to deal with objections is not to argue. Your first instinct should be instead to ask questions. Good questions to ask are "Can you be more specific?", "Can you give an example?", "Is that your only objection?", "How would you fix it?", "I have no solution to that objection, does this mean that my idea has no merit?". The last one is one of the best: it social engineers the objector into feeling uncomfortable, and encourages them to overcome their own objection so that you don't have to. Remember: when you are listening to them talk, you are winning, when you are arguing, you are losing.
Don't go all emo. People pick up on your emotional state. You want to project a "calm-assertive" attitude. I get that term from "The Dog Whisperer" TV show, where the dog trainer tells owners to be calm-assertive with their pets, but the same applies to dealing with computer geeks. Showing emotion occasionally is okay, but only if you are in control of the emotion you are displaying, rather than letting the emotion control you. Remember that people pick up on subtle emotions well. You may be sitting quietly in the room, but be loudly projecting your sullen anger or agitation. When you can project an attitude that you don't seem upset by the fact that many (or all) disagree with you, then you've won half the battle. When you project the attitude that you are in control, then others will believe you.
I describe this as "social engineering", but you've probably guessed is that it really more than that. My previous company, Network ICE, had three founders. The reason we got along so well was because of instead of angry arguments, we aggressively attempted to social engineer each other. A typical "argument" would go like: "(Alice) What is your idea? (Bob) No, you tell me what your idea first! (Alice) No, I don't think you'll like my idea, so I think we should start with yours first.". Arguments where two people are trying to out-listen each other always end better than those where they talk to out-talk each other.
I could write a whole book on the topic, but these are the essentials:
- sell your idea, don't tell
- accept that there is no "best" solution
- listen, listen, listen
- don't get drawn into futile arguments
- stay calm and assertive
Tuesday, June 05, 2007
Details matter
Bruce Schneier describes his African safari. He tells how the staff explained to him that when threatened by different animals, people needed to respond differently. You stare down some animals, you avert your gaze from others. You run from some, stand your ground with others. You can climb trees to avoid some animals, but other animals are better climbers than you are. Following the wrong strategy for an animal can get you killed, such as staring down an animal that provokes it to attack.
Schneier doesn't make what I think would be the obvious corollary with cybersecurity, namely that the details of each threat matters. In order to defend yourself, you need to pay attention to the details.
The Slammer worm resulted in a lot of sales of anti-virus product. However, anti-virus products do not protect against in-memory worms like Slammer. Anti-virus is not the correct defense against Slammer. The correct defense would include intrusion-prevention systems (IPS), better firewall rules, better patching, and better vulnerability scanning. In other words, unless you pay attention to the details of Slammer, you are unlikely to defend yourself well against it.
Corporations have a culture of ignoring the details of cyber-threats. They build their security policies at a high-level, from the top down. Of course these policies state that the details must be taken care of eventually, but much of the time, their processes never advance that far. When confronted with a cybersecurity failure due to lack of attention to the details, they will often go back and redesign their policies from scratch, again at a high-level, and again ignoring the low level details.
A good example of this is the recent fad of "secure development lifecycles", where corporations now pay attention to securing their internal software projects. The low-level details they need to solve are things like "SQL injection" and "cross-site scripting". However, when companies approach the problem from a high-level, they often never get as far as these details. Thus, the uptake in "secure development" has not resulted in solving the widespread problem of "SQL injection".
Its interesting reading documents on the Internet about the security lifecycle, such as this one. It's full of high-level platititudes but empty of any low-level details. For example, it stresses the importance of teaching software security in universities, but it's approach is largely meaningless. A better approach to the problem, one that is focused on the details, is to tell universities to stop teaching students to use "strcpy()" and to start teaching them how hackers "smash the stack".
The successful security lifecycle projects I've seen are those that start first with the details, then build upwards from there. In other words, processes that focus first on a detail like "SQL injection" is likely to both solve that problem as well as be extensible to other problems. An example of this is Microsoft: while they do describe the security lifecycle from the high-level, their processes were created from low-level details. The documents they produce show that they pay attention to low-level details.
You would think that the technical staff would be the leaders in getting their employers to focus on security details, but you'd be wrong. Technical people ignore the details of business to the same degree that business people ignore the technical details. It's a rare company that has a leader who both understands the business as well as the security details. In addition, the technical staff likes to focus on exciting problems like stopping 0day worms, but the biggest problems are the boring ones (like guessable passwords), and companies are more likely to be hacked by the boring problems than the exciting ones.
So what is the solution? My recommendation is to change the culture so that technical details matter. Any high-level document used in the process should include "use-cases" or something that points to a low-level detail. This will keep the project anchored in reality, and discourage it from drifting off course.
Schneier doesn't make what I think would be the obvious corollary with cybersecurity, namely that the details of each threat matters. In order to defend yourself, you need to pay attention to the details.
The Slammer worm resulted in a lot of sales of anti-virus product. However, anti-virus products do not protect against in-memory worms like Slammer. Anti-virus is not the correct defense against Slammer. The correct defense would include intrusion-prevention systems (IPS), better firewall rules, better patching, and better vulnerability scanning. In other words, unless you pay attention to the details of Slammer, you are unlikely to defend yourself well against it.
Corporations have a culture of ignoring the details of cyber-threats. They build their security policies at a high-level, from the top down. Of course these policies state that the details must be taken care of eventually, but much of the time, their processes never advance that far. When confronted with a cybersecurity failure due to lack of attention to the details, they will often go back and redesign their policies from scratch, again at a high-level, and again ignoring the low level details.
A good example of this is the recent fad of "secure development lifecycles", where corporations now pay attention to securing their internal software projects. The low-level details they need to solve are things like "SQL injection" and "cross-site scripting". However, when companies approach the problem from a high-level, they often never get as far as these details. Thus, the uptake in "secure development" has not resulted in solving the widespread problem of "SQL injection".
Its interesting reading documents on the Internet about the security lifecycle, such as this one. It's full of high-level platititudes but empty of any low-level details. For example, it stresses the importance of teaching software security in universities, but it's approach is largely meaningless. A better approach to the problem, one that is focused on the details, is to tell universities to stop teaching students to use "strcpy()" and to start teaching them how hackers "smash the stack".
The successful security lifecycle projects I've seen are those that start first with the details, then build upwards from there. In other words, processes that focus first on a detail like "SQL injection" is likely to both solve that problem as well as be extensible to other problems. An example of this is Microsoft: while they do describe the security lifecycle from the high-level, their processes were created from low-level details. The documents they produce show that they pay attention to low-level details.
You would think that the technical staff would be the leaders in getting their employers to focus on security details, but you'd be wrong. Technical people ignore the details of business to the same degree that business people ignore the technical details. It's a rare company that has a leader who both understands the business as well as the security details. In addition, the technical staff likes to focus on exciting problems like stopping 0day worms, but the biggest problems are the boring ones (like guessable passwords), and companies are more likely to be hacked by the boring problems than the exciting ones.
So what is the solution? My recommendation is to change the culture so that technical details matter. Any high-level document used in the process should include "use-cases" or something that points to a low-level detail. This will keep the project anchored in reality, and discourage it from drifting off course.
Subscribe to:
Posts (Atom)
