The wizards quickly show their limitations, though they do serve the highly useful purpose of introducing the user to the application's components. Without this sort of guide, you'd be left to muddle through the complex interface, a frustrating and potentially fruitless experience.
Protocol Modeler's Network Recorder provides a more focused testing method. Hit the record button, then prompt the application under test to execute the network transaction you'd like to investigate. It can be a well-known standards-based application, such as SMTP or IMAP, in which case the packets will be decoded into proper fields. Or, it can be a proprietary application, where the captured traffic will not have an automatically overlaid format. In this case, the user must scroll through the transactions and attempt to decipher what's happening. Finally, it could be a Web application, in which case Protocol Modeler provides additional support for investigating HTTP-based vulnerabilities as well as a browser interface for walking through an application and gathering data for the recorder. Once data is captured, it can be viewed, manipulated, loaded up with fault injectors and played back to test for vulnerabilities.
One of Protocol Modeler's most powerful features is its variety of fault injectors, which can be dragged into the desired components of a transaction and are critical to the program's process. For example, in a Web application providing user input that appears to be fed to a back-end database query, attempting a SQL Disclosure fault injector would be a good choice. After you hit play, the transaction plays back repeatedly using different permutations in an attempt to fool the Web server into passing SQL commands to the back-end database server directly. Protocol Modeler watches for the application to "fail" in this manner. Continuing with this example, if it sees an apparent SQL error coming back on the HTTP return, Protocol Modeler notes this and reports it to the user.
Protocol Modeler uses several strategies to monitor for faults and signs of vulnerabilities. One, previously noted, is to watch for typical return values of a fault; another compares normal return data, as from a normal-size input, to deviant return data, as from a successful buffer overflow applied to the same input.
The fault injectors can be applied in two ways. You can drop one directly into a job, and Protocol Modeler will calculate all the appropriate places to apply it automatically. This blanket method often results in extremely long test times, depending on the fault injectors used. Alternatively, fault injectors can be applied to specific parts of a transaction, for example, an HTTP post field.
Bob Friday, Chief AI Officer for Juniper Networks, explains how the advanced technology is transforming operations.
Contact center leaders from 8x8, Awaken Intelligence, and 360insight discuss the importance of agent experience.
AI may force enterprises to rewire parts of their data centers so they are fully optimized to run such workloads. The question is do you use Ethernet or InfiniBand?
