Vulnerability, Let Me Count the Ways to Exploit Thee
Have you ever looked at a vulnerability and thought about all the different ways that an attacker might be able to exploit it? Here at Ixia BreakingPoint, that's something we do every day. And we take pride in crafting strikes that enumerate the different forms an exploit for a vulnerability can take. We call them exploit variations, or StrikeVariants. And when you run a Strike through a testing device, you never know which variant you're going to get. That's the realism provided by Ixia BreakingPoint—you don't know ahead of time how an attacker might try to exploit a vulnerability, so you've got to protect against all the variations.
So how do you know you're protected against all the variations in a Strike? How do you know how well your network protection device covers your network against a particular vulnerability? Previously, you had to run a strike repeatedly and hope that eventually you'd exhaust all the variations. That scenario is probably acceptable in most cases—but there are some strikes with well over 100,000 variations, and randomly selecting each of the different code-path combinations that comprise all the different StrikeVariants could take a very, very long time. And even then, you'd really have no way of knowing that you'd seen all the different variations.
If you have these concerns, the StrikeVariants Evasion Profile group should come as a welcome feature update. With the 3.4 release, you can now enumerate, in a repeatable fashion, all the different variations of a strike. Within a strike there are often multiple choices or code paths that are randomly selected, that together generate the payload seen on the wire.* There are several different options available in the StrikeVariants Evasion Profile group, that enable two primary testing scenarios: testing all variations of a strike, and specifying only specific variations of strike.
The first testing scenario is for those who want to measure the effectiveness of a network protection device. Choose one or more strikes for a strike list and select StrikeVariants AllVariants Evasion Profile. With this configuration, for each strike all possible variations—or StrikeVariants—will be enumerated for a test. Using this evasion profile, you can see just how well you are covered against a particular vulnerability. The Shuffle option will randomly select which StrikeVariants are chosen. The results of this testing scenario can be used to inform the second testing scenario.
The second testing scenario allows for testing only specific StrikeVariants. For example, if a strike in the first testing scenario has 100 StrikeVariants, and your network protection device blocked 97 of them, you may only want to re-test those that were missed. If the missed StrikeVariants were numbered 8, 22, and 77, by setting Variations TestType to Subset, and entering '8,22,77' in the text box, you could replay just StrikeVariants 8, 22, and 77.
The StrikeVariant number can also be used when discussing a particular strike with the Ixia BreakingPoint Support Team. By specifying a StrikeVariant number and the seed value used in the test, the exact same payload can be generated from any other 3.4 system. This enables Ixia BreakingPoint developers to quickly recreate and verify any issues for a given strike.
Some strikes have many thousands of variants—and because StrikeVarians are generated at runtime, test initialization and run times can increase significantly. By choosing TestType Limit, and entering a numerical value, the number of StrikeVariants for each strike in a strike list will be equal to or less than the Limit value. In cases where Limit is not used, if a strike is more than the maximum number of allowed StrikeVariants, a random selection of StrikeVariants will be chosen. The maximum number of StrikeVariants is currently capped at 20,000 per strike, and 100,000 total per test.
We hope you find this feature useful and look forward hearing from you about how you are using it.
* NOTE: StrikeVariants represent unique code paths and functions used to generate strike payloads—they do not represent all possible values generated by those code paths and functions. Using a seed value is the only way to ensure the exact same payload will be generated each time a StrikeVariant is run.