I hope everyone had/is having a good holiday. My only mishap has been to unwittingly deliver alcohol laced chocolates to my teetotal future inlaws. Fortunately it was taken in good humour and while I’m not sure if my “wash them down with a good Shiraz” jibe was particularly well received I think that the general good mood of the season saw me through!
Getting back on track and onto a subject I find myself thinking of frequently: that being of what motivates an attack on a particular web site? Here are my answers to that question:
1. It’s blindingly easy to attack. I encountered a couple of successful product defacements this past year that were the result of the vulnerability being found using one of the many Google-hack attack searches. If you are making it that easy then it’s a fair bet you’ll receive some unwelcome attention at some point in time, and find your product the subject of one of the many hackers bulleting boards where the exploit will be published for the rest of the world to see.
2. It’s worth it for the attacker. If the potential Return on Attack (RoA) for the hacker makes for a worthwhile investment of time and energy then you will be attacked. RoA equates to the gain for a successful attack against the security measures in place. This interesting paper presented at the forth workshop of information security economics (WEIS05) contains detail on the subject: http://infosecon.net/workshop/pdf/23.pdf.
Are we actually getting any better at preventing either of the above? My opinion is that we are. I encounter far more awareness of source-code related issues that would lead to exploitable web products amongst development teams than I did a couple of years ago. That does not mean that web sites are necessarily fully secure (in the same way that a locked door can often still be picked open by an expert), but it does mean that vulnerabilities become harder to find and in consequence take more time and effort for a hacker. And as we also know, trying to hack a website causes a good deal of detectable noise as the hacker needs to use a wider variety of tools to look for the way in. In consequence, as hackers detest being caught, they are likely to move onto an easier target and leave yours alone. Well, that’s the theory!
Something else to always keep in mind as well is that a specific customer account might be attacked as a result of the customer’s own computer being compromised and his credentials captured. Does this count as a hack? What about if admin-level credentials are captured and used and thus potentially giving access to many accounts? It’s certainly an attack but it’s not hacking – it may even be more opprtune than planned so far as the perpetrator is concerned. I suppose that Phishing also falls into this category. Depending on the type of web product in question you might need to rely upon fraudulent use controls and/or raising awareness of such issues with customers, and perhaps even some other authentication form-factor.
The point I’m trying to make is that I believe if we make it difficult for an attacker then the web site is less likely to be subjected to attack. That is very easy to say and not always so easy to achieve but there are many simple ways to reduce the attack surface. Over the course of January I’m going to talk about the various controls that I implement to mitigate risk. I’ve also got another risk workshop to run later on in the month – this time over in America, so I’ll be able to comment on the different perspectives of UK and USA based audiences.
This is my last entry of 2006. I hope you are finding this blog information and useful. I deal with information risk issues on a daily basis so if you have a particular aspect you’re interested in or questions you’d like answered then just ask away.