Network security and performance are important aspects of design that are closely related. When designing a network, the security is a critical portion. Modern network security is achieved thru many different components that cover detection, prevention, and reacting to an incident. Network operators also need to ensure that these security features have a minimum impact on performance as that will affect the overall user experience.
When evaluating components of a network such as firewalls, switches, access points, and servers, it’s important to understand the test methodology of security and performance of the components to fully understand the results they provide. Test methods need to ensure consistent results that cover all the security cases. It’s important to run performance testing with security features enabled to understand the realistic performance number. If you test performance with no security, you will find the results are typically much better than if the security features are enabled. Network operators need to test that both security and performance of the network meet their users’ expectations.
To test the network, an operator could attempt to create test methods that verify all the security and performance requirements. They would need to identify all the security and performance metrics and then evaluate all the components in the network. This approach is inefficient as all the network operators would be creating same test methods for verifying the same exact security and performance metrics. Developing a standard test methodology allows operators to leverage existing tests allowing them to focus on creating unique test required for their users and networks.
When creating security metrics, it’s critical that test methodologies cover multiple scenarios to ensure that devices perform as expected in realistic environments. For security test methodologies, it may be necessary to randomize input parameters to ensure all use cases are covered, in order to detect devices that have tuned device performance to meet test case needs rather than those of real use cases. For example, when measuring if a firewall detects CVEs, it’s an important to run a realistic traffic mix over the firewall when sending the vulnerabilities to ensure the device still detects and blocks the attacks. If the test is just run with CVEs enabled, the firewall will easily detect the vulnerability but under different loads it may act differently. Network operators and users need access to the test methods to get the full understanding of what is tested and how it was tested.
A testing standard that is not open is when a test methodology exists, but the network component isn’t able to see them. In some cases, the testing is performed in an independent lab, in that case the network operator doesn’t have access to the test standard either. Network components can get results when testing a closed standard, but they can’t see how the testing is performed.
An open testing standard allows everyone to see what is tested and how it’s tested. There are several benefits including wider audience for review, feedback, and knowledge share. If everyone can see the open standard, they can review if it meets requirements, but in the case of security testing, it’s important to detect potential flaws in the test methodology and address them. Feedback into the test methods is part of the continual improvement needed for a successful security testing as the use cases are changing at a rapid pace. With the rapid changes in security testing, it’s important to get feedback with as many people as possible that might include researchers, labs, and users. This type of knowledge share and review makes the open standard better.
Earlier in the article, we discussed the evaluating of network components such as firewalls. It’s also important when comparing security results to have transparency into the testing methodologies which helps users with these comparisons. In the case of firewalls, users want to compare the performance of a firewall inspecting HTTPs connections. If an operator is trying to verify a set of results without an open standard, they might use a different encryption algorithm that was used by the network component. This leads to confusion between the network component, a firewall in this case, and the network operator. If the standard was open, both sides could see and understand how the results were created.
Industry forums, standard bodies, and test programs need to continue to create more open security testing standards. Open standards help security network developers meet requirements while providing visibility into the testing process and results. Comparing results only works when there is an agreed-upon methodology which are useful for network operators to determine how to deploy functions into a network in a secure way.
About the author: Timothy Winters is a Senior Executive, Software and IP Networking, at the University of New Hampshire InterOperability Laboratory (UNH-IOL).
