Issue with Limited Access User Being Logged Out on OpenCTI

[Security-Team12]

Description

Hello,

I’m experiencing an issue with user access on the OpenCTI platform. I need to create a user who has no access to any data except their own dashboards. I want the user to be authenticated, so public dashboards are not a viable option.

To achieve this, I created a group and a role as shown in the attached image, giving the user access only to dashboards. When the user logs in, everything seems to be correct, and only the dashboard section is accessible. However, when they try to open a dashboard, the user is logged out after a few seconds. Upon logging in again, the user is immediately logged out once more.

This issue only resolves when I grant the user higher access levels, which allow them to view all organizational data (excluding the TLPs). However, I do not want this user to see any incidents unrelated to their specific dashboards. The only data they should be able to view is what’s within their own dashboard. They should not have visibility into any other incidents.

Could you please assist me with this issue? Is this a bug?

Thank you in advance for your help.

Best regards,

Environment

1. OS (where OpenCTI server runs): { Ubuntu 20.04 }
2. OpenCTI version: { OpenCTI 6.2.6 }
3. OpenCTI client: Docker

Reproducible Steps

Steps to create the smallest reproducible scenario: 1-Created a new group and role with restricted access, limited only to viewing the dashboards section. 2-Assigned the newly created group and role to the desired user. 3-Granted access to the specific dashboard for the desired user. 4-Logged in with the relevant user. 5-Viewed the dashboards. 6-The user was logged out a few seconds after opening a dashboard. 7-Logged in again with the same user. 8-The user was logged out again after a few seconds.

What the fix is about:

From Filigran product team: being logged out is a bug. User should nto be logged out, even though access knowledge is not selected as a capability.

Screenshots

[nino-filigran]

@Security-Team12 I have a few comments/questions:

• Indeed, dashboard should not close, this is not normal.
• however, if you do not give your users the right "access knowledge", your users will be able to create/update/read widgets, but they would be empty, since they rely on the right of accessing knowledge to view the data.

The use case you're trying to achieve, aka only providing access to a subset of data only in dashboard, is not how the platform is supposed to be used, since you need to access the knowledge to view data. But luckily, we have a solution for you: you need to play with the markings:

• by creating new markings, any entity that would have for instance TLP + custom marking won't be accessible for users who do not have the 2 markings. Therefore, you can create combinations of marking to only allow access to a subset of data, and provide the access knowledge right.

I have a few questions though:

• why do you need the user to be authenticated, if it's only to view data (since in dashboards, you cannot modify the data)?
• what is the exact use case you aim to answer with such setup?

[Security-Team12]

Hi Dear @nino-filigran

Thank you for your previous response. The way we use the OpenCTI tool is somewhat complex, and we need your assistance with a specific use case.

We receive incidents from multiple organizations and aim to create a separate dashboard for each organization. These dashboards should allow the organizations to view specific observables, such as shared top IP addresses in the incidents they have submitted. However, we want to ensure that they cannot identify which organizations have submitted these incidents. Additionally, we need to restrict them from viewing each other's incidents on the platform. We only want them to see the relevant observables on their widgets and some statistical information about all of incidents from all organizations.

To facilitate this, we have labeled each incident and observable (like IP addresses) with the name of the organization that submitted it, intending to create distinct widgets for each organization. While TLP markings on incidents could partially address our concerns, the issue persists because the organization labels on each observable remain visible. In some cases, multiple organizations might be labeled on the same observable, such as an IP address, and we are unable to hide these labeles from the organizations.

Moreover, we have encountered an issue with public dashboards. If we create public dashboards for, say, 10 different organizations, there is a risk that one organization might perform crawling and gain access to the dashboards of other organizations, especially since they have access to the system through the firewall. Therefore, authentication is crucial for us.

Could you please advise on how we can manage these issues? Specifically, we need guidance on ensuring data privacy between organizations and securing dashboards against unauthorized access.

Thank you for your assistance.

[nino-filigran]

Hi @Security-Team12 to help you, I'll first ask a couple a question to understand better your use case and current setup. If it's easier and more convenient for you, we can also talk on slack (Nino Rowlands):

We receive incidents from multiple organizations

How do you receive these incidents? Do you have a main platform connected to other platform? If so, how are data transmited to you? If not, how do you get this data: custom connector, taxi collection, file import...?

These dashboards should allow the organizations to view specific observables, such as shared top IP addresses in the incidents they have submitted.

If I understand, you have X orgs submitting various IPs. And in the dashboard you create, some of the IPs that have not been submitted by an org can be seen by this org. However, you don't want to disclose who provided this IP. Am I right?

To facilitate this, we have labeled each incident and observable (like IP addresses) with the name of the organization that submitted it

Are you using the Entreprise edition and the Organisation segregation? This feature aims to solve this exact use case.

there is a risk that one organization might perform crawling and gain access to the dashboards of other organizations, especially since they have access to the system through the firewall

I'm interested in hearing more about this. The solution is in theory secure enough and this should not happen. Therefore, if you have security concerns with more details, I'm keen to hear them.

[iman006]

@nino-filigran Thanks for your response and attention to detail.

How do you receive these incidents? Do you have a main platform connected to other platform? If so, how are data transmited to you? If not, how do you get this data: custom connector, taxi collection, file import...?

We receive incidents in an internal system within our organization. Afterward, we export the data as a CSV file and use the CSV Mapper feature to import the necessary information into OpenCTI, including incidents, IP addresses, and labels indicating the organization that submitted each incident. Each object, whether an incident or an IP, is tagged with the corresponding organization's label so we can manage and create dashboards for different organizations.

In the past, we accomplished this using TheHive system and its corresponding connector.

If I understand, you have X orgs submitting various IPs. And in the dashboard you create, some of the IPs that have not been submitted by an org can be seen by this org. However, you don't want to disclose who provided this IP. Am I right?

Yes, that’s correct. We want each organization to view a range of statistical and aggregated information about all incidents, IPs, malware, etc., without seeing the names of the organizations that provided this information(The name of each organization is included on the labels attached to each entity and is also recorded in the incident name.) . Additionally, each organization should have access to more detailed and confidential dashboards containing the incidents and information they specifically submitted to us.

To achieve this, we have created 10 different dashboards. While some general information is shared across all of them, each dashboard contains more sensitive data that is specific to the organization it is designed for. We have already created the dashboards, but we are encountering issues with sharing them.

Are you using the Entreprise edition and the Organisation segregation? This feature aims to solve this exact use case.

Currently, we are using the Community Edition, and I have limited knowledge of the Organization Segregation feature. If resolving this issue involves this feature, I would appreciate it if you could provide more details about how it works.

I'm interested in hearing more about this. The solution is in theory secure enough and this should not happen. Therefore, if you have security concerns with more details, I'm keen to hear them.

In situations where we want to provide public dashboards to the organizations under our supervision, we need to grant them access to the OpenCTI IP address. This allows them to open and use the URL associated with their respective dashboards. Imagine we have created ten dashboards for ten different organizations, each with its own unique URL for accessing the dashboard. The information within each dashboard is meant for one specific organization, and the other organizations should not be able to view it. All of these dashboards are hosted on a single OpenCTI server with the IP address 80.80.80.80.

For each organization to access their respective dashboard, they need to be granted access to the IP address 80.80.80.80, along with the specific URL for their dashboard. However, there is a concern: if one organization decides to use web crawlers to discover other URLs on the OpenCTI server, they might be able to find and access the dashboards of other organizations. This is possible because all organizations have access to the same IP address, and all the URLs are hosted on the same server.

While this might not be an issue if the dashboards contain only non-confidential information, it becomes a serious problem when sensitive data is involved. In this scenario, it seems essential to implement authentication (AUTH) to ensure that each organization can only access its own dashboard and cannot discover or access the dashboards of other organizations.

This is our main issue with public dashboards. It would be ideal if we could create a separate user for each organization and grant them access to view only their specific dashboard, without allowing them to see all the knowledge related to the incidents.

While this problem can be partially addressed with TLP (Traffic Light Protocol) markings, it comes with the drawback that the organizations would not be able to view the general and aggregated statistical information that we have compiled from all organizations.

[nino-filigran]

@Security-Team12 & @iman006 Here's a blogpost about the feautre, that explains in more details what this feature is about: https://blog.filigran.io/opencti-organizations-segregation-and-sharing-b7d4ba3f9398

In short, it serves the use case of having a single platform that is accessed by multiple orgs. You can define what's the "main platform organization" (let's say entity A). Then, once you import your data through CSV, you could then share each of the entities individually to each organizations, using the sharing capability. User belongs to these orgs will then be able to access the entities shared with them.

This way, the orgs could access the platform and only view the entities that you have decided to share with them. As a result, you would achieve your use case.

Then when it comes to dashboards, you could have a dashboard per org as usual, that would contain all your confidential data for each org, and a generic one, that you would share publicly, which disclose overall statistcs across your platforms. This way, your security issue is also avoided, since data not shared with them won't simply be accessible.

The "drawback" of organization sharing is indeed that if an entity is not shared with a speicfic org, the org (and its users) won't have access to it at all. As a result, providing statistics about the overall platform requires to use this trick to display all information.

Thanks for sharing all this, hope my answer helps you out.

[nino-filigran]

Given this feature relies on our Entreprise Edition which requires to pay a license fee, if you need more information about how to tackle your exact use case, I invite you to book a demo through this form: https://filigran.io/book-a-demo/

You would be able to understand better this functionnality, since sometimes words do not suffice and viewing the solution helps a lot to understand better the use case. Of course, I'm happy to still provide you guidance here if I can help you :)

[Security-Team12]

@nino-filigran Thank you for your helpful guidance. I have another issue with the public dashboards. When I share a dashboard publicly and then open the URL for that dashboard, all my widgets are displayed correctly and fully populated with data, except for the widgets of type "area" and "line." These widgets appear empty in the public dashboard. I’ve attached a sample image of these widgets for your reference. I would appreciate it if you could assist me with this issue as well. Thank you. this is my area widget : this is how it appears on the public dashboard: and this is my widget query and setup:

[nino-filigran]

@Security-Team12 Just to make sure: did you ensure:

• that you share the correct markings when creating your public dashboard ?
• that your marking are shareable in security/groups?

If you do not have issue for others, I would say so, but I want first to verify this.

[iman006]

@nino-filigran Yes, I am confident that I have granted the necessary access to the TLP, and the data is sharable. This is because the same data is populated in another widget with a different type for example radar widget, without any issues.

[nino-filigran]

@iman006 Hmm, I'm unable to reproduce it, it works well for me, I see both widgets correctly, using the dashboard & share dashboard of our public demo environment.

Does the problem happens if you open in a private navigation window?

[Security-Team12]

@nino-filigran Yes, I tested this public dashboard in different modes, but unfortunately, all the widgets were populated except for this one. I am using version 6.2.6, so maybe this issue has been resolved in later versions. 🤔

[Security-Team12]

@nino-filigran Also, I encountered something strange: when I export the same widget of the "area" type from the system and then import it into another dashboard that has no widgets, and create a public dashboard with the same conditions and TLP, the information in this widget gets populated and displayed correctly in the public dashboard. It’s exactly the same widget with the same settings, just imported into a new dashboard. But the problem is that this information, under the same conditions, is not displayed in my Main public dashboard.

[nino-filigran]

Ok so to sum up, beside the issue listed in this ticket, you do have 2 additionnal issues:

• With Line & area widget, when created in a context of private dashboard, everything is well displayed but as soon as you share them, you do not see any data anymore.
• With area widget, when you create a widget in a dash, export, create a public dash, then you see the data properly but only in your public dashboard.

Can you try to make sure that you're on the latest version please? This would help us understand better the situation.

[Security-Team12]

@nino-filigran Yes, that’s correct. However, regarding the second issue you mentioned, I export the same area-type widget that I have on my main dashboard, which is not visible on the public dashboard, and then import it into another dashboard that is new. After that, I make the new public dashboard . In this case, the widget is visible on both the new dashboard and its public view, and the data is displayed correctly!. However, the same widget with the same specifications is not visible on the public view of the main dashboard(old) or on dashboards that I duplicated from the main dashboard and made public. This is a strange issue.

[nino-filigran]

Thanks for your detailed answer. I've raised this ticket internally anyway. Once a dev will take the ticket, you'll get an update and they will start working, having the full context of what's happening :)

[Security-Team12]

@nino-filigran Thanks a lot