I started out here by writing a reply to href="http://garage.docsearls.com/node/view/453">r0ml's recent post on href="http://garage.docsearls.com/">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 href="http://www.catb.org/~esr/faqs/hacker-howto.html#I_want_to_crack_and_Im_an_idiot">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.