I started out here by writing a reply to r0ml's recent post on Doc Searls' IT Garage. For some reason, though, reading this article started me thinking about security. and so its scope has expanded.
Based on my second- and third-hand knowledge, in previous office information technology revolutions, security domains were well separated, or at least gave a convincing illusion of being so. At first, things which ran on the mainframe were the responsibility of the IT department, things which ran on the workstations were the responsibility of the "rocket scientists", be they devs or quants. Anything IT talked to that wasn't actually running on the mainframe was suspect.
As IT subsumed the TCP/IP infrastructure, the professionals ran to IPX and various transports for SMB: anything IT talked to on a Netware or NT share was suspect. Now that IPX has gone the way of the dodo and CIFS is exclusively a TCP/IP beast, there is a new problem: assuming the end-users are equally sophisticated as your IT staff (unlikely) but less concerned with security (very likely), if they attach a machine to "the network", meaning the IT-maintained, TCP intranet, then there is no protection against the outside world besides the firewall. There is no domain that IT can look at and automatically say "ah-hah - data coming from there is suspicious, and sensitive data should not go there".
With a new Outlook virus every two weeks, allowing users to download and run things off the web puts corporate IT into an almost tragic position. An industrial spy who writes a trojan that uses visual basic can act as if they were actually a user, willy-nilly attaching any file on the user's hard drive with the word "budget" in it to an email in outlook and mailing it to servers in russia. When users inevitably fall prey to these problems, it becomes IT's responsibility. Even - and perhaps especially - the machines sitting on the users' own desks are part of the IT infrastructure.
They also must remain part of that infrastructure until there is some other way to deal with assigning responsibility for security problems. If the CTO is going to get the axe for poor security practices, you bet he's going to scream bloody murder every time an IT staffer lets a user install a .scr file somewhere.
This all creates a problem of in the mercurial worlds of legislation and accounting, but I think the next IT revolution might put power back in the hands of the users if these alternate universes come back into tune with reality. The fact is, IT in the large is doing a pretty bad job with security. Firewalls that block everything but port 80 and leave email in the DMZ a good example of the sort of cargo-cult paranoia that drives modern security design. Who is it out there that really believes that attackers can't tunnel their outgoing information through HTTP or email?
What about incoming attacks? Outlook is always easy to pick on, but it is
hardly the only problem. Let me preface what I am about to say: I don't have
any connections in the white-hat or black-hat security communities. I do know
a few programmers though, and most of them work with the web. Every so often,
one of my colleagues will hit a website, look at a peculiar URL, say
"Hmm... that's funny" and try passing some obviously invalid data as a
parameter. On several occasions, this has resulted in me getting an IM or an
IRC connection saying something like "Hey, look at this:
http://...?PROGRAM=/bin/cat%00/etc/passwd". Or maybe,
http://.../query?sql=SELECT%20custname%20FROM%20customers%20LIMIT%2010.
These simple attacks, performed through the public web-sites made available by
the companies themselves, result in password files being exposed, or even
customer information being inadvertently granted to outsiders. In every case,
the problems have been promptly reported to the proper authorities within the
companies with the problem (and in at least one case, where the company was
unresponsive, to the police).
Aside to the viewers at home: before you ask, no, I will not tell you who discovered the problems, or where the problems were discovered. Most especially, I will not "teach you to hack", and if you asked, you are sub-human scum. I thought long and hard about posting this part of the entry, and if any discussion about this breaks out, I will immediately remove public access to it.
I've never heard two reports from the same person, or at the same company; these are not hardened criminals breaking into sites, or one company whose security is abysmally bad. Security on the internet really is so bad that a casual observer with no security training and only a smattering of knowledge about the potential configuration of a website is often able to accidentally break into it. It's a quiet epidemic in the technology industry, one that goes to the roots of the unexpected success of the internet and the hyper-speed at which programmers have been forced to produce code and be the first to market. This epidemic will become a harsh reality for consumers soon, as computational trust issues have now taken on clear and present political consequences.
Back to the issue at hand, though. In "Do It Yourself" IT, who is "Yourself"? The implied "Me" shifts back and forth between IT companies and vendors, but the "You", the "real people" who need to do their work with computers, are hamstrung by mistakes "We" have made. It seems to me that the most serious among these mistakes, the really limiting ones, are related to security. The limiting factor isn't one particular aspect, but both problems and solutions, both perceptions and misconceptions about security and real security issues.
Business technologists need to get serious about security, and start considering attacks against their software in a real way. That means getting security where it counts: in the applications and in the operating system. IT management needs to take drastic action and hold vendors responsible for even potential security problems. There is a tendency to whitewash these things or to put them on the back burner, since when security is not an emergency, it's not a visible problem at all.
Until that climate changes, the user's computer will be a prisoner of IT's fear that it will cause security problems. I don't have any illusions that suddenly everyone will start getting better at security auditing, but the fundamental technologies underlying our infrastructure need to be cleaned up significantly. I'll call out a few by name by way of example - Perl, PHP, and ASP. Every compromised site I've ever seen was using one of those three technologies, and it was a problem at that level or a very bad, but very common idiom that made the sorts of mistakes I've seen easy to make for developers.
I know I plug high level languages a lot, but I don't want to end on a glum note of "and that's how things are". You can improve your code's foundation today, if you just pay attention to security. If you're starting a new project, Lisp, Smalltalk and Python may not be perfect, but applications written with them (and with an eye to security) can set you free, to be You, or Me, and let you define who Yourself is.