User Innovation and Security

User Innovation by end users of IT systems is inevitable. For years this innovation has primarily happened on the end user device. There have been a number of reasons for this; flexibility, isolation, responsiveness, connectedness, tools, capacity, control, etc. Each of these have created a compelling User Innovation platform.

Most organisation don’t actually like their users innovating in this way because they think users should be “doing their job”. One of the levers that organisation pull when they are trying to get people to focus on “doing their job” is security; “you can’t do that because it’s against the security policy”. The “security policy” being the lever to get them to step back into line, but this doesn’t work because the need to innovate is strong.

Let me try and explain the reasons why I don’t think that management via a rules based security policy works.

Security is normally the responsibility of a central function who express this responsibility through a security policy. Users are responsible for following the security policy, not for good security. The policy that is defined needs to be applicable to everyone making it generic in nature and tends to be rules based “though shalt not send executable files across email”.

The combination of centralized responsibility and generic rules based policies put the end user in a situation where they don’t understand the real security issues and hence innovate around the policy in inappropriate ways.

Rules based policies then get embedded into the service that is manufactured for the end user. Because the User Innovator assumes that the rules have been embedded into the service they also assume that if they are allowed to do something that it’s not a security problem.

But the truth is, it’s not possible to embed the rules in all situations within the service. Lets take Internet based services as an example. How do you set boundaries on the whole Internet with a set of rules and how on earth do you embed those rules into the service that you deliver.

At the same time you limit what they can do within the organisation so that Innovators are more likely to innovate outside it.

The publishing of potentially sensitive corporate data on Google Calendar which has been uncovered this week is probably a good example of these issues. I’m sure there are a number of reasons for the problems, but one of the main ones has to be people’s lack of understanding of the security issues involved, their reliance upon the security boundaries set for them and the level of control placed upon them within the organisation.

User Innovators need to be embraced as people who are adding value, they then need to be given some responsibility to consider the risks of the innovations that they are undertaking. Sometimes this means physically protecting them. Sometimes this should mean educating them on the risks that they are about to face and providing them with mechanisms for mitigating those risks. User Innovators need to be taught how to undertake a risk assessment of their innovation. They are going to innovate, so we should help them to do it knowing the risks.

The User Innovators are not the enemy though, they are trying to innovate so that they can gain something and that something is normally a benefit. Their skills should, therefore, be harnessed to help answer the security problem that are changing every day. There are a number of ways of getting their significant expertise focused on a particular problem, but I think that’s a topic for another day.