In the world of a dot-com startup, security is an easy thing to push to tomorrow.
Don’t get me wrong – we all know it’s important. But it’s rarely important AND urgent.
Until, of course, you’re reminded by the hackers.
Lesson 1: Schedule Security, or the hackers will schedule it for you.
Recently, due to *human* failure, one of our exterior-only (not core systems) was hacked, for simple commercial malware intent. Fortunately, losses were minimal, and he/she was not able to create a “back door”, and we know this was a reasonably inexperienced hacker, because he/she left a lot of “tracks” – the good ones immediately hide most of the evidence of their intrusion. He or she simply wanted to embed virus-installing malware links, which was removed within minutes. Nothing serious (no client data, no credit cards, etc.) was compromised – but it was a good reminder.
Lesson 2: All hacks are either (1.) Opportunistic or (2.) Targeted
The opportunistic ones are fairly easy to deal with: Simply be a harder target than the next guy. As your e-business grows, and you have greater traffic, Google Pagerank (an unofficial semi-used indicator of SEO value) then the opportunistic attackers have greater reason to go after you. The opportunistic ones usually just want eyeballs to spam-ads, clicks to virus or malware, or hard drive space for as cheap and fast as possible.
The vast majority of hackers (99%) on the web are after simple things – space in which to host malicious code, SMTP servers to spam from, zombie machines to swarm into a DDOS (Distributed Denial of Service attack), etc.
Much more scary are the targeted attacks.
Truly locking out 100% of targeted attacks is very, very difficult. Easier is making the cost and difficulty to hack you exceed the perceived or actual value of intrusion. Even major banks, the NSA and CIA, and internet security companies like Norton or Kapersky get hacked, often because a human dropped the ball more than code failure, but both happen. As SwiftCloud (company I founded) grows in scale / scope / perceived data value, I know it becomes a bigger target, and eventually, a hole will get found.
So for that, you’re left with the final major lesson:
3. Layer your castle walls
Internet security also includes human practices – the White House website was (maybe still is) written to a DVD-rom, then every 5 minutes uploaded to the live web server, so if anyone hacked it, their hack would live for a maximum of 5 minutes. This is fine for simple read-only sites, but impractical for today’s dynamic database-driven interactive sites, though it’s a useful lesson regardless. Keep backups and assume one day you will get hacked and everything wiped out. Recently we had a datacenter go down, and then the backup generator failed, and then the load balancer failed, causing a client’s mission-critical site to go down [note: this has since been revised, fixed, tested]. Assume the worst will happen, and restrict access to those who need it only, even if you trust them implicitly.
In our hack above, one of our employees was hacked, and the hacker then used that info to simply “walk in the front door”. Fortunately, we had restricted access enough it was just a lesson, instead of major cleanup or a reputation-killing public disclosure. In this case, the exterior site was isolated from the more crucial interior site, and the access was to a single domain, single database on a single server – I’m definitely not saying this to brag, I’m pointing out that security can and should be engineered in from day one. Tripwire and other security code is awesome – but it’s just one defensive tool of many.