Multi-Tenant Deployment

[bastianXY]

Hello,

First of all, thank you very much for the great connector. I am currently testing it for implementation in our environment.

Our environment is structured as follows:

• Each customer has a manager/manager cluster
• There is a centralized indexer cluster
• The central dashboard connects to the managers via the API to manage the different customers

The managers each write their events to their own index.
e.g. wazuh-alerts--xxx

Plan:
My plan would now be to place a separate connector for each customer to separate the data

Now my questions:
Can I search for index wildcard match. For example wazuh--- in the OS call.
Can I pass an organization in the ENV to which the systems are assigned
Is it possible to assign the systems to an organization (for clear separation)
How do I deal with the same entity/system names that are from a different organization?

Thank you for your answer!

Kind regards

Bastian

[misje]

Hei,

Always nice to see my work in use. I haven't tried Wazuh nor OpenCTI in multi-tenancy mode before, but by having individual connectors in use (and possibly some development), I see no reason for this to be problematic.

Can I search for index wildcard match. For example wazuh--- in the OS call.

Absolutely, the OpenSearch API allows wildcards in the index string, as does the index setting (WAZUH_OPENSEARCH_INDEX). It sounds like you would like to configure each of your connector to search for indices for your customer's manager.

Can I pass an organization in the ENV to which the systems are assigned

Yes, you can name each customer's organisation as a system with the setting WAZUH_SYSTEM_NAME. You may also give the customer a separate author using the setting WAZUH_AUTHOR_NAME.

Is it possible to assign the systems to an organization (for clear separation)

Not at the moment, but this sounds like a small enhancement. This would be one setting, the organisation (name) to which the Wazuh SIEM (WAZUH_SYSTEM_NAME) relates to, along with the necessary relationship? The only applicable relationship type appears to be "relates-to".

How do I deal with the same entity/system names that are from a different organization?

That is an excellent question. OpenCTI's deduplication rules are documented here, but they are not necessarily complete. For a system, you'll see from the way that OpenCTI generates unique IDs, the identity's name and class is used. Two systems with the same name will therefore be the same entity in OpenCTI. I'm not sure how to best approach this. This isn't necessarily just an issue in large, multi-tenancy deployments. Do you have any suggestions? I suppose that a simple workaround is providing a setting that prefixes the system name with something, like the organisation name, domain name etc.

[bastianXY]

Hello Andreas,

first of all, thank you very much for your answers, I really appreciate it!

On the topic: “How do I deal with the same entity/system names that are from a different organization”
At this point, I can only think of extending the system name.
So e.g. SYSTEMNAME@COMPANY_NAME, SYSTEMNAME@WAZUH_AUTHOR_NAME, ...

One more:
I am not a good programmer now, I work in IT security, networking, but I always struggle through when I need something.

Is there a place in your code where I can add code myself without it flying out again with the next update?
For your information:
I would like to extend the system so that I can also generate observables and, if necessary, indicators for certain events.
As an example, I would like to include incorrect authentications etc. Even if these are not available as observables/indicators, the country and the number can be evaluated and used to fill blocklists that our firewalls can then access.
...
I would also like to expand the creation of SYSTEMS. I would also like to create systems from syslog sources. For this I need the conditions that are necessary for the connector to create a system.
I would then create the required fields of the syslog sources via ingest pipeline.
...
I hope I'm not taking on too much, but I'd like to give it a try!

Wish you a nice day,

Bastian

[misje]

Is there a place in your code where I can add code myself without it flying out again with the next update?

This is a bit hard to answer, but what you would normally do (in git), is to branch off and do whatever changes you would like. When this project updates, you merge or rebase the changes upstream (i.e. my changes). If nothing conflicts, your changes will stay as they are. Whether they work really depends on the upstream changes (look at the changelog). I can't really point out a particular place in the code where changes are "safer" than other places. It depends on what you want to change.

For your information: I would like to extend the system so that I can also generate observables and, if necessary, indicators for certain events. As an example, I would like to include incorrect authentications etc. Even if these are not available as observables/indicators, the country and the number can be evaluated and used to fill blocklists that our firewalls can then access. ...

Can please provide a detailed example? I have problems understanding exactly what you want. This connector works by looking up indicators in Wazuh. Are you perhaps thinking of a reversed flow, where an alert in Wazuh should create an indicator?

If so, that would fall out of scope of this connector. It feels more at home in wazuh-opencti. That project hasn't changed much since I first created it, but I have many ideas after having worked on opencti-wazuh-connector. – Like creating observables, sightings and incidents, much like this project. Indicators, too, would be possible, if a particular alert is a true indicator of compromise.

I would also like to expand the creation of SYSTEMS. I would also like to create systems from syslog sources. For this I need the conditions that are necessary for the connector to create a system. I would then create the required fields of the syslog sources via ingest pipeline. ... I hope I'm not taking on too much, but I'd like to give it a try!

I think this too belongs in "wazuh-opencti"?