8th September

How much do you trust your bank?

The ever-interesting "Light Blue Touchpaper" blog, from the University of Cambridge security team, has a post up about the Which report into online banking security, which links back to an earlier post of theirs about vulnerabilities in the implementation of the "CAP" (I thought this stood for 'Card Authentication Protocol' but the Cambridge paper has 'Chip Authentication Programme' - they are probably right, except for the last two letters Cool ).

There are lots of issues raised - which reminds me of one of the useful dictums of dealing with customer security - the sorts of people who comment on security blogs (more generally "security specialists" or "people attending security conferences") are rarely representative of the customer base a normal business needs to serve. Anyway, I am interested in one of the proposals:

The banks should be exploring technologies which allow server side verification that the client is indeed secure. To a limited extended trusted computing could be used to solve this problem. Although such technology is clearly too immature at this moment in time.

It is interesting to consider to what extent this is actually practical. "Trusted Computing" simply isn't - trusted that is. The links to business DRM and the media industries have ensured that. Although it is a truism that you are better able to secure a small application / applet than a general purpose computing device. The problem here is that you are not fighting errors, you are fighting a capable adversary who can respond to any new security measures. And is a legitimate customer in their own right so you cannot hide your security measures from them.

It is necessary to consider how the fraudsters might spoof or mimic 'correct' responses to security tests, as well as realising that you need to serve 'the customer' - which means a default of two or three generations ago Microsoft, operating system and browser, limited or no security tools and still capable of functioning with the latest Linux kernel and konqueror, or the special browser software available for the blind or partially sighted. It must work through an application-level corporate firewall (with a hard-core malware filter) and a browser without scripting. There are also have privacy and deployment restrictions - conducting a vulnerability scan of your customer machine is simply not practical, even were it legal (your customer may consent, if it is their machine to consent, but has their ISP?) It makes the whole business much more complicated than it seems on the surface.

12th August

Customer Relations and "sucks" Websites

I have often been asked for assistance in taking down fraudulent and offensive websites. Sometimes, the sites are "sucks" sites - a genera of customer complaint linked to the proper domain name with "sucks" or "really sucks" appended. I have always seen these as a customer relations problem rather than an information security issue - fix the customer's problem and then ask them to take down the site, and annoyed with customer-facing teams whose response was to reach for the law rather than admit that a mistake has been made.

It is nearly impossible to win against the publishing potential of the internet - there are too many domain extensions available for you to register all possible offensive domain names. More significantly free speech laws, certainly in the USA (where much cheap or free web hosting still is), mean that unless you can allege passing off or a DMCA violation (publishing your IPR protected material such as a logo), your legal right to have the content removed is dubious. (However, see here for non-complaint domain registrations.)

Thanks to a plug from Amazon for this book, I have found this interesting article, written from the marketing perspective (the people who were normally desperate to have the sites removed) about how poor service can destroy even a good product and the importance of reputation.

Some good legal information can be found here and a beautiful example of how not to do things here.

31st July

iPhone- or not to iPhone.... that is the question!

With the news from Blackhat, the issues around iPhone security are once again to the forefront.

I'll be upfront - we both use iPhones for business and personal telephony, mobile email and web and (especially in my case) games. When the business decision was being taken, I was strongly in favour of the Blackberry route - mostly because there is currently a method of configuring these to allow use for low-level UK Government protectively marked data. I was outvoted (it is amazing how a tied vote always goes agin the blokes when the opposition comes from the distaff side) because of the easier readability of the iPhone screen.

But the iPhone is not massively secure:

  • it is a new and very complicated OS with a rapid update cycle, therefore there are going to be exploitable errors;
  • industrial design, not security, is really Apple's space - despite the US Army's adoption of OSX for their main, and some other, web-sites;
  • the programmers seem to need a bit of secure coding training - and probably some expert cryptography advice;
  • the ability of users to download active content is going to defeat almost any security regime.
However, security is a balance between business functionality and risk - and, at the moment, the balance for us means that we keep the iPhones, although I will be looking out for ways to improve their protection.