theReformed

First article of the new year is in regards to the flourishing WebAppSec community and it’s guidance effort targeting developers and consumers alike. The threat of web application vulnerabilities is now a common-place theme in this new day. Over the last ten years, the advent of the information security community, something previously overlook, has been it’s gradual embracing of the need for web application security as data, handling and formatting become more dynamic. The community has turned itself 180-degrees from reactive to proactive, albeit without a widely adopted standardization in responsiblity / disclosure (which in itself has led to a significant uprise in baseless, malicious disclosures by the 13-year-old next door, savvy with his laptop and his illegitmate copy of AppScan).

As a branch-community, WebAppSec has done a piss-poor job in educating developer masses and instead of concentrating on measures in reaction, we should have been concentrating on measures in foundation. What I mean by this, and harkening back to a segment in one of my previous articles (here), there has been no residual accountability in our community or the industry on their lacking in education of the end-user on their avenues of protection in production. The industry throws fifteen different security products at them and through fear-marketing, tell them everything is at stake if they don’t purchase our product - something which may or may not be true depending on circumstance. The consumer doesn’t necessarily NEED to understand the technologies being employed in protecting their assets after-the-fact, however, what they do need is education in at least understanding their web-application from the security standpoint at origin. The only viable answer to the security question is strictly in the hands of the author of the application itself at the time of production. This weblog itself @ theReformed, running WordPress, is inherently vulnerable to any number of published or unpublished vulnerabilties because it wasn’t designed as a secure application, but as a publically-accessible, publishing platform (say that five times fast).

Sure, there exists any number of disclosure open-policies (RFPolicy v2.0), but how many people in the webappsec community are adherring to these guidelines? In that context, we’ve therefore allowed the industry’s constituents to regulate themselves and the avenue of open-source technology, development and information has cut our own throats. Of course, as things roll down hill, that massacre has been passed on to the unsuspecting consumer, one who not by choice is inherently ignorant to the threats against their personal or business web-applications.

FORWARD NOTE: Regarding my next few points, as most of you know I respect Robert and his opinion’s very much having known him for many years now when we emerged from a different ethical scene - even invited him to my wedding :D. I believe he understands that I do my best to stay unbiased and objective when I look at a concept. Most of his opinions and statements in this interview, I agreed with - I just happen to have a different perspective than his on a few specific points.

Recently, I was reading Net-Security.org’s INSECURE MAG #14 (here) and came across an interview with my friend Robert Hansen (RSnake) that was discussing his expertise, impact and opinions on WebAppSec, wherein he stated something that I took a step back and had to think about, “I know lots of people think that stupid users are to blame for getting hacked, but I totally disagree with that (I like to think I have a pretty modern view of security in this regard) ….. They’ve followed every piece of advice that we as the security community have programatically offered them. The answer, unfortunately is that we, as a security community, have done a miserable job in giving consumers the correct tools to secure themselves.”

This is where Robert and I would most likely differ in opinion - I believe we, as the security community, have performed poorly in defining a relative standard of secure code practice for our associated developer community. It shouldn’t entirely be the consumer’s responsibility to police their Internet application, because the basic design, language, string, library or algorithm is inherently flawed before they ever utilize it (granted not always the case, but plausible) - there are only a handful of relevant checks and balances to keeping someone from writing a vulnerable application inside tools like Microsoft Visual Studio or even rich-media development tools like Adobe Flash Studio. The community should be assessing and mitigating the threat beforehand, establishing an instructional programming alternative for our developer community, decreasing the likelihood of poorly implemented, insecure products ever making it to market before we have to come up with workarounds and patches in the first place - its a lofty and far-flung idea probably to never happen, I’ll concede that.

I might also not agree, respectfully, when he says, “Let’s take an example of a user who logs into a Windows machine for the first time. It complains that there is no AV or Firewall. So they turn on Windows firewall or install another one, and the AV of their choice. They patch up because Windows yells at them. Does that make them secure?“, in the sense that the consumer IS partially to blame in many cases by failing to head these warnings.

Using an unnamed associate as an example (accomplished his professional career, but certainly technology-disabled - though not illiterate), he strictly looks for compliance (as Robert pointed towards consumers earlier in the interview) with the necessity of securing his data, the method of handling and with no deliberate intent to protect it other than what the industry has thrown at him as a solution to do so, spending countless dollars on suites of software that are ineffective. Unfortunately, those solutions don’t fix the problem and software nagware only serves to irritate him rather than motivate him to further correct the problem. This is self-imposed ignorance on the part of the consumer, wherein all the, and I use the term loosely, ‘solutions‘ have been presented, but out of fear, interest or lack of comprehension of it’s necessity / role the consumer doesn’t implement it. Why wouldn’t they be to blame, depending on circumstantial eligibility?

What advocacy group has this community developed that really speaks to the consumer on their level, leveraging the appropriate solutions / alternatives to their counterparts? OWASP is about as close as it gets to this definition that I’ve seen, a quite commendable effort by volunteers, but still lacking in the ability to connect with the consumer at the lowest tier, the market driving force that creates the demand - a demand that shouldn’t exist or should at least be transparent in some form. There is an old addage that the people and the politicians don’t speak the same language; the same can be said for programmers and end-users, they just don’t speak the same language, which is why IBM hires/employs a marketing firm or internal professionals to create it’s commercials, awareness ads and advertisements. If it was left up to the programmer’s the commercial would hypothetically be in all scrolling binary, with a black screen, red letters and Nine-Inch-Nails playing in the background. Probably not as bad as that, but you get the idea.

Additionally, the playing field has grown much too large and the consumer audience’s choices factor. Fields of products are making claims to patch mistakes, prevent authentication issues, reduce buffer exploitation and secure this / that. Yes, we’ve most certainly stepped to the plate in providing tools - however, how appropriate, efficient or relevant are they to the commonplace pitfalls programmers encounter? They number in the hundreds now commercial or otherwise, becoming exhaustive for even a entire team of professionals to completely evaluate for their uses. It would also seem, that the most effective tools have a history of having the most ineffective marketing campaigns, suffering poor adoption rates throughout the consumer community while some of the most ridiculous software packages have made their mark (and buck) because they know how to speak to the market. So there is a problem of communication and associating or relating the problem at hand to the consumer.

Rounding this back out to a final point, we must depend on our software architects/authors/programmers/magicians to apply the proper precautions when developing their next application. We can’t expect them to do this, without lobbying them with the appropriate instructions, tools and content to do so. We can’t assail our consumer base with the products to fix the things these individuals have failed to mitigate initially without realizing we could have resolved the situation from the ground-up and then blame our consumers for failing to act on our recommendations when we don’t provide some glimmer of hope that we’re working to improve their software’s security before it even hits the market -OR- we saturate them with so many warnings that they stop listening (ala ‘the boy who cried wolf’).