A recent audit at a company I work with uncovered an unauthorised website set up to aid collaboration on a project involving two other companies. A new recruit, keen to impress and not aware of the company’s security and acceptable usage policies on social networking, created a site to enable project members to quickly share and update information. It was impressive and was helping speed up progress on the project. However, the site had to be temporarily disabled while appropriate security controls were put in place.
Even basic collaboration software is extremely complex and, sadly, when it comes to security, doesn't have a great track record.
Collaboration tools such as wikis, video conferencing, instant messaging, shared document workspaces and even Facebook and Twitter all allow for the easy exchange of information among collaborating parties. But, even basic collaboration software is extremely complex and, sadly, when it comes to security, doesn't have a great track record and can contain exploitable vulnerabilities that could expose data and users to attack. Default installations often have unnecessary services turned on by default, and, as new features are always being added, it can be difficult to assess how secure or vulnerable the versions being used really are.
Before setting up collaboration software for use with third parties such as clients, suppliers or a group of organisations involved in a project, it should be decided which organisation will be the designated owner, responsible for implementation and day-to-day operations, even if all the services are outsourced to a specialist provider. Appointing an owner of the project means somebody has authority and control over users and how the collaboration tools are used.
Participating organisations then need to agree on and create a Web security policy covering user access, privileges and acceptable usage. Each organisation may have different methods of managing user identities and authenticating them, and these need to be reviewed to ensure they are appropriate and acceptable to everyone. Widely different security cultures and levels of security awareness in each organisation can also lead to problems, so it's important to control not only who, but also how users can connect to the collaboration applications.
Often called a Code of Connection, this policy lays out a baseline set of controls to be implemented on all devices that will need to connect to the collaboration software. This should include controls such as patching, antivirus and malware policies, and firewall and content checking requirements; basically, this is a statement of the level of security and system hardening that will be required before a device is allowed to connect. It should also cover whether mobile access is allowed, and, if so, whether it must be via a corporate VPN.
How stringent this code of connection is depends on the level of assurance required between the organisations involved. It may be necessary on very sensitive projects to isolate systems used for collaboration, both physically and logically. Sometimes creating a dedicated network with carefully controlled access can be an easier and safer option than trying to use an existing network.
Depending on the sensitivity of the data involved, communications should be encrypted, as should data at rest. Rules should be agreed to and everyone should understand what may and may not be discussed and how information may be exchanged. This may require some form of labelling scheme to record the information owner, state to which collaborating partners the information can be released, and to identify any proprietary information or intellectual property rights.
These and other general acceptable-usage rules can be posted and highlighted on the collaboration tool itself, along with the sanctions users face if they contravene them. You can also include information about how users’ actions are monitored and the purposes to which any personal information gathered and stored is put. To help prevent users from inadvertently or accidentally sharing classified information or causing other security incidents, they should receive training on how to use the collaboration tools and be made aware of the acceptable usage rules and their responsibilities. Depending on the scale and budget of the project, it may be a good idea to provide some form of help desk or support service to this end.
The project should certainly have an information security incident management plan that encompasses every organisation, covering reporting lines, appropriate points of contact and areas of responsibility. And, of course, in order to investigate any incidents, there needs to be an audit trail, so audit and system monitoring processes must also be put in place and be acceptable to everyone involved. In the event of a data breach or security incident, many of the recommendations I've outlined will seem obvious in hindsight, but without them in place from the beginning, any incidents can easily get worse with everyone blaming the others, probably ruining a working relationship in the process.
In most collaboration ventures, the main threats will come from the outside, but it can happen that a collaborating organisation is also a competitor in other areas with one or more of the other organisations involved. For example, two consulting firms may team up to deliver on a project too large for them to handle individually, or requiring skills neither can satisfy on its own. Be aware that cooperative relationships like these can be short lived, though, and collaboration tools, Web connected as they are, present a potential opportunity for one organisation to introduce a Trojan or other malicious software into a competitor’s network to be used at a later date.
The ease with which sophisticated yet potentially dangerous collaborative programs can be set up means employee awareness about the policies that govern their use is essential. Nobody wants to stifle ingenuity and enthusiasm, but security has an important role to play when it comes to sharing information.
About the author:
Michael Cobb, CISSP-ISSAP, CLAS is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.Cobb serves as SearchSecurity.com’s contributing expert for application and platform security topics, and has been a featured guest instructor for several of SearchSecurity.com’s Security School lessons.
This was first published in August 2011