As you scour through technology websites and periodicals (wait, does anyone actually read magazines anymore?), there is a lot of buzz around the latest voice recognition technologies. We see it in our smart phones, home digital assistants and robocalls. The technology itself is impressive, scales pretty well, and allows you to make verbal commands throughout your homes and offices. Recent versions in newer technologies like Amazon Echo can even filter background noise and music listening for the next command. In the last few years, the improvements have been truly impressive even through the results are arguably predictable and scriptable once a command is given.
This brings me to my point. Why are we so focused on the actual command in voice recognition when the background noise itself may be more revealing to the situation? In this blog I will walk through an analogy and then explain how listening to the noise can actually help in IT security.
Listening to the noise may have benefits
If Siri could detect gunshots and respond to a 911 call would there be any benefit? Could we stop a crime faster? We already accept that the technology is always listening so why can’t it be programmed to listen for viable threats as well as commands? Cities already have cameras almost everywhere already doing this, for example.
Some may argue this is too intrusive and too Orwellian (read: 1984). I argue that the benefit could be substantial. Location services could easily turn off the capabilities when at home or in a private location and leverage the always-listening microphone when we are in public venues. The false positive rate is another fact to consider with this approach but a pop up or warning asking, “Did you just hear gun shots?” could help filter the risks. There are probably plenty of other methods to manage the noise and we need to start thinking about the noise and its relevance when trying to understand any situation.
Looking at “noise recognition” for security and user events
Let’s consider the noise we get from security and network management events. If they are noise, why do we collect them in the first place? Do they ever have any relevance? The truth is, you do not know until you need it. The correlation of noisy events may help you detect a breach or provide better forensics, but understanding the noise in the first place might have some inherent benefits that we are failing to identify. So, let us consider how we can look at noise recognition for security and user events like a listening microphone.
Many regulatory compliance initiatives require the collection and consolidation of all log files. There is a considerable amount of noise with these collection paradigms. The event entries themselves may be designated with a risk level from critical to informational, or may have no risk level at all. Informational records are typically the noise. If critical, high, or even medium, risk level items could be classified as noise. I would contest that there is a false positive problem instead.
When is information not noise?
Let’s consider information event noise, and when an information record is not noise. For example, in every security information and event manager there are plenty of information records for logon and log off events. Standalone, they are noise. However, if the records contain “smoking gun traits” like unusual login location, afterhours time and date, or concurrent sessions, then the noise of an information record needs to be recognized just like a gun shot.
A SIEM is always listening, so why can’t we recognize the noise? It can, but we fail to use intelligence and analytics to identify these traits as a part of noise. Security professionals would concur that usual noisy events are an indication of an incident but they were not properly separated from the higher risk events until a breach occurs.
Threat analytics listens to the noise
This is where data analytics comes into play. Data analytics can help pull the needle from a haystack and see through the noise to identify meaning from malicious activity. This includes use cases like the first time a program has ever been executed in an environment, vulnerabilities that are unique to only a few resources, and user behavior that is not typical but may just show up as normal logon or logoff events.
BeyondTrust’s PowerBroker Privileged Access Management platform includes a feature called Clarity, a cluster mapping analytics engine that is designed to cut through the noise of PowerBroker events to listen for activity in the noise that would normally be missed. The technology, like a microphone, is always listening and can find when something usual is happening.
Recognizing the noise is just as important as the conversation itself. For more information on how BeyondTrust can help your organizations recognize the noise in privileged events, contact us today.
Morey J. Haber, Chief Security Advisor
Morey J. Haber is the Chief Security Advisor at BeyondTrust. As the Chief Security Advisor, Morey is the lead identity and technical evangelist at BeyondTrust. He has more than 25 years of IT industry experience and has authored four books: Privileged Attack Vectors, Asset Attack Vectors, Identity Attack Vectors, and Cloud Attack Vectors. Morey has previously served as BeyondTrust’s Chief Security Officer, Chief Technology, and Vice President of Product Management during his nearly 12 year tenure. In 2020, Morey was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board, assisting the corporate community with identity security best practices. He originally joined BeyondTrust in 2012 as a part of the acquisition of eEye Digital Security, where he served as a Product Owner and Solutions Engineer, since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. Morey earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.