So, you are using the cloud and all is going well. New upgrades to the software appear at regular intervals providing new functionality… all is going well. But what happens if something goes wrong? Twitter has just had such a problem, and it took down the service for many users. Who cares… it’s just Twitter?!?!? Well, quite a few companies have Twitter as a key part of their communication strategy these days, so when it’s down it does make a difference. However, the real issue here is the risk around upgrading cloud applications.
Obviously, the vendor doesn’t plan to make a mistake – but what if they do? What if it was your CRM system, or your ERP solution? In this particular instance, there were missing, late and/or duplicate entries… what would happen if this were your ERP system – could it handle the problems and more importantly would you know about it before the auditors!
Part of any risk analysis for the business needs to include the risks associated with 3rd party suppliers – and IT and data handlers are no exception. Service Level Agreements need to reflect these possibilities and potentially have clauses for reverting (quickly) to earlier versions, rather than bug-fixing on-the-fly to resolve issues. Now is the time to take a look at the contracts you have – and ask your supplier the questions… “What if an upgrade goes wrong?”
One of the things I talk about to customers is the potential issues with Open Source and security. It seems that others are also concerned and Fortify have been analyzing the problem.
They looked at a number of Open Source packages available and for a couple of the most popular found that they were vulnerable to SQL injection attacks as well as Cross Site Scripting. Open Source is a good thing, don’t get me wrong, however security is not necessarily at the forefront of the developers’ minds when they are developing functionality. With access to the datacentre information over the web, these applications represent real risk when it comes to data loss and general IT security. Perhaps we need to give Open Source applications a security rating?
There has yet to be any cases of popular Open Source applications being deliberately compromised by cyber-criminal gangs – but we do known that their operations are becoming increasingly more sophisticated in their approaches – and perhaps they have already done this, and we just plain don’t know about it…
So, if you are going down the Open Source route this is another case of ‘buyer beware’… except of course it’s ‘free’…
It emerged that more than 600 HMRC staff have been disciplined for reading information about UK citizens that they shouldn’t have – unless they have a specific need to do so. I wrote about the decline of implicit trust a while ago and this is just another example. Of course it is impossible for people to avert their eyes if there is something sensitive on the screen – and human nature is always drawn to things that are interesting (just think of surfing the web and the tangents you follow). There is technology that can help in this instance…
Automated redaction technology has been around for a while – in essence this ‘hides’ interesting information from unauthorized eyes from within a document. For example it might hide names and addresses, or bank details – or tax return information.
With a database application, it is the application that need to be altered so that sensitive information is not displayed. Not only is it time to revisit who has access to applications but also exactly what information they have access to – and is it really necessary.
In the cases where information is needed to be viewed on occasion, then a well communicated corporate policy coupled with an on-screen question / warning followed by an audit trail works… That way people won’t be tempted to look at the interesting stuff that’s out there.