Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

5/13/2019
10:30 AM
Timothy Winters
Timothy Winters
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
50%
50%

How Open Testing Standards Can Improve Security

When creating security metrics, it's critical that test methodologies cover multiple scenarios to ensure that devices perform as expected in all environments.

Networks are a complex collection of components defined by many different standards. These standards help solve network problems ranging from security to performance and usability.

An open standard is a publicly available standard that can be consumed in a variety of ways for deploying a secure solution for a network. Readers of open security standards use them to understand how a technology might be useful to solve security on the network. Implementers of open standards can create solutions to address documented security issues. Network operators read standards to understand how the different implementations work together to make a complete security solution.

These network solutions often come from different sources, which leads to the creation of a variety of testing procedures and methodologies to ensure that network components support all the security and performance requirements of the network users. Since the majority of standards are also open, it would make sense that the methods for testing are also open. But often this isn't the case, and I think it should be.

The Case for Open Security Testing Standards
The argument I often hear against open testing standards is because network component engineers can see the test and create a solution based on the known criteria. This, to use a grade school analogy, seems like cheating since the test questions are known in advance, making it possible for a network operator to engineer their products to pass the test. If the tests have full coverage for the security features that a network operator wants, then it doesn't matter if they know what is being tested. The outcome of the testing will be a network component that shows compliance to the full coverage of test cases. By creating an open testing environment, network component engineers can build a solution that will meet the network operators' requirements.

When creating security metrics, it's critical that test methodologies cover multiple scenarios to ensure that devices perform as expected in all environments. For security test methodologies, it may be necessary to randomize input parameters to cover all use cases in order to detect devices that have tuned device performance to meet test case needs rather than the needs of real use cases. For example, when measuring if a firewall detects CVEs, it's important to run a traffic mix with vulnerabilities to ensure the device detects and blocks attacks under a variety of conditions.

Another advantage of open testing standards is that they give users and network operators the ability to see what security testing is performed and how testing is performed. Knowing what security test cases are being performed allows the operator to confirm that the test meets specific requirements. If not, they can add additional tests.

Creating a Feedback Loop
If there is an organization responsible for maintaining the standard, operators can feed that information back to cover missing areas so that in the future the network operator won't have to run additional testing. Knowing how network components are tested also lets network operators and users better understand the meaning of results because results alone often don't give enough context about the testing conditions of the network component. For example, it's important to understand if a device passes security tests when there is no load but doesn't detect attacks when it's under load.

It's also important to compare security results from different networking providers as a means of increasing transparency into testing methodologies, which also leads to better decision-making processes. In other words, open testing standards provide an "apples to apples" comparison opportunity. In security performance testing, for example, the results of a bandwidth test on a firewall can change greatly based on the security features that are enabled. If no open standard exists to specify that information, a user might be looking at results for two different implementations and not understand that the results differ depending on what features are enabled.

Implementers of security standards are aided by having open testing standards offering better visibility into what network operators are interested in validating. Network operators are aided by open standards testing to allow them to achieve comparisons that make network decisions easier.

Related Content:

 

 

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Timothy Winters is a senior manager at the University of New Hampshire InterOperability Laboratory (UNH-IOL). He works with companies from all over the world to develop broad-based, flexible testing strategies to cost-effectively meet network interoperability ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: It is too bad the ceiling is made of glass!
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3686
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
CVE-2019-3683
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
CVE-2019-3682
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
CVE-2019-17361
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.
CVE-2019-19142
PUBLISHED: 2020-01-17
Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.