Noise Reduction and Prioritisation: One Size Does Not Fit All

noise reduction and prioritisation

One man’s trash is another man’s treasure, what one considers undesirable is likely specific to the listener. Or, at least, that is the unwritten rule in several situations, one of which seems to have so far been the threat landscape monitoring tools industry.

The endless war against alert fatigue

In the infosec community, talking about noise reduction has become as ubiquitous as the mandatory small talk about COVID-19 updates at the start of Zoom meetings. With cyber security professionals submerged by alerts day after day, finding increasingly better ways to prioritize is key to any cybersecurity product.

The attractiveness of the one-size fits all approach to reducing noise has escaped few such product providers, hoping to successfully prioritize information that is relevant for all their customers, regardless of industry and challenges. While this approach might make sense for standard threats, such as malware detection or server vulnerabilities, it is extremely difficult to find a generalized approach for technical leak detection.

Alert and event use cases vary

At a high level, besides major financial institutions, for whom almost all activity on dark web platforms is of relatively high value, dark web monitoring is not necessary for some   organizations. Digging deeper to find technical leaks on code sharing sites such as GitHub is of high value for organizations working with private repositories and trying to find where (not if) employees pushed code with their private email address by mistake.

However, higher education institutions we work with have mentioned how the students’ code commits are of much less value to them. They still want to track them, but keep them at a lower priority level than employee-related activities and infrastructure.

For infrastructure anomaly monitoring, firms owning IP ranges, with parts running on-premises, have a very different monitoring approach than those running their infrastructure behind cloud load balancers or third-party services such as Cloudflare. On these services, potentially sensitive ports such as 8080 or 9200  can usually be assigned lower priority.

Leverage user input to improve risk-scoring engine

With these concerns in mind, we have moved  towards an intelligent, adaptive risk scoring method that adjusts  itself continuously. Users now have the opportunity to give direct feedback to our risk-scoring engine, which will over time impact the way our system prioritizes activities and alerts for them. The result will be a continuously improved  alerting system, customized to each organization or user.

Reach out to us if you are tired of seeing your alert feed polluted with what the biggest players consider important. We will help you monitor the clear and dark web for technical leakages before malicious actors take advantage of them.

Share This Article

Product Team

Flare’s product team explores new technologies and processes that will help Flare stay ahead of the competition and guides the engineering team in the development of the product.

Related Content