Setting The Standard

Next week is my favorite week of the year. It's the Sales Operations meetings held at our headquarters in Austin. Each year we bring the sales people and sales engineers together to review the previous year and preview the year moving forward. More importantly I get to show off.

2009, from all facets, was an incredible year here at BreakingPoint. Sales had an amazing year, with huge growth. Our employee base grew by nearly 30%, much of that being our heavy investment in the security group. We put out 3 major releases and 3 minor releases of our firmware for the BreakingPoint Elite. And our application protocol list now tops more than 100 and our strikes are over 4,300.

This news is certainly exciting, but that was last year. And this is a completely new year and we are ramping up in engineering like you could not imagine. The next firmware release will once again improve the performance of everything from our application protocols, security engine and our SSL. And, of course this is all done without having to replace your blades and at no extra cost. Bet your other vendors don't say that every year.

Next month I'll be putting together a screencast showing you all the features in our next release. I'll save all the juicy bits for then, but here is a teaser of what to expect:

• Five new test labs, including huge strides for mobile networks.
• Changes in the way we are using the NetLogic network processor.
• Switch from using our network processor cores to do SSL, to leveraging the encryption engine on the chip itself (the impact this has on our number of handshakes is staggering).

Last year we changed the way people test their network equipment, this year we will set the standard.

Reminds me of when I worked at Cisco many years ago and Kevin Kennedy (Vice President) would show a slide in which Cisco was compared to other similar companies. There must have been 30 companies listed and at the time 3Com was below us, Lucent ahead of us and all the way at the top were companies like HP. At the time HP was 10x the size of Cisco. Today, Cisco is tens of billions of dollars ahead of HP, with a third of the employees. 

Every year that presentation showed Cisco passing yet another company. We have the same chart for our industry and the same goals, and some companies were ahead of us at the beginning of 2009. During 2009 we passed four of them and this year we will pass four more. And one day, like Cisco, we'll be at the top of everyone else's list.

NOTE: Sometimes Cisco didn't pass a company, the company fell. I'm seeing a lot of that lately, maybe I should send some flowers.

Application Protocol Fuzzing

Application protocol fuzzing resources

2009 Blog Rewind: Protocol Reverse Engineering

As we take a look back at 2009 our next two posts were read tens of thousands of times, both talking about protocol reverse engineering. The first post, written by Dustin D. Trammell, took a look at "Automated Protocol Reverse Engineering":

In my research into this discipline I have come across a number of techniques for automating the task of protocol reverse engineering. No one solution offers a 'silver bullet' that magically produces a protocol specification of an unknown protocol, but various automated techniques combined with manual processes can come rather close to this lofty goal if employed against a large data set of protocol traffic and with an appropriate amount of pre-processing of that data set.

Read the full post on Automated Protocol Reverse Engineering.

Following up on Dustin's post, Tod Beardsley wrote about Manual Protocol Reverse Engineering just a week later:

Accurate, rapid analysis of proprietary binary protocols is pretty hard, requiring a familiarity in usual socket programming practices, a determined patience, and a whole lot of note-taking. Closed binary protocols are rarely as simple as ICMP ping, they often have no real documentation, and the people who do know how they work usually keep their mouths shut.

Read the full post on Manual Protocol Reverse Engineering.

Realistic Testing of Server Load Balancers

Realistic server load balancer testing is now critical, as load balancers have become a key network device. Lack of proper testing has unfortunately resulted in serious performance and security issues. One primary example would be the recent problems for Google's Gmail. Testing load balancers means hitting them with realistic and actual network scenarios, rather than the "ideal scenario", in order to assure their resiliency. BreakingPoint has published an updated Server Load Balancer Test Methodology and I took this opportunity to sit down with BreakingPoint CTO Dennis Cox to talk server load balancer testing.

You can download the BreakingPoint Server Load Balancer Test Methodology, which includes multiple test scenarios including:

• Testing the number of TCP connections per second the load balancer is able to handle to provide a baseline test of the device’s performance capabilities.
• Determining the overall bandwidth the load balancer can support through testing the number of HTTP/HTTPs connections per second the device can handle.
• Emulating blended application traffic to validate the load balancer can handle a true network scenario.
• Simulating dynamic pages and image files to validate HTTP Caching performance.
• Confirming the load balancer can handle malformed packets or errors with the packet through application fuzzing.
• And more...

How To Test IPS Devices: Updated IPS Testing Methodology Published

Today we released an update to our IPS testing methodology, significantly enhancing the document with more test scenarios and pages of step-by-step tips. You can download the BreakingPoint IPS Test Methodology here.

Security threats, as you all know, have become so complex and numerous that organizations often are having difficulty figuring out which threats are the most dangerous. Resiliency testing of networks and security devices, such as an IPS, with "realistic Internet-scale traffic" is the first step in securing organizations. Being realistic in your testing means using live security strikes, blended application traffic, maximum load and even throwing in unforseen scenarios.

Let's face it, if your IPS fails to work properly, even letting a single flow of malicious traffic pass, you are dealing with viruses, worms and backdoor attacks that can gain access to the corporate network and cause a great deal of problems, potentially bringing down the network.

The IPS test methodology is meant to help determine the IPS’ actual capabilities under real-world conditions. For instance, the IPS device might be able to detect and mitigate malicious activity under light network traffic load. However, when network traffic becomes heavy, the IPS device might detect significantly less malicious activity. These types of tests fill up this methodology.

Sufficient testing must be preformed to fully characterize the impact different scenarios will have on the IPS. Realism is key.

To give you an idea of what you'll find in the methodology here is the table of contents:

1. Introduction
2. Baseline Application Performance: Maximum Connections
3. Baseline Application Performance: Throughput
4. Baseline Attack Mitigation: SYN Flood
5. Baseline Attack Mitigation: Malicious Traffic
6. Application Traffic with SYN Flood
7. Application Traffic with Malicious Traffic
8. Application Traffic with Malicious Traffic and SYN Flood
9. Jumbo Frames 88 IP, UDP and TCP Fuzzing
10. Protocol Fuzzing
11. Evasion Techniques
12. Negative Testing