Friday, August 1, 2008

The crud moved up the stack

A long time ago (in internet time), in a galaxy really nearby, a few large software companies attached their buggy, unsecured operating systems to the Internet.

Havoc ensued.

The overall quality of software, as measure by MTTB (Mean Time to Badness), or 'if I connect to the internet, how long 'till bad things happen' was pathetic. Cow tipping was an amusing past time, Land attacks, Ping of Death attacks, Smurf attacks, were a daily event. Toss a few malformed packets into a campus, watch the campus roll over and die. Build a worm that can hack a zillion web servers in a week, or sling out a UDP packet that can turn hundreds of thousands of database servers into corporate network wrecking zombies, affecting even the companies that wrote the software. Sysadmins made the problem worse by connecting any old crap to the internet without the slightest thought for securing it.

It was chaos.

But software vendors recognized the problem, or at least most of them did, and implemented necessary processes to ensure that their software was written, tested and deployed in a manner that largely solved the worst of the problems; sysadmins started hardening first, then deploying, and things generally settled down.

In other words, the worm and hack outbreaks of the early 00’s accelerated the development of reasonably secure operating systems with pretty decent default installations, and in particular, changed the attitude toward secure software development at a few large software vendors. The change in attitude toward the importance of security has, in my opinion, made a dramatic difference the security and availability of operating systems (using Windows 2003/IIS6 as the best example).

Today?

The crud moved up the stack. We now have tens or hundreds of thousands of web sites vulnerable to XSS and mass SQL injection attacks, poorly written applications that require DBO or DBA privs, full rights to file systems and random firewall port openings. We have applications that are written and deployed with trivially exploitable vulnerabilities, applications with no concept of roles, rights or privs, and application vendors who yank support from you if you attempt to add the most basic of security controls on to their crap.

It's the same story, just moved up the stack.

Unfortunately, todays problem is much harder to resolve. In the late 90’s and early 00’s, a relatively small number of developers at a few large vendors could largely solve the problem by changing the way they build software. Figure tens of thousands of developers or so, who worked for no more than a handful of software companies, who were reporting to what we presume to be authoritative managers, and who could be ‘forced’ to follow a methodology or standard, could more or less solve the problem by doing the right thing when they wrote code.

Today, with web apps as the hack target, the community of developers who have to understand the problem and change the way they build systems is pretty much anyone who has ever slung up a simple web/database application. That population of developers is millions, not thousands, they are all over the map in terms of their skill set, and they are largely outside the bounds of large structured software companies or anything resembling top down authority, and are extremely unlikely to be using any software development methodology whatsoever, much less a methodology that encompasses secure software development. (They'll be agile though.).

Educating them is a pretty tough problem. Changing the way they write code is even tougher.

My experience hosting applications developed by small companies and contractors is universally negative. They simply don’t have the a clue how to handle the current round of SQL injection, XSS, etc., they have no clue what file system or database rights and permissions their applications require, they have no concept of separation of code from data, they require a well known SA password on a database, 'Everyone' 'Full Control' on the SQL database directory structure, and when asked about application security, they are as likely as not to respond with a brochure outlining how many locks there are on the doors to their hosting facility. Least bit? Not even close. They need all the bits. They aren't sure which ones they're actually using, and it'd take at least until lunch to figure it out.

It sounds to me like a much larger problem.

The chaos continues.

No comments:

Post a Comment