I don't agree with much in this article. My thoughts on Marcus' list of "dumb ideas":
1. Default Permit - this one makes sense, getting "fail open" vs "fail closed" right is important in lots of places in engineering.
2. Enumerating Badness - isn't this is just the typical method for implementing default permit?
3. Penetrate and Patch - yes, it's always better to design a system to be secure and to code it with good security practices in mind, but any system with more than a handful of lines of code will be too complicated to guarantee correctness. "Penetrate and patch" can still find errors in well built systems. I do think that different ways of doing the "penetrate" part have different value. For example, I much prefer "white box testing" (ie testing with access to source code) to "black box testing". Extending this concept, when writing code with security in mind it can be helpful to consider common approaches an attacker might take (ie simulate the "penetrate" part of the process mentally), and use that insight to write better code (ie "patch" the code as it's being written).
4. Hacking is cool - well, the truth is, finding flaws can be intellectually gratifying. Sure, maybe the "coolness" factor has an impact on how many script kiddies exist, but there will always be people who like to "hack" stuff. Some portion of those people will stray into gray and black areas.
5. Educating Users - sure it's hopeless, and designing systems and processes to minimize people's impact is a win, but the prediction that users who need education will not be in the high tech workforce in ten years... not gonna happen.
6. Action is Better Than Inaction - From the article: I know one senior IT executive - one of the "pause and thinkers" whose plan for doing a wireless roll-out for their corporate network was "wait 2 years and hire a guy who did a successful wireless deployment for a company larger than us." Not only will the technology be more sorted-out by then, it'll be much, much cheaper. What an utterly brilliant strategy! Ugh! How about looking at risk vs reward. How much did that conservative "pause and thinker" put his company behind by waiting two years to adopt some new technology? Yes, sometimes that's the right choice, but sometimes high rewards merit taking big risks! This is as true when thinking about security as it is in any other business decision. A blanket recommendation to avoid risk does not cover all situations.
Ok, so you agree with 1 and 2, and as for 3, where users feel free to break things 4 teh lulz (cf HN exploit), there's a non-zero chance than a normal user will become an attacker.
4. Dissecting a slug, making slides, and examining them under a microscope is cool. Sprinkling a family of slugs with salt and watching them die is not cool. The end result is the same, that the slugs die, but it's fundamentally a social problem, when people feel empowered to break breakable things.
5. In growing up, why did you not talk to strangers as a kid? Why did you look both ways before crossing the street? Our parents and friends teach us convenient behaviors so that we don't have to make the same mistakes. If all of your data is now going to live in the cloud, you'll learn pretty fast, and educate your kids/kid siblings about what not to do on the internet. No one who's ever been phished is going to make that mistake again (my friend in undergrad did), no one who's ever downloaded random video codecs from Eastern European nations is going to make that mistake again (my bf did); we'll learn what not to do so that messing up really merits a techno-darwin award.
6. Yes, the "senior IT executive" calculated the risks and rewards, and for an enormous corporate network with large institutional inertia, it was cheaper to hire a guy who learned on someone else's dime. It's like "cutting-edge accounting", or changing your house's plumbing. If your business isn't accounting, just follow industry best practices.
Yeah, he seems to think that everyone who is a pen tester or a security researcher also writes malicious viruses on the side. Here's a clue: botnet writers are not also working for the security industry, because they don't have to. They're making enough money to just sit and improve their botnets.
1. Default Permit - this one makes sense, getting "fail open" vs "fail closed" right is important in lots of places in engineering.
2. Enumerating Badness - isn't this is just the typical method for implementing default permit?
3. Penetrate and Patch - yes, it's always better to design a system to be secure and to code it with good security practices in mind, but any system with more than a handful of lines of code will be too complicated to guarantee correctness. "Penetrate and patch" can still find errors in well built systems. I do think that different ways of doing the "penetrate" part have different value. For example, I much prefer "white box testing" (ie testing with access to source code) to "black box testing". Extending this concept, when writing code with security in mind it can be helpful to consider common approaches an attacker might take (ie simulate the "penetrate" part of the process mentally), and use that insight to write better code (ie "patch" the code as it's being written).
4. Hacking is cool - well, the truth is, finding flaws can be intellectually gratifying. Sure, maybe the "coolness" factor has an impact on how many script kiddies exist, but there will always be people who like to "hack" stuff. Some portion of those people will stray into gray and black areas.
5. Educating Users - sure it's hopeless, and designing systems and processes to minimize people's impact is a win, but the prediction that users who need education will not be in the high tech workforce in ten years... not gonna happen.
6. Action is Better Than Inaction - From the article: I know one senior IT executive - one of the "pause and thinkers" whose plan for doing a wireless roll-out for their corporate network was "wait 2 years and hire a guy who did a successful wireless deployment for a company larger than us." Not only will the technology be more sorted-out by then, it'll be much, much cheaper. What an utterly brilliant strategy! Ugh! How about looking at risk vs reward. How much did that conservative "pause and thinker" put his company behind by waiting two years to adopt some new technology? Yes, sometimes that's the right choice, but sometimes high rewards merit taking big risks! This is as true when thinking about security as it is in any other business decision. A blanket recommendation to avoid risk does not cover all situations.