Call me a cynic, a "doom and gloom" believer, a nay-sayer or what ever else you want - but understand that fundamentally I'm just a realist with a lot of experience in failure.
Hopefully you've had a chance to listen to the OWASP Podcast #27 featuring yours truly and heard my take on App Sec... If you haven't heard the OWASP Podcast yet, Jim Manico does an awesome job identifying, tracking down and interviewing people who have an influential role in web application security - and I for one feel honored that I was picked to be a part of that group. After listening to myself on the podcast I started to see what some of you guys had been telling me about myself - I make one hell of a cynic, don't I?
I sat and thought about it some, as the rains poured down over Progressive Field in Cleveland, OH (and the White Sox pounded the Tribe). Am I really a cynic or do I just know better than to expect something that will likely never come? I think the reality here is that I've worked in companies large and small, with funding and with a shoestring budget, well staffed and with a skeleton crew - and the result has been consistent failure.
Are we just physically incapable of writing good, secure web application code? Yes.
Well, no, take that back. In an imaginary world where we have unlimited time, unlimited tools at our disposal, everyone is well-educated (in security) and has an incomprehensible amount of intelligence for development... yea we'd still fail. You see good security is (like the devil) in the details. Put down the sharp implement and let me explain.
Even in a perfect world there are still things that the individual developer cannot control. In modern applications development it is almost non-existant that a single person writes an entire application without the use of either some code-generating tools, 3rd party objects/modules/includes, or additional support such as a horde of developers. This creates a condition known as "I-have-no-idea-what-they-did-but-it's-not-my-problem-itis" for which there is no known cure. Say, in this perfect land you have a group of developers that understands their tasks well, can secure their code and is smart enough to get support when they need it - but what about all the code they are re-using or integrating with? It's still unpredictable at best and who knows what sorts of security muster it's passed (or not). Someone once told me that we'd have no more code insecurity if we could just get rid of the programmers and replace them with re-usable code. I then reminded that person that someone had to write that re-usable code engine... which leads to the possibility for flaws.
Emerging from our perfect world where security still fails on occasion and returning to the real world we realize that we're under-staffed, over-worked, under-educated and under-budgeted. We've lost the race before the gun goes off. Chasing the big white whale becomes the dream of a madman. In a typical company where risks are a-plenty, and IT is up to its eyeballs in delivery issues it's a little difficult to suddenly step in and talk about security vulnerabilities like they're somehow more important than the 10,000 things that are already on fire. When the whole forest is on fire... which tree do you save first?
Enterprises and SMBs alike are looking to save money, cut corners (whether they want to admit it or not) and unfortunately security sometimes falls off the docket. Whether it's the security team's fault for not properly articulating the issue or the CIO's for simply not understanding the risks... the result is often the same. Somewhere in your business are thousands of lines of insecure, exploitable, and very lucrative code. Worse yet - that stuff has been there for years and now when you review a small snip that's changing and find that the whole thing has to be re-done... no one wants to pony up the money to do the work - right?
If you're not having too hard of a time explaining what it is you really mean by "we're going to be hacked" then you're figuring out how to get budget, or you're attempting to fit the notions of security into the greater SDLC... there's always a problem.
Think of it this way - as technologies become more complex security and development know less and less about each other's art - thus leading to a state where very bad things can happen in a heartbeat. This isn't magically going to get better when you wake up tomorrow. You're also not going to stop outsourcing, off-shoring, and doing development with teams that don't speak your language or understand your culture. Your ancient applications aren't magically going to be sunset in favor of their newer, more secure, versions. Things just aren't getting any better, this has been a trend since the mid-90's.
So... am I a cynic? Yea, I'm a cynic.
Why am I a cynic? I think it's because I know better, and I'm just a realist.
I do hope every day that there is a game-changer just around the corner. A new web development language that inherently disallows the developer to write insecure code, would be a great place to start! Until then ... Skeletor lives.