Wednesday, 27 June 2012

Innovation Blackout

In the Harvard Business Review Blog Evade an Innovation Blackout, Jordan Cohen points out the difficulty of engaging effort for new ideas when the people with the ability to develop those ideas are up to their asses in aligators.
In a financial downturn, the razor-gangs that decend on the organisation are a big inhibitor of necessary change at just the wrong time. Any innovation is seen as something to be avoided or delayed rather than embraced as a means of getting out of a failing operation.

Monday, 25 June 2012

Backup Google Apps II

Continuing from   Backup Google Apps , I have been taking a look at Backupify.
This product meets a key component of my disaster recovery scenario. I am assuming that the worst that can happen to a Google Account is that users and the administrator lose access to it and, perhaps through the action of a 'bad person', Google cannot be persuaded to restore the account access.
Backupify can be accessed through a login independently of Google Apps which provides an alternative route to the backups if the 'bad person' has locked users out of the primary google apps files. Documents and Mail can be downloaded from Backupify as an alternative to restoring to the apps account so there is a measure of comfort that if the worst happens there will be a recovery path.
However there are some fish-hooks...

  • Because Backupify is accessible from Google Apps single sign-on, this convenience would be available to the bad person who could then lock the legitimate user out of Backupify*.
  • To support the download capability, Backupify transforms the Google Apps documents (creating xls files for Google Apps spreadsheets for example). This has unfortunate side effects, as there is not a one-one relationship between Google documents and the MSOffice equivalent so the round trip will lose
    1. any scripts developed in google apps spreadsheets
    2. the effect of google functions in spreadsheets
    3. charts in spreadsheets
    4. external references to shared or published documents

So there still does not appear to be an equivalent in Google Apps of the conventional off-site backup that will allow a recovery of all information in a disaster situation.
Is losing access to the Google Account a scenario that should be considered? I can think of a few possible events. In no particular order of likelihood or Machiavellian complexity:
  • Side effect of law enforcement action in US (eg Megaupload
  • Destructive action by a Google Apps super administrator 
  • A 'bug' in Google Apps

 [Update] * Backupify recognised the issue and responded (sensibly in my opinion)
Currently, we are looking to improve security with an extended identity verification that would allow you to regain access to your account faster in the case that this happened. We do not have this in the product now, but in the meantime if you want to send us a photo of your picture ID then we can store that internally and securely with your account. That way in the future is someone did gain unauthorized access to your Backupify account via Google Apps login and they changed the Backupify password that you set then we could work with you and use the photo ID that you sent to verify your true identity and get you access to your account again.
so we can expect there to be a process that could circumvent the issue of losing access to the backify account.

Wednesday, 13 June 2012

Backup of Google Apps

I am looking at the need for backup and recovery capability for organisations that manage their information and operations through Google Apps. 

Classically, backup for the unforeseen event comprises a resource remote from the primary information that can be used to support the business operations in the event of the non-availability of the primary source. Analysis of risk and impact of losses can be used to determine how long that you are able to do without the primary source and how much you should be prepared to pay for recovery within that time. Generally, only broad classifications of risk to the primary information is considered (destruction of data centre; denial of service etc).
In “cloud” services, we are buying a measure of protection of our information assets from the provider whether that is Google, Microsoft or Waikikamukau Data Services. The trust we can place in these organisations is related to their competence and also the size of the pain that the organisation will feel when your primary information is unavailable. For example, if Google reported that it could not recover from a failure of just one of its data centres, there would be a massive loss of confidence affecting the viability of the multibillion dollar company.
So we might safely assume that Google will be able to restore your account in event of a catastrophe in their domain, but user mishandling of information is another matter and firmly in the user’s court. For this the user needs a strategy to suit their needs for information assurance.

Implementing some form of backup for Google Apps will require one or more of

  • Maintaining an inhouse backup storage server to backup cloud based documents to local hard disk  or another storage supplier like Amazon.
  • Use a 3rd party service like Backupify or Spanning to copy and restore Google Apps documents/files.
  • Something to confirm that your backup policy is adhered to

In the case of Spanning Backup there are a few issues to be aware of.

  • When a document is recovered it is a new Google Apps document. Any references to the original will not be replaced by the restore operation. This will affect Sites that link to Apps documents, shares of the original, and published documents.
  • When a shared document is recovered, the new document is retains the shares of the original but the ownership changes to the user that performed the restore.
  • When a restore is performed, a folder is created to contain the restored documents. This folder is treated like any other, including taking part in subsequent backup cycles. There are opportunities for confusion about which version of a document is which.
  • The backup can only be used to recover to Google Apps and not as a path to another service

There will be good reasons for these issues and the design fits well with organisations where the individual user is responsible for their own environment (like with a personal computer). However, those familiar with IT-managed filestore could be surprised, unpleasantly.

Monday, 4 June 2012

Privacy Watchdog with Teeth?

Lets take computer privacy breaches seriously here in New Zealand. Give the Privacy Commission some teeth and send appropriate messages to the likes of ACC.
A recent case in the UK resulted in a significant fine being levied on a National Health Trust which failed to destroy sensitive data on 1000 hard disks before releasing them. More worrying was that they thought that they could contract out of the responsibility by using a 3rd party to facilitate the disposal.
Here in New Zealand, we get investigations but no sense that responsibility for the protection of sensitive data is sheeted home to senior management. The pressure on organisations that mishandle sensitive data is reduced by the requirement that the “complainant can show that they have suffered harm” rather than that there was a breach. Only “if the harm is significant, a complainant might be able to claim that they are entitled to compensation”. Note that there is no actual entitlement to compensation nor a means of making orders like that made in the UK case. The best we can hope for is a sound drubbing of the Minister by the the capital’s press but even that has been lacklustre.

Wednesday, 16 May 2012

Smart Meter Privacy

John Udel has raised Smart Meters up the conciousness ladder in a timely post.
Smart meters are new. But we can’t afford to think that every new technology rewrites all the rules, requiring new legislation which, as we know, can never keep pace with innovation. Here’s a powerful simplifying rule: It’s your data. That’s the default. And you shouldn’t need to be a do-it-yourselfer to assert ownership. Even if you use a utility-supplied meter, as most people will, it’s still your data.
It's your data??? I am not sure that it is so simple. It is 'their' accounting record. The meter certainly reveals something about the occupier, which is not necessarily the other party to the power company contract, and there are certainly undesirable uses for the information - for example knowing that the house has a pattern of occupation.
There needs to be an auditable protocol for dealing with the handling of the broad swathe of surveillance data from smart power meters to smart parking and cctv but I don't think it starts with "It's my data"!
I am looking forward to the views of the NZ Privacy Commisioner on this. I would hope that some clear direction is given so that surveillance data which can be associated with individuals is treated in the same way as Personal Information and therefore covered by the privacy principles. Attaching some teeth to the principles would be good too, but one step at a time.

Monday, 26 March 2012

ICT Benchmarking NZ

The Administrative & Support Services Benchmarking Report for the Financial Year 2010/11 is probably not going to make it into the best seller list and if you have to download it from the treasury web site you may experience for yourself what the prime minister  was describing when he was quoted as “shocked” by the state of many government IT systems, which he says will need to be upgraded to improve public sector efficiency.
However, it is hard to see whether we should be appalled , content, or apathetic about the current spend of $980 million on ICT which represents nearly 57% of total government administration and support services costs.
We might expect a benchmark report to indicate some standard to be achieved but I searched in vain. $980m seems low when compared with the total expenditure of the NZ Government. The NZ Govt Treasury Web Site was down as I wrote this so I am relying on the 2011 budget forecast figure of $78,944.4 million. Actual spend was 70,450 million. So the ICT spend is about 1.3% of total spend. You can compare that with the profligate Brits who reported that the “average for the percentage of total revenue expenditure spent on ICT in central government departments is at least 5%”. They were not very happy about that but did note in a report of Public Administration Select Committee that “It is widely accepted that 3% is a benchmark of good practice in the private sector service industries for ICT spend as a percentage of total revenue expenditure. Socitm benchmarking in recent years has demonstrated that local government organisations spend consistently less than 3%”. The US federal govt spends about 2% of its 3.8 trillion expenditure on ICT.
So in benchmark terms are we spending too much or too little?
The emphasis on ICT being 57% of total government administration and support raises the same question. With pressure to cut public service numbers (the other main component of administration and support) we should be looking at increasing the proportion of the A&S cost that is taken up by ICT. But really is it a sensible benchmark factor?

Added actual NZ govt expenditure 9:24pm