IBM Security QRadar

Authors

• Bankole Adams
• Holly Wright
• Greg Davis

Overview

Domains and multi-tenancy were introduced into QRadar to enable customers to have stricter and more configurable control over the accessing, sharing and correlation of network data within their organization.

The article explains domains and multi-tenancy in QRadar, from basic to advanced concepts, offering some practical examples along the way. We will examine where and how domains and tenants are implemented in QRadar. Let us start by looking at some definitions.

Domain

A domain is a segment of a network that is defined by a boundary, and which contains one or more network entities. In QRadar, we use network entities, such as event collectors, log sources and flow collectors to define domain boundaries. The following diagram shows some sample entities that could be encapsulated within a single domain.

Multi-tenancy

Multi-tenancy in computing allows different categories of users (tenants) to use the same instance of a software. Multi-tenancy enables separation of tenant artifacts and customization of tenant environments, while enforcing data protection and integrity for all tenants. In the following multi-tenancy diagram, domains are scoped to segments of the network. Typically, different network segments belong to different tenants. As such, domains are created and assigned to different tenants and grouped within a “tenant container”, which is created for each tenant. As a result, data generated by different tenants is dutifully recognized by QRadar and access is restricted to allow only users of the appropriate tenant. 

1          Introduction of Domains and Multi-tenancy into QRadar

Multi-tenancy was introduced into QRadar in two phases. Each phase on its own offered a comprehensive solution to particular customer issues.

Phase 1            IP Networks Overlapping (Domain isolation)

Let us consider an example where an organization has IP addresses overlapping across its different divisions. When analyzing network traffic in these environments, it becomes difficult to quickly identify the true origin of communications. Furthermore, QRadar features such as coalescing and de-duplication can result in the incorrect recombination of network records from different domains. QRadar solved these problems by enabling the association of network entities with named domains, using an IP address and domain combination rather than just the IP address, to indicate uniqueness.

Figure C.1 below shows an overlapping IP scenario. When events from log sources A and B are sent to the log analyzer, it is not immediately clear which division sent the event with an IP address of 192.168.2.1. The solution is shown in Figure C.2. The log sources are tagged (more on Tagging in Section 2) with named domains (Domain A and Domain B) and this mapping is visible to the log analyzer. The de-duplication and coalescing processes are now domain-aware and will only perform re-combinations within a given domain. After configuring domains, the security analyst in this scenario can identify exactly which division sent which record with IP address 192.168.2.1.

Figure C.1 - IP networks with overlapping addresses without domains configured

Often, small to medium sized organizations find that they only need to solve the overlapping IP problem and this can be achieved in QRadar by creating domains around network artifacts.

Phase 2            Supporting Multi-tenancy

In phase 2, QRadar took multi-tenancy to another level. Tenant containers were created to enable full separation of tenant data, including the encapsulated domains. Just as domains wrap around network entities, tenant containers wrap around domains (see Figure B above). In this scenario, you can view QRadar as a single monitoring house that receives data from compartmentalized networks according to their tenancy. Within QRadar, the consumption of tenant data is restricted to only users permitted for the given tenancy. In Figure B, QRadar is configured to map data from Tenants A, B, C into domains A-n, B-n and C-n respectively. When QRadar receives network data from these tenants, the pipeline will tag the data with the domain matching the traffic. If this domain has been assigned to a tenant, the tagged traffic will only be accessible only to users that belong to that tenancy.

This full multi-tenancy solution is most relevant for large organizations and Managed Security Service Providers (MSSP).

2          Domain Creation, Mapping and Tagging

Domain creation, mapping and tagging is an essential part of any multi-tenancy solution. For a QRadar instance to be ready for IP Overlapping (domain isolation) or multi-tenancy solutions, some initial configuration is required. These are the typical configuration steps:

• An administrator creates domains around network entities, using the Domain Management admin tool. The Domain information, including information about the mapped network entities, are stored in QRadar’s mapping database table.
• After deploying the configuration above, QRadar tags data coming from domain-mapped network events in the pipeline with appropriate domains. Figure C.2 shows network data after domain tagging.
• Data that is not associated with any known domain mapping is tagged to “Default Domain”

2.1       Entities for domain mapping

The domain management tool offers sections that allow you to map the following to domains:

• Domains can be mapped to these event sources:
  • Event Collector (EC Domain)
  • Log Source (LS Domain)
  • Log Group (LSG Domain)
  • Custom Event Properties (CEP Domain)
• Domains can be mapped to these flow sources:
  • Flow Collectors (FC Domain)
  • Flow Source (FS Domain)
  • Flow VLAN IDs (VLAN Domain)
• Domains can be mapped to Vulnerability Assessment (VA) Scanners

After mapping these entities to domains, QRadar is able to tag incoming events and flows with the matching domain definitions.

2.2       Domain Tagging Order

After entities have been mapped to domains, QRadar can tag traffic received in the pipeline with domain information. It is possible that an incoming event or flow will match multiple entities of a domain definition. As such, a priority order exists to determine the precedence of these entities.

Entity priority for domain tagging of events:

Figure D.1 shows the priority given to the domain mapped sources (Custom Event Property (CEP), Log sources etc.) when assigning domains to an incoming event.

All normalized events are queued up for domain tagging. In preparation for domain tagging of events, QRadar first brings up the existing domain mappings associated with CEPs, log sources, log source groups and event collectors.

The value of the configuration option DOMAIN_CEP_FALLTHROUGH is also read from /store/configservices/staging/globalconfig/nva.conf and is used to determine which tagging path will be traversed. If this option is false, then the only entity used for event domain tagging is the Custom Event Properties entity and all others are skipped.

Next in the tagging order is log source ID. The log source ID on the incoming event is now checked against the log source IDs in domain definitions. If a match is present, the event is mapped to the relevant domain. Otherwise, the processing continues in this order of priority. If no domain mapping can be found for the event, it then gets tagged with “Default Domain”.

Entity priority for domain tagging of flows:

Domain mapping priority for incoming flows works in the same way as events. Incoming flows will first be checked for the presence of any VLAN information, and whether this matches any domain definitions configured in QRadar. If there is a match, the flow is tagged with the relevant domain. If not, the flow is next checked for a matching Flow Source, and then will be checked for a matching Flow Collector. If none of these entities match, the flow is tagged with “Default Domain”.

Note: The VLAN tag domain entity was introduced in QRadar version 7.3.2.

3          Configuring QRadar in Readiness for IP Overlapping (Domain Isolation)

Let us use a fictitious company Tazydah MotorHomes Inc to demonstrate configuration and activation of IP Overlapping functionality. The company has human resources, manufacturing and marketing departments. Each department has servers, workstations and mobile devices that are connected to the company network.

Let us create a domain that will identify devices in manufacturing, marketing and human resources and call them “Tazydah Human Resource”, “Tazydah Marketing” and “Tazydah Manufacturing”.

3.1       Create Domains

Start from the admin page and locate the Domain Management icon and launch the tool.

We will create domains for Tazydha departments using their log sources and log groups. We assume that prior to this, appropriate log sources and groups have been created. Figure E.2 shows the creation of "Tazydah Human Resource" domain using a log source group in this department. Using the same tool, we create domains for Marketing and Manufacturing departments.
                                                           

We repeat the process to create domains for other departments. We have used a Custom Event Property to create a domain for Manufacturing, a log source to create a domain for Marketing and a Scanner to create a domain for one of Tazydah’s scanners. After domain creation and performing a deploy, QRadar is now set up to tag events coming from sources mapped to the domains created (as listed in Figure E.3).

3.2       Creating Security Profiles

Security profiles are used to control the data QRadar users have access to. In this example we use Security Profiles to define which users have access to data mapped to the Human Resources domain. This is available through the Security Profile Admin tool.

Similarly, security profiles for the manufacturing and marketing domains can be created. After creating these security profiles, user roles and individual users are also created, using the steps here (https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.3.2/com.ibm.qradar.doc/c_qradar_adm_user_mgmt.html). Upon creation of a user, a user role and a security profile is assigned which determines the data the user can see. In the above scenario, assigning the “Tazydah HR SEC Profile” to a user and performing a deploy will limit the accessible data to only that within the “Tazydah Human Resource” domain.

3.3       Configuring the Network Hierarchy

After domains are created in a QRadar instance, the QRadar Network Hierarchy will become domain-aware. As such, you will need to navigate to Network Hierarchy Admin tool and assign network assets to domains.

After the first domain is created, all out of box network hierarchies available through the Network Hierarchy admin tool are initially assigned to the “Default Domain” (see the background list in figure F.1).

A common mistake is not updating the network hierarchy with the correct domain configurations after creating this first domain.  A typical symptom of this is that a user will suddenly be unable to see data in their Ariel viewers, since “Default Domain” was automatically assigned to all network groups on creation of domain in the system. As a result, user access to the network becomes restricted. Also, by default existing security profiles are not assigned the “Default Domain”. To resolve this issue, the admin will need to revisit the security profiles and network hierarchy and assign appropriate domains.

Figure F.1 shows how to create a new network and group and assign this group to a domain. We are creating a domain around the network group that has Human Resource network CIDRs and IP addresses.

After configuring the domains in the Network Hierarchy admin tool, we now have the following for “Tazydah_HR_NetGroup” network. Note that for network hierarchy changes to take effect, a deploy will need to take place.

4          Configuring QRadar for Multi-tenancy

We will use fictitious Managed Security Service Provider (MSSP) Iron Fortress to demonstrate the multi-tenancy solution. The service provider uses a single instance of QRadar (on premises or QRadar on Cloud) to monitor network data for several of its customers.

A prerequisite for configuring QRadar for multi-tenancy is to first configure QRadar for IP Overlapping (Domain Isolation) readiness as described in Section 3 above.

It so happens that Tazydah MotorHomes has hired Iron Fortress to manage its security services! All the network resources and domain configurations have been transferred to Iron Fortress QRadar administrators.

The Iron Fortress administrator has decided to create one tenant for each of their customers, as they intend to cleanly separate the customer data. Other Iron Fortress customers are: Farmlands Inc. and The Cup Shop.

4.1       Create Tenants

The Iron Fortress administrator created a tenant “Tazydah MotorHomes Inc” using the Tenant Management admin tool, as shown in figure G.1. This tenancy “wrapper” will encapsulate domains, users, network resources and data that belongs to the Tazydah MotorHomes company.

4.2       Assign Domains to Tenants

After creating tenants, you can now assign domains to them.

1. Launch the Domain Management admin tool to see domains that have been created.
2. Select the domain(s) you want to assign to a tenant.
3. From the tool bar select “Assign Tenants”.
4. Select the tenant you want to assign the domain to.

In figure G.2 we select “Tazydah Human Resources” domain and assign it to “Tazydah Motorhomes Inc” tenant.

4.3       Create Tenant User

When domains and tenants have been added to a QRadar instance, a new “tenant” field shows up at the bottom of the User Admin form in the Permissions section (figure G.3). When creating a new user, the admin will now need to choose the tenancy the user belongs to. The admin can assign the user to a specific tenant or select N/A if the user is a member of the MSSP.

4.4       Creating a Tenant Admin

The MSSP administrator does not necessarily have to perform all the admin tasks in QRadar. The MSSP administrator can create a special user called “Tenant Admin” for a tenant. The tenant admin can perform a set of predetermined but limited tasks against resources for that tenancy. A tenant admin has more capabilities than a regular tenant user.

First, the MSSP admin must create a special user role that includes granting the available admin permissions. See this article (https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.3.2/com.ibm.qradar.doc/c_qradar_adm_user_mgmt.html) for more information on how to create user roles and users. Then when creating the tenant admin, the MSSP admin selects the special role in the “User Role” dropdown, as well as the relevant tenant (observe role in Figure G.3). 

5          Domain Enabled Areas in QRadar

Domain Usage

After domains are created, several areas of QRadar become “domain enabled”. You will see domain columns show up on some pages, you will see domain sections or options show up on forms or tools. There are some tools you need to pay immediate attention to after creating domains in the system.

These include:

• Security Profile Admin Tool
• User Admin Tool (after tenants are created)
• Network Hierarchy Admin Tool
• Reference Set UI Admin Tool
• Data Obfuscation Admin Tool
• Centralized Credentials Admin Tool
• Ariel viewers (log and network activity pages)
• Ariel search forms
• Offense view pages and search form
• CRE: Rules Creation Wizard
• Assets Web Pages
• Resource Restriction

6          Domain and Multi-tenancy Use Cases

In addition to the overlapping IP address and MSSP use cases already described, there are many other scenarios where it can be beneficial to leverage domains and multi-tenancy in QRadar. Below are some other use cases adopted by QRadar customers.

6.1       Using Custom Event Properties in Domain Definitions

All Custom Event Properties (CEPs) in QRadar can be included in domain definitions. This can be useful for mapping events to their correct domains, when the only distinguisher between the events and their relevant domain is a particular attribute in the log itself.

For example, Tazydah MotoHomes Manufacturing department has an application that they’ve built in-house. In the event logs, this application reports “NAME=TazydahApp”. We created the domain against this CEP in section 3 (see figure E.3). Including this CEP in the domain definition ensures that all logs reported by Tazydah MotoHomes Manufacturing’s app will be tagged with the relevant domain. This field can be extracted as a CEP to uniquely distinguish this application from others on the network.

Note: If you want to ensure Custom Event Properties are the only entity used in domain mapping on incoming events, this can be achieved by setting the DOMAIN_CEP_FALLTHROUGH configuration boolean to false, as discussed in section 2.2.

6.2       Using Flow VLAN IDs in Domain Definitions

Let’s consider the MSSP Iron Fortress once again. In this scenario, we will consider another two of Iron Fortress’ clients - Farmlands Inc and The Cup Shop.

Farmlands Inc. uses VLAN 10 for all of its traffic and The Cup Shop uses VLAN 20 for all of its traffic. Iron Fortress can use the single QRadar instance to collect both Farmlands Inc. and The Cup Shop’s traffic.

Iron Fortress MSSP admin configures Domains for each of the tenants, “Farmlands-Inc-Domain” and “The Cup Shop Domain”, with Flow VLAN IDs set to 10 and 20 respectively, as seen Figure H.2.

The Iron Fortress admin can then assign tenants to each of these domains and assigns Farmlands-Inc-Tenant and The-Cup-Shop-Tenant, respectively. Now, when a security analyst from Farmlands Inc. logs into QRadar, they see only traffic that belongs to their network, which is on VLAN 10. All of their rules, searches and data feeds is limited to the data that is assigned to their tenant, and even though they are using the same QRadar deployment, they can’t access The Cup Shop’s network data from VLAN 20. They can even take this a step further by creating tenants with different security access profiles, so that only a subset of the Farmlands Inc. analyst staff are able to see sensitive traffic, for example.

6.3       Using Reference Data in Domain Definitions

After configuring your first domains in QRadar, another part of the product that becomes domain-aware is the reference sets. Now, when you navigate to the Reference Set Management tool in the admin screen, you will see a new property, “Domain”, appear when adding and editing Reference Set Data. Figure H.3 shows where this new field appears after domains have been configured.

Adding domain information to your reference set data is important, as it ensures that when you use these reference sets in rules and queries, that they are appropriately scoped to the correct domain. The below example shows the case where the reference set is used to define “Tazydah Motorhomes”, which is a set of known IP addresses within the Tazydah Motorhomes domain.

6.4       Obfuscating Data within Domains

QRadar is capable of data obfuscation. This is when data is made intentionally obscure or unreadable to humans by encryption, typically to protect sensitive data. Tazydah Motorhomes has made the following request to their MSSP Iron Fortress. They want all the username fields for all users in the Human Resources group to be obfuscated (encrypted). This will not obfuscate user data showing up for other Tazydah Motorhomes domains.

The Iron Fortress admin will set up new obfuscation profile and expression to handle the above scenario as follows:

1. Open the Data Obfuscation Admin tool. Create an obfuscation profile as shown in figure H4. On form submission, download and save the security key store file. 

b. Create an obfuscation expression and apply it to the Tazydah MotorHomes Human Resources domain.

1. You will create an expression by double-clicking the profile created in the previous step a (see Figure H.5 below). This opens the list of expressions in this profile. Currently your new profile has no expressions.

Click the “Add” button. This opens the “New Data Obfuscation Expression” form. We now fill the form using the Field Based type to create and expression to obfuscation username for human resource management domain as shown in Figure H.5. Note you can also create your own custom match pattern using the Regex type expression.

c. Ensure the obfuscation expression is enabled by selecting the check box
d. Send events and confirm that the username field for management users is obfuscated.

Figure H.6 shows the log activity page when there is no obfuscation. Notice that the username fields are all human readable.

Figure H.7 shows the same events sent after obfuscation was enabled for events in the human resource management domain. This time, the username fields for all events in the “Tazydah Human Resource” domain are obfuscated.

6.7       Scanning Assets for Vulnerabilities per Domain

If a scanner is assigned to a domain, any assets discovered by the scanner will automatically be assigned to the same domain. The Iron Fortress MSSP administrator has decided to execute a scan of assets using the scanner on the Tazydah Inc domain and report on any assets with vulnerabilities. They do so by following these steps:

1. First create a scanner using the VA Scanner admin tool.

2. Create a domain that maps to the created scanner with the Domain Management tool (Figure H.9).

3. Schedule the scanner using the Schedule VA Scanner admin tool (Figure H.8).

4. See the scan reports on the Assets Figure H.10 shows the asset page which reports the asset profiles resulting from the scan. In a domain-enabled QRadar instance, all profiles from scan results are reported against the domain registered against the scanners. In our scenario here, the asset profiles resulting from the “Tazydah Axis Scan Domain” scans are reported against that domain.

The Admin has the option of printing or exporting the listed asset profiles. They can also drill down to view vulnerability information per listed asset.

 

5. The Admin has the option of printing or exporting the vulnerable assets listed on this page.

Conclusion

Whether you are an organisation who wants to separate its different divisions, or you are a large MSSP managing data for multiple tenants, there is a QRadar multi-tenancy solution that will fit you. This article has demonstrated the many ways in which multi-tenancy and domain support facilitates threat-hunting, privacy and information delivery in QRadar. We have covered the benefits of different solutions, instructions for configuring domains and tenants, and looked at the many domain-aware QRadar features. For more information about multi-tenancy in QRadar, try this video (https://www.youtube.com/watch?v=Xrn7q9v3vAk), this open-mic (https://www01.ibm.com/support/docview.wss?uid=ibm10734477&aid=1) or contact the authors of this article.

#QRadar