Why Real-Time Threat Detection is Critical: Devo, LogPoint, QRadar, Microsoft Sentinel, Panther, Splunk, Sumo Logic, and SureLog Point of View

5 min readApr 24, 2024

Real-time threat detection involves analyzing event data for malicious activity the instant it’s generated by the event source. Traditionally, this has been achieved using a SIEM tool that aggregates logs in a single place, enabling security engineers to write detections that trigger alerts when a vulnerability or threat occurs.

Key Reasons Real-Time Threat Detection is Critical:

Immediate Threat Identification: Real-time detection systems are designed to identify and respond to threats as they occur, which is crucial for preventing potential breaches from spreading through the network and causing more damage.

Reducing Response Time: The faster a threat is detected, the quicker the response can be initiated. This rapid response is essential in minimizing the impact of the attack, reducing downtime, and maintaining business continuity.

Compliance with Regulations: Many industries are governed by regulatory requirements that mandate real-time monitoring and reporting of security incidents. Non-compliance can lead to legal repercussions and fines.

Protection of Sensitive Data: Fortune 500 companies often manage sensitive and valuable data, including customer information, intellectual property, and financial records. Real-time threat detection helps safeguard this data from cyber threats like ransomware, data breaches, and insider threats.

Maintaining Reputation and Trust: A swift response to cyber threats is critical in maintaining the trust of customers, partners, and stakeholders. Real-time detection enables companies to manage and mitigate issues before they escalate, thereby protecting the company’s reputation.

Adaptability to Emerging Threats: Cyber threats are constantly evolving, and real-time detection systems can be updated to identify and respond to new and emerging threats more effectively.

Cost Efficiency: Although the initial setup of real-time threat detection systems can be costly, the long-term savings from avoiding major breaches can be substantial. Preventing large-scale breaches helps avoid costs associated with recovery, legal fees, and potential fines.

Operational Efficiency:

SOCs can trigger alerts about potential intruders in minutes rather than days or weeks, which lowers security teams’ mean time to detect (MTTD) and mean time to respond (MTTR). This efficiency is achieved by running threat analysis at the point of ingestion rather than in batches or by indexing data, thereby significantly reducing the lead time to receive an alert.

Every SIEM solution, whether commercial or open source, supports real-time threat detection to some extent. I will provide examples from several well-known SIEM products.

SIEM Product Examples:

Devo:

“if you created an alert past the hour with a one-hour period, the first time it will be triggered (if the conditions are met) will be when the clock strikes the hour and not after 60 minutes. In other words, if you created it at 9:37, it will be triggered at 10 and not at 10:37” [1]

“Newly created domains can have up to 10 alert definitions activated while domains with a full subscription can have up to 300.

When you create a new alert that exceeds that limit, it will be automatically deactivated upon creation. To activate it, you can either deactivate other alerts or delete them to free up some slots.

If you need to adjust this limit, contact Devo support.” [2]

LogPoint:

“Select the Search Interval. If you set the search interval to thirty, Logpoint performs the search every thirty minutes.” [3]

QRadar:

Qradar supports real time detection using 3rd party tools [4,5,6].

Microsoft Sentinel:

“No more than 50 rules can be defined per customer at this time.” [7]

“At this time the following limitations remain in effect:

a. Because this rule type is in near real time, we have reduced the built-in delay to a minimum (two minutes).

b. Since NRT rules use the ingestion time rather than the event generation time (represented by the TimeGenerated field), you can safely ignore the data source delay and the ingestion time latency (see above).

c. Queries can run only within a single workspace. There is no cross-workspace capability.

d. Event grouping is now configurable to a limited degree. NRT rules can produce up to 30 single-event alerts. A rule with a query that results in more than 30 events will produce alerts for the first 29, then a 30th alert that summarizes all the applicable events.” [7]

Panther:

“Once logging begins, data is parsed and normalized automatically and then stored in AWS S3. Panther then runs a real-time detection engine against the logs that are within S3.” [8]

(So, there is no stream processing or threat analysis at the point of ingestion; instead, it occurs in batches or by indexing data, which significantly increases the lead time to receive an alert.)

Splunk:

“For Splunk Cloud Platform, indexed real-time search is turned off.” [9]

“For Splunk Enterprise, indexed real-time search is turned off by default. To turn on indexed real-time search, follow these steps.

Prerequisites

· Only users with file system access, such as system administrators, can turn on indexed real-time search.” [9]

“I suggest that you give up on real-time searches for exactly this reason, among many other good ones:” [10]

“Why are realtime searches disliked in the Splunk world?” [11]

“Each realtime search unpreemptively locks 1 core on EVERY INDEXER and on your Search Head. If you have more realtime searches than cores, you will get this error” [12]

“Running multiple real-time searches will negatively impact indexing capacity” [13]

“Despite what all of the marketing and training says, SPLUNK IS *NOT* A REAL-TIME PRODUCT!” [14]

Sumo Logic:

“Some queries can not be used in Real-Time Alert searches. Other operators can be used in Real-Time search, but in the search, they must be included after the first “group-by” phrase:” [15]

“A maximum of 120 emails are sent per day per Real-Time Alert” [15]

“Aggregate real-time scheduled searches evaluate the first 1,000 results per search. For Example, if the scheduled search is supposed to return more than 1,000 results, reduce the scope of the search.” [15] (This is a significant restriction, particularly for companies with thousands of staff, because if your detection logic, such as thresholds, requires evaluating more than 1000, it does not work.)

SureLog:

SureLog SIEM supports both real-time and batch detection without any restrictions or limits

References:

1. https://docs.devo.com/space/latest/95126665/Several+alert+type

2. https://docs.devo.com/space/latest/95126538/Creating+alert+definitions

3. https://docs.logpoint.com/docs/alerts-and-incident/en/latest/Alert/Creating%20an%20Alert%20Rule.html

4. https://www.ibm.com/docs/en/qradar-on-cloud?topic=notifications-configuring-event-flow-custom-email

5. https://www.ibm.com/docs/en/qradar-on-cloud?topic=notifications-configuring-custom-offense-email

6. http://www.eventgnosis.com/

7. https://docs.microsoft.com/en-us/azure/sentinel/near-real-time-rules

8. https://panther.com/blog/adopting-real-time-threat-detection/

9. https://docs.splunk.com/Documentation/SplunkCloud/latest/Search/Aboutrealtimesearches#:~:text=For%20Splunk%20Cloud%20Platform%2C%20indexed,time%20search%20is%20turned%20off.&text=For%20Splunk%20Enterprise%2C%20indexed%20real,time%20search%2C%20follow%20these%20steps.&text=Only%20users%20with%20file%20system,on%20indexed%20real%2Dtime%20search.