Getting attacked can be expensive – for several reasons. Therefore when considering your security spend, you need to weigh up the cost of putting things right should things go wrong, verses the cost of doing regular upgrades or going the extra mile with security.

Firefighting

If the attack on your site is ongoing – such as a Brute Force Attack or a DDOS (Distributed Denial of Service attack) – and you’ve got a Developer on hand (or a team of developers), there can also be work to be done literally during the attack.

An attack is slightly different than a hack, as it doesn’t necessary mean anyone gets in and does anything and actually “hacks” you, but I’m writing about it here as it is a definate way that costs can mount up.

Your developers might be trying to chase down the attackers, identify their IP addresses and block them, see what firewall rules can be put in place to keep them out, turn off services that you want to ensure they can’t get to and more. Attacks can go on for hours, with the attackers springing up in different places even though you think you’ve stopped them, and it can keep your developers busy for a while.

Meanwhile, afterwards, you’ll typically ask your developer for an udpate on what happened, what alerted them to the issue, what they found, what they think might happen next. Perhaps your CSO will ask for a call with them. Perhaps you’ll have a series of group conference calls about it with lots of members of your team. Time is money. Before you know it, you’ve burned through 10 hours of your developer’s time just getting them to firefight and then tell you about it. Especially if some of it went into the night and so was charged as overtime.

Putting things right

The next cost you hit after being hacked is the developer time it takes to get things back on track again. If you haven’t got a go-to developer you’re going to be desperately scrambling around trying to find someone, and you might not be able to broker the best deal if you need someone good, fast. You’ll be asking them to drop everything and potentially work out of hours to get things safe again for your visitors so that might not be cheap.

It can also be time consuming to fix a hack. Hackers don’t tend to leave a note with instructions on what they did, and how to put it right. They also like to leave back doors so that once they’ve been in, even if their work is cleaned up, they can let themselves in again and carry on wreaking havoc. So your developer will need to do what they can see is obvious on the surface, but then do some investigative work to try and dig into what they may have done that’s less obvious or hidden somewhere, lurking for a later date.

If you haven’t got a back up your developer can get their hands on, and the code is riddled with nasties, it can sometimes be a case of needing to scrap your website and start over. That is the worst case scenario, but it’s not unknown.

Follow up

So this was touched on above, in regards to your team having calls or meetings about everything that happened. But if you think any customer data was compromised during the attack, you’re going to need to speak to your legal team about whether you need to declare it to the Information Commissioner’s Office. Or at least discuss it with your Data Controller. And all that needs to happen within 72 hours of the suspected breach. Meanwhile your team may also decide to report the offending IPs, if you know them, to the hosting company that was used to carry out the attack, if your developers have managed to track it down.

Again, time / people = money.

Going the extra mile

Typically, after you’ve had a nasty hack or attack, you’re going to be extra wary of the dangers of not keeping up with security and will throw the book at getting everything done that you can. So all those things you put off doing initially due to the budget, suddenly you’re doing anyway – on top of everything I’ve already described here.

Website upgrades are rarely a priority – until they’re the only priority. Website security isn’t important until it’s the most urgent thing for your company.

The cost of your reputation

Now, this one I don’t know the cost of. But no one wants to send an email to their customers telling them that they got hacked, and that – if you’re lucky, you’re just very sorry for any inconvience caused due to the interruption of your services… if you’re unlucky, that some data of theirs has possibly fallen into the wrong hands.

Customers want to trust the companies they do business with. It doesn’t matter to them how complicated the world of web security is – most of them won’t know but will just expect you to have done everything right.

Budget tally

Everything here adds up to quite a lot. So that’s where you need to decide how to play things. If you don’t store user data for example, you’ll never need to write one of those “sorry” emails. If your team is just you so there won’t be lots of paper work to pass around if something happens and you can just have a quick chat with your developer afterwards, then those costs won’t be as bad as in a big organisation. Even if you do do everything you can think of to protect yourself, it’s not guarantee the bad guys won’t find a way in.

But it’s just food for thought – can you afford to not do everything you can?