Coming from the world of networking, most professionals’ introduction to a security engineer is usually an adversarial event. At first blush, it’s easy to notice all of the differences. Network engineers are all about the flow of data. Letting the packets get from the source to the destination. Security engineers are all about confinement and containment. Network engineers work in a Network Operation Center (NOC) and security engineers work in a Security Operations Center (SOC) and for most organizations, these are oil and water. Different rooms with different managers. For the most part, even different languages.

The first badge of honor for a network engineer is taking down a production network, the second badge of honor is an argument with a security engineer.

This bifurcation comes from the parts of the network that the teams focus on, and while many might find this surprising, this is a really good thing for networks in general. When taken in the context of the TCP/IP Stack example seen on the right, network engineers focus on the lower levels while security engineers focus on the upper levels. As complicated and sophisticated as modern networks are, there isn’t any way for a single person or team to focus and specialize on everything happening on our networks. While this separation of responsibilities is a good thing for the network and the business that depends on that network, it can lead to some interesting differences in how these teams view “problems”.

A network engineers view of problems generally boils down to something along the lines of either connectivity problems or a lack of frames/packets. As a network professional we use terms like association, connected, up, down, request, response, rate, errors, CRC, runts, grunts, giants, collisions and so on. These terms all come from how the network and the devices are performing, and when viewed in the context of the TCP/IP model, they all happen to come from the bottom half. We see these terms in our logs and CLI sessions, and they are all an indication of how our networks are performing.

Figure 2 Network Interface Status

What network engineers care very little about, if we are being honest, is what is contained in all of these payloads that we are transporting. Is it an email? A web page for a popular news site? Maybe it is a Tor session for a nefarious transaction being made on the dark web. For the most part, we don’t know and we don’t care. What we care about is this – “Is the data flowing?”

We get to think this way because sitting in that other room, somewhere else, is a team that cares A LOT about what is in the payload.

While we ponder whether or not our routing protocols are configured correctly, the SOC is focused on things like malicious payloads, company secrets being leaked, illegal activity that could be happening on the dark web. Is the data encrypted or in the clear? Is the source of this packet supposed to be talking to that destination or not? Would someone working in finance use PowerShell?

Security engineers use terms like clear text, synching, URLs, IOC, PII, malware, spyware, domains, subdomains, scans, exploits, C2, and it goes on even more than the list that network engineers have. Just like as before, if you look at the TCP/IP model the majority of these terms will come from the upper half of the model and they are all concerned about what is happening on the network. While network people look at CLI screens and logs, security engineers have a slightly different look.

Figure 3: Cisco Threat Response

As network engineers, this isn’t something we would look at or for, but that’s OK. We don’t have to because there is someone else there (hopefully) to handle that. The network handles the how security handles the what.

Nice and easy!

There is one part of this separation that does lead to some funny interactions, and it all boils down to what is considered a “bad thing”. You see, for network engineers, a bad day is when the packets and frames stop flowing. When the ignores, errors, and drops spike, that is a bad thing for the network. For security people, that can be a good thing! If that malicious payload can’t be reassembled due to missing parts, problem avoided! Routing to the internet drops? Network engineers enter a crazed panic state while security engineers have a different view: no way an attacker can get to us now, we are safe!

Security folks, however, are the polar opposite of that. Contained in all those packets in Figure 2 could be loads of malware, devices talking to known Command and Control (C2 or C&C) botnet servers, corporate secrets being stolen, any number of bad things that could potentially cripple a business. As a network engineers, we look at Figure 2 as a network running clean and humming along nicely, just as we designed it. While we sit and watch those utilization numbers increase in a good way, it could potentially be the business as a whole being driven into the ground. No problem for the “network” but a big problem for the SOC, and eventually, the company.

Granted, all routing to the internet being down is also bad for the business and the company, but hopefully, you are starting to see my point.

For years, the NOC and the SOC have sat at opposite ends of the spectrum but as networks and functionality converge, it needs to be incumbent on both the NOC and SOC engineers to do a better job of reaching out across that gap that exists and learn more about what the other does. Even though at times it feels like we are on different teams the truth is we have always been on the same team. In SOC parlance, both the NOC and SOC are on what is known as the “Blue Team”, the defenders of the network.

While the NOC and SOC can work independently from each other, it’s only when the efforts and knowledge from the entire picture is combined do you truly get a full picture of what is happening. Instead of a tunneled view limited to half of what is happening, a full spectrum, high-definition image of the full scope can be built and viewed. Both parts of the TCP/IP model converged together, forming a complete picture, enabling the business to make the best decisions at the proper time.

While everything might appear completely opposite with network and security engineers on the surface, at the end of the day, we really are the same. And more importantly, working on the same team for the same goal.