“Oh, East is East, and West is West, and never the twain shall meet …” When Rudyard Kipling wrote that opening line to “The Ballad of East and West,” little could he have known it might one day serve as a metaphor for the relationship between modern-day security operations (SecOps) and network operations (NetOps) teams.
Historically, the two have operated as separate entities in distinct silos and often, at odds – with SecOps prioritizing security and focused on preventing attacks from percolating through the enterprise infrastructure and NetOps prioritizing network performance and incented by high infrastructure resiliency and minimal disruptions. While both priorities are vital, the friction, of course, has stemmed from the fact that one set of priorities can negatively impact the other and it’s been difficult for the two teams to find satisfactory middle ground … well, until now.
Today, change is afoot. Much like in Kipling’s 19th-century story, where a British officer and Afghan raider begin as rivals and end as mutual admirers, SecOps and NetOps are starting to put aside their differences and find ways to work better together. As Gartner reports, these once distinct groups have begun to realize and accept that alignment is not a nice to have, but a business imperative.
Clearly, organizations can’t afford breaches, but they also can’t afford to have their network grind to a halt if they want to keep and attract customers. And while a kumbaya campfire sing-along may not yet be on the docket, the two camps are beginning to merge into a more unified whole that supports a common end goal: a well-performing and secure network infrastructure that protects and optimizes the end-to-end user experience. It becomes and imperative for the whole of the organization and not just for the Security teams. NetOps and SecOps working together.
A Shared Instrumentation Layer: Increase Security without Compromising Network Availability
In a perfect world, SecOps might choose to deploy many prevention tools inline with the network, where they could respond faster to cyberthreats by blocking them immediately upon detection. Alas, our world is not perfect and rising data volumes combined with a growing attack surface, attack sophistication and attack frequency create a disruption-defense conundrum. While it may be ideal for SecOps to run security tools inline, if these tools become overloaded, they can slow network throughput to unacceptable levels and create uptime issues for NetOps.
As a compromise, SecOps will often deploy more security tools out of band than they would prefer, and mainly reserve inline configuration for preventions solutions, such as firewalls, Intrusion Prevention Systems (IPS), Web Application Firewalls (WAF) and anti-malware or Advanced Threat Prevention (ATP) tools. Not only can these prevention tools also struggle to keep pace with the processing demands of faster networks, but there is another major operational issue: NetOps remains responsible for handling the day-to-day administration and maintenance of these tools. So, whenever SecOps needs to upgrade, add or delete an inline tool, they must coordinate with NetOps to find a mutually acceptable maintenance window – a process that can take weeks, if not months, and again, is not an ideal for either SecOps or NetOps.
As one way to ease the friction and facilitate team convergence and collaboration, Gartner suggests a shared instrumentation layer across teams. Tools like a network packet broker (NPB), for instance, can provide data to both networking and security tools to reduce redundant work, decrease network overhead and improve tool efficacy – all amid growing network data volumes and threat sophistication.
For security tools, an NPB is like a seasoned camp counselor who knows how to focus on and hone a camper’s strengths. See, security tools don’t need to see all traffic; they only need to see what’s relevant to their job. For example, a WAF only needs to see web traffic and an IPS doesn’t necessarily need to re-inspect traffic that’s already been inspected in another zone. In other words, different traffic should be handled in different ways, and if a security tool isn’t overloaded with irrelevant data to inspect, but instead, is fed the precise data it needs by an NPB, it can keep pace with faster networks and start to detect and prevent more threats.
What’s more, an NPB can distribute traffic across multiple inline tools simultaneously. Not only does this capability allow security inspection and monitoring tools to scale up to the speed of the network, but in the event of tool failure, traffic can be redistributed to the remaining healthy tools. Who from either camp could argue against those merits?
I’m thinking East may meet West after all.
Kumbayah, my lord …
