Friday, January 17, 2020
The recent release of “Star Wars: The Rise of Skywalker” reminds us that it is entirely possible for two different people to look at the same piece of media or information and draw substantially different conclusions about it. This is true of fans of a franchise who may love or dislike a movie, but especially true in the workplace, when people with drastically different jobs are inclined to read into a situation based on their individual experience and perspective.
We see this in action when a security engineer and a network performance engineer examine an individual irregularity within a network. Essentially, security engineers and network performance engineers are operating as different sides of the same coin. They are examining the same piece of information or data, but their own specific context colors their interpretation of it, leading them to completely different conclusions about the nature of the irregularity.
A security engineer, for example, is concerned primarily with the threat environment surrounding a network. When tasked with investigating a spike or microburst in a network, they are likely to attribute it to a probing attack because they have approached the information with threat monitoring and attacks in mind.
On the other hand, a network performance engineer is primarily concerned with network functions and operations. They can study the same spike or microburst as the security engineer, but conclude that it has occurred because of a capacity issue rather than a probing attack.
This trend is visible not just with spikes and microbursts, but with all sorts of irregularities within a network. Of course, only one answer can be true: there is an indisputable cause for the irregularity, be it security-related or network performance-related. Security engineers and network performance engineers cannot, then, rely on their initial assumptions to correctly diagnose the issue. Instead, a closer examination of the irregularity is needed.
Context Is Key
In order to get the full picture around a network irregularity, engineers should consider event context, immediate context and network context.
Event context refers to the immediate context around the irregularity itself, and is limited because it is just the initial alert that something has gone wrong. Immediate context provides a slightly larger picture by including crucial information, including the nature of the transaction in question and the traffic flow at the time of the irregularity. Lastly, network context provides a look at what else was happening in the network when the irregularity occurred.
Network context is particularly important because it allows engineers to broaden their understanding of network operations at the time of the irregularity. An engineer investigating the irregularity alone is essentially training a high-powered microscope on one tiny piece of evidence, potentially missing out on other crucial information. Network context tells the engineer whether a threat exists in the system and provides insight on what led to the irregularity in the first place.
When put together, event context, immediate context and network context constitute complete context. A security engineer who believes a spike or microburst has occurred due to a probing attack can use context to determine whether network operations support or disprove that conclusion. Equally, a network performance engineer convinced that a capacity issue has caused the spike or microburst can either confirm or reject that belief.
Complete context is also helpful because it can prepare engineers for the chance that the irregularity will repeat in the future. When engineers understand what the network looks like ahead of the irregularity, whether it was caused by an attack or a network error, they are able to anticipate it before it can occur again, and take steps to mitigate it.
Just as two different “Star Wars” fans can have very different reactions to a movie, so can two different engineers, drawing drastically different conclusions about the cause of a network irregularity. But while “Star Wars” fans are entitled to their own interpretations of a movie, engineers must determine the true cause of an irregularity in order to prevent it from occurring again. The best way to do that is through a close study of the complete context around the event.
To learn more about network security performance data, watch the Fuel webinar, “How to Add Deeper Context to Your Network Security Performance Data,” related to this blog post.
Webinars are available to Fuel members. Not a member yet? Learn how to join today.
More to Explore
Check out these Fuel blog posts for further reading: