To Fix System Bugs, Wurldtech Gets Fuzzy Wid It
The list of people who enjoy finding bugs more than Dr. Nate Kube isnāt very long. His companyās customers might be at the top of that short list. āWhen vendors or manufacturers use our stuff to find bugs, theyāre just bugs,ā explained the co-founder and CTO of Wurldtech Security Technologies. āWhen those bugs are found in the field, theyāre security issues.ā
āIn a house, if you know where the doors and windows are, you have a better chance at securing it,ā said Wurldtech CTO Nate Kube, in explaining the need for vulnerability testing during system development.
Kube explained some of his companyās techniques for detecting software faults and failures at the 2008 Yokogawa Technology Fair and Users Conference this week in Houston.
āAnything can be hacked,ā said Kube. āThere need to be layers of protection to everything. People, quality and devices are all components to security. At the end of the day, donāt get comfortable just because you have antivirus protection.ā
Kube oversees development of security technologies for SCADA and process control domains at Wurldtech, and he explained that the best way to find potential problems is to figure out where they might enter. āWhen you determine the vulnerability profile, you have a better idea of how to protect it,ā he said. āIn a house, if you know where the doors and windows are, you have a better chance at securing it.ā
Kube divides software bugs into two categoriesāfaults and failures. A fault is a static defect in source code, while incorrect system behavior or output is a failure. He recommends two complementary approaches to verification. Source code review uses manual analysis to find faults, and testing uses program execution to find failures.
Observabilityāthe ease with which outputs from the device under test (DUT) may be observedāand controllabilityāthe ease with which inputs may be supplied to the DUTāinfluence test automation.
Fuzzing, or fuzz testing, is a type of security testing that provides data, or fuzz, to program inputs so that defects can be noted if the program fails. āItās like sending negative packets,ā explained Kube. āIP or TCP is a language. You can send invalid statements in the language. Itās a way to send invalid traffic.ā When issues are discovered, theyāre system implementation issues, not usually design issues, he said.
āWhen weāre testing an implementation, the more information we can get from the device, the more tests we can send,ā said Kube.
Fuzzing can be done during software development by in-house test teams, QA teams or the developers. Results can be handled as bugs. But when fuzzing is done by organizations to verify their networks, it can result in found issues that require fixing by the organization and may need to be reported publicly or discreetly.
Since its formal designation in 1990 by Barton Miller at University of Wisconsin-Madison, fuzzing has come a long way. Originally, fuzzing wasnāt concerned with the state, message structure or oracles, and the only repeatable part was the random seed used to start random sequences. Thirty-two-bit messages were the limit.Ā Advanced fuzzing can understand protocol structure, has simple rule libraries and offers some support for multi-message or stateful protocols. Kube says real hard-core fuzzers use a high degree of controllability and observability, understand protocol semantics and states, and use an extensive rule library, as well as feedback mechanisms to optimize test design.