The IDS (Intrusion Detection System) has been around for several decades. We believe there is still much room for growth. In no way am I criticizing the researchers or vendors who build an IDS - I am merely going to acknowledge the difficulties involved.
Lack of Solution
While I believe an IDS can actually assist in dealing with many of the same threats as firewalls and anti-virus, the data tells us that they don't normally represent an effective solution. Therefore, many organizations chose not to use them. My argument? If this was the case, then one would instinctively expect the level of penetration to be even lower when deploying an IDS.
In terms of challenges, one of the most commonly identified issues in relation to an IDS is the problem of false alarms; resulting from situations in which legitimate and harmless activity is falsely judged to represent an attack.
Time is money and you have little time. The problems of false positives (e.g. the time wasted by investigating them, or the potential for genuine alerts to be overlooked in the noise) have led to significant changes in the marketplace. The emergence of IPS (Intrusion Prevention System) technologies occurred as a direct response to this issue and the negative press surrounding IDS. Having said this, false positives are far from the only issue that can present problems. A review of IDS/IPS literature reveals that challenges may be faced at a number of levels, from constraints during the initial rollout of the technology through to its effectiveness and its ongoing use.
Security Orchestration, Automation and Response
Too often, alerts are generated independent of context to other data that is prevalent or available in the network. The value of a next generation SOAR (Security Orchestration, Automation and Response) technology is: Network Consensus in Context. The same way you would conduct a manual digital forensic investigation is how you can best reduce alert overload and not rely on a single security device.
QuorumTM is a SOAR technology. It recognizes that while independent point solutions can propose a threat candidate, convicting an activity based on one tool is a fool’s errand. Because a narrowly observed activity can be taken out of context. For example, packet dropping alone and the high speed network traffic can contribute to false positives and false negatives. The high speed of network traffic combined with the information overload can cause packet dropping. Therefore, the probability of missing attacks increases. Why? Because encrypted traffic and IPv6 encrypted traffic attacks can successfully reach the destination without being monitored by IDS/IPS.
Additionally, the amount of information generated by the IDS/IPS increases the workload for the system/security administrator who must consider it. Too many alerts require significant effort to monitor and that detracts from effectively fighting the threat. Security experts subjectively, rather than objectively, must randomly "choose" which alerts to act on. Eventually, this overload leads to analysts ignoring all the alerts. This is dangerous! Ensuring effective configuration is difficult! Tuning the IDS/IPS to minimize false alarms and missed attacks takes time and effort, and in our experience, yields little value.
QuorumTM approaches the network differently! It independently looks at the raw packet data and provides for an efficient methodology to log the network traffic and run on-the-wire analytics at machine speed. Therefore, QuorumTM is able to analyze and validate whether or not alerts should be made. It is able to massively reduce the number of threats candidates because it first forecasts the threat and confirms that forecast through UEBA (User and Entity Behavior Analytics). It forecasts the threat by attack vector BEFORE it manifests at your perimeter. QuorumTM also analyzes the network holistically to see if actual intrusions are taking place. Moreover, the actual alerts are reduced massively to the ones that are actionable. These actionable alerts are presented in a meaningful and robust interface.
Finally, @RISK felt it had to build a GRC function within the platform because when it comes to determining the alert severity level, there are no standard metrics for the alert severity level. @RISK leverages 20 years of CVE pattern of life (POL) analytics, Cyber Frameworks correlation, and uses an organizations security policy with machine learning to establish risk tolerance to interpret and rank/prioritize the generated alerts. Alert correlation is a failed mathematical practice. Instead, @RISK has built in a requirement to study the relationship between the various user and entity behaviors, forecasted threat data, and abhorrent and anomalous behavior as a cumulative "Kappa" to determine the occurrence of the attack scenarios.