How to speed up security tool evaluation and deployment

With the rise in both the volume and variety of cyber threats, it seems there are now specialized tools for almost everything.

This was never more obvious than at the latest RSA Conference, where there were more than 800 exhibitors — almost 200 of which were first-time sponsors. 

The upsurge in vendors has translated into an explosion in the number of security tools that businesses have deployed, creating security sprawl, as Tom Clavel, senior manager of product marketing at Gigamon, wrote in a recent blog post.

The ZK Research 2017 Security Survey confirmed this. It found that businesses have an average of 32 security vendors deployed. It’s important to understand that 32 is the average across all companies, with enterprises often having hundreds. Unfortunately, security sprawl is a very real thing and has become the new norm for security professionals.

This begs the question: How do security teams change how they operate so they can quickly evaluate new tools and deploy the ones that benefit them? One of the biggest improvements organizations can make for security operations is to find a faster, more consistent and more accurate way of doing proofs of concept (PoCs). This will enable the organization to evaluate more tools faster and will instill greater confidence in the results.

Evaluating security tools is a difficult process

Evaluating security tools is complex process and can often take weeks or even months to complete. Testing security tools in a lab isn’t as thorough as doing so in a live environment. In a lab, it’s easy to perform a load test on a security tool. For example, a security team could push one gigabyte of traffic through a firewall to see how it performs. What can’t be tested is the device’s effectiveness in catching live malicious traffic.

In theory, live data could be captured and then replayed into the security tool. Then, the same data could be streamed to other tools being evaluated, with the results compared to gauge each tool’s effectiveness. However, this process can be time-consuming and isn’t perfect because the security team is working with a limited set of data. It’s possible to plug the security device into the span (mirror) port on a network device, but typically only a couple of these are available, making it difficult to test multiple tools at once.

Putting the security tool into a live environment would be much more effective, but doing so obviously involves a higher level of risk. If the tool misses something, the company will be breached.

Additionally, if the plan is to evaluate tools from multiple vendors, the security team will need to interrupt operations multiple times — stopping the data flow, inserting the tool and then starting operations up each time a new tool is tested. This causes a significant amount of business disruption and risk, so the security team may choose to test new tools or vendors after hours or in very specific timeframes, lengthening the process even more.

Furthermore, live tests happen concurrently, not simultaneously, so the results will lack comparable data points. Each test uses different traffic — and different threats will be detected, prevented or missed — without knowing how another tool would have reacted to the same traffic. These live tests lack the traffic consistency that is required to instill confidence in the security tools being tested.

Security delivery platforms simplify proof of concepts  

A better approach is to use a security delivery platform (SDP) to make PoCs almost plug and play. For those not familiar with SDPs, they can be thought of as network packet brokers with specific functionality designed for security.

From a design perspective, the network team would insert the SDP into the network or plug the SDP into the span port on the network device to be protected by the security tools. The SDP vendor typically provides test access points (TAPs) so that issues with span ports such as dropped packets are eliminated. All the live network data is then replicated by the SDP, and the network operations team can allocate an appropriate number of ports to the security team (just a few ports up to an entire chassis).

The security team could then plug any number of security devices into the SDP and test them all simultaneously using the same live data, creating a true “apples to apples” comparison. This results in all the tools being tested on the exact same traffic, bringing consistency to the process, significantly reducing the amount of time it takes to test these tools, and even increasing the number of tools that can be tested at the same time.

Whether the network operations team would own a unique SDP, to simplify the process of deploying network management tools, or the security team would keep a separate SDP, the benefit is the same: Security teams can run PoCs on new tools quickly because they can be attached to the SDP, causing zero disruption to the business.

The number of entry points into systems continues to grow, as does the sophistication of malware. This isn’t likely to change any time soon. At the same time, the industry is likely to see the development of specialized tools continue to expand. It’s in every security team’s best interest to figure out how to conduct PoCs on new tools faster so they can be deployed faster to protect the business. SDPs can make the entire testing process significantly faster and more accurate, and they should be considered an important component of a modern security architecture.