1. 14
  1.  

  2. 8

    I read this yesterday, and I’ve been thinking a lot about number three “Penetrate and Patch”:

    In other words, you attack your firewall/software/website/whatever from the outside, identify a flaw in it, fix the flaw, and then go back to looking. […] In other words, the problem with “Penetrate and Patch” is not that it makes your code/implementation/system better by design, rather it merely makes it toughened by trial and error.

    It made me compare and contrast well designed systems which go years without security issues with things like Wordpress which seem to have issues quarterly (monthly?).

    On four “Hacking is Cool”

    My prediction is that the “Hacking is Cool” dumb idea will be a dead idea in the next 10 years. I’d like to fantasize that it will be replaced with its opposite idea, “Good Engineering is Cool” but so far there is no sign that’s likely to happen.

    The opposite is true (this was written in 2005), and with the rise in bug bounty programs, hacking is cooler than ever. Note, I’m not saying that bug bounties are bad, or that we shouldn’t have them, but it does make me think more about the mindset behind them, and what kinds of behaviour this encourages in developers of systems.

    1. 4

      If you’re a security practitioner, teaching yourself how to hack is also part of the “Hacking is Cool” dumb idea. Think about it for a couple of minutes: teaching yourself a bunch of exploits and how to use them means you’re investing your time in learning a bunch of tools and techniques that are going to go stale as soon as everyone has patched that particular hole. It means you’ve made part of your professional skill-set dependent on “Penetrate and Patch” and you’re going to have to be part of the arms-race if you want that skill-set to remain relevant and up-to-date. Wouldn’t it be more sensible to learn how to design security systems that are hack-proof than to learn how to identify security systems that are dumb?

      I read this as “Just do it right, don’t waste time learning how it goes wrong.”

      1. 3

        Yeah I wouldn’t go all the way to the point of “Just don’t make mistakes”, but I do think there is something to be said for taking things slower and spending more time designing carefully up-front, rather than falling into the Penetrate and Patch cycle. However I’d also want to use all of the tools available at my disposal to verify the design, but they can’t replace having a secure design, nor can they (fully) make an insecure design secure.