4 Ways To Measure Secure Data Collaboration

One of the most important things you can do as a leader when trying to implement change is to measure the impact of that change through key performance indicators (KPI). While organizations have spent years tuning financial KPIs and even security KPIs (e.g., risk), not much discussion has been had about KPIs to measure Secure Data Collaboration. We are proposing four KPIs that would allow organizations to understand the effectiveness and adoption of Secure Data Collaboration.

One of the biggest challenges with KPIs is that there is no shortage of data. We were recently reminded of this by an information security and collaboration leader who often must report to executives that:

“the KPI should show me what we want users to be doing more of and the
kind of behavior we are trying to change.

With that guidance in mind, these are the four KPIs that we propose to measure Secure Data Collaboration. 

 

KPI #1: Are we keeping sensitive information in our control?

% of Restricted data in our full control

The metric: Measures the percentage of files downloaded from a trusted file share (e.g. SharePoint) when shared externally, based on the data’s sensitivity.

With Secure Data Collaboration sitting at the center of security and collaboration, we believe it is essential that organizations understand whether they maintain control over their most sensitive information. While some organizations may want to block all downloads, that kind of control may not meet the needs of the business. We recommend having visibility on whether your most sensitive data (e.g., labeled as “Restricted”) stays in your control. This course of action allows organizations to meet the business need to share sensitive information with external parties.

 

KPI#2: Are our users using Microsoft 365 for external collaboration? 

External Collaboration Activity using M365

The metric: Measures the number of share creators as well as internal and external users actively collaborating within Microsoft 365.

 

Organizations are making significant investments in selecting Microsoft 365 (M365) as their platform for modern collaboration. However, some companies only use M365 internally while relying on point solutions for external file sharing, thereby missing out on the additional return of their M365 investment. Therefore, measuring how much your modern collaboration platform is being used to collaborate externally will provide great insight into how much return you are getting on your overall investment. If you are concerned about turning on external sharing or guest access in Microsoft 365, then feel free to give us a call, we can address the underlying security, privacy and compliance concerns 😊.

KPI #3: What type of data is being shared with external collaborators?

% of data shared externally by sensitivity

The metric: Measures files shared by the sensitivity-level with external recipients.

One of the challenges that information security often faces is reporting on a KPI that is easy to understand. We recommend a data classification strategy that be easily consumed by anyone (red = highly sensitive, orange more sensitive, yellow = somewhat sensitive, green = not sensitive). The goal of Secure Data Collaboration is to allow sensitive information to still be exchanged with external collaborators. As a result, this metric does not aim to sound a fire alarm if highly sensitive data is shared externally. Its purpose is to bring awareness to executives of potential exposure. Many industries have extremely tight rules around what type of data can be shared externally (e.g., Aerospace and Defense – ITAR); however, you still need to share data and collaborate with external parties. Better understanding the potential exposure allows companies to implement appropriate controls to enable Secure Data Collaboration policies.

 

KPI #4: What is our overall level of engagement with external parties? (customers, partners, suppliers) 

External Collaboration Engagement

The metric: Measures the type of file activity when information is shared. No file activity by the user would represent low engagement, file views by the user would be classified as a medium level of engagement and file opens and uploads by the user would be deemed as a higher level of engagement. 

Implementing a KPI dashboard will generate reams of data about the file-sharing activities of your customers. Analyzing this data will allow you to gain better insights into whether your customers are actively engaged with your organization and their potential revenue.

Bringing it all together

 

We would love to hear your feedback about the KPIs we are proposing in this Secure Data Collaboration dashboard. Please share any other ideas that you think could help effectively measure Secure Data Collaboration. If you would like more information on how to get access to these kinds of metrics, please feel free to reach out and we would be happy to walk you through it. Below is what a sample KPI dashboard could look like as a slide to report back up to your executives.

Secure Data Collaboration Dashboard

What does riding a horse have to do with modern collaboration?

File Sharing Encryption

Recently we had a great debate at e-Share about file encryption and secure data collaboration. The discussion centered around a claim that if you are a modern collaborator, you do not need to encrypt shared files since links are used to access files stored in the cloud. 

How we came to a consensus was with an analogy about riding horses and driving cars.

Before the car was invented, people rode horses. Intelligent horseback riders would wear helmets or protective gear to ensure they would not get hurt if they fell off the horse. After the car was invented, people did not wear helmets while driving since the car’s frame would give them protection. Cars have become even safer than riding a horse over the past century, with the advent of seat belts and airbags. Most people other than race car drivers do not wear helmets because it is redundant.  

Traditional file sharing and content collaboration is like riding a horse. The sharing of data is built around an on-premises file transfer solution. Using encryption (putting a helmet on) makes sense as the data (the horseback rider) is exposed and needs protection as the data leaves the premises. Modern collaboration is like driving a car; the file is already and always stored in a trusted container (e.g., SharePoint Online), and adding encryption (wearing a helmet) is redundant. The critical thing to focus on is ensuring the correct privileges are established to access the information (the keys to access the locks to get in and start the car).

 

The other great thing about modern cars is their navigation system. They can track where you are always going. The same is true with modern collaboration. Link-based sharing allows you to ensure your data can be audited and always tracked at the time of access, not just at the time of sharing. This is a critical distinction. With secure links, the file is never downloaded by the recipient, and therefore you are not securing a file; you are controlling access through a least privilege model.  

Show the difference between modern and traditional sharing

But people still ride horses…

Yes, horses are still ridden for work, transportation, and leisure but cars have replaced horses as the most popular form of transportation. We see a similar evolution in organizations. While most of the business is shifting to modern collaboration that protects data with a Secure Data Collaboration strategy, some people still share and download files. We do not argue that applying encryption (putting on a helmet) is a bad idea in those instances.

 

Please let us know if you would like to learn more about how your company can implement a solution that allows secure data collaboration. You can find us down at the stables trying to convince the modern collaborator holdouts. Giddy-up! 

5 Lessons Learned Deploying Microsoft Information Protection (MIP) Labeling

Microsoft Information Protection

Like our customers, e-Share strives to leverage all the modern collaboration tools we have at our disposal. As a Microsoft customer eager to deploy MIP labeling, we have optimized the business value attained with current licensing and cost-justified our adoption journey for productivity tools as well as Microsoft Information Protection.

With this suite of Microsoft products, we want to use OneDrive, SharePoint, and Teams not just internally but also for external collaboration. As we looked to achieve our own Secure Data Collaboration goals, it became clear that we could benefit from the adoption of MIP labeling. As a team, e-Share has deep experience building and managing data loss prevention and data classification products. Naturally, with this kind of background, deploying our own labeling taxonomy should be a breeze – right?

After a few more meetings than we anticipated, we had defined a taxonomy that we could all agree on and met the requirements of our SOC 2 driven Information Classification Policy. Here is where our e-Share taxonomy landed using MIP labeling:

  1. Public:
    • This is information that is suited, and in many cases created, for public disclosure.
    • No control policies but requires business justification if a user selects this label.
  2. Confidential:
    • This is information that is related to everyday business activities, such as product and marketing documentation
    • This is our default label
    • All Confidential data must stay within e-Share’s control, which means e-mail attachments will be stripped (using e-Share’s Secure Mail Gateway) and placed into a trusted share on SharePoint
    • External users will not require a login to the trusted share
    • However, every action (open, edit, download, etc.) will be logged and be visible in our Microsoft Power BI analytics reports
  3. Restricted (includes all Confidential policies):
    • This is all customer custodial data and customer data
    • Login to the trusted share will be required from external users (OpenID, OTP)
    • Anything regulated found with auto-labeling would be tagged at this level
  4. Private (includes all Restricted policies):
    • This is information that only a minimal amount of people should have access to
    • Investor, financial, internal-only documents
    • Allow list (limited to 20-30 people/domains)
    • Headers and footers are applied

So, what did we learn deploying MIP labeling?

1) Always start with why – then talk about the labels.

With labeling, people tend to overly focus on the actual names of the labels, resulting in many hours/weeks/months/years of discussion. However, if you are not clear on the “why,” there will be an endless loop of frustration. In this case, the why is what controls do we want to have? At e-Share, since we use our product, the discussion focused on the kinds of access we will grant external recipients to our Trusted Shares based on the label. To accomplish this, you need to think hard about who you interact with the most daily and compartmentalize policies to those categories. This then leads to lesson number two.

 

2) Do not overcomplicate (KISS – Keep It Simple, Stupid)
As organizations start to think about their labels and classify the different groups and privileges, things can get complicated quickly. Therefore, the moment you feel discussions getting out of control, communicate the importance of simplification. Less is more. Strive to find the few things that can make a real difference.  If you try and build a label with sub-labels for every interaction that might exist, the taxonomy will become overburdened and useless. e-Share decided to stay very simple (which is hard) and stick to four labels with no sub-labels. It is essential to consider the level of maturity and readiness of your end-users regarding data protection. Giving users too many options will cause analysis/paralysis, diminishing the classification process.

3) Consider how this will impact sharing with external users.
Often labeling discussions get focused on data inventory and internal data flows, but perhaps more importantly, you should consider how these labels will impact external sharing. As you can see from the e-Share taxonomy, our data classification policy is more heavily focused on what this means for external users and their access to our data. Of course, it is vital that certain internal information is kept private (e.g., investor relations). So we accounted for that with a label that provides policy granularity at a user/domain level.

4) Focus on newly created data first, then data at rest and in motion.
Even as a small company, e-Share has a ton of unstructured data; however, we started our labeling journey with data that is newly created and deployed MIP to all users in the business first. From there, we used Microsoft Cloud App Security to apply document labels to existing files in OneDrive and SharePoint so that we can control access to any and all externally shared files based on label policies (e.g., Restricted files require a user login through OpenID).

5) Defaults can help when used correctly.
There is always a great debate around using default labels. If you are not careful, they can create complacency and confusion. For e-Share, as you can see, we opted to stay away from an Internal label and instead used Confidential as our default label. We have found that 90% of our data is Confidential, so let us not get in our employees’ way. However, if they downgrade to Public, we have a business justification workflow to ensure the downgrade is warranted and tracked.

Microsoft Information Protection labeling is something to consider for every company which uses Microsoft products and collaborates externally. If you want to talk more about labeling and even see a demo of our taxonomy in action, we would be happy to walk you through it. Please click here to contact us