Embedded analytics are third-party solution integrated into another company’s software platform to deliver customer-facing analytics. They allow the end-users of the software to gain access and visualize the information they require quickly and easily. Often, these tools are white-labeled, which means they can be used on a company’s platform without consumers knowing that it’s a third-party analytics tool.

Why is Security Essential for Embedded Analytics?

When you are embedding another company’s platform, do not underestimate the importance of high-quality security. Following and ensuring proper security measures are in place for an embedded BI solution is more important than with an internal business intelligence tool, because of the nature of how the product is used and because it is customer-facing.

For an internal facing tool, if a mistake is made, the people impacted are the employees of the company.  There tend to be fewer issues and concerns if internal tools have security mistakes since coworkers are generally aligned on the same mission.

In an external facing platform, however, the repercussions are quite different.  If business-impacting, mission-critical data is leaked, who is affected?  This would be your customers and this can be detrimental to your customers’ businesses and your relationship with your customers.

Let’s look at a hypothetical example.  Let’s say Stripe uses embedded analytics to show revenue for companies using its platform.  If two competitors, Nike and Adidas, are both using stripe and happen to find a way to see each other's revenue statistics, it would be a major issue.  If Nike knew how much Adidas was doing in sales and was able to drill down into various questions, they could have an unfair advantage given access to information they shouldn’t have.  Nike and other customers would have major concerns over Stripe and their product.

Embedded BI Security Requirements

One of the most important elements of BI security requirements is strict, yet rich internal access control requirements. For example, someone who is on the customer success team shouldn’t be able to view the finance team’s dashboards if they don’t have the permissions to view them. There needs to be a system (like role-based access control) that allows for the definition and separation of who does and does not have the authority to see various resources.

When it comes to external-facing analytics, the end user who is viewing the embedded analytics should only be able to see data they have access to. Following proper BI security requirements and protocols would mean there is no ability to exfiltrate data, and there is no way customers can trivially hack into other customer accounts or views. Additionally, there is no way to view a dashboard they aren’t allowed to see, even if it is for their specific provisioned workspace.

Of course, getting this right can be tricky. Let’s use the Explo embed snippet below as an example.

‎ 

In the above example, you will notice that two key components will let Explo know what dashboard to load and who it is accessing it.

·         DASHBOARD_EMBED_ID

o   This needs to be a UUID that is not guessable, otherwise, adversaries can just guess what other dashboards might exist on the frontend and be able to see them

o   So, ids need to look like QRA3vqN1Ed and not finance_dashboard_1.  Otherwise, end users can guess other ids like finance_dashboard_2 or customer_dashboard_1

·         CUSTOMER_TOKEN

o   This needs to be a unique token that is essentially a password (think SHA-256), otherwise, people can try to change their token from “customer-1” to “customer-2”, or literally from “nike” to “adidas”, or if it’s a monotonically increasing number “814” to “815”.

Security from Explo

When you are choosing a third party for embedded analytics, you need to know they follow BI security requirements. Explo has a fantastic reputation and provides great security. Check it out and get a demo to see how it can work for you.