Saturday, July 26, 2008

Quality, Security, and Risk

Providing a quality service or application is often a good indication of an organisation that is paying attention to detail and as a result there is reason to suspect that they're also paying attention to security. A bit general perhaps but if you're looking for smells, I believe the quality of an organisation's public channels can provide some indication of the quality of that organisation's internal systems and processes.

From the inside a good indication that attention is being paid to detail is the existence of a risk program. Assessing risk in information systems is a prerequisite for both quality and security. Assessing risk is really only expensive in time and that only for initialisation, once established it only requires a relatively small effort to maintain. The tool I've used previously is a spreadsheet and the process involves a round-table discussion with all involved parties to thrash out what risks can be identified in operations/systems/applications. The great bonus of this exercise is that everyone gets an opportunity to have some input in a neutral forum and issues that have been held close can be exposed to the light.

Once an agreed list of risks has been composed, the next step is to assign values representing the impact and likelihood of each risk on a scale from 1 to 5:

ImpactLikelihoodGross Risk
5 (catastrophic)5 (almost certain)E extreme/critical
4 (major)4 (likely)H high risk
3 (moderate)3 (moderate)M moderate risk
2 (minor)2 (unlikely)L low risk
1 (insignificant)1 (rare) 

Another table then provides a value for the gross risk assessment (see previous table for Gross Risk legend):


The spreadsheet has a single row for each identified risk, and within that row there are columns for a description of the risk, the impact and likelihood and the calculated overall risk. Other columns include accountability and the current risk mitigation measures and management comment. It becomes fairly obvious then what issues require immediate attention and which ones can be treated as routine. It is also a great way for highlighting to management issues that might otherwise not get the attention they deserve and ensuring that if something does go wrong that management had previously been made aware of the risk, accepted the risk and agreed to the mitigation measures that had been put in place, i.e. the principle of no surprises. Plus once it is in place it only requires a regular review to continue to be effective.

This is not something I cooked up myself, it was a process established as part of a risk program and introduced by a third party organisation. I don't know where that third party sourced the process. I do know it is simple and effective.

Tuesday, July 22, 2008

Dropping IE 6

So 37signals is reporting on Apple's decision to drop support for IE 6 in MobileMe. I'm sure there are many who would like to drop IE 6 from a great height. I will confess that in my current position as a web developer for a NZ bank, I have users connecting with IE 4 and NN 4 browsers. This is a situation I inherited and one I'm happy to relinquish when my notice period finishes in a couple of weeks time. One of the major issues is that there is no way to correlate the user with the browser. This means there is no way to contact users of older browsers and assist them to upgrade and as a result the bank's sites are all lowest-common-denominator HTML. Of course to get into this situation in the first place required a hefty portion of mediocrity which included very little cross-browser testing. The average user experience is likely be fairly average but only the user knows.

Which brings me to my prior position, also for a NZ financial organisation, where we did take a lot of care with the sites we published. There we also had users connecting with older browsers but we kept a record of which browsers a user connected with. As usage of older browsers dropped away we found we were able to contact the typically small (<100) number of users affected and arrange an upgrade. Feedback was generally really good, some folk were happy to have an excuse to upgrade, some folk had access to a supported browser at work (and sadly one old chap conveniently popped his clogs).

Which left us still supporting users of IE 5.0 and Navigator 6.2. There are some inconvenient issues with DHTML on those browsers and they require a little extra work. Fortunately there is an enormous body of knowledge around what those issues are and how to work around or avoid them. We didn't need to be at the cutting edge which is where a lot of cross-browser issues can be crippling. I personally wanted to provide a good user experience for all our users and with a small team that was very doable. Looking to the future, I mandated the use of web standards and high quality JavaScript and as the usage of older browsers drops away it all just gets easier.

I can appreciate that Apple wants to have absolute control of the user interface design and requiring a modern browser must make that easier. I had a quick look at the page info for MobileMe, there's a lot of stuff coming down the pipe to your browser, far more than I would allow for my web applications — most of my users are still on dial-up and the user experience would be dreadful.