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.

Improve this question
0

6 Answers 6

Reset to default
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

Improve this answer
11
  • 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: mediawiki.org/wiki/Extension:Group_Based_Access_Control
    – Nikolas Sakic
    Jun 16, 2010 at 21:38
  • 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, 2010 at 15:15
  • 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, 2010 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, 2010 at 14:00
  • 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, 2010 at 2:17
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?

Improve this answer
5
  • 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, 2010 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, 2010 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, 2010 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, 2010 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, 2010 at 10:14
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.

Improve this answer
3
  • 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, 2010 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, 2010 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, 2010 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).

Improve this answer
1
  • 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, 2010 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.

Improve this answer
3
  • You're saying that we should look more broadly than just wiki but at all applications, right?
    – Reinstate Monica - Goodbye SE
    Jun 16, 2010 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, 2010 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, 2010 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.

Improve this answer
3
  • Hi Andrew - I'm puzzled that you say we are not trying to secure MediaWiki. But I think you are right that we need clear guidelines as to what constitutes a security breach.
    – Reinstate Monica - Goodbye SE
    Jun 16, 2010 at 14:18
  • It sounded more polite than "you're doing it wrong"... :)
    – Andrew
    Jun 16, 2010 at 23:58
  • So it sounds like you're saying first define what goes where (and related security issues) and then choose your tools. Good in theory. In practice these discussions can take years... =:-)
    – Reinstate Monica - Goodbye SE
    Jun 17, 2010 at 10:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .