Collaborative tools are any tool that is utilized to facilitate a collaborative work between multiple individuals. This can include physical media like a whiteboard or digital applications like Google docs. At this point digital Collaborative tools are pretty commonly used for many business processes. Most people at one time or another have been asked to work with colleagues on shared documents or code. There are a wide range of digital collaborative tools for almost every aspect of work Google Docs allows document sharing and collaboration, Bitbucket facilitates Collaborative code creation, Stack Exchange allows us to gather and share knowledge across the web.
While digital collaborative tools have massively increase productivity and made collaboration much easier across large distances. Digital collaborative tools also expose two broader security concerns in regard to access. Who has access to this tool? How sensitive is the data I’m working with? These are the most important questions you should ask yourself before using any collaborative tools.
For instance is it appropriate to post code to a Collaborative tool to solicit support? Let’s start with the first important question, who has access? Is this tool public, client facing or HCM internal? Second lets ask, how sensitive is the data? Does it contain IPs, Passwords, Personal or Company identifiable data? You want to make sure that by putting this data in a specific tool you aren’t exposing data to someone that wouldn’t or should have access.
It can sometimes be helpful to breakdown tools into these three categories public, client, and internal tools to assess if they are appropriate for the data. For example let’s say your code contains IDG source code its pretty reasonable that you can share that code on HCM’s Internal Bitbucket but you most likely wouldn’t put that code on a client code repository and you certainly wouldn’t post it to a public forum. Now keep in mind while these three categories are a useful shorthand it is still important to consider access within the tool itself as well. For example let's say you are using a client forum that is available to all users with that company, is it appropriate to post your code there? Likely no as that would give broad access to users that have no business accessing your code a better alternative would be to post the code to a private forum for your specific working group with that clients environment or to limit the access to your forum post only to people in your working group.
While restricting access is an effective way to keep data safe, when using collaborative tools, there are use cases where you need to solicit the public or third parties for help and input. This is where data sanitization comes into play. You want to strip away all specific data and keep only data that is necessary for the purpose. One example may be sharing a past Clients architecture specification with a prospective Client. In this example you would remove anything specific to that client such as Client’s name or acronyms, IP addresses, and host names. Another example is posting code to a public forum like oracle support forums. In this example you only want to post a snippet of the code rather than the full code file. Additionally you want to remove any implementation specific code this will further reduce exposure of data with the added benefit of making your code easier to understand. Finally, you want to remove any identifiable data like Client’s name or acronyms, IPs, and host names. Once you have sanitized your data appropriately for the audience you intend to share your all set to post or share the data.
Collaborative tools are so pervasive within the workplace is often easy to get very comfortable and post or share things without giving it a second thought. However, data protection is an important task that is everyone’s responsibility and can have significant impact when done without careful consideration. So before hitting share, be sure to consider these two important questions, who has access? How sensitive is the data?