Given past performance of software security, its hard to be optimistic where things are going wrt Web 2.0 security. Granted when Web 1.0 was built out did not have the ability to use static analysis to find vulnerabilities, we didn't have good identity standards and so on. So are we at a new a beginning where new tools and mechanisms will save our bacon? Or will Web 2.0 herald some new some 21st century O'leary cow that burns it all to the ground?
Again, if we take developer innovation as a given we can see that information security has a decade worth of innovation to catch up on, its very hard to argue that infosec will just latch on to Web 2.0 and actually solve this problem when it has not addressed any of the new innovations in the last decade or so.
Andy Steingruebl went to a Web 2.0 security conference and took notes on the ideas and presentations, if you are in infosec and/or developing Web 2.0 apps (that is to say if you are reading this blog), I recommend you read it and chase the links to get an idea of what is viable or not. Now to thoroughly depress/inspire you further let me share Andy's conclusions from listening to this state of the state on Web 2.0 security
We haven't come close to solving the security problems in a Web-1.0 worldSo this leaves two possible choices 1) redo Web 1.0 security or 2) leave that bridge burning and try to fix the latest. Unfortunately people are instead choosing option 3 - use the same thing that didn't work in Web 1.0 and try to protect Web 2.0 with it.
We don't know what the security policies really ought to look like for the web, consequently we don't know what the architecture and implementation look like either.We do know it should come from a security architecture and design not from an auditor's spreadsheet though.
Browsers are lacking fundamental architecture and policy around security.And everything including administrative functions run in a browser these days
Web-2.0 only makes things worseThe OWASP guide, last I checked is over 300 pages long, when I train and consult with developers, I always ask how many are familiar with OWASP. Less than 20% are in my experience, and of those percentage most only know the OWASP Top Ten. If you have not read the guide and understood the concepts, it is really hard for me to see how your app is going to have anything more than cardboard walls level of security. Sadly, a lot developers think that software security is a solved problem, Tim Bray(*):
Of course some of these get into very sensitive security issues; but actually we’re getting pretty good at providing information on the Web in a secure way.This type of misconception leads to the worst case scenario where you actually build apps with sensitive data and functionality, link 'em all up through mashups, Rest and whatever; and do all of this without realizing that a root and branch reform is necessary in your web application security model. How'd we get here? Broken processes? Business too demanding? No security support in programming languages? Sure they all play a role, but its not the main problem, allow me to invoke the great Gerald Weinberg:
No matter how it looks at first, its always a people problemIn our case, its quite simple the security people don't know enough about software development and developers don't know enough about security. So you can look at the innovation table and see how far software technologies have advanced and how security technologies have not kept pace, and that is an admittedly terrifying thought; but what's most scary to me is to think about the generation of people that are left behind at each technical evolution working on trivial or low priority issues.
One of the reasons I teach software security training is to combat this, but in a company with thousands of developers I still may only get to teach 50 or 100. Many times when i teach we have the security people, developers, and architects in the same class; and usually they all know each other, but they don't work together, and a lot of the value in the class is them sitting together for a couple of days - finding some common ground, identifying some things each other are working on and then figuring out ways to make some joint progress. This is why I like teaching the class more at a company than as a public class -because when I am on site at a company they all have to work together.
So while we go through a ton of cool things in class like threat modeling, SAML, federation, static analysis, WS-Security and so on, the coolest thing is just facilitating interaction and in some small way helping to define some ways the groups can collaborate on tools, practices, and security architecture going forward.
When it works its really great, and sometimes we even get to flip around my earlier statement - architects, software developers and security people work together as a software security team and the software security team finds vulnerabilities we didn't even know about, leverages security capabilities we didn't even know they had and deploys security services that protect the enterprise assets.
Putting aside Web 2.0 as a technology; hopefully, Web 2.0 people means that software developers are software security people and security people are software security people. On that basis Web 2.0 may actually get an answer to Andy's concerns, without that Web 2.0 will remain DOA on security until Web 3.0.
* Note: I pick on Tim Bray not because he is an idiot, quite the opposite, its because I have higher expectations and expect more regard for security out of that community. I fondly recall the days when open source took security more seriously than Microsoft.
