Synopsys Defensics Reviews

Codenomicon is a good tool. It is used for network protocol implementation testing, to find any Zero-day issues, vulnerabilities in XSL. It's an excellent tool that has its advantages and its limitations.

In our company, we have a lot of applications. A lot of protocols are used between embedded devices which are never tested for any abnormal behaviors. We have found multiple issues in our embedded system network protocols, related to buffer overflow. We have reduced some of these issues.

This collection of storage-related components were most valuable in extending a security assurance program into the area of black-box security testing for a NAS appliance.

A security assurance engineer was able to perform due diligence across all network-facing protocols.

My prior organization designed, developed and deployed a Network Attached Storage (NAS) appliance. A key part of the company wide security assurance program for all products, is to perform penetration testing against all network facing IP ports.

For the web, SSL and RESTful APIs, there are very good COTS and open source tools to perform Dynamic Application Security Testing (DAST) testing. Unfortunately for NAS protocols like SMB, NFS, CIFS, and iSCSI, I researched and found that Codenomicon Defensics was the only viable source to satisfy our DAST requirements.

Through the use of Selenium for automated web testing, it was easily found out that Codenomicon Defensics could be integrated into our Continuous Integration / Continuous Deployment (CI / CD) Agile processes, specific to automated testing.

Also, like many of the other application security testing products, Defensics incorporates automatic update support and works on Windows, MacOS and Linux desktops.

Presently we are using Codenomicon Defensics for a few suites, only for testing. we are doing few open floor tests. Nexus is the one which we will use for European testing. For US usage testing, we will use Codenomicon.

It tests for switches and router sections. We use it for product testing. We will get the license and then bring it back to the IT team.

• Test cases are not generated on the fly (which means that it isn't really fuzzing per se). They are organized in groups and defined according to the type of message and the tested part of the message. Compared to more random tools, fuzzing sessions can take less time and be more relevant.
• Simple and straightforward GUI.
• Context-sensitive helps in describing every configuration field along with their CLI equivalent.
• You can set a test sequence and thus test several protocols without any user interaction, and it can be sequential or in parallel.
• Interoperability feature which enables the user to ensure that the SUT supports the various types of tested protocols' messages. If a type of message failed the interoperability test, it won't be included in the fuzzing session, unless you want them to be included.
• Instrumentation capabilities (valid cases, ping, custom command) and actions (execution of a restart script of a device after a given number of failed instrumentation steps) upon instrumentation results.
• Reproduction of single test cases or along with the rest of the test case group.
• Network capture during fuzzing session as well as during the reproduction.
• Top 100 of the test cases which caused an important delay on the SUT response. Those cases are reproducible in order to check that the same test cases caused the unwanted behavior. This is useful for covering not well processed frames that don't necessarily make the SUT crash.
• Different sets to use depending on the available time and the coverage wanted (Full, Unlimited, Quick Run, Sample, etc.).
• We can create custom test cases by setting a value or a range of values on particular fields of a protocol.

• You can't implement proprietary ciphering algorithms, nor can you modify protocol models if you need to test customized public protocols.
• You can't use the program at all without the USB license dongle. This would be useful for instance to export results, prepare the wizard, and so on. It can be inconvenient if several teams use the license.
• Time estimation: order of magnitude is not always respected.
• To test ARP on the client side, you have to clear the MAC table of the SUT. A feature such as sending ping requests to the SUT with a different virtual IP/MAC address each time to force the client to send ARP request would be great.
• No automatic bug reproduction (as Peach has for example).
• You can't create a protocol model from scratch using the GUI. You can use the traffic capture fuzzer, import a PCAP file and generate tests cases from it. Known protocols are described according to a wireshark dissector, proprietary protocols have to be defined manually (by defining a label on a part of the data). It seems that we can go further with the Java SDK, but we didn't have enough time to test it.
• When using the GUI, you can't run fuzzing sessions both sequentially and in parallel at the same time, for instance for testing different protocols on different devices. One possible workaround is to use the CLI of Defensics and to use different configuration folders.
• When you choose the network interface to use, there is an «auto-configuration» box ticked by default. It means that Defensics will try to guess the interface you will use, but it often lead to mistakes.