Full-spectrum security

Yesterday, I stopped into Carey My Keys on St. George Street to have some spares cut.  The front door was open to both the patrons and the weather, and the poor dude who was supposed to be staffing the counter was instead juggling two phone calls.  While waiting, I took a gander around the place.

Keys are no use without locks, of course, so the range of those on sale was impressive.  Ditto the safes.  And a few fancy-schmancy electronic devices. Also on display, though not actually for sale, were two dogs, both sprawled out in the warmth of the afternoon.  At least when no human attention was forthcoming.  (Because, naturally, any Office Dog worthy of the title must be a friend to the world.  It's in the union by-laws.)

I couldn't help but appreciate the full range of security options, of which dogs, of course, are by far the oldest.   I suppose even Office Cat #1, who growls and hides at the sound of a knock or the doorbell, technically qualifies as security--particularly whenever I'm wearing headphones.

In the purely physical world, each form of security acts as a filter against specific hacks.  Locks can be picked.  Someone with inside knowledge could find a way to disable a security alarm.   Dogs could theoretically be neutralised one way or another--possibly before sounding any form of alarm.  But all together, someone would have to be both determined and thorough about breaking into your house to do it successfully.  Particularly if you were home at the time.

Online, it should be much the same story, meaning an overlapping of different mechanisms to prevent someone from breaking in.  Sure, you can set up your web application to use Secure Sockets Layer (SSL) 100% of the time, not to mention require password lengths to be measured by the kilometer.  But that doesn't stop someone with a bot-net trying to crack it with sheer brute-force computing power.  Adding a captcha (those mangled combinations of letters/numbers you have to type) to the login form complicates matters for the bot-net, but in the end, it's just another iteration of the arms-race.  But locking out the account (even for a minute) really puts a crimp in a bot's style. 

Alas, that doesn't stop someone from setting up an identical-looking website and sending out emails that attempt to trick your users into signing in (a.k.a "phishing").  (And, by the bye, nothing in the above scenario covers direct attacks on your I/T infrastructure.  That's a whole 'nuther job, and I'll get to that in a minute.)

As in real life, nothing's ever 100% secure.  That being said, the fact that there is no proverbial silver bullet is no excuse for not loading the entire clip.

As a programmer, a ridiculous percentage of the code I write exists to lock out the baddies.  A sample (but by no means complete) list of tactics:

• Verifying all input sent by the browser to the server, and back and forth between the server and the database.
• Scrubbing potentially malicious characters out of text entered by the user (e.g. attempted SQL injection or JavaScript injection attacks).
• Encrypting important data (e.g. passwords and email addresses)  so that even if the database were compromised, those would be useless to the thief.
• Preventing specific error messages from the server (and, most especially the database) from being displayed back to the web browser.
• Encapsulating code data access functionality in database functions, which adds another level of validation/protection.
• When appropriate, using industry-standard frameworks.

It's mechanical, repetitive work and boring and time-consuming as all get-out.  But it wouldn't mean bupkis if the person wearing the Sys. Admin. hat (which sometimes is me) drops the ball on things such as:

• Not keeping the system patched with security updates.
• Not shutting off unnecessary processes--particularly those which can reach (or be reached from) outside the network.
• Not limiting the channels (a.k.a. ports) on which traffic can flow to and from the server.
• Not using strong passwords.
• Not locking down resources (e.g. files and databases) to restrict which users can access them...and limit those to the bare minimum.
• Not using/enforcing SSL certificates (or using self-signed ones).
• Not having intrusion detection in place, or having no mechanism to defend against denial-of-service attacks.

Again, that's just a taste.  Does it add to the cost of a project?  Most certainly.  But it's nothing compared to what a hack will cost in terms of lost customer goodwill.  And that's even without lawsuits being filed.  And if that breach runs afoul of privacy laws/regulations...Ouch.

In practical terms, anyone thinking of paying programmers to develop a custom application should make security part of the initial discussion*.  It's not an after-market feature that you bolt on right before it goes out the door.

More importantly, it's not a feature that one single person should be responsible for.  Even when that one single person wears many hats (as I do).  

- - - - - 

* Pro tip:  Talk to your favourite geek ahead of time to develop a few intelligent questions about security alongside other pertinent issues like scalability.  Informed questions are an inoculant against being taken lightly.

Story:  Before I knew anything about cars, I used to call a friend who fixed them for a living.  Then I could walk into the shop and parrot something like, "My gut feeling is that there's a flat spot in the starter, but you might want to take a look at the solenoid, too," and have a reasonably good chance of not being fleeced.  Trust me, this is a totally legit. way to approach negotiating with anyone who's a domain expert where you're not.  Eventually, though, I found a mechanic I could trust.  Which was just as well, because I learned a lot of things about cars--or at least 1983 Toyota Tercels--as its innards were replaced during the remainder of its 16-year lifespan.