Cenzic 232 Patent
Paid Advertising
web application security lab

Do We Need a Security Industry

I ran across Sylvan’s post today about an article by Bruce Schneier about the state of the security industry. Now let me be clear, I have tremendous respect for both of of them, but I also have a lot of practical real-world experience to draw on, so here are my comments. Bruce and Sylvan both believe that it is better to be more secure first rather than building add-on services. I could not agree with this more. However…

What came first - the chicken or the egg? How can you know something consists of bad security before it gets broken? Clearly, we look at our past and make assumptions about the future state of the security model. We know what can’t work because we know what hasn’t worked. From that we extrapolate concepts and build frameworks that we believe solve the issues. But keep in mind that programmers are still flawed creatures.

Programmers make mistakes - they are lazy, make shortcuts, make concessions for functionality and ultimately make technical errors. It’s a fact. To my knowledge there has never been a secure programming language for web technologies or a 100% secure framework (if someone can point me to anything practical and flexible I’d be interested in it). Ultimately, I am actually somewhat surprised by Bruce’s position. If you look at his first book - Applied Cryptography - he basically stated that all security could be solved by good math. In his second book - Secrets And Lies - he basically said, “Hey, you remember that last book I wrote… wow, I couldn’t have been more wrong - humans are error prone creatures.” He really matured as a security expert between those two books in my mind. He started off as an academic and he ended up being a practical security expert. The math behind what we were all trying to build was fine (well, sometimes anyway), but it was the fact that people write their passwords on sticky notes and pick passwords that are their dog’s name that makes security flawed. But even putting all that aside, there is a lot of legacy code out there to overcome.

Now let’s get to the meat of this. Sylvan was critical of my conversion to not despising the use of WAFs in production environments. When I suggested to my client that I believed a WAF was a good solution (for them, in their particular situation) you have to understand that this was not a situation where they had the ability to pick a secure platform. It was far far too late for that. For them to choose a path other than a reactionary one would have proven to cause tremendous delays in their ability to protect themselves, and they were under grave and persistent threats. So asking them to embrace a secure platform is irrelevant to their current real world security needs. Here is where I think Bruce may be slipping back into academia. I don’t believe these issues can be solved by secure programming/frameworks, etc. This issue is far too complex. Simply put, complexity is the bastion of flaws.

In my experience the real-world issues that companies face is a hybrid of business issues, legacy code, acquisitions, third party complexities, client side security, poorly thought out input/output validation, un-patched systems/code, failure to follow the model of least privilege, and a thousand other smaller issues. To say that you can point to one thing and solve all of them or even most of them is understating the problem we currently face.

Again, I have the utmost respect for Bruce and to his credit he did come around at the end of his article stating that the products were going to be around for the rest of our lifetimes, I just think that these issues are not as trivially solved as this. I do agree with him in that the IT industry is attempting to to turn security into a commodity. However, as technology advances hackers will find their way around whatever tools are put in place. I disagree that security will fall out of the public’s eye - it may wane, but only as long as it takes for the next wave of attacks to surface.

So, sure it would be fantastic to build secure coding practices, and I agree that things like that would help out, but it’s far too late for the companies out there that already have these problems. Yes, companies should adopt this, and yes, they should take proactive measures. In the meantime, bolt-on-solutions are a practical pseudo-solution for the flaws we will continue to face until widespread adoption of better coding practices is commonplace. I’m not holding my breath.

4 Responses to “Do We Need a Security Industry”

  1. Jordan Says:

    Incidentally, I’ve got an article coming out pretty soon that makes a similar point about complexity being the bane of security. I suggest that because all AJAX (and indeed, other RIAs) apps are essentially written in two different languages — one client-side, and one server-side, that automatically makes them less secure because it significantly increases the complexity. Oh, and yeah, they’re being run in a browser (with all the weaknesses that brings with it) with protocols that weren’t really designed to do what we’re using them for, so that’s not helping either!

  2. RSnake Says:

    Thank you, Jordan - I had actually originally meant to make that point. Not only are we facing the webserver issues, but we also have to face completely client side problems, like the UXSS in PDF files for instance - something that had nothing to do with the server at all, but it was terrible for the consumer. It’s just a whole level of added complexity, especially since that wasn’t even the browser, but the browser plugin. I think your article is timely.

  3. Ti Says:

    totally agree - you need to stop the bleeding first (which is what i think you were emphasizing). While the source of most problems trace back to poorly written code, that’s not always the case and more importantly it takes a culture $hift for an organization to continuously produce secure code. Most orgs won’t allow security to severely impact production schedules (unless there’s a vuln firedrill) and would rather pay for protection than manufacture it. If you want an organization to produce secure code you need to train the architects, the spec designers, the developers, the testers, the server admins and the web admins. then you need a plan to update their knowledge (and any new hires), an accountability plan and external validation that it’s all working…rinse and repeat

  4. Ronald van den Heetkamp Says:

    “humans are error prone creatures.”
    Yeah thats what Bruce said, now he is contradicting this by saying:
    “is better to be more secure first rather than building add-on services”

    Well, you can’t. it’s impossible to anticipate on all angles to see every threat while building software. You just can’t do it. You are going to make mistakes no matter how good you are, somewhere you leave holes along your trail while programming.

    So patches are needed when holes are found, and usually they are found by hackers who can think around a system and is creative to try just the thing no one ever thought of, and finds a new hole. To there is a simple conclusion; the best security officers are hackers, always been always will be.

    But the thing is, and this is something that I need to get used to: If you attack someone elses system or piece of software, you’ll find holes, while you never try to attack your own piece of software. Strange huh? really weird. I think it has to do with the fact that one is so conditioned in thinking he writes secure code that this person isn’t even trying to attack it.

    Interesting stuff anyway.