In Part 1, ‘[ ________ ] is the Best Policy, we looked at some of the common aspects of an open source policy and discussed how our recent survey discovered that 41% of people think that policies are not enforced. Now in Part 2, we will look at how effective policies are when considering security concerns.
Policies within a technology organization are generally intended to adjust behavior in a certain way. They try to get people to do less of one thing or more of something else. It’s really just a basic tool for social engineering on scale. Well, that’s when they work, of course.
Strange Beasts
Policies are strange beasts, quite often designed and constructed by people other than those who are responsible for doing the work that will soon be governed. In some instances the policy writers are far from being experts in the underlying subject matter (I wish this had been a survey question…). What is common, in pretty much every case though, is that someone has demanded a policy and they probably wanted it yesterday.
Policies can be born out of someone’s architectural bias, from audits, as a result of an unwanted event, as a cost cutting measure, as a legal requirement or for many, many other reasons. Whatever the initial drive, someone is often made responsible for the successful introduction of a policy. (Note: Not successful adoption. That is often federated out, which in turn can lead to diffusion of responsibility...another topic for another day).
The Fear Factor
Unfortunately, due to the fear of adding further work burden to teams, it is quite common for policies to drive towards things that are already achievable. This often dilutes their initial purpose. If this happens, the policy will no longer change behaviour in the way it was originally intended. But a policy will exist. And so the exercise, at least from one perspective, is complete.
I was once told that delivering the wrong thing is better than delivering nothing. It sounds so very wrong, but happens all the time. People measure output first, quality second. Unfortunately, policies would seem to fit that paradigm a lot more often than they should.
Where Concepts and Practice Differ
Based on our June 2014 survey results, 39% of people said the actual policies that were put in place did not look to address security concerns. This would seem to backup our slightly whimsical overview of policy creation above. 39% of people are alluding to the fact that the policies are both ineffective and encourage box ticking behavior. Have you ever thought a policy in your organisation was there purely for show?
There is Hope
There are strategies you can employ to guard against this and to prevent falling into that 39%. When writing a policy one should also look to also define measures of success for the implementation to ensure it can be effective for the purposes the policy was originally intended.
For a policy which says:
Measures of success for the implementation might look like :
Meaningful Change
When you have met the measures that enable the implementation, you can be more confident that the policy can be enforced. You can also drive a policy which is meaningful.
The working group which is established to build / review a policy can also be more easily lobbied, resulting in a policy that will change the behaviour of the organization in the way it was intended. If policy creation and implementation are considered as an atomic unit, the chances of success will increase dramatically.
Creating, implementing, and enforcing policy is often much easier said than done. That said, I hope the advice here will help you throughout your journey to success.
Finally, here at Sonatype, we offer policy workshops if you are looking to take a more prescriptive approach to managing and automating open source policies.
