QRadar Demonstration with a Compliance Use Case and User Behavior Analytics

How to use this lab document

This lab is structured to both introduce you to QRadar SIEM and to be a starting point for you to create demonstations to customers. Text that appears like this will include actions to perform and important information to understand when going over the lab. It will be helpful to read all of this text.

There will also be blue "note" boxes like this that contain additional narration talking points that you would use in the customer conversation while performing a demo based on this lab content. For the lab, you can quickly skim over these notes for additional context.

You must have completed all steps in the setup lab. This includes running the noiseOn.sh and runUC.sh scripts to prepare the QRadar SIEM instance with data used in the examples.

Offense 1 - Excessive Firewall Denies on a Compliance Asset

The market-leading QRadar correlation engine can detect an unusually large spike in network traffic denied by network access control lists (ACLs) or firewall rules. Such a burst of denied traffic is usually caused by either: 1) a mis-configured application or firewall or 2) suspicious or malicious activity. This suspicious or malicious activity may be connected to unsuccessful attempts to connect to a command-and-control (C2) server or data exfiltration, resulting in a burst of failed connections. This could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods can also produce such a surge in traffic.

1. Click the Excessive Firewall Denies on a Compliance Asset
   offense.

2. Click the ellipsis (...) in the title to expand the full name of
   the offense.

   

   This is the offense overview page, where the security analyst starts reviewing the offense details.

   By classifying your compliance-relevant servers with policy-mandated or policy-protected data on them, you can ensure that specific QRadar rules related to unsuccessful attempts at network traffic alert you when malicious activity is detected on those assets. This enables your analysts to stay proactively ahead of the attacker's path.

   This offense is indexed on the Source IP and has multiple Destination IPs. The magnitude of the offense is 4, which helps you to prioritize the offense review. The offense summarizes 24 events, which trigger one insight Excessive Firewall Denies on a Compliance Asset.

   Note: Be aware that some of these numbers can be different in your
   demo.

   Let's have a look at the Insights, also known as Test Conditions, that
   were successfully met from the collected events.

3. Select the Excessive Firewall Denies on a Compliance Asset
   Insights to reveal a side pane that shows the test conditions of the
   rule.

   

   Reviewing the insights helps a Security Analyst to analyze the problem
   without reviewing all individual events. The insights Notes already
   explains why the offense was triggered. The Tests section provides
   details on how this offense is generated. It is designed to alert you if
   multiple conditions are met:

   • The IP address must represent a critical asset as defined by the
     listed building blocks, such as Personal Data, GLBA, HIPAA, PCI DSS,
     or SOX Servers.

   • Another part of the rule, the test condition, says that event must
     generate Firewall or ACL denies and it is not a single event. QRadar
     tracks events and has counters that will alert if this is happening
     at least to 2 destinations over 5 times within 5 minutes.

   Be aware that we have lowered the thresholds for those rule tests from
   the default values due to demo environment constraints.

4. Click View Event Details.

   

5. Observe and be prepared to describe the AQL query at a high level in a demo.

   

   By understanding the insights, you do not need to review the details of
   all the individual events involved in this suspicious activity. If you
   decide to view the events related to these insights, the Search screen
   opens. Without the need for deep AQL knowledge, the automatically-built
   query shows the events associated with this offense and the particular
   insights.

   Note the event count column. Some events are grouped using the
   coalescing feature. Event Coalescing helps improve performance and
   reduce storage for non-critical security events where the full event
   payload does not need to be saved.

   Note also that the Internal IP 10.4.0.25 is marked red.

   As data comes in and is coalesced, a large burst of events can
   convert hundreds of thousands of events into only a few dozen records.
   This action is done while QRadar maintains the count of the actual
   events. Coalescing gives QRadar the ability to detect, enumerate, and
   track an attack on a huge scale. It also protects the performance of the
   pipeline by reducing the workload of the system, including storage
   requirements for those events. When events are received that match a
   specific criterium, QRadar can use coalescing to determine what to store
   from the event payload based on the log source settings in QRadar.

6. Click any of the Destination Address IP addresses and examine
   the IP address slide-out pane.

   

   Note that this internal IP address is labelled as PII Server, which
   means it contains personal identifiable information. Not properly
   holding, processing, and protecting PII data can cause issues with many
   compliance regulations if the data is compromised. We also see that this
   asset has been manually assigned a risk weight of 10 in the QRadar Asset
   database, it is located in Germany, and the owner is Ronnie Sharrer. If
   more details about the asset are needed, you can click View Asset info,
   which opens a new Asset details tab.

7. Click View Asset info.

8. Review the asset details page and close it.

   Hint: If you are running the virtual demo, you can click anywhere on
   the page to close it.

   

   For example, the DNS Name indicates it is a database, and the Operating
   System indicates the server is running Red Hat Linux 8.

9. Close the Asset Details tab.

10. From the event search page, close the Asset info side pane, and in
    the upper left corner, click Return to Offense <n>.

    Note: The offense number might vary.

    

    This offense was not complex; it only contained one insight and 24
    events. Moving forward, let's examine some more offenses related to some
    other compliance aspects.

11. Click Offenses in the breadcrumb to return to the main offense
    dashboard screen.

    

Offense 2 - Security Logging Disabled on a Compliance Asset

Hint: If needed, apply the Compliance filter again to reduce the
number of offenses on the screen.

Many regulations have requirements intended to provide guidelines for
minimum protection related to standard objectives. For example, Payment
Card Industry Data Security Standard (PCI DSS) is a set of requirements
intended to ensure that all organizations that process, store, or
transmit credit card information maintain a secure environment.

QRadar helps you stay compliant with these standards by accurately
logging all access, modifications, and deletion attempts to PCI data.
All activity dealing with cardholder data and primary account numbers
(PAN) requires a log entry according to various compliance standards.

1. From the offense page, filtered by Compliance related events, click
   the Security Logging Disabled on a C... offense to review
   details.

   

2. Click the ellipsis in the title to expand the full name of the
   offense.

   

   Like our previous use case, we take a close look at suspicious behavior
   on a compliance-relevant asset related to disabling security logs.

   Security logs are important for overall coverage in monitoring and
   detecting malicious activities. Moreover, the offense indicates it is
   happening on an asset with compliance-relevant data (Destination IP).

   The offense is based on communication between two internal IP addresses.
   There is no trace of user activity. Note the Destination IP shows a red
   triangle indicating a high risk score for the asset.

3. To learn more about the asset, click the 10.4.0.25 IP.

   

   This asset is reported as a server containing PII
   information, and it has a risk score weight of 10. It is located in
   Germany, and the owner is Ronnie Sharrer.

4. Click View Asset info, and a new Asset Details tab opens.

5. Review the asset.

   

   For example, the DNS Name implies it is a database, and the Operating
   System indicates the server is running on a Red Hat Linux 8.

6. To go back to the offense, close the Asset details tab.

7. Close the Asset info side panel.

   Let's review some other parameters of the offense, such as the log
   sources reporting on this asset.

8. To review the log sources, click the Log Sources 2 at the right
   bottom of the page, indicating the amount of the log sources that
   contributed to the offense.

   

9. Review the search results for the log sources associated with the
   offense.

   The main log source reporting on this offense is an EDR system (endpoint
   protection) with the IP address 10.20.1.10. This can be an EDR server
   reporting on the endpoint, which is, in this case, the destination IP of
   the PII database server that we reviewed just a while ago.

   The other log source in this search result is the QRadar custom rules
   engine. These events are usually triggered by conditions found in other
   events, for example, if a certain number of events have occurred or if a
   certain accumulated risk score has been reached. Events from the QRadar
   custom rules engine can influence the creation of new events, increase
   or decrease magnitude and other levels for offenses, or act in many
   other ways.

10. Click Return to Offense <n>.

    Note: The offense number might vary.

    

11. To review the insight, click Suspicious Behavior and or Watchdog
    Disabled.

    

    Looking at the Tests condition, you can see that Suspicious Behavior
    Detection has been disabled. Let's examine the events associated with
    these insights.

12. Click View Event Details.

    Note that the search is automatically formed to collect the data
    associated with the offense and this insight.

13. In the search result table, click the Event Name to open the details
    pane.

    

    This event was generated by Symantec Endpoint Protection. The
    event Category is Service Stopped. Based on the Critical Magnitude and
    realizing that this insight pertains to a critical compliance-relevant
    asset, the analyst must act immediately. Let's examine the raw payload
    in more detail.

14. In the Insights pane, click Open payload.

    

15. Review the payload.

    

    The payload confirms that Symantec Endpoint Protection was disabled on
    the compliance-relevant asset (10.4.0.25) with PII data.

16. Close the Payload window.

17. To return to the search window, close the side pane.

18. Click Return to offense <n>.

Note: The offense number might vary.

![](./images/102/image36.png)

> Many organizations use the [MITRE ATT&CK Framework](https://attack.mitre.org/), which represents adversary tactics that are used in a security attack. It documents common tactics, techniques, and procedures that can be used in advanced persistent threats against enterprise networks. The QRadar Use Case Manager app can map custom rules and building blocks to specific tactics and techniques to allow organizations to visualize, understand, and plan their threat detection coverage.

Next in this demo, you will investigate the MITRE ATT&CK classification and learn that the offense is classfied as a Defense Evasion tactic.

1. To review the details of the MITRE ATT&CK classification, click
   Defense Evasion.

   

   The attack is classified as Defense Evasion -- the adversary is trying
   to avoid being detected.

   In the side pane you can see which of the MITRE techniques are covered
   by your rules and building blocks that supported triggering the offense,
   including the Confidence level.

   Learn more about the MITRE Defense Evasion tactic by clicking
   View tactic coverage.

2. Click View tactic coverage to navigate to the MITRE website for
   the Defense Evasion tactic. Browse through some of the details.

   

   This integration through the link in View Tactics coverage to the MITRE website accelerates access for the security analyst to details about each of the tactics and techniques.

3. After reviewing the MITRE page, close the MITRE tab.

4. Close the Defense Evasion side panel and click the Offenses
   breadcrumb to review the last use case.

   

We have reviewed one more offense, which was indexed on the Source IP address. In this offense, a Symantec Endpoint Protection server reported a disabled endpoint protection service on the destination IP address of a high-value compliance-relevant asset.

It is now time to look at the last offense example, with this one a little more complex than the previous two.

Offense 3 - Compliance Events on GDPR Assets... (Indexed by User mcoy)

Hint: If needed, apply again the Compliance filter to reduce
number of offenses at the screen.

General Data Protection Regulation (known as GDPR) is a regulation that requires organizations to protect the personal data and privacy of European Union (EU) citizens, and non-compliance can result in significant fines.

Technical safeguards, such as Data Loss Prevention (DLP) technology, help in preventing a breach. You can pair your QRadar with your security
tools to notify you of specific policy alerts that you have deployed through other security technologies such as IBM Guardium, Imperva,Vormetric, and so on.

Because organizations are held liable for the loss of any personal data they collect, layers of protection are added by incorporating DLP
controls within QRadar to identify and restrict the transmission of personal data outside the network.

Let's now closely look at and analyze one GDPR related offense.

Important: Be aware that there may be multiple similar Compliance
Events on GDPR asset offenses, but only one where the Offense Source is
the user mcoy. Use that one for this lab and demos.

1. From the offense page, filtered by Compliance related events, click
   the Compliance Events on GDPR Ass... offense that displays the
   user mcoy as the Offense Source.

   

2. In the offense details page, click the ellipsis to see the full
   name of the offense.

   

   Note that the name of this offense is very long. That is due to the
   offense chaining feature combining multiple insights contributing
   to the offense using the same index. Those insights are linked or
   chained by using the proceed by keyword.

   Before we dive into the insights of this offense, let's examine the
   upper part of the page, where you can find offense summary data.

   The Offense Type tells you about the root information that was used to
   collect data. We also call that parameter the offense index. The two
   most common offense types are Source IP, Destination IP and Username.

   This offense is indexed by username.

3. Click the Offense Source USER mcoy.

   

   When you open the details pane for the Offense Source or username, you
   might get additional information about that user, which then leads you
   to drill down into the User Behavior Analytics (UBA) app. We will
   discuss the UBA app in more detail a bit later.

4. Close the User details side pane and return to the offense details
   page.

5. Expand the Source IP and Destination IP addresses.

   Besides the offense being indexed on username, the offense collects all
   internal and external Source and Destination IP addresses from the logs
   (and flows) contributing to the offense.

   

   The next important detail we want to investigate is the magnitude of the
   offense.

6. Click the Magnitude region.

   

7. Review the Offense Magnitude side pane.

   

   This will be on the quiz

   The magnitude provides a score on how bad the issue is associated with
   the offense. The magnitude is calculated based on the relevance and
   severity of the events contributing to the offense, as well as the
   credibility, which depends on a level assigned to the log source that
   processes the event. For example, the credibility of IBM Security
   Guardium logs might be considered higher than logs from a web server
   that does not handle personally identifiable information (PII).

   Note the formula displayed on the screen that shows how the magnitude is
   calculated.

   RELEVANCE x 50% + SEVERITY x 30% + CREDIBILITY x 20%

   Note that the magnitude score decreases over time. This is sensible because the older the offense is, the less relevant it becomes. The magnitude score ranges between 0 and 10. The higher the score, the more urgently the offense is in need of analysis for potential security issues.

8. Close the Offense Magnitude pane and return the offense summary
   screen.

   Observe that offense includes multiple source and destination IP
   addresses relevant to mcoy activity. Also, QRadar reports on MITRE
   ATT&CK tactics and techniques observed in this offense. It can also be
   relevant for the analyst to observe the event categories that
   contributed to this offense.

9. From the offense details page, click the number of events in the Categories.

   

   QRadar uses event categories to group incoming events for processing.
   The event categories are searchable and help you monitor your network.
   Each event that occurs on your network has associated high-level and
   low-level categories. Thus, the events are aggregated and can be
   searched by those categories.

10. Review the search results.

    

    When you examine the Low Level Categories that contributed to this
    offense, note that the single event in the User Login Success
    category indicates an urgency to immediately investigate this offense in
    more detail, especially with the context of the high amount of prior
    chained General Authentication Failed category events.

11. To close the Events Categories list, click Return to Offense
    <n>.

    Note: The offense number might vary.

    

    Before we drill down into the events that contributed to this offense
    and dig out all details about what has happened, let's analyze some
    of the offense insights.

12. Click the _BlueCoat Event from Server insight.

    By looking at the Tests definitions, you see that the insights are
    triggering because network traffic is detected between the domain
    controller and one or more web categories that have been flagged as
    potentially malicious inside the BlueCoat Investigate Categories
    reference set. To better understand what has happened, we must look at
    the events associated with this insight.

13. Click View Event Details.

    

14. Review the events associated with the BlueCoat log source.

    

    The events associated with the BlueCoat insight are pulled from QRadar
    using the automatically formed AQL query. You can see that there are two
    remote sites communicating with the internal IP address 10.64.2.13.

15. Click the internal IP address 10.64.2.13.

    

16. Review the Domain Controller asset.

    

    Note that the internal IP address is classified as Domain Controller and
    has a risk weight of 10. A security analyst would know that there is no
    plausible reason for direct interaction between external networks and a
    domain controller. Next, let's look at one of the external IPs.

17. Close the side asset panel and click the external IP
    216.239.32.21.

    

18. Review the IP address side panel.

    Note that this IP address depicts a low X-Force risk score at this time.
    This is real-time information pulled from the IBM X-Force Exchange
    database. However, to investigate how this IP address was behaving over
    the past, you can click View X-Force info.

19. Click View X-Force info.

    

20. Review the X-Force Exchange page with the IP address historic data
    that is presented in a new browser tab.

    

    The X-Force Exchange database keeps historic records of malicious
    activities in the public IP address space. Right now, this IP address is
    clean, but back in time (when this demo was originally developed) we see the
    IP address has multiple issues related to spam, botnet, and malware
    activities. The IP address was also part of multiple collections that
    were used to track different threat campaigns. All this data is
    integrated with QRadar SIEM and can be used to improve detection and
    investigation of malicious activities.

21. Close the X-Force Exchange window and the IP address side panel.

22. From the search page, go back to the offense by clicking Return to
    Offense <n>.

    

    Let's review the next insight in this offense, Suspicious Activity on
    Personal Data Detected by DLP Devices.

23. Click the Suspicious Activity on Personal Data Detected by DLP
    Devices insight.

    

24. Review the Notes and Tests sections related to this insight.

    Looking at the Notes section and the Tests related to this insight, you
    realize that the test triggers if a DLP (Data Loss Prevention) service
    detects a policy or rule defined in the GDPR DLP Policies reference
    set. We will look at those tests and the insights in more detail a bit
    later using the Use Case Manager app, but now let's review the events
    related to this test and the offense.

25. At the bottom of the side window, click View Event Details.

    

    The new search is automatically formed showing the Guardium events that
    observed activities between internal systems. The destination systems
    are marked red, which means those are critical assets.

26. On the Event Details screen, click the critical IP 10.4.0.26

    

    This asset is labelled as a CRM database and the owner is Mary Coy, who
    is also involved in this offense. This either indicates malicious
    insider threat activity or an outside adversary using stolen
    credentials. Let's continue the investigation.

27. Exit the asset details pane and go back to the search results
    window.

    Let's look at the Admin Commands by non DBA - Alert event in more
    detail.

28. Click Admin Commands by non DBA -- Alert.

    

    This Guardium event is marked critical. If we scroll to the bottom of
    the event details pane, we can see what insights (QRadar rules and
    building blocks) were fully or partially matched in this event. Any
    matched rules or building blocks can contribute to an offense or create
    a new one.

    You can also see the full payload, how the event is received by QRadar
    from Guardium.

29. If not already expanded, expand the Custom Properties section.

    

    In the Custom Properties section, you can see what parameters
    are extracted from the event payload. One of them is the policy name --
    GDPR Personal Data Admin User -- alert per match (violation) on DML
    and Select Commands. Make note of this policy name, because we will
    reference it later in the lab and demo.

    You also see the user, mcoy, who executed the database SQL command.

30. Click Open payload.

    

31. Review the payload details page.

    This will be on the quiz

    On this page, you can see how the raw payload looks. If you identify some
    relevant data in the payload, you could create an additional custom
    property to extract the information, which you can use in the rules
    processing the events.

    This eases the daily activities for your Security Analysts because they
    no longer need to review a lot of raw payloads. Instead, QRadar
    automatically extracts important fields in the custom properties and
    uses the custom rules engine, tests, and insights to digest the
    information for the analyst, packaging all pieces of information into a
    more human-readable package, which we call an offense.

32. Close the payload details page.

    

    Let's go back to the offense.

33. Close the side panel, too.

34. From the Search page, click Return to Offense <n>.

    Note: The offense number might vary.

    We can continue to examine every insight and analyze them in more depth.
    But, even by reading the Insights titles, we can see the unfolding
    attack story: the Domain Controller was communicating with remote IP
    addresses with a bad reputation. Then the mcoy account executed
    suspicious activity on the CRM database -- maybe data was exfiltrated.
    And then, the account tried to log in to another system and eventually
    succeeded. All this data was collected in 45 events. The offense
    chaining feature summarizes the threat in the offense title by
    combining multiple insights into one offense connected with the word
    proceeded by.

    Based on the detailed offense analysis, an analyst can perform a variety of actions on the offense, such as closing false positives or escalating the offense to an incident response or a ticketing system.

35. Click Actions to list the actions that can be performed on the offense.

    

    If the offense is deemed false positive, the analyst should close it. It is not considered a good practice to defer or not perform offense closure because QRadar gets trained based on the offense closing reason the analyst specifies. Closing offenses also helps with performance.

    If you do not properly manage the offenses, they may expire. If necessary, an analyst can also freeze an offense to avoid expiration.

    In this case, the incident is a real threat and requires an incident response. Thus, you can send the offense information to QRadar SOAR for
    further incident response. That action is beyond the scope of this lab.

    Therefore, leave the offense in the current active state.

36. Close the action popup menu.

So far, we have demonstrated how a security analyst can use offenses to
analyze information that QRadar has received and processed. We performed
detailed offense analysis and highlighted important artifacts, such as
index, magnitude, event categories, insights, and events.

Let's now take a close look into QRadar use cases and rules with the Use Case Manager app.

Reference Data Manager - overview

This action opens a new app called the Reference Data Management app
on a new browser tab. This app manages your reference data collections
that are used in the rules (use cases). Those reference data collections
can be multidimensional, but the most used type is a simple list, also
known as reference sets. One of the reference sets is the GDPR DLP
Policies. We see that it currently has 17 elements, and those are
different events that can be observed on DLP devices, such as IBM
Guardium. If you need to expand your coverage to other DLP events, add
more line items to this reference set.

Notice that one of the listed polices is the Guardium policy that we
analyzed earlier in the GDPR offense -- GDPR Personal Data Admin User
-- Alert per match (violation) on DML and Select Commands.

Let's also review another reference set that we discussed earlier in the
demo: Personal Data Servers. For more efficiency, click in the search
field and type Personal.

1. In the left part of the screen, click Search and type Personal.

   

   Then click the Personal Data Server reference set.

2. Click Personal Data Server.

   

   Observe that five network IP addresses are defined as the servers with personal data. One of them is IP 10.4.0.26, detected earlier in the demo. At the bottom of the screen, you see Dependents where this reference set is used. One place is the building block BB: Compliance Definition: Personal Data Servers. Quick reminder - that is the building block that links to the Suspicious Activity rule that triggered in an earlier part of the demo.

   This shows the picture of how the parts come together to identify servers holding PII.

3. To go back to the UCM app:

   • Close the Reference Data Management tab.

4. Close the rule analysis window.

   

   Now, let's observe another powerful UCM feature. As mentioned, the app
   comes with some preloaded filters. Let's load another filter that helps
   us review all non-installed content.

5. Click the Select template icon.

   

6. From the pop-up window, scroll down and select All non-installed content.

   

7. Review the loaded page.

   

   The new view loads. Here you can see all available content that you can
   download from the IBM App Exchange and add to your QRadar SIEM
   deployment. You can narrow down this list by using the search bar. For
   example, let's look for some ISO 27001 compliance content.

8. Click the search bar, and type ISO.

   

   We see 18 different rules that are part of the ISO 27001 Content
   extension, which are currently not installed on your QRadar SIEM. Let's
   open one rule.

9. Click Login Failure to Disabled Account.

   

10. Review the rule page.

    

    Note that the rule is part of the IBM Security ISO 27001 Content
    extension, which is not installed. However, note that you can still
    analyze rules, and see details and dependencies.

11. Close the page.

12. In the Content extension name column, click any IBM Security ISO 27001 Content.

    

    Also click the content extension name.

13. Review the QRadar Assistant app page, which opens in a new browser tab.

    

    When you select any content package inside the UCM app, it takes you to the QRadar Assistant app. This app is linked to the IBM App Exchange, and if you have been granted the appropriate administrative permission on QRadar, you can install the content package with one click. For this lab you will NOT install the content package. Let's continue with UCM.

14. Close the Assistant app tab and focus back on the UCM app.

    • The Assistant app opens in the new browser tab. Close the tab and shift focus back to the UCM app.
    

Let's see how the UCM app can be used to review MITRE ATT&CK coverage.

MITRE coverage demo

This will be on the quiz

1. Click the ATT&CK Actions menu, select Coverage map and report.

   

2. Then switch to full screen using the full screen icon.

   

   Coverage map and report matrix shows your current QRadar coverage per
   tactics and techniques. The color code is significant; the darker
   shade of blue means that coverage is better. Let's examine the Command
   and Scripting Interpreter techniques.

3. Click Command and Scripting Interpreter > PowerShell.

   

   Note that a new filter shows on the filter list. Now exit the full
   screen and apply the filters.

4. Exit from the full screen.

   

5. Click Apply Filters.

   

6. Review the filtered results.

   

   Note that you see 5 rules related to this technique loaded in the table.
   One is disabled and four others are enabled.

   You can also use MITRE filters to see the usage and trends of
   implementation of the MITRE framework in your QRadar deployment.

7. Click the ATT&CK Actions menu, then click Coverage summary
   and trend.

   

8. Review the Coverage summary and trend page.

   The MITRE Coverage Summary data helps you to understand where you are
   with your current QRadar implementation in relation to different MITRE
   ATT&CK tactics. For example, in this QRadar deployment, of the total
   installed rules, 18% are mapped to cover the Initial Access tactic.

   

   There is also a MITRE Coverage trend graph.

   Finally, we want to point out that you can review use case implementation.

9. Exit from the summary page.

10. Expand Rule-log source type coverage, then click Current and
    potential coverage.

    

11. Review the page.

    

    This page displays all rules per log source that you have installed and
    that you can install.

    Here you see Rules per log source type, used and unused, how many rules
    are installed, and how many more you can implement. The list also shows
    that, by default, QRadar supports almost 400 log source types. The MITRE
    Coverage is also documented.

12. Exit the page.

    

    You can also use the UCM app to tune the QRadar rules.

This part of the lab was about how the Use Case Manager, Reference Data Management, and Assistant app can help you analyze missing and installed content on your QRadar SIEM deployment. These apps also help to understand dependencies between rules, building blocks, and reference data. Also Use Case Manager allows understanding of how the currently configured rules map to MITRE ATT&CK framework tactics and techniques.

It is time to move on and see how the UBA app can help in analyzing potential malicious user activity.