Good Fences Make Aloof Neighbours
Charles Miller, Confluence Architect talks about ConfluenceSeptember 21, 2006
One of the great ironies involved in developing Confluence is the fact that we've put a lot of effort into giving our wiki software the flexible, but easy to use permissions model that an enterprise would demand, but I seem to spend just as much time trying to convince people not to use it.
Ward Cunningham's original wiki, and many of the sites that followed it, have no security at all. The whole premise of 'wiki' is that anyone can edit everything, because the value of serendipitous contributions from well-meaning passers-by outweighs the cost of vandalism. This level of openness is unlikely to appeal to an enterprise looking for a wiki to deploy internally, but it's important to keep the principle in mind: wikis are successful because they remove barriers, not because they erect them.
Case in point. A while back I made a news post to my Confluence personal space on the Atlassian extranet, just before I left the office for the day, but I mistyped a link. By the time I got in the next morning, someone from the San Francisco office who knew what I was really trying to point to had fixed the link for me. If I had restricted editing to myself, that couldn't have happened nearly as easily.
Security is about managing risk. If you apply a security measure without understanding the risk you are attempting to mitigate, chances are you're going to end up with bad security.
So what are the threats against a wiki? Generally in information security, we are protecting three things:
- Confidentiality - people should only be able to see information they have permission to see.
- Integrity - the information should be safe from unauthorised modification
- Availability - the information should be accessible when it's needed
How you protect confidentiality (which spaces and pages you allow which people to view) depends entirely on your needs. If you're a company with an Apple-like adherence to secrecy, you're going to want to make sure that each team is working entirely in isolation, and nobody can view anyone else's spaces. Some of our more 'interesting' customers will even buy multiple instances of Confluence or JIRA because their security regulations prohibit different teams sharing the same database.
On the other hand, if you don't have such a strategic or regulatory interest in keeping the left hand from knowing what the right hand is up to, a more open wiki gives you the perfect platform for interested people in your company to keep up with what is going on elsewhere, and for ideas to spread across the entire enterprise.
Integrity and availability are the two areas most commonly thought of as vulnerable in a wiki. If anyone can just come along and change something, the line of thought goes, how can that information possibly be safe? This might be fine for the online social experiments that are public wikis, but to a risk-averse enterprise customer, it seems it's best to make sure that the only people who can edit a page are those who can be implicitly trusted with it.
I have two locks on the front door of my apartment. This is one of the security compromises that anyone living in a reasonably-sized community will make, and while you quickly get used to them, there are significant disadvantages. Everyone who wants to get into the apartment must carry keys around with them. You can't just get someone to grab something from your apartment on their way in to work because you forgot it earlier. If your keys are stolen, you have to get the locks changed. Occasionally you might get locked out. Or you may break up with your girlfriend and then wait three months for her to give you your spare keys back.
But what if I could be notified the moment something was taken from my apartment, identify with certainty who took it, and get the stolen goods back undamaged with almost no effort? Ignoring privacy issues (which take us back to confidentiality), would it now be worth my while to mess around with keys?
In an enterprise environment, where every contributor to the wiki is identifiable, and every change reversible, what value remains in restricting edit rights a priori?
4 Comment(s)
This is very well put. I spent about a year getting Confluence approved and rolled out at my last company and a large part of the political battle was related to people's knee-jerk reaction that they wanted to have their own "secret stuff". Predictably, most opposition was from middle and upper management - most grunt-level employees were more than happy to share. My strategy was to develop popular support in each department by talking to people one on one, having lunch with them, asking them what they liked and disliked about the existing document management system, and so forth. This resulted in various managers and execs hearing "wiki, wiki, wiki" from a lot of different sources instead of just from me.
I was pretty successful as well by arguing that the cost of the employees not being informed about the product was a known quantity, whereas the fear of an information leak was a speculative worry. Also, I pointed out the irony of worrying about the openness of a wiki, when due to the unusability of the current system people were using ultra secure channels like, um, email, instant messenger, water cooler chat, and rumors :-) Confluence beat out the other wikis because I could honestly say "well, you can lock down pages if you like", but once I won the war to implement it, very few people ended up bothering to lock anything down.
I left that company partly due to the stress of having to fight so hard for so long for something obvious, but it's gratifying that I still get emails from people telling me they love the wiki, or that they used some wiki page I wrote a year ago to solve some problem. Go Confluence!!
By John Price at September 21, 2006 10:36 AM
You're right about the last paragraph. But think about external contract workers, we want to give them access to their team's space only and they certainly shouldn't be allowed to view anything else of our documentation. We have spaces for all of our teams and departments and one central space with stuff that is of everyone's interest (except the external workers). But what if I want to permit the externals to just be able to see that one page in the central space? We can't because Confluence only has the "Restrict to" ability and not an "Allow".
Look at the votes and the demand for features like these - do you really think the reason for them are customer's who don't think far enough? Of course we looked into permitting write for everyone but decided that we can't do it in our organization. You shouldn't educate your customers how to protect their valuable documentation, you rather should implement the most requested features and give them the tools they need.
By greuff at September 22, 2006 12:03 AM
greuff;
I'm not arguing against us providing better permissioning, just that people should think twice, or even three times before applying it. Obviously you have thought carefully about the matter.
The reason that we haven't implemented the improvements you're asking for is not because we don't think they're valuable (we do), but because we need to take the time to implement them properly. There are significant challenges both in terms of performance (more complicated permissions checks mean the application needs to do more work loading every single page), and in designing the user interface correctly.
By Charles Miller at September 22, 2006 12:23 AM
a part of our wiki is also accessable externally from a customer of us for projects and collaboration. without permissions, they would have access to our full wiki, which would be not a good idea
also it was an big argument for our managment, that we can hide information (we have to, for example for NDA contracts). even if we use it little to never.
but it's like elsewhere, it is enough to know that you could if you like, not that you do :)
By guesommer at October 5, 2006 4:51 AM