Garett Montgomery, Sr. Security Research Engineer at Ixia
Sr. Security Research Engineer at Ixia
Blog

BreakingPoint Strike Lists: A New Default for Better Cybersecurity Testing

July 22, 2020 by Garett Montgomery

With the Application and Threat Intelligence (ATI) strikepack release of 2019 (ATI-2019-24), astute readers might have noticed the inclusion of two new smart strike lists: Consumer Application Strikes and Business Application Strikes. And while the release notes may have provided information as to what they are, I’d like to take a few minutes now to provide some additional context that might further illustrate the potential benefits of the new lists.

But first I’d like to provide some background information and clarify the usage guidance about a strike list called Security All Strikes that has been around for a long time. Since well before I started working with BreakingPoint back in 2012, the Security All Strikes list has served as a convenient means of testing security device efficacy by running the full catalog (8,600+) of BreakingPoint strikes through a device under test (DUT). 

In the past, a strike used to be synonymous with ‘a network-based exploit targeting a vulnerability‘. But over the years, as BreakingPoint evolved to keep pace with the changing security landscape, new features have been added and new kinds of strikes included, with the overarching goal of providing example traffic to serve as means of testing a network-security device.
  
With these changes, so too has the term ‘strike’ expanded and evolved. Today, a strike might refer to an executable file being transferred via HTTP, a telnet command to port 25, a TCP packet with some infrequently-used options set, a sequence of similar HTTP requests with only a single parameter changed for each, as well as the more-familiar SMTP EHLO message containing 4096 alphanumeric characters without a newline. While one is almost certainly malicious in nature, and the others could be used for malicious purposes, you wouldn’t necessarily want your security device blocking all them, all the time. The important takeaway here is: context is of paramount importance. Just because it’s a strike, doesn’t mean it’s always, regardless of the context, bad, nor should it always be blocked.  

To that end, with ATI-2020-02 we’ve updated the description of the Security All Strikes list to – hopefully – more clearly articulate its intended purpose: to serve as a convenient means of running ALL the strikes. The new description is as follows: “Run the entire suite of strikes against a DUT (excluding those performing protocol fuzzing and analysis or transferring malware). Running this set of strikes through a DUT can take many hours to complete, and provides only a simplified, out-of-context analysis of the detection-rate of a DUT (not all strikes should always be blocked).”

Does this mean Security All Strikes isn’t a good strike list to use for comparing security-device detection rates? Maybe, maybe not - it depends on context. (But probably not, since our recommendation is to always have relevant criteria for building the strike list, representative for each particular production environment).

  • If you are using the list in conjunction with the Strike Variants evasion profile to enumerate all possible variations of all strikes in order to monitor for changes in detection rates (as a form of regression testing, or comparison to a previously established baseline), Security All Strikes could be an appropriate choice
  • If, on the other hand, you are looking for something out-of-the box that can provide a wide assortment of relevant attacks to simplify the comparison process, Security All Strikes is unlikely to be the right choice. You’ll find that far more time is spent analyzing the results to determine if a blocked/unblocked strike should or should not have been blocked (depending on the context) – and vice-versa – than is saved by choosing the list with the most strikes.

Below is the newly updated description of the strike list, as can be seen in ATI-2020-02


1

So, if Security All Strikes isn’t the ‘best’ list to use, which one is?

While the ‘best’ list of strikes to run will always be dependent on the criteria used to define ‘best’, (most-relevant, fewest false-positives, fewest false-negative, etc.), there are times where neither the required time nor operating environment details are available to create the ‘best’ list, but you still want a ‘meaningful’ list of strikes to use for testing. This is where ‘canned’ strike lists come into play – strike lists included within each ATI Strikepack representing a filtered selection of strikes. These lists can – and should – serve as a starting-point for creating lists of strikes tailored to the security-device features they are designed to test.

Some examples of these canned strike lists include: 

  • Strike Level 1 – 2019 – Strikes targeting vulnerabilities disclosed in 2019, with CVSS scores of 10.0.
  • Microsoft Tuesday (by year) – 2013. Strike targeting vulnerabilities in Microsoft products that had patches released in 2013.
  • Public PoC Strikes. Strikes targeting vulnerabilities for which there is a publicly-available proof-of-concept exploit. 

Rather than representing any ‘official’ categorization or grouping of strikes, these lists are intended to demonstrate some of the ways that related strikes can be grouped, in order to construct meaningful, relevant strike lists.  

With that (possibly overly-long) description of one of our older strike lists setting the stage, I’ll now return to the opening of this blog-post: to provide some additional insight into the two recently released, complimentary strike lists Consumer Application Strikes and Business Application Strikes

Consumer Application Strikes is a collection of strikes containing the ‘consumer’ keyword. The ‘consumer’ keyword has been added so far to 43 strikes targeting applications like Magic Music Editor or World of Warcraft – applications that aren’t typically found on business networks.

  • The primary use-case is the exclusion from testing those strikes that target vulnerabilities in applications that are not relevant for the majority of corporate networks
    • After all, when comparing security devices, should equal weight be given to blocking an exploit targeting Zortam Media Studio and blocking an exploit targeting the e-commerce platform your business relies on?

2

Business Application Strikes is intended to be the inverse of Consumer Application Strikes – a list of strikes targeting the most-frequently seen applications that are found on a majority of corporate networks. 

  • In addition to excluding strikes containing the ‘consumer’ keyword, strikes within the following directories are also excluded: analysis, botnets, fuzzers, generic, recon, malware, and shellcode
    • The primary use-case is to provide a default ‘suggested’ list of strikes that will  have only definite attacks, and as such should always be blocked, all of the time (this makes it a much more suitable choice as a default, or go-to strike list, than Security All Strikes for high-level comparison of network security devices, without bothering about context).

3

At the ATI Research Center, we are always looking to improve the quality of the delivered content, hence it is important to go back and revisit the relevance of old resources. By curating the canned resources and making recommendations, we can make sure customers have relevant and up-to-date information on how to best use our products.

LEVERAGE SUBSCRIPTION SERVICE TO STAY AHEAD OF ATTACKS 

Ixia's Application and Threat Intelligence (ATI) Subscription provides daily malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Ixia test platforms. The ATI Research Center continuously monitors threats as they appear in the wild. Through the ATI subscription, BreakingPoint customers now have access to Attack Campaigns for different advanced persistent threats, allowing them to test the ability of their currently deployed security controls to detect or block such attacks.