6

We have a wiki which is used by over half our company. Generally it has been very positively received. However, there is a concern over security - not letting confidential information fall into the wrong hands (i.e. competitors).

The default answer is to create a complicated security matrix defining who can read what document (wiki page) based on who created it. Personally I think this mainly solves the wrong problem because it creates barriers within the company instead of a barrier to the external world. But some are concerned that people at a customer site might share information with a customer which then goes to the competitor.

The administration of such a matrix is a nightmare because (1) the matrix is based on department and not projects (this is a matrix organisation), and (2) because in a wiki all pages are by definition dynamic so what is confidential today might not be confidential tomorrow (but the history is always readable!).

Apart from the security matrix, we've considered restricting content on the wiki to non super secret stuff, but of course that needs to be monitored.

Another solution (the current) is to monitor views and report anything suspicious (e.g. one person at a customer site having 2000 views in two days was reported). Again - this is not ideal because this does not directly imply a wrong motive.

Does anyone have a better solution? How can a company wide wiki be made secure and yet keep its low threshold USP?

BTW we use MediaWiki with Lockdown to exclude some administrative staff.

Reinstate Monica - Goodbye SE
  • 442
  • 5
  • 18

6 Answers6

8

One obvious point, or so it seems to me, is if you want something that's very tightly locked down then are you sure you actually want a Wiki. Isn't a large part of the ethos of a wiki that it's as open as possible? Once you've moved far enough away from the original purpose then doesn't it sooner or later become a better idea to try a different tool that has a closer fit to start with rather than straining the one you have totally out of shape?

Rob Moir
  • 31,664
  • 6
  • 58
  • 86
  • 2
    +1 for misapplication of technology. It's important you define what information is going to live in the/which wiki _before_ you start letting everyone edit. If you're keeping [somewhat] sensitive material in you need to break out that material into separate [a] wiki(s). – jscott Jun 15 '10 at 15:30
  • 1
    Excellent comment - using technological means to solve a social problem should be an immediate red flag of "what exactly are we trying to achieve again?". – Andrew Jun 15 '10 at 23:12
  • Thanks for the answers. I partially agree: ideally wikis should be "as open as possible". But within companies that is not always desired by security staff. There is commercial wiki software available (e.g. Confluence) to break wikis up into spaces. Personally I do not think this is desirable (see security matrix issue in original question). But I think it is a bit too simplistic to say that we shouldn't use a wiki in this case: wikis have other advantages of course (e.g. low edit threshold). The problems with separate wikis are: extra maintenance and duplication of information. – Reinstate Monica - Goodbye SE Jun 16 '10 at 14:07
  • I see what you're saying Mark. I appreciate you're in an awkward position. I'm just saying that there comes a point where you're straining a particular product all out of shape and would be happier choosing a product that fits your needs better to start. Additionally, "there are seldom good technological solutions to behavioural problems" is a saying I heard a long time ago that's still true today. If you have a problem with *people* leaking information then a solution that fixes *the computers* isn't going to make people happy. – Rob Moir Jun 16 '10 at 14:24
  • Agreed - although the technology can limit the possibility of a leak occurring and the impact if it does. That's why we monitor page views and publicise that fact - so that if someone were to leak information we'd have a pretty good idea of who that was. So far it looks like there is no silver bullet solution... – Reinstate Monica - Goodbye SE Jun 17 '10 at 10:14
4

We use company-wide wiki. This is how we do it:

  1. We use LDAP for storage for username and kerberos for authentication. MediaWiki has extension for using LDAP.

  2. We locked down that IP address such that our offices in Canada and US has access to wiki, done on our firewall. Even though the wiki is on external IP address, the firewall only allows access from within offices and whomever vpn-ed in.

  3. In LocalSettings.php (wiki conf file), we made it such that you can't read pages unless you are logged in. However, we did allow some pages accessible without actually logging in.

  4. We also use 'accesscontrol' extension for restrict pages. We have some pages that only sysadmin team can see, so, if someone from NOC try to see that page, they will get 'access denied' page. This is all handled with AccessControl extension.

Before you start, you need to know how users are managed in your office. We have everything in LDAP. We groups like sysadmin, developers, NOC etc etc and users are assigned to those groups. So, it is easier to give or take away access based on the group they are in.

-F

Nikolas Sakic
  • 492
  • 2
  • 8
  • Thanks Nikolas. 1. Yes, we also use LDAP. 2. It is only accessible via our employees (on intranet) but since some sit at customer sites this is not considered secure enough (competitors are also present). 3. We've got this as well. 4. We've got Lockdown for almost all pages - so that sounds similar. How do you do that - do you essentially have only two groups (admins + the rest) or various groups? We can grant / remove access to the whole wiki based on LDAP but not fine grained within the wiki. My question is (partly): is that desirable? – Reinstate Monica - Goodbye SE Jun 16 '10 at 14:21
  • 1
    We have 20+ groups. Initially, we did lockdown all pages which turned out to be a bad idea. We should only lockdown pages with sensitive data. Who cares if our on-call schedule is visible to other teams. That info should be public data anyway. So, we went through and unlocked all pages, so, anyone who wishes to see the pages has to be logged in. Access to whole wiki is give based on ldap group. Check out: http://www.mediawiki.org/wiki/Extension:Group_Based_Access_Control – Nikolas Sakic Jun 16 '10 at 21:38
  • So do you now lock down any pages? If so, how do you organise that - page by page or e.g. via a namespace? I know SimpleSecurity can help here. – Reinstate Monica - Goodbye SE Jun 17 '10 at 10:21
  • 1
    We do it page-by-page, we found that that works best for us. Like marketing depratment has restricted such that it is not even read-only. However, we have many pages read-only for other teams. Pages that have installation instructions or documentation- those pages are read-only for entire office except our team 'sysadmin'. We do all that using accesscontrol tags. – Nikolas Sakic Jun 17 '10 at 15:15
  • Hi Niklas - even though your answers (including comments) did not get the most votes they are the best for me because they contain real actions I can put into practice. Hence - this is my accepted answer. That page by page is a good idea. Can you tell me why you selected AccessControl instead of SimpleSecurity? And why do you have Read Only pages - doesn't that destroy the whole wiki idea and imply a lack of trust? People cannot even correct typos then. We handle this by requesting people not to edit certain pages (except for typos) which works well. – Reinstate Monica - Goodbye SE Jun 18 '10 at 09:19
  • 1
    Thanks Mark. We could have used SimpleSecurity as well. For us, however, we tested with AccessControl first and it was more than what we needed at the time. So, we went with it. We make certain pages read-only b/c no other team has any business updating those pages. For example, we have SOP for managing zone files for our domain. If you are a member of QA, you can look at how we do it, but you have no business editing that page. EVen if there is a typo. The content is checked,reviewed, and approved anyway b4 getting posted on the wiki. – Nikolas Sakic Jun 18 '10 at 13:59
  • 1
    Message me if you are setting up wiki on your staging enivornment, I can give you conf settings from my setup. – Nikolas Sakic Jun 18 '10 at 14:00
  • I'd like to see that, Nikolas, thanks. How can we get in contact off this page (to avoid irritating other users)? Or do you want to post your settings here? – Reinstate Monica - Goodbye SE Jun 21 '10 at 10:34
  • 1
    I can post here if you want, not sure if we can send msgs on this site. I can post settings here if you like. – Nikolas Sakic Jun 23 '10 at 02:17
  • Great! Now I think about it probably more people will benefit from it. – Reinstate Monica - Goodbye SE Jun 24 '10 at 11:41
  • Nikolas - if you're still reading this I'd appreciate those settings. – Reinstate Monica - Goodbye SE Jun 29 '10 at 09:58
3

You need to make it clear what is appropriate and what isn't appropriate for posting if you're going to use something like MediaWiki. That's about all of the security that you're going to get.

If your business requirements mean that you need complex ACLs, you need to look at a solution designed for it. SharePoint, Traction, Alfresco and SocialText are all products that can do that.

It all depends on the organization... don't make policy based on the product that you decided to use for a random reason.

duffbeer703
  • 20,077
  • 4
  • 30
  • 39
  • Thanks duffbeer703 - this is the "restricting content" solution I mentioned. The policy is already "out there" (though it is fuzzy). The product was not chosen at random: MediaWiki was selected because it is: free, well-tested, continuously under development (being improved) and recognisable (thanks to Wikipedia). – Reinstate Monica - Goodbye SE Jun 16 '10 at 14:10
  • 1
    I've been in the same place, it's frustrating. I said "random reason" because based on the security/control requirements, Wikipedia is unlikely to be a good candidate. If you really feel strong about the wiki concept and want to push it forward, you need an executive champion who can tell the command and control advocates to tow the line. Organizations with obvious security requirements like Department of State and the CIA are using modded MediaWiki, so it can be done, and you can be sure that those implementations were top-down decisions. – duffbeer703 Jun 16 '10 at 16:45
  • Hey - that's very interesting! I did not know about Intellipedia (but found it now on Wikipedia) - wow! This could provide key information and strong arguments - thanks. – Reinstate Monica - Goodbye SE Jun 17 '10 at 10:18
1

I had the exact same problem, and came to the same conclusion as Robert. Upon researching further, there are wikis that do have complex ACLs, giving you the benefit of both worlds. But in this case, its probably best that you keep your wiki, but have another tool for all the "secure" items.

We tried Mediawiki because of the idea that Wikipedia uses it, unfortunately maintaining it is harder than we expected, especially as we implemented more and more extensions. In the end, we wished that we used a different wiki engine that might not have been as ambitious, but with an easier maintenance cycle (and built in ACLs - although that goes against the wiki ethos).

rumz
  • 215
  • 1
  • 4
  • 13
  • Thanks roomy. I assume ACL means access control list? I'm not convinced this is the "best of both worlds" because of the reasons I mentioned in the original question. We're happy with MediaWiki and like all the free extensions and the fact that it can be relatively easily configured. Have you considered migrating to a new product? – Reinstate Monica - Goodbye SE Jun 16 '10 at 14:13
0

If you perceive the problem to be a legitimate concern, then your focus should lie at the source, across any medium such as email, Facebook, etc. The problem domain is classified as Data Loss Prevention/Protection (DLP) and several security vendors provide solutions, including an open source project called OpenDLP.

WuckaChucka
  • 375
  • 3
  • 8
  • 23
  • You're saying that we should look more broadly than just wiki but at all applications, right? – Reinstate Monica - Goodbye SE Jun 16 '10 at 14:15
  • Correct. You want to guard against data loss in transit, but in order to do that, you need to know where your sensitive data lies at rest. – WuckaChucka Jun 16 '10 at 17:21
  • Yes, we have that now. The older systems (intranet, document management systems) do have various levels of security. So we use the wiki in some cases as a kind of portal to help find (and collate links to) other sources of information. So - many people can read the wiki (low security stuff) which links to content which not everyone can read. – Reinstate Monica - Goodbye SE Jun 17 '10 at 10:20
0

You said:

there is a concern over security - not letting confidential information fall into the wrong hands

You're asking the wrong question. You are not trying to secure MediaWiki - to quote the MediaWiki page on security issues,

MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible.

What you really need is good company-wide policy about what is confidential, what constitutes a breach, how you manage confidential information, etc. This is a management issue. "Use (more) technology" is the wrong way to approach this until you have good policy and management.

Andrew
  • 7,772
  • 3
  • 34
  • 43