It’s easy to see how network tool sprawl gets started. The needs and challenges facing security and networking groups are immense. Network speeds have steadily increased, and there are always new demands and uses. Network conditions and requirements change weekly, if not daily. Security threats increase in number and approach. At the same time, technological advancement rapidly brings new solutions to the market that are beneficial in addressing networking and security needs.

Adding or changing tools or solutions becomes essential. Existing tools may have difficulty scaling to network growth and changes, and mismatches of network speeds and interfaces create difficult challenges. Many organizations contend with a jungle of cabling and connectors to get components connected in the right way, and managing this becomes increasingly difficult. This dynamic produces three distinct problems: the sizable work involved in approving each for deployment, the limitations in infrastructure to accommodate solutions and the potential conflicts solutions pose to each other or the network if not operating in logical sequence.

A particularly time-consuming and, perhaps, vexing challenge to SecOps is the process to get a new solution approved for network deployment. Adding security solutions to the network has the ability to introduce new points of failure, possibly limit scalability and potentially affect overall network performance and capacity. Keeping the network a “fine oiled machine” is critical for real-time business, and NetOps pays close attention to anything that could undermine its high-performance operation.

One problem endemic to the vetting of a new network security solution is the lack of clearly established requirements, specifications or even approvals for network solutions. Many times, the wheel gets invented nearly every time in terms of what gets evaluated and the criteria for approval. While obviously reducing the agility of security teams to deploy solutions geared to the latest threats or newest breakthroughs, the process also is time and resource consuming for NetOps. Establishing and maintaining principles for deployments, specifications and processes for review and approval and clear overall procedures and approval chains could help streamline this problem.

In addition, the use of new networking technology can help establish a flexible deployment hub for governing new solutions to protect network performance, scalability and availability. Such a feature helps to reduce a great deal of concerns, since the deployment hub can essentially vouch for the new hardware or software solutions and prevent them from adversely affecting the network. Part of the issue behind traditionally extensive review and approval processes for new network deployments is one of fear and trust. This needs to be met with specifically articulated standards and requirements, and it can be helped with a policy- and logic-driven deployment hub.

A second challenge with network tool sprawl is a limitation of physical resources. Most organizations have limited network SPAN or TAP capacity on switches located in the appropriate part of the network. In addition, there is generally a lack of rack space to host additional hardware solutions needing access to network traffic. Cabling and correctly matching interfaces and speeds is another issue to contend with. A good solution to this problem is two-fold. First, use of tool chaining should enable a nearly unlimited number of solutions access to network traffic. Of course, this exacerbates problems brought by tool sprawl. Second, an ability to virtually host multiple software solutions on a single hardware platform addresses the problem of limited rack space. Third, flexibility to accommodate different network and component speeds and interfaces makes physical connections far less complex and time-consuming.

So then there is the issue endemic to tool sprawl: complexity and potential chaos. One problem to address is the operational flow of traffic processing or inspection. Another is conditional logic that creates a bypass, shutdown or alternative approach is a solution becomes unavailable for any reason. For instance, if a firewall fails, how should traffic be treated? If protection or monitoring of data center traffic fails, what should happen? Should an in-line solution fail open or closed, or can some kind of failover be employed? If failover is used, what should happen with existing connections? Is maintaining state essential? These are all important questions to consider, and organizations should establish the detailed requirements and policies for them. In addition, technology needs to help ensure that policies and logic are maintained as new solutions are deployed.

Tool sprawl has traditionally had a negative connotation for good reason, and, certainly, has been responsible for real problems, but with the proper planning and established guidelines it does not have to be necessarily taxing. Technology that can help uphold these specifications can greatly reduce the work in both the review and operation of new solutions. The goal is to produce a win-win for NetOps and SecOps: ease, flexibility and agility of deploying important new solutions, greater certainty and assurance of protecting network performance, availability and scale. Now, both can be achieved.